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

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

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

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

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

I sure can't understand why this issue is so hard.