CLHS: Issue UNINITIALIZED-ELEMENTS Writeup

#

## Issue UNINITIALIZED-ELEMENTS Writeup

    Forum:		Public Review
    Issue:        UNINITIALIZED-ELEMENTS
    Forum:	      CLEANUP
    References:   DEFSTRUCT (p308), MAKE-ARRAY (pp287-288)
    	      Moon's public review comment #3 (X3J13/92-3203)
    	      Issue BOA-AUX-INITIALIZATION
    Category:     CLARIFICATION
    Edit history: 24-Jun-91, Version 1 by Hornig
    	      12-Aug-91, Version 2 by Pitman (flesh out Problem Description
    	        and Examples, light editing of other sections, add endorsement)
    	      20-Dec-92, Version 3 by Loosemore (update writeup to reflect
    		draft 12.24; proposal is unchanged)
    	      08-Jan-93, Version 4 by Loosemore (more comments from Moon)
    Status:	      Version 2 failed 4-5-1 at Dec 1991 meeting
                  Version 4 passed 9-0-0 at Mar 1993 meeting

    Problem Description:

     CLtL says of ARRAY element initial values (p287):

       If the :initial-element option is omitted, the initial
       values of the array elements are undefined (unless the
       :initial-contents or :displaced-to option is used.)

       [Similar remarks are made for :initial-contents and
        :displaced-to.]

     CLtL says of DEFSTRUCT slot initial values (p308):

       If no default-init is specified, then the initial contents
       of the slot are undefined and implementation-dependent.

     From this wording, the draft specification (12.24) has chosen to say that
     uninitialized array elements have an "implementation-dependent value",
     but that "the consequences are undefined" if an attempt is made to read
     an uninitialized structure slot.

     Aside from the inconsistency being a source of confusion, the language
     in the array section would seem to prevent implementations from
     diagnosing references to uninitialized array slots in high-safety code,
     something that would be very helpful in debugging.

    Proposal UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED:

     Specify that the consequences of reading an uninitialized array
     element or structure slot are undefined.

    Test Case:

     #1: (LENGTH (LIST (AREF (MAKE-ARRAY 1) 0)))

         returned 1 under CLtL and draft 12.24
         but has undefined consequences under this proposal.

     #2: (DEFSTRUCT (KONS (:CONC-NAME "") (:CONSTRUCTOR KONS)) KAR KDR)
         (LENGTH (LIST (KAR (KONS))))

         returned 1 under CLtL
         but has undefined consequences under draft 12.24 and this proposal.

    Rationale:

     This change will permit, but not require, an implementation to detect
     reading of uninitialized values.  Reading an uninitialized value usually
     indicates a programming error.  Implementations which wish to ease
     debugging may detect this error and report it to the user.

     Implementations are already required to detect references to
     uninitialized symbol value and function cells in high safety mode,
     and to uninitialized slots in objects of types STANDARD-OBJECT
     and CONDITION in all safety modes.

    Current Practice:

     Symbolics currently initializes uninitialized array elements to a
     type-dependent value.  Symbolics currently detects references to
     uninitialized structure slots and calls the SLOT-UNBOUND generic
     function.

    Cost to Implementors:

     None.

    Cost to Users:

     This change might affect user programs which read uninitialized slots
     but then do absolutely nothing with the value (such as those in the
     Examples section).  In pracitce, there probably aren't a lot of
     programs with that property.

    Cost of Non-Adoption:

     Users will not be able to detect this important class of programming
     errors reliably.

    Benefits:

     High-safety implementations may continue to detect these problems.

    Aesthetics:

     Most people think it is unaesthetic to read a value which has not been
     initialized.

     Some people think it is unaesthetic to have the language initialize
     things to unspecified values.

    Editorial impact:

     The sections of text affected by this proposal are already flagged
     in the TeX sources for the draft.

    Discussion:

     Hornig, Pitman, Moon, and Loosemore have expressed support for some
     version of this proposal.

     Version 2 of this proposal failed by a narrow margin at the December
     1991 meeting, but the same issue was raised again by Moon's public review
     comment #3.

     According to Kent Pitman, the current inconsistency arose because some
     people were concerned that "implementations might have to blow out in
     the printer when someone did (MAKE-ARRAY 4)".  But various people wanted
     reading uninitialized structure slots to have undefined consequences
     because "the presence of CLOS and STRUCTURE-CLASS and SLOT-UNBOUND
     implies that it is reasonable for an implementation to call SLOT-UNBOUND
     and for SLOT-UNBOUND to signal an error when such a slot is accessed".

     Moon says:
      I don't see anything in the standard that requires the printer to
      "blow out" when printing an object for which there are applicable
      functions that have undefined consequences.  After all, the printer is
      not (required to be) a portable program and is not required to call
      any particular functions (except for PRINT-OBJECT on instances of
      user-defined classes).

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