compiler-let

[Niels Lauritzen <SR.LAURITZEN@SPEECH.MIT.EDU>]

If you object to the reference to compilers in COMPILER-LET
how about naming it...

MACROEXPAND-LET since both the interpreter
and the compiler have a macroexpansion phase and these bindings
may affect macroexpansion.  (not to be confused with MACROLET)

or (not so good)

EARLY-LET because it binds before evaluation time 
in both the interpreter and the compiler.

I certainly don't think that we should do away with
the functionality of MACROLET and COMPILER-LET.
They both are useful for hacking fancy macroexpansion environments.

Now I propose another form to round out the "binding" family
MACROEXPAND-FLET.  Use it to define functions that are only used
during the dynamic extent of macroexpansion. 

we have
DEFVAR       define a global, dynamically scoped variable
DEFUN        define a global function
DEFMACRO     define a global macro

LET      establish a lexically scoped variable,
	 or bind a dynamically scoped variable

FLET     establish a lexically scoped function

 (in an intermediate category)
MACROLET establish a lexically scoped macro

MACROEXPAND-LET (was COMPILER-LET)
    macroexpand time binding of a variable (dynamic scoping)
MACROEXPAND-FLET
    macroexpand time binding of a function (dynamic scoping)

MACROEXPAND-LET* would be icing on the cake because the same effect
could be achieved by using a series of nested MACROEXPAND-LETs.

It seems to me (pardon me if I'm all wet) that because of the way
macroexpansion is done (recursively),
we don't need to distinguish between lexical and dynamic scoping of a macro.
The environment of definition is always the same as the environment of the caller.

So we don't need separate forms for

MACROEXPAND-MACROLET              
    macroexpand time binding of a macro (dynamic scoping),

because it would be the same as MACROLET,

or a lexically-scoped MACROEXPAND-LET or lexically-scoped MACROEXPAND-FLET.