[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILER-LET-CONFUSION
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: issue COMPILER-LET-CONFUSION
- From: email@example.com (Sandra J Loosemore)
- Date: Thu, 16 Feb 89 13:35:15 MST
- Cc: firstname.lastname@example.org, CL-Compiler@SAIL.Stanford.EDU, iim@ECLA.USC.EDU
- In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 16 Feb 89 13:54 EST
> I presume, of course, that the COMPILER-LET was really introduced by a macro
> to communicate with another macro that might or might not be there, and that
> in this case it is not there [...]
> Now in your proposed solution, you say I should write instead:
> (DEFVAR *FOO* 0)
> (DEFUN FOO ()
> (SYMBOL-MACROLET ((*FOO* (NEW-VALUE)))
> I don't see how this has solved any problems. In fact, it has introduced some.
> Because now it reliably returns the value that I don't want.
I don't think this problem is unique to using SYMBOL-MACROLET in this
If the SYMBOL-MACROLET (which replaces the COMPILER-LET) was
introduced by a macro and the symbol is not supposed to be visible to
ordinary user code, then it should be a gensym instead of some random
symbol. That would avoid any accidental name collisions with a symbol
that is being used as a variable (special or not) in the code in which
the original macro call appears.
I've had to use gensyms as the names of ordinary MACROLET macros in a
couple of situations already, where I had a macro that expanded into
some local macro definitions that weren't supposed to be visible to or
shadowed by random user code in the body, but that were supposed to be
visible in the expansions of some other macros. I don't see how having
to do this for the names of symbol macros is any different.