Re: issue LOAD-TIME-EVAL

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

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

>    It is safest to explicitly initialize the object returned by
>    LOAD-TIME-VALUE, if it is later modified destructively.

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

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

>    The semantics of LOAD-TIME-VALUE would be simplified considerably if
>    the READ-ONLY-P argument were removed and destructive operations on
>    the result of evaluating <form> prohibited.  However, some people feel
>    that the ability to destructively modify the value is an essential
>    feature to include.

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

I'm one of the people who would like to be able to modify values,
but I also want to be able to evade the QUOTE semantics for objects
in code without having to create a gensym to hold the value.  So I
would be partially happy (whatever that means) even if the objects
were read-only (provided they weren't coalesced with other objects
-- and this matters even w/o the ability to modify because EQL can
still tell the difference, as can EQL hash tables).  But objects
aren't like objects usually are if they can't be modified.

> Kent Pitman says:
>    Although I'm willing to take multiple evaluation in the interpreter
>    as a compromise position, I would like it mentioned in the discussion
>    that this was only an expedient to getting this issue accepted at all,
>    and that I'm not really happy about it. I have said that I think a
>    number of our lingering problems (with EVAL-WHEN, COMPILER-LET, and
>    this -- for example) are due to the presence of interpreters which do
>    not do a semantic-prepass at a known time. If I had my way, we would
>    require a semantic pre-pass and we would then be able to forbid
>    multiple evaluations even in the interpreter.

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.