Forum: Public Review
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
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.
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
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
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
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.
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.
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
Making the language more consistent is a good idea.
Tweaking two sentences on page 3-48.
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
(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.)