Definition time macros

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: Tue, 15 Jul 1986  14:55 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    
	Date: 15 Jul 86 12:07-EDT
	From: mike%gold-hill-acorn@LIVE-OAK.LCS.MIT.EDU
    
	I'd like to see this tightened up to indicate that macros expand 
	once, as in a compiler, and are not expanded over and over each 
	time an expression is interpreted.
    
    I feel very strongly that requiring this is a bad idea.

I feel very strongly that requiring this would be a very good idea.  I
think Scheme has a big lesson to teach us here. They have made lexical
analysis occur at a well-defined time and it has made program-understanding
a much more straightforward issue.

For example, in the current state of confusion, the fact that there is
no definite time at which macro expansion occurs means that
 (DEFUN FOO (X) (IF X (BAR) (BAR))) 
can have its behavior depend on X in interpreted code but not compiled
(assuming BAR is a macro that does not expand into a reference to X),
especially if runtime macro caching is being done. This could be baffling
to naive users and is quite irritating to some of us sophisticated users.

I also believe there are a number of glaring uglinesses in the language
which can be fairly directly attributed to the decision to not have a
well-defined ENCLOSE time. Among these are the assymetry between interpreted
and compiled "#," and the weird definition of EVAL-WHEN. I could and would 
make proposals to improve/fix both of these problems if we had a well-defined
ENCLOSE time.

All linguistic issues aside, it's also the case that since implementations
are currently free to vary on this, the debugging skills a programmer learns
in one implementation may not carry over to another. In fact, those skills
may work against the programmer if he has a mindset that leads him to make
assumptions as in the case of the FOO definitino above which don't pan out.