Re: issue LOAD-TIME-EVAL

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

> Date: Tue, 10 Jan 89 00:20:32 GMT
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> 
> >    In interpreted code, (LOAD-TIME-VALUE <form>) is equivalent to (VALUES
> >    (EVAL (QUOTE <form>))).
> 
> Surely not, for this would cause all the QUOTE restructions to apply
> if certain options of QUOTE-MAY-COPY were passed.

Perhaps I can rephrase this.  I seem to remember having tried once
before but apparently things got even more messed up in the process.
The idea is that evaluation takes place in a null lexical environment,
that it's performed by EVAL, and that exactly one value is returned. 

> >    Note that, in interpreted code, there is no guarantee as to when
> >    evaluation of <form> will take place, or the number of times the
> >    evaluation will be performed.  Since successive evaluations of the
> >    same LOAD-TIME-VALUE expression may or may not result in an evaluation
> >    which returns a "fresh" object, destructive side-effects to the
> >    resulting object may or may not persist from one evaluation to the
> >    next.
> 
> This sort of defeates the purpose of :READ-ONLY-P NIL.

I'm not sure exactly what problem you have here.  :READ-ONLY-P NIL
says that it's OK to bash the object destructively, which is sometimes
useful even if such destructive side-effects are not persistent. 

> I don't understand what this explicit initialization is or why it helps.

OK, here's an example.  Suppose I have a function that requires a large
array for some temporary storage.  There's really no need for it to
cons up a fresh array every time it's called, so I can use LOAD-TIME-VALUE
with :READ-ONLY-P NIL to say that it's OK only to cons up the array once.
However, there might still be garbage left in the array from one call to
another, so each time the function is called it would have to reinitialize
the array if it depends on it containing some particular values, instead
of just assuming that the array still contains whatever MAKE-ARRAY put into
it.

> >    Implementations must guarantee that each reference to a
> >    LOAD-TIME-VALUE expression results in at least one evaluation of its
> >    nested <form>.  For example,
> >      (CONS #1=(LOAD-TIME-VALUE (COMPUTE-IT)) #1#)
> >    must perform two calls to COMPUTE-IT; although there is only one
> >    unique LOAD-TIME-VALUE expression, there are two distinct references
> >    to it.
> 
> Why do we want this restriction?

A previous paragraph says that it's OK to evaluate LOAD-TIME-VALUE forms
only once.  This is to clarify what "only once" means -- once per
reference.  As I already pointed out in response to somebody else's message
on this same point, it means that it's not a valid implementation
technique to cache LOAD-TIME-VALUE forms and resulting values and do a
lookup based on EQ source code.

As to why we want this restriction, it's to avoid problems due to
unexpected sharing of source code.  This kind of sharing is
particularly likely to happen when LOAD-TIME-VALUE forms appear in the
expansion of a macro. 

> You might cite reasons, even if only by a phrase or two.  (I'm never
> happy when all I'm told is that "some people think it's essential".)

That particular phrase is Kent's.  I've long ago given up on trying to
read Kent's mind :-), so he'll have to provide his own explanation.

> I think Kent is right about the lingering problems, but I'm not sure
> users would prefer the new behavior when debugging/modifying macros.
> I don't think the implementation cost of a prepass is all that great.

I agree with this -- the problems are cultural rather than technical.
People here at Utah who were initiated into the Lisp world by PSL
really retch at the thought of making a prepass a required part of the
language, because they view the ability to redefine macros on the fly
as an important feature (regardless of whether or not they actually
use the feature much in practice).  Most people here are still using
HPCL-I, which does perform a prepass, and almost universally this is
the one misfeature they pick on most, even though the implementation
suffers from *far* more serious deficiencies (I stopped using it much
myself because it was so full of bugs).

-Sandra
-------