issue SYMBOL-MACROLET-SEMANTICS

[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?

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. 

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.  For
one thing, it might be confusing because the "bodies" of the macros
are substituted directly in one case and evaluated in another.  If
compatibility is a problem implementations could keep SYMBOL-MACROLET
defined as a macro.

-Sandra
-------