issue LOAD-TIME-EVAL, again

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

I've been trying to sketch out a revised version of proposal 
LOAD-TIME-EVAL:NEW-SPECIAL-FORM that addresses the problems that have
been raised recently, and once again I need some feedback before I can
proceed.

I've come to the conclusion that allowing the result of the
LOAD-TIME-CONSTANT form to be modified destructively (that is, by not
forcing the value to be read-only) requires an absolute guarantee that
each reference to a (LOAD-TIME-CONSTANT ...) form results in exactly
one evaluation of the embedded form.  The problem with allowing
collapsing of multiple references to EQL (or even EQUAL) forms is
fairly obvious; each reference should get its own, freshly consed
result value to bash on.  

The other problem is with my earlier idea of allowing the interpreter
to perform multiple evaluations on the subform.  This won't work
because user code might rely on destructive modifications to the
cached value, and break if a fresh copy is returned instead.  One
possible solution would be to prohibit this by specifying that
successive evaluations of the same (LOAD-TIME-CONSTANT ...) form
return values that are semantically equivalent but not necessarily EQ.
Effectively, this would require users not to assume anything about the
contents of the object and to explicitly reinitialize it each time.

The reasons why I would like to remove the restriction on the
interpreter are both aesthetic (to make LOAD-TIME-CONSTANT processing
similar to macro expansion) and practical.  I'm very concerned that
requiring the interpreter to recognize unique references to
(LOAD-TIME-CONSTANT ...) forms so it can guarantee unique evaluation
would require some really tricky implementation techniques.
Code-bashing is the obvious way to do it, but besides being forbidden
by the current proposal, it isn't such a good thing to do on quoted
expressions passed to EVAL.  The other alternative I can think of
would be to have EVAL or FUNCTION to do a preprocessing codewalk to
take care of the LOAD-TIME-CONSTANTs.  This would be a major change
for many implementations and I think we would run into a lot of
resistance to it.

I see the following alternatives:

(1) Remove the optional READ-ONLY-P argument and require that the
    results of LOAD-TIME-CONSTANT forms be treated as read-only.  Remove
    the restriction on the interpreter evaluating the forms only once,
    and allow both the interpreter and compiler to collapse EQUAL
    (LOAD-TIME-CONSTANT ...) forms.

(2) Retain the READ-ONLY-P argument while specifying that successive 
    invocations of a given (LOAD-TIME-CONSTANT ...) form return values 
    that are semantically equivalent but not necessarily EQ, to allow  
    the interpreter to do multiple evaluations of the nested <form>.
    Collapsing of (LOAD-TIME-CONSTANT ...) forms would not be permitted.

(3) Somebody suggest a simpler implementation technique that will
    ensure that the subforms of (LOAD-TIME-CONSTANT ...) expressions 
    are only evaluated once.

(4) Somebody convince me that implementors are really willing to
    rewrite their interpreters to use a preprocessor that will ensure
    that subforms of (LOAD-TIME-CONSTANT ...) forms are only evaluated 
    once.

Comments, please?

-Sandra
-------