RMS and the problem of macro-expansion during compilation

[JONL at MIT-MC (Jon L White)]

Indeed, as GLS says 19 JUN 1978 1919-EDT, **if** the DISPLACE/DISPLACED
scheme were to become instutionalized, the compiler could hack it specially.
But it still could not know whether the result was macro-produced or
original native code.  This problem does concern several people
(see PSZ@ML, RICH@AI) who have alternative shcemes for macro-expansion
management.  After having talked with RICH for some time, I agree that
all of these schemes are good for their purpose, and we probably cant
institutionalize any one of them now.  But, DISPLACE is another matter,
for **all** of the other schemes use a simple-minded SUBR DISPLACE.
As to users being consternated at the multiple expansion of macros
during compilation (for whatever purpose), there are some who have
clever macros with weird side effects, (and memoizing is one side effect)
among whom is KEN@AI.

   May I also take this opportunity again to remind the community
that my mail file is growing exponentially since my re-arrival in
cambridge.  A short glance  at my directory seems to indicate that
I receive as many characters every two weeks now as I did the entire
first quarter.  PLEASE, try not to resend a big piece of mail when
you reply to a point;  can the point be made clear with a few words?
could it be understood from the (local) context  of the LISP MAIL
file?  Especially ludicrous is the reply to reply to reply . . .
that includes a copy of all previous correspondence.  This is
n-squared in the number of replies, and there are probably 30 people
who receive this junk.  All of this applies to the LISP MAIL
file equally.