CLHS: Issue DEFVAR-INIT-TIME Writeup

#

## Issue DEFVAR-INIT-TIME Writeup

    Issue:        DEFVAR-INIT-TIME
    References:   DEFVAR (p68)
    Category:     CLARIFICATION
    Edit history: 23-Apr-87, Version 1 by Pitman
                  29-Mar-87, Version 2 by Masinter

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

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

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

    Rationale:

    This clarification follows the intent of the original Common Lisp
    designers.

    Current Practice:

    Nearly all implementations implement the proposed interpretation.

    Adoption Cost:

    None, for most implementations; very small for any the implementation
    that adopted delayed evaluation.

    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:

    The cleanup committee supports this clarification.

Copyright 1996-2001, Xanalys Inc. All rights reserved.