[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flush COMPILER-LET?
- To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
- Subject: Re: Flush COMPILER-LET?
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Mon, 26 Sep 88 12:27:37 MDT
- Cc: cl-compiler@sail.stanford.edu
- In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Sun, 25 Sep 88 19:51:06 BST
I could live with getting rid of COMPILER-LET. It is supposed to be
used for communication between complicated macros; i.e., the bindings
it makes at compile time are available during the expansion of macro
calls in the body. It does seem like you could get most of the same
effect using MACROLET.
In other words, suppose I have something like:
(eval-when (eval compile)
(defvar *foo* nil))
(defmacro foo-macro (x)
(compute-foo-expansion x))
Then, I could replace
(compiler-let ((*foo* t))
... (foo-macro ...))
with
(macrolet ((foo-macro (x)
(let ((*foo* t))
(compute-foo-expansion x))))
... (foo-macro ...))
I actually use COMPILER-LET in one place in the compiler I've been
hacking on. It appears in the expansion of a source-to-source
transformation on UNWIND-PROTECT, to rebind a variable internal to the
first pass of the compiler. That is hardly what I would consider a
typical use, though, and I can think of a couple other ways to do the
same thing.
-Sandra
-------