Date: Thu, 3 May 2001 18:09:01 -0500 (EST)
From: Dan Knapp
(if (not (< x 3)) (assertion-failed '(< x 3)))
This is a good example, which cannot be implemented in Haskell. "Exception.assert" is built in to the ghc compiler, rather than being defined within the language. On the other hand, the built in function gives you the source file and line number rather than the literal expression; the macro can't do the former.
Yeah, it's a good example, but are there any other uses for such quoting?
There are a few. But this isn't the -only- reason to still use macros.
We could systematically go through all the macros I've written in the last
few years, and for each one we could figure out what language feature would
be needed in order to make that macro unnecessary. At the end of the
process you would have a larger programming language, but I still wouldn't be
convinced that we had covered all the cases.
A macro facility is like a pair of vise-grips (if you don't know what those
are, see http://www.technogulf.com/ht-vise.htm). You can do a lot of
things with a pair of vise-grips, although usually there's a better tool
for the job -- if you haven't got (say) a pipe-wrench, then a pair of
vise-grips can substitute. Now the more tools you have in your tool box,
the less often you will use your vise-grips. But no matter how bloated
your tool box becomes, you will still want to include a pair of vise-grips
for the unanticipated situation.
I have one problem with my own analogy: If you find yourself using your
vise-grips everyday for some task, you will probably soon go and purchase a
more appropriate tool. 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.
Date: Fri, 04 May 2001 12:57:29 +0200
From: Jerzy Karczmarczuk
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
Date: Mon, 7 May 2001 17:48:47 +0200 (CEST)
From: Michal Gajda
participants (2)
-
Alan Bawden -
Michal Gajda