[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
- To: David N Gray <Gray@DSG.csc.ti.com>
- Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 21 Sep 88 13:48 EDT
- Cc: cl-compiler@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: <2799851831-13818993@Kelvin>
Date: Wed, 21 Sep 88 11:37:11 CDT
From: David N Gray <Gray@DSG.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.
Since the evaluation happens at load time, how can it happen more than
once? If you load the same file again, you create a new object, you
don't "load the same object again." It's true that #, has always been
poorly documented, which is how we got into this mess in the first place.
> ... 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.
All constants are created at load time. Think about it; the output file
from COMPILE-FILE doesn't contain objects, it contains instructions to
the loader telling it how to create objects.
> ... 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
No, of course not. I'm saying that #, is a feature of the reader that
needs to cause the loader to do something appropriate with it. #, never
affects the evaluator, EVAL and COMPILE never see anything different when
#, is used than they would see normally.
> 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.
That's exactly the opposite of what I thought I was doing, so I guess we're
not communicating very well.
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
I sure can't understand why this issue is so hard.