Hacker News Reader

Comment by nilved | Hacker News Reader

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.

View on HN

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