On Fri, 4 May 2001, Alan Bawden wrote:
(...) But I think that in many circumstances macros do such a good job that I don't see the need to clutter up the language with the special-prupose features needed to replace them. (...)
I'm currently making fun by writing compiler from eager lambda calculus with hygienic macros to it's desugared form(when using parser combinators, I estimate 2k lines of ML code), so I take freedom to share my experiences. Working(simple and without typechecking, so only the syntactic correctness is checked) version expected at the end of the month. * Introduction of general hygienic macro's as you propose, forces us to cope with following problems: 1. Full typechecking of macros(in place of definition) seems to need second-rank polymorphism. (Decidable, but harder to implement) Of course you can delay typechecking until you expand all macros, but then error-messages become unreadable. [in Lisp it is non-issue] 2. Macros make the parsed grammar dynamic. Usually compiler has hard-coded parser generated by LALR parser generator(like Happy or Yacc) compiled in. Introducing each macro like you proposed would need(I think) generating new parser(at least for the fragment of the grammar). [In Lisp we just separate form with macro named head, and then apply macro's semantic function to macro's body at COMPILE TIME. So: a) the basic syntax is unchanged b) we need to evaluate expressions at compile-time] * On the other hand it yields following advantages: 1. Powerful enough to implement do-notation(for sure) and (probably) all or most other to-core Haskell translations. 2. Lifts (unsurprisingly) the need to use cpp preprocessor when handling compatibility issues. Hope it helps :-) [and feel free to mail me if you are interested] Michal Gajda korek@icm.edu.pl