[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue DEFVAR-INIT-TIME (Version 1)
- To: CL-Cleanup@SAIL.STANFORD.EDU
- Subject: Issue DEFVAR-INIT-TIME (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 23 Apr 87 16:59 EDT
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: DEFVAR (p68)
Edit history: 23-Apr-87, Version 1 by Pitman
Status: For Internal Discussion
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 structure.''
Although I think the original CL designers all knew what this wording
was intended to mean, I have discovered people who have misinterpreted
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.
Having made this false assumption, the people I talked to thought --
and understandably (if lamentably) so -- that they wouldn't know if
the variable was to be used until the code ran, so they had the model
that the intention was to provide a kind of lazy initialization that
happened upon the variable's first unbound reference. This confusion
appears to have been further supported by the additional verbiage 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).
I think it was clear at design time that this was intended. The manual
should therefore be clear.
Nearly all implementations implement the proposed interpretation.
The misinterpretation is much harder to implement than the proposed
interpretation. Adoption of the changes should be straightforward.
This clarification makes the semantics of an important primitive
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.
KMP thinks this clarification is important.