symbol-macrolet

[Gregor.pa@Xerox.COM]

    Date: Mon, 23 Nov 87 15:19 EST
    From: 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.

Well, my concern was that there were macros which use once-only for
semanic reasons rather than purely optimization reasons.  These macros
assume that if a variable is lexical, they can know whether that
variable is being modified in their scope, they can perform some
optimizations.  Granted, this is bad macro writing style, but I claim
that it is common.  Its also true that the cases where these macros will
break is rare, but they do exist, and it makes me uncomfortable to think
there will be no way of fixing them.

On the other hand, I agree that it makes me unhappy to have to modify
the behavior of macroexpand-1 this way, and to modify the behavior of
the interpreter this way.  I had not realized that this was such a
radical change.

I guess now I am not sure.  Maybe the best thing to do is leave
symbol-macrolet the way you suggested and just document the exact form
of lossage I am describing.

Let me take this space to present one view of how macroexpansion
environments could be made more useful.  If they were themselves a
function, which could be given an operation and arguments, and if the
default function accepted operations to macroexpand-1, fboundp, etc.
then I could just extend these things by wrapping my own function around
them which carried additional information.  That would make it possible
to write a portable code walker in Common Lisp.  But it would not solve
this problem.
-------