[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue DEFVAR-INIT-TIME (Version 2)
- To: CL-Cleanup@SAIL.STANFORD.EDU
- Subject: Issue DEFVAR-INIT-TIME (Version 2)
- From: Masinter.pa@Xerox.COM
- Date: 29 May 87 21:15 PDT
- Cc: Masinter.pa@Xerox.COM
Status: I worked over the wording on this one a little. Ready for
References: DEFVAR (p68)
Edit history: 23-Apr-87, Version 1 by Pitman
29-Mar-87, Revision 2 by Masinter
The description of DEFVAR is not completely clear about the time at
which the initialization occurs.
On p68 it says ``VARIABLE is initialized to the result of evaluating the
form INITIAL-VALUE unless it already has a value. The INITIAL-VALUE form
is not evaluated unless it is used; this fact is useful if evaluation of
the INITIAL-VALUE form does something expensive like create a large data
At least one implementation interpreted the "unless it is used" to mean
"unless the variable is used" rather than "unless the initial-value is
to be used". The problem is that the "it" is ambiguous. Thus, DEFVAR was
interpreted as a kind of lazy initialization that happened upon the
variable's first unbound reference. (This interpretation appears to have
been further supported by the additional wording in CLtL about not
creating expensive structures that are not needed.)
Clarify that the evaluation of the initial value and the initialization
happen at DEFVAR execution time (if at all). The cause of the confusion
is the statement that the initial value form is not evaluated unless "it
is used". Better to say that INITIAL-VALUE is evaluated if and only if
the variable does not already have a value. Then there would be no
confusion about the time of evaluation.
This clarification follows the intent of the original Common Lisp
Nearly all implementations implement the proposed interpretation.
None, for most implementations; very small for any the implementation
that adopted delayed evaluation.
This clarification makes the semantics of an important primitive more
Most users presumably expect the behavior currently in practice in most
dialects. There's not a lot of code where the difference comes into play
anyway. Presumably the conversion cost is fairly trivial.
Being a clarification, this really doesn't have much aesthetic effect.
The cleanup committee supports this clarification.