[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.