issue SYMBOL-MACROLET-SEMANTICS

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

    Date: Thu, 13 Oct 88 17:08:55 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    This seems like a reasonable thing to do here.  The only serious
    problem I see is that the description of SYMBOL-MACROLET in the CLOS
    document says that it changes SETQ's of the symbols in the body to
    SETF's during macro expansion.  Now that you are proposing that
    SYMBOL-MACROLET won't be a macro any more, I think you have to specify
    a change in the behavior of SETQ as well as SETF.  It seems like they
    would have to be pretty much the same now, right?

Yes.

    I am a bit concerned about how this proposal interacts with the SETF
    processing model specified in issue SETF-FUNCTION-VS-MACRO -- with the
    description of SETF being distributed in several places, something
    might get overlooked in the final standards document. 

How could they interact, when SYMBOL-MACROLET-SEMANTICS applies when the
<place> subform of SETF is a symbol, and SETF-FUNCTION-VS-MACRO applies
when the <place> subform of SETF is a cons?  It's true that the number
of issues being addressed simultaneously is getting out of hand; the
extremely long delay in resolving some issues is making this worse.

    Another thing is that I really don't like the name SYMBOL-MACROLET and
    as long as you are proposing to make it a special form, you might as
    well try to change the name to something nicer at the same time.  

I'm afraid I don't follow your syllogism here.  Also I think you'd have
to make a specific proposal of a new name to get anyone to pay attention.