Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM

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

>  ...  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
COMPILE-FILE?

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

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)
or
    '#,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.