Explanation of macros; Haskell macros

[Joachim Durchholz]

Peter Seibel wrote:

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

You're right, and made me rethink what's actually disturbing me about 
macros.

Perhaps it's that I have to adapt to dual-mode (two-tier?) thinking: I 
have to reason about both what the macros are doing and what the 
software is doing.
Alternatively, I could consider the macros as "part of the language" and 
not reason about the macro code but about their effects - in which case 
I have effectively augmented the language by all macros that are in use.

Personally, I'd still prefer a compiler that's evaluating constant 
expression.

Is there anything that a macro does that can't be done by preevaluating 
data structures that contain functions (or closures)? At first glance, 
I'd say no, but then I don't know what macros are used for in practice.

Um, well, yes, there is one thing that macros can do: extending syntax 
in ways that aren't part of the original language syntax. E.g. replacing 
all those parentheses by indentation, or something similar un-Lispish.
(Extending syntax in such ways is a mistake IMHO, but YMMV. Anyway, I'm 
more interested in the question if there's any /semantics/ that can be 
done via macros but not via compile-time evaluation.)

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

I believe it's not DEFMACRO that's complicating things, it's the macros 
that it allows (see above).

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

Agreed on all accounts (except that I don't know how "multilingual" 
Lispers really are *g*).

Does anybody have a keyword-style list of useful applications of the 
macro facilities?

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

"99% of all cases" is a pretty good argument actually :-)
It's just that Pascal doesn't (want to) believe that it's enough for 
type checking. His problem, not mine...

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

Agreed.
I'm getting more and more convinced that it's not language size or KISS 
issues that's setting me off, it's that "two-tier thinking" that I 
(perhaps mistakenly?) associate with macros.

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

I wouldn't want HM typing if it were just beautiful theory.
HM typing happens to be a beautiful theory. Things are getting less 
beautiful once you interact with the Real World (TM), which is stateful 
- OTOH, Real World is a mess, so don't expect computing to be beautiful 
anymore when there is interaction with it *g*. What surprised me is how 
much of a computation can be separated from such interaction. With the 
proper framework, one can even describe interaction patterns (which are 
themselves stateless), feed these patterns to the framework, and watch 
in amazement how the execution engine follows these patterns. It's the 
kind of abstractive facility I've been yearning for decades...
Lisp could do this just as well. It's just not done because taking the 
shortcut and doing stateful computations directly is so much easier.
(And I don't pretend that functional languages are doing this kind of 
thing perfectly right now. I think the potential in these ideas is just 
beginning to be exploited - and what's available is already quite 
impressive.)

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

Actually I'm trying to understand macros and macro usage right now, 
without having to learn all the details of CL (which would be a bit of 
overkill - I know it might not be enough, but then my time is limited so 
I'm doing my best within the available budget).

Regards,
Jo