COMPILER-LET

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

The ANSI X3J13 (Common Lisp Standardization) compiler cleanup committee
is contemplating a proposal to remove COMPILER-LET from the language.
If you have some code that uses COMPILER-LET and you don't think that
it could be rewritten to use some other construct, the compiler
committee (cl-compiler@sail.stanford.edu) would like to hear about it.

Reasons for flushing COMPILER-LET include:

* COMPILER-LET is ugly and confusing.  The dynamic extent of the variable
  bindings in interpreted code can lead to subtle bugs.  In compiled code,
  the variable bindings are only visible to macros within the lexical scope
  of the COMPILER-LET.

* COMPILER-LET appears to be rarely used. 

* Most (all?) instances of using COMPILER-LET for the purpose suggested
  in CLtL ("communication among complicated macros") can be handled
  just as well using MACROLET.  Using MACROLET for this purpose also makes
  it more clear that the expansion of certain macros depends upon the
  lexical context in which they appear.

  For example, 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 ...))

-Sandra Loosemore (sandra@cs.utah.edu)
-------