[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compiler-let
- Subject: Re: compiler-let
- From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
- Date: Mon, 7 Jul 86 13:45:37 MDT
- Apparently-to: common-lisp@su-ai.arpa
- Distribution:
- Expires:
- Followup-to:
- Keywords:
- Newsgroups: fa.common-lisp
- Organization: University of Utah CS Dept
- References: <860707151336.1.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>
- Reply-to: shebs@utah-orion.UUCP (Stanley Shebs)
- Sender:
- Summary:
In article <860707151336.1.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU> JAR@MIT-AI.ARPA (Jonathan A Rees) writes:
>COMPILER-LET seems pretty confused;
Hear, hear!
>Of course, the fact that COMPILER-LET has different meanings in
>"interpreted" and "compiled" code is in conflict with th "consistency"
>statement on page 2. If COMPILER-LET is to be made meaningful, a
>precise distinction between the interpreted language and the compiled
>language must be made somewhere, and this is something I haven't seen so
>far.
Since interpreter/compiler/strange evaluator consistency is one of the
few things that almost everybody agrees is good about Common Lisp,
it should take precedence over anything that would damage this;
COMPILER-LET should be flushed, and EVAL-WHEN, and I wouldn't mind
some constraints on macros in general, although there's not much
prospect for that...
>I'm surprised that people writing code-walkers haven't complained about
>COMPILER-LET before (sorry if you have and I've forgotten).
For PCLS we took advantage of subsetness and totally ignored COMPILER-LET,
since nobody could figure out what it was really for or how a user could
use it in correct code.
stan