[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILER-LET-CONFUSION
- To: sandra%defun@cs.utah.edu
- Subject: Re: issue COMPILER-LET-CONFUSION
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 16 Feb 89 16:26 EST
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@SAIL.Stanford.EDU, iim@ECLA.USC.EDU
- In-reply-to: <8902162035.AA05682@defun.utah.edu>
The whole point to giving a variable a name is so you can type it.
If (COMPILER-LET ((*FOO* (NEW-VALUE))) ...)
turns into (SYMBOL-MACROLET ((#:G0001 (NEW-VALUE))) ...)
then how can I later reference the thing. How will the lookup
routine be able to take *FOO* as an argument and figure out what
the gensym was called? If there's a place to store that relation,
why not just store the relation between *FOO* and the value itself
rather than indirecting through an irrelevant macroexpand?
Also, somewhat unrelated but I just thought of it, the body of
SYMBOL-MACROLET is not (necessarily) executed at binding time,
while *COMPILER-LET*'s body is. I'm not sure how that will affect
things. I can't convince myself that delaying the evaluation of
that form will have the right effect. [Even if it did, you'd need
to do (EVAL (MACROEXPAND ...)), not just (MACROEXPAND ...) in
the lookup routine unless you made the simplification I alluded
to in the previous paragraph.]
If you want to continue to pursue this, I guess I need to see
the fully elaborated technique described again, taking into
account the need for clarifaction on the points I've raised,
so that I can reevaluate it anew without feeling like there are
kinds of loose ends that might or might not be answered already
or that i might or might not have to magically factor in...