Explanation of macros; Haskell macros

Joachim Durchholz joachim.durchholz at web.de
Sat Nov 1 06:14:41 EST 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
>>compile-time expressions.
> 
> 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 
analysis)?

Regards,
Jo





More information about the Python-list mailing list