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