[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: LOAD-TIME-EVAL (Version 8)
- To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
- Subject: Re: Issue: LOAD-TIME-EVAL (Version 8)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 1 Feb 89 18:51 EST
- Cc: David N Gray <Gray@DSG.csc.ti.com>, KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@SAIL.STANFORD.EDU
- In-reply-to: <8902012212.AA27088@defun.utah.edu>
Date: Wed, 1 Feb 89 15:12:44 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
I'd like to get this issue out of the way. To me it appears that we
have pretty much reached a consensus, and the remaining obstacle is
deciding upon some exact wording. Here is my suggestion for an
amendment.
Remove the paragraph from proposal LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM
that begins "Implementations must guarantee that each reference....".
Replace it with:
Within a single call to EVAL, COMPILE, or COMPILE-FILE,
implementations are permitted to coalesce EQ LOAD-TIME-VALUE
expressions (that is, lists of the form (LOAD-TIME-VALUE ...) that are
EQ) appearing textually within the code being processed. Since a
LOAD-TIME-VALUE expression may be referenced in more than one place,
users must use caution when destructively modifying the resulting
object, as there may be other references to the object.
If any of you have some alternate wording you'd prefer to see, or or
some additional changes to include in the amendment, I'll be happy to
entertain further suggestions (but please try to be specific).
Well, I agree with the idea that when a form (LOAD-TIME-VALUE <form>)
is referenced from more than one place (compare be EQ), the system
is not required to evaluate the inner <form> more than once. The attempts
to define it otherwise just weren't working.
However, you've put in the phrase "Within a single call to EVAL" and I
cannot imagine what that actually means (because EVAL is recursive). I
don't think you responded to David Gray's objections to that phrase. Is
there any reason for it? How about the following wording instead?
Remove the three paragraphs from proposal
LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM that begin "Note that, in
interpreted code, ...", "Implementations must guarantee that each
reference....", and "In the case of a LOAD-TIME-VALUE form appearing
in a quoted expression passed to EVAL...". Replace those three
paragraphs with:
If the same (compared with EQ) list (LOAD-TIME-VALUE <form>) is
evaluated or compiled more than once, it is unspecified whether <form>
is evaluated only once or is evaluated more than once. This can
happen both when an expression being evaluated or compiled shares
substructure, and when the same expression is passed to EVAL or to
COMPILE multiple times. Since a LOAD-TIME-VALUE expression may be
referenced in more than one place and may be evaluated multiple times
by the interpreter, it is unspecified whether each execution returns
a "fresh" object or returns the same object as some other execution.
Users must use caution when destructively modifying the resulting
object.
If two lists (LOAD-TIME-VALUE <form>) are EQUAL but not EQ, their
values always come from distinct evaluations of <form>. Coalescing
of these forms is not permitted.
Note that I have removed all the vague wording that I objected to and
have removed the inconsistencies between the interpreter and the
compiler, except for the requirement that (similar to macros) after
COMPILE or COMPILE-FILE all the load time values are guaranteed to be
resolved, whereas the interpreter remains free not to cache. I'm
much happier with this wording than with what you proposed.