Hacker News Reader

Comment by kccqzy | Hacker News Reader

Maybe this is heretical among Haskell lovers, but my personal, rather undeveloped, feeling is that Haskell syntax is too complicated for macros. Sure, Haskell code feels natural to read, but in fact they had a lot of "superficial complexity"[1], i.e. the syntax supports many ways of expressing the same thing. This makes any sorts of introspection at compile-time troublesome. Compile-time code generation is less of a problem but still it makes the experience less pleasant.

[1]: Hudak P., Hughes J., Peyton Jones, S., Wadler P. (2007). A History of Haskell: Being Lazy With Class.

View on HN

Many of the answers in the SO thread[0] linked from TFA agree with you: there are other means of abstraction in Haskell that "fit" with the language better, and they (and I) think those abstractions mostly obviate the need for Template Haskell.

[0]: https://stackoverflow.com/questions/10857030/whats-so-bad-ab...

Not at all! I like Haskell because it nails the two things that are most important to me: a good type system and the ability to restrict side effects. Constructive criticism of other parts of the language can only be a good thing.

That's not heretical, most Haskellers agree that macros are a misfeature because (a) they are only useful in homoiconic languages (b) they are only useful in strict languages (c) they interfere with type safety and code clarity.

Why would they only be useful in strict languages? You don't need a macro to write `unless` in Haskell, but you do to (say) automatically generate typeclass membership given a datatype, or autogenerate lenses, and that use is orthogonal to evaluation strategy.

I guess parent is just saying that macros allow programmer control of evaluation order, which you can't get otherwise in a strict language, but you can with laziness.

The point could have been worded better I think.

It's a misunderstanding that has unfortunately caught on among many Haskell programmers. People who say "macros are only useful in strict languages" mistakenly think that macros can only be used to delay evaluation. Of course, there are many more uses of macros, as you point out. Macros can define new binding forms, e.g., in Racket, pattern matching is a library, while it in Haskell it must be part of the core language. Macros are also useful for abstracting over non-first-class language forms like top-level definitions, import/export statements, and even type definitions.

Agreed. We're always trying to move Template Haskell code into new and more powerful type system features.

I admittedly have limited experience with macros, but I'd like to know more about why (c) is the case. It seems like, if you've got type inference at compile time or even before compile time, then it should be feasible to type check the macros.

It is a bit difficult to have static type checking, type inference, and dynamic code generation all working together seamlessly. If you have a macro expansion whose types are entirely inferred, then naturally they should check properly, even if they are inferred improperly.

The larger the macro, the more cryptic the errors are as well, since you could conceivably be generating entire functions whose output and input types are inferred based on very distant macro input and context, and such a type error is going to be very confusing to your users. C++ has this problem: simple errors can dump a dozen screens of template garbage on you.

Can't you solve problem (a) with quasiquoting?

Reply on news.ycombinator.com