Issue DEFVAR-INIT-TIME (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Issue:        DEFVAR-INIT-TIME
References:   DEFVAR (p68)
Category:     CLARIFICATION
Edit history: 23-Apr-87, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  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.

Proposal (DEFVAR-INIT-TIME:NOT-DELAYED):

  Clarify that the evaluation of the initial value and the initialization
  happen at DEFVAR execution time (if at all).

Rationale:

  I think it was clear at design time that this was intended. The manual
  should therefore be clear.

Current Practice:

  Nearly all implementations implement the proposed interpretation.

Adoption Cost:

  The misinterpretation is much harder to implement than the proposed
  interpretation. Adoption of the changes should be straightforward.

Benefits:

  This clarification makes the semantics of an important primitive 
  more well-defined.

Conversion Cost:

  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.

Aesthetics:

  Being a clarification, this really doesn't have much aesthetic effect.

Discussion:

  KMP thinks this clarification is important.