COMPILER-LET

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 26 Sep 88 13:36:01 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    ... 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. ...

The whole purpose of COMPILER-LET is to allow communication between textually
unrelated macros, so of course it's only visible within the lexical scope of
the COMPILER-LET in the compiler.

In my opinion, the real problem is that interpreted-only implementations are not
required to make a semantic-prepass. This means that macro expansion and 
COMPILER-LET handling may happen all at once or at any known time, so it must
risk interfering with runtime variable bindings. If interpreters were required
to do the pre-pass (effectively, a mini-compile just doing macro expansion, etc),
not only would COMPILER-LET seem ok, but other problem spots in the language
(like EVAL-WHEN) would be easier to tackle as well.

I've sent more detailed comments to CL-Compiler, and will carry on a complete
technical discussion there, but I wanted to make this reply to all of Common-Lisp
since many people will not see that discussion so that they know that this is
not as one-sided an issue as you have painted it.

End of opposition viewpoint.