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

[Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>]

I am more or less in favor of the proposal.  LOAD-TIME-VALUE is
a much better name than LOAD-TIME-CONSTANT if we are going to
allow the value to be a reliably modifiable object.  And I
agree with KMP's arguments that it should be modifiable.

I am less hapy with the exception that allows the interpreter to
multiply evaluate the expression to produce a new value each time.
While the exception is consistent with the rules for macros, I
do not think the two cases are really analogous.  LOAD-TIME-VALUE
results in an object, so it matters if the object is a different
one each time.

> LOAD-TIME-VALUE is, in effect, a promise by the user that multiple
> evaluations of <form> will return values that are semantically 
> equivalent (although not necessary EQ).

What this means, in part, is that the programmer can't mean EQ by
"semantically equivalent" in interpreted code but can in compiled.
I suspect it will be a pain to write code that can take advantage
of the COMPILE-FILE guarantee but nonetheless still work if the
form is multiply evaluated.

> If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, [...] It
> is guaranteed that the evaluation of <form> will take place only once
> when the file is loaded

To me, the value of this guarantee is much less when it does not
apply when interpreting.

> If a LOAD-TIME-VALUE expression appears within a function compiled
> with COMPILE, the compiler may either evaluate the <form> or use
> a previously cached value.

I'm not sure what this means.  Does it mean that different code
compiled at different times can nonetheless end up using the same
value?  (I hope not....)

-- Jeff