Explanation of macros; Haskell macros
joachim.durchholz at web.de
Sat Nov 1 12:14:41 CET 2003
Peter Seibel wrote:
> Joachim Durchholz <joachim.durchholz at web.de> writes:
>>And, of course, macros can evaluate at compile time. Personally, I'd
>>prefer to do compile-time evaluation based on "the compiler will
>>evaluate all known-to-be-constant expressions". The advantage here
>>is that programmers don't need to learn another sublanguage for
> Ah, but in Lisp we don't have to. We use Lisp.
Having readers and special forms /is/ an extra sublanguage. I don't have
to learn extra syntax for these forms (which is good), but I do have to
learn about a lot of special rules that apply to macros and nothing else
(which is not so good).
Letting the compiler evaluate what it can means that I don't even have
to learn extra forms.
Actually, that's one of the reasons that keeps my from trying out a
modern Lisp: I'd have to learn all these extra forms, and I've got a
feeling that macrology à la Lisp is oversophisticated for something as
simple as compile-time evaluation.
I'm pretty sure that macros solve more problems than just compile-time
evaluation. I just suspect that better solutions are available in every
case, and I not just suspect but know that macros have some very serious
disadvantages (such as bad debugger interaction, a potential for really
ugly hairballs, and a constant temptation for stopgap solutions that
"work well enough").
Lisp-the-language is a quite pretty lean-and-mean KISS language. The
stuff that's built on top of it (macros, readers, dispatch mechanisms,
etc. etc.) is neither lean nor KISS nor (IMHO) pretty - YMMV. Or, more
to the point: I have yet to see something that cannot be done in a
leaner, more KISS way.
Which is why I'm going to stick with functional languages. After all,
the higher-order stuff was what attracted me to Lisp in the first place,
the rest of the language less than impressed me. I'll grant that modern
Lisps have found ways around any problems (otherwise, modern Lisps
wouldn't be in use), but why mess with workarounds if I can have the
cake (higher-order programming) and eat it, too (amenability to static
More information about the Python-list