Re: Issue: LOAD-TIME-EVAL (Version 8)

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

> Date: Tue, 24 Jan 89 21:24 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> The second clause (order) is clearly wrong, since if a top-level form
> contains a LOAD-TIME-EVAL, the load-time-eval must be evaluated no
> later than when the evaluation of the top-level form reaches it.

Yes, you're right here.

> If you didn't have the non-read-only case, then coalescing would be allowed
> and you wouldn't have to try to define what a distinct reference to a
> LOAD-TIME-VALUE expression is, since you wouldn't have to require that
> each distinct reference gets evaluated.  I guess too many people like
> the non-read-only case for it to be likely to go away.

We talked about removing the non-read-only case before and for the
same reasons, but Pitman objected, saying he thought it was essential
to the proposal.  Basically, if you're going to do destructive
operations on an object, bad things will happen if it's shared with
anything else.  I suppose an alternative would be to shift this burden
onto programmers rather than implementors, as long as implementors are
not permitted to coalesce EQUAL LOAD-TIME-VALUE expressions (which
would result in unexpected sharing). 

> I have not been able to think of any satisfactory solution to this
> problem, but I do not think you can get away with leaving it as-is.  I
> guess that the most likely route to a solution will involve defining
> some sort of "tree walk" through the source code, defining the identity
> of a form as the path taken through the tree to reach that form.  I'm
> guessing that the intuition that the proposal intended to capture is the
> same thing that this tree walk does.

Yes, that is pretty much what I had in mind, but I agree it is not
formally stated.  Perhaps a more formal statement would be that you do
a code walk to expand all macros, then do a COPY-TREE on the resulting
code, then all the LOAD-TIME-VALUE expressions you end up with would have
the right uniqueness properties.

> Alternatively, you might abandon the intuition and think about the 
> consequences of just using EQ of the LOAD-TIME-VALUE expression.  Would
> it be so bad?

That's pretty much the alternative I mentioned above, I guess.  Maybe
you could try to resolve this with Pitman off-line, since he was the
one who was really pushing for allowing destructive operations, which
are really the source of the problem.  I wouldn't have any objection
to seeing whatever you two agree on submitted as a cleanup to the 
cleanup.

-Sandra
-------