[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue COMPILER-LET-CONFUSION
Date: Sat, 21 Jan 89 20:15:11 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
At the Hawaii meeting, Kim Barrett showed me a clever example of how
you can already get this effect using SYMBOL-MACROLET.
Where one would now write something like:
(compiler-let ((*foo* (new-value)))
... (some-macro) ...)
(defmacro some-macro ()
... *foo* ...)
one could instead use SYMBOL-MACROLET:
(symbol-macrolet ((*foo* (new-value)))
... (some-macro) ...)
(defmacro some-macro (&environment env)
... (symbol-macro-value '*foo* env) ...)
(defun symbol-macro-value (symbol env &optional default)
(multiple-value-bind (expansion macro-p) (macroexpand-1 symbol env)
(if macro-p expansion default)))
Date: Thu, 16 Feb 89 11:08:26 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
... What I want to know, is anybody now still in favor of retaining
COMPILER-LET? Kent, since you're the one who has argued for COMPILER-LET
most strongly in the past, do you think the SYMBOL-MACROLET technique
would be sufficient to solve the kind of problems you now use COMPILER-LET
for? Or do you still want to keep COMPILER-LET around anyway? ...
I looked at this when you first sent it out and it looked buggy to me
and so I put it aside until I had more time. I'm sorry for taking so long
to get around to it, but now that I've looked at it in more detail, I still
see the same bug.
Maybe I'm just confused about what you're suggesting. If so, maybe the
following info will help you to be more clear so I can see what you are
getting at. I see the following screw case, which your example doesn't
really say how to deal with because it's not full elaborated:
The whole problem with COMPILER-LET in the past, that originally brought
all this up, is:
(DEFVAR *FOO* 0)
(DEFUN FOO ()
(COMPILER-LET ((*FOO* 1))
*FOO*))
My claim is that this should reliably return 0, not 1. Certainly it would
if a semantic-prepass were required because the dynamic environment of
execution would not overlap with the dynamic environment of compilation.
I grant that CLtL now says that it may return either 0 or 1.
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, and that therefore the programmer's intent was
effectively to just execute
(DEFVAR 0)
(DEFUN FOO () *FOO*)
Now in your proposed solution, you say I should write instead:
(DEFVAR *FOO* 0)
(DEFUN FOO ()
(SYMBOL-MACROLET ((*FOO* (NEW-VALUE)))
*FOO*))
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.
Am I missing something?