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


Forum:		Public Review



References: DEFSTRUCT (p308), MAKE-ARRAY (pp287-288)

Moon's public review comment #3 (X3J13/92-3203)



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


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.


Specify that the consequences of reading an uninitialized array

element or structure slot are undefined.

Test Case:


returned 1 under CLtL and draft 12.24

but has undefined consequences under this proposal.



returned 1 under CLtL

but has undefined consequences under draft 12.24 and this proposal.


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


Cost to Implementors:


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.


High-safety implementations may continue to detect these problems.


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


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.


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

[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.