[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
- To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
- Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Wed, 21 Sep 88 11:37:11 CDT
- Cc: cl-compiler@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: Msg of Tue, 20 Sep 88 19:46 EDT from "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
- Sender: GRAY@Kelvin.csc.ti.com
> The new mechanism has all sorts of problems with multiple evaluation
> that #, did not have. The semantics of #, were very clear, if somewhat
> off the wall.
Since neither the MIT Lisp Machine manual nor CLtL correctly document how
to use #, it would hardly seem that the semantics are "very clear". The
question of multiple evaluation applies to #, also, it just hasn't ever
been spelled out before.
> ... any implementation that
> formerly treated all constants as read-only now needs a way to label
> each constant as read-only or writable.
But #, never could be treated quite the same as other constants, since it
is constructed at load time instead of compile-time. The Explorer
write-protects ordinary constants, but not when #, is used.
> ... Since #, is a feature of LOAD rather than of EVAL, we don't
> need any new rules about what happens if you evaluate it twice. Since
> #, is a feature of LOAD rather than of EVAL, there is no issue of
> semantic incompatibility between the compiler and the interpreter.
#, is a feature of the reader that needs to cause both the loader
and evaluator to do something appropriate with it. Are you suggesting
that it is only permissible to use #, within an input file to
> How to make the mechanism underlying #, available? This would be a
> function that receives a form and returns an object (I'd use the term
> "magic cookie" if I didn't hate it) which can be placed inside a quoted
> constant; by the time the program is loaded, that position in the quoted
> constant will contain the result of evaluating the form in the null
> lexical environment. It is only useful to call this function from
Although this approach follows the way we happen to implement #, I don't
care for it because it seems to be institutionalizing an implementation
technique rather than focusing on the functionality to be provided.
I also had a negative initial reaction to the new-special-form proposal,
but my attempts to come up with something simpler only led me appreciate
it. There is still a valid question though of whether we want
#,exp <==> (LOAD-TIME-VALUE exp T)
'#,exp <==> (LOAD-TIME-VALUE exp T)
'(... #,exp ...) <==> (LOAD-TIME-VALUE (LIST ... exp ...) T)
I could go either way on that; the first way (as proposed) is much
simpler, but the second is consistent with current practice.