CLHS: Issue BOA-AUX-INITIALIZATION Writeup

#

## Issue BOA-AUX-INITIALIZATION Writeup

    Forum:		Public Review
    Issue:		BOA-AUX-INITIALIZATION
    References:	Loosemore's public review comment #26
    		Boa lambda lists, Section 3.4.6, page 3-48
    		DEFSTRUCT :TYPE slot option, page 8-4
    		DEFSTRUCT slot-initform, page 8-3
                    CLtL-2 p 482
                    Issue UNINITIALIZED-ELEMENTS
    Category:	CLARIFICATION/CHANGE
    Edit history:	26 Dec 1992, Version 1 by Loosemore
    Status:         Proposal ERROR-ON-READ failed 7-3 on letter ballot 93-302.
    		Proposal ERROR-ON-READ passed 7-0 at October 1993 meeting.

    Problem description:

      In the discussion of BOA constructor lambda lists on page 3-48
      says that, for a slot whose name is given as an &AUX variable
      without an initialization form, the "slot is not initialized; its
      initial value is implementation-defined."  The corresponding
      passage from CLtL says the initial value is "undefined" rather
      than "implementation-defined".

      It is not clear whether and when errors about the uninitialized slot
      might be detected.  If the slot is given an "implementation-defined"
      value, for example, is it permissible for the implementation to
      signal an error at instance creation time if the slot :TYPE for
      the uninitialized slot doesn't match the type of the value that
      particular implementation has chosen?  Or is it permissible for
      implementations to signal an error if an attempt is later made to
      read the slot's value before it has been explicitly assigned a
      (type-correct) value?

    Proposal (BOA-AUX-INITIALIZATION:ERROR-ON-READ):

      Make BOA constructors with &AUX variables without an initialization
      form treat the corresponding slots in the same way as slots defined
      without an slot-initform; the consequences are undefined if an attempt
      is later made to read the slot's value before a value is explicitly
      assigned.

      Clarify that, if such a slot has a :TYPE option specified, there can
      be no type mismatch error when initialization of the slot is suppressed
      in this way.

    Rationale:

      This makes the treatment of uninitialized structure slots consistent.
      It also makes it permissible for implementations to diagnose references
      to uninitialized structure slots in high-safety code, which is helpful
      in debugging.  (See issue UNINITIALIZED-ELEMENTS.)

      The interpretation of the &AUX syntax in BOA constructors was carefully
      chosen to permit the default structure slot initializations to be
      overridden completely.  There are some circumstances -- such as when
      setting up complicated circular data structures -- when there is
      simply no appropriate value that could be used as a default.  While
      one could simply specify the DEFSTRUCT definition without slot-initforms
      for those slots to get the right behavior, one would also lose the
      benefit of type-checking on accesses to the slot since DEFSTRUCT
      syntax allows one to specify the :TYPE option only if a slot-initform
      is also specified.

    Current practice:

      At least one implementation (CMU CL) signals a type mismatch error at
      instance creation time if the slot type you specified doesn't match
      that of the value that particular implementation has chosen to store
      in these slots.

      Other implementations either do no type checking, or defer type
      checking until when the slot's value is read.

    Cost to implementors:

      Those implementations that now do type-checking at instance creation
      time will have to be changed.  This is probably not a huge change.

    Cost to users:

      Some user code may be broken by this change; but such code is already
      nonportable.

    Aesthetics:

      Making the language more consistent is a good idea.

    Editorial impact:

      Tweaking two sentences on page 3-48.

    Discussion:

      The consensus of the public review committee was that this proposal
      was the best of the alternatives.

      Clarifying that we really want the initial value of these slots to be
      "implementation-defined" would have the problem that it would be
      impossible for users to portably specify a slot :TYPE other than T.

      The possibility of having the standard specify an explicit value (NIL)
      for uninitialized slots was also mentioned, but this was considered
      unaesthetic; it would still weaken type-checking to some extent, make
      it harder to detect uninitialized slots, and be inconsistent with other
      parts of the language.

      Rob MacLachlan says, about CMU CL's behavior:

        Our interpretation is that the slot type declaration must encompass
        all values that the slot can be created with.  This is important,
        since we want all possible values of the slot accessor to be of that
        type.

      (In other words, it appears they want to do type-checking when the
      slots are written rather than when they are read, since writing is
      a less frequent operation.)

Copyright 1996-2005, LispWorks Ltd. All rights reserved.