symbol-macrolet

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 19 Nov 87 17:13 PST
    From: Gregor.pa@Xerox.COM

    I suppose we should say explicitly that the symbol macros are recorded
    in the macroexpansion environment so that macroexpand-1 of a symbol
    which is a symbol-macro will expand it.

I thought we were going to allow SYMBOL-MACROLET to be implemented in a
portable way, as something that fully macroexpands the form given and
then makes substitutions for symbols in it.  During macroexpansion the
symbol-macrolet'ed symbols would be just like other symbols, which seems
okay since they are (I think) supposed to be used in ways that are
semantically like variables; certainly that's true in the case of
WITH-SLOTS.

You seem to be suggesting that instead we will require every
implementation to change its macro mechanism to support symbol macros
directly.  Does this also require that every implementation must change
its interpreter and compiler to macroexpand symbols as well as lists
before attempting to evaluate them?  Whether the answer to that is yes or
no, it seems likely that every implementation would have to change its
internal representation of lexical environments, to allow for symbols to
be "bound" to macros as well as to values.  We might get a great deal of
resistance to that from some implementations.

Unless we can come up with some more compelling examples than so far, I
don't think CLOS should require SYMBOL-MACROLET to do anything to the
macroexpansion environment.  I think we should stick with the very
simple and easy to understand definition of SYMBOL-MACROLET that we have
now:  "Each reference to -symbol- as a variable within the lexical scope
of symbol-macrolet is replaced by -expansion-."  Both examples so far
appear to be predicated on the assumption that a call to SLOT-VALUE is
much less efficient than accessing a variable, and therefore we want to
allow for common subexpression optimization to be done by hand for these
in a funny way.  I for one see no reason to stipulate that inefficiency,
nor to assume that CSE optimizations must be done by hand.