[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue COMPILER-LET-CONFUSION
- To: kmp@stony-brook.scrc.symbolics.com
- Subject: issue COMPILER-LET-CONFUSION
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Sat, 21 Jan 89 20:15:11 MST
- Cc: iim@ecla.usc.edu, cl-compiler@sail.stanford.edu
In an earlier message on this topic, you wrote:
> Suppose that instead of referencing the value as a special, you had
> an operator COMPILER-SYMBOL-VALUE to get its value. [That could be a
> function, macro, or special form.] I wouldn't have a problem calling
> a function to get this data because I still get to use the same basic
> `shape' of code. Also, uses of COMPILER-LET are rare enough that a
> bit of extra syntax is not overwhelming.
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)))
How does this strike you? I really like this approach, because it is
entirely lexical and avoids all the problems relating to the special
binding of COMPILER-LET. There will be some conversion necessary for
user code, but as you noted in your earlier message, the basic "shape"
of the code remains the same.
-Sandra
-------