[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: common-lisp@SU-AI.ARPA, SR.LAURITZEN@SPEECH.MIT.EDU
- Subject: compiler-let
- From: Niels Lauritzen <SR.LAURITZEN@SPEECH.MIT.EDU>
- Date: Fri, 11 Jul 86 05:41 EDT
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.
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 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 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.