[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: firstname.lastname@example.org
- Subject: COMPILER-LET
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 26 Sep 88 17:11 EDT
- Cc: email@example.com, firstname.lastname@example.org
- In-reply-to: <8809261936.AA05384@defun.utah.edu>
Date: Mon, 26 Sep 88 13:36:01 MDT
From: email@example.com (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.
- From: firstname.lastname@example.org (Sandra J Loosemore)