Explanation of macros; Haskell macros

[Peter Seibel]

Joachim Durchholz <joachim.durchholz at web.de> writes:

> 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).

Hmmmm. The special forms (25 of them, called special operators these
days, by the by) are used the same in macros and functions. Lisp's
customizable reader is a separate thing--there is no need to customize
the reader to write macros.

> Letting the compiler evaluate what it can means that I don't even
> have to learn extra forms.

I'm not sure what "extra" forms you're talking about. Other than
DEFMACRO, I guess. But by that argument we'd be better off without
DEFUN too because that's just another darn thing to learn.
> 
> 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.

Yes, it probably would be over kill if that was all it was for.

> I'm pretty sure that macros solve more problems than just
> compile-time evaluation.

Yup.

> I just suspect that better solutions are available in every case,

Interesting. A lot of people suspect that who haven't actually used
Common Lisp macros. Yet almost all Common Lispers--who by in large are
*not* monolinguists--think macros are one of Common Lisp's great
features. I'm not saying your wrong, but if those better solutions are
out there for all the things I can do with macros, I haven't seen
them. Now I don't know Haskell or ML so I'm also suffering from finite
knowledge. Maybe one day I'll have time to learn one of them for
myself and see if they really do offer better solutions.

> 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").

Well, of those the debugger interaction is perhaps the most serious.
Yet in practice (Hey Pascal, I almost said "in 99% of cases"!) it
doesn't seem to be that much of a problem. Maybe that's because we've
just learned to deal with the pain; maybe MACROEXPAND is all you
really need to get your bearings. At any rate, there's no in principle
that a Lisp implementation couldn't keep track of macro information
along with the compiled code just the way most compiler keep track of
line number information in order to show you the code as written in
the debugger. (And if it was really slick to let you step through the
macro expansion, etc.)

> 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.

Clearly. I find Common Lisp to be a pretty beautiful piece of
*engineering*. Which may be different than a beautiful realization of
a beautiful theory.

> Or, more to the point: I have yet to see something that cannot be
> done in a leaner, more KISS way.

Well, if I promise to continue to think that someday I really should
learn a hard-core FP language so I can see what all the static typing
fuss is about, will you promise to think in the back of your mind that
maybe someday you should learn Common Lisp and see what makes us all
so gaga over macros.

> 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)?

Right on. If that's the flavor of cake--enjoy it.

-Peter

-- 
Peter Seibel                                      peter at javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp