Atomic Macros

[ALAN at MIT-MC (Alan Bawden)]

Perhaps we should be working towards a "Fusion Macro"?

Seriously, I would like to offer some arguments about atomic macros.
First let me say that I am opposed to adding atomic macros to MacLisp
or LispMachine lisp.  My reasons for this are probably similar to
PSZs: although the feature has some merit, it is really not something
that can be added to the language at this point without causing
complete and total upheaval.

SET and PROGV are one problem.  Another: suppose we say that
(LET ((X 0)) ...) atomicmacroexpands the X to see if it is going to
expand into another symbol.  What if it expands into (MUMBLE 'X)?  Do
we continue to macroexpand, or do we stop and destructure?  (I don't
like destructuring either, but there it is.)  If you think we should
continue to macroexpand then suppose the guy wrote
(LET (((MUMBLE 'X) 0)) ...) in the first place?  If you think we
should destructure then by what right do you differentiate between
X => (MUMBLE 'X) =>Y and X => Y ("=>" indicates one level of
macroexpansion)?

Perhaps you can solve these problems, (I just thought of a way out
myself) but there are going to be others you haven't thought of yet.
In particular you have just screwed every macro writer who ever did
(ATOM FOO) to determine if it was safe to substitute the value of FOO
directly into some code that might evaluate it twice.  ("But nobody in
their right mind would define an atomic macro whose expansion
evaluated with side effects" I can hear several people yelling...  I
know.)

I bet I can think up more.  I bet nobody is willing to put the effort
into implimenting them.  I bet we can continue to live without them.

Now, for those of you who are wondering why I put atomic macros into
LIL if I think they are such losers:

1) In LIL we have no destructuring.

2) LIL has no interpreter where there are symbols that can be passed as
arguments to things like SET and PROGV.

3) We don't let atomic macros do anything in LETs, it is an error to
do (LET ((X 0)) ...) if X is an atomic macro.  This is so that we can
do the right thing when we decide what that is.  I tend to think that
the HIC solution (GJC's "atomic macro of the second kind") is the right one
at the moment.

4) Since LIL is growing from the ground up, we have no commitment to any
other past features that might screw us.

5) We have no users with existing code that this might break.

Basically the point is that this atomic macro thing is a good idea,
but only as something you have in mind from day 1, not something that
you add in 10 years later when you first think of it.