4 ms·
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 st
by nilved 10y ago
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.
- LukeHoersten 10y agoAgreed. We're always trying to move Template Haskell code into new and more powerful type system features.
- ufo 10y agoCan't you solve problem (a) with quasiquoting?
- kenko 10y agoWhy 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.
- jwhite 10y agoI 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.
- stchang 10y agoIt'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.
- bunderbunder 10y agoI 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.
- Retra 10y agoIt 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.