[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Sandra J Loosemore <email@example.com>
- Subject: issue SYMBOL-MACROLET-SEMANTICS
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 27 Oct 88 00:02 EDT
- Cc: firstname.lastname@example.org
- In-reply-to: <8810132308.AA19978@defun.utah.edu>
Date: Thu, 13 Oct 88 17:08:55 MDT
From: email@example.com (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?
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.