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



References: CLtL p.308-10 & 86-003 p.4


Edit history: Revision 1 by Skona Brittain 05/13/88

Problem Description:

There is some confusion over whether default initialization

forms for defstruct slots get evaluated, when they are not needed

because a keyword argument was supplied to the constructor function.

As a consequence of this confusion, there is confusion over whether

there can be a type-mismatch error between the specified type of the slot

and the type of the default value.

On page 308, it says "The default-init is a form that is evaluated

each time a structure is to be constructed; the value is used as the

initial value of the slot. If no default-init is specified, then the

initial contents of the slot are undefined and implementation-dependent."

On the next page, however, it says that the default-init is evaluated if

the keyword argument is not supplied and the converse, although not stated,

is intended and informally implied.


Clarify that the converse is true. i.e that the default-init is not evaluated

if the keyword argument is supplied.

In the quote from page 308, delete the second sentence and replace

"a structure is to be constructed; the value is" by "its value is to be".

To section 19.3, add a clarification,

such as the following from Guy's issues file:

"The default value in a defstruct slot is not evaluated

unless it is needed in the creation of a particular structure

instance. If it is never needed, there can be no type-mismatch

error, even if the type of the slot is specified, and no warning

should be issued."

Test Case:

In the following sequence, only the last call is an error.

(defstruct person (name 007 :type string))

(make-person :name "James")



It is inefficient, and inconsistent with the rest of the language, for the

default initialization form to be evaluated when it is not needed.

Consequently, when it's not needed, such type-mismatch errors should not be

detectable in general.

Any existing confusion should be clarified by this proposal.

Current Practice:

KCL does not evaluate the default initialization form unless it is needed;

even when it is needed, the type checking is not done at all.

Cost to Implementors:

If there are any implementations that currently behave differently from

the proposed way, then they need some slight modification.

Cost to Users:



Clarity and portability. In particular, clarifying that the unaesthetic

situation mentioned in the next section is allowed should be reassuring.


It appears slightly unaesthetic to have a default value that violates a

type specification.


Although this issue was mentioned in Guy's original issues file, it has

not been officially discussed since.


Additional notes:

Several members of the cleanup committee endorsed this proposal.

JonL added:

You can add to the "Current Practice:" section:

LUCID does not evaluate the default initialization form unless it is

needed; even when it is needed, the type checking is not done at all.

However, at structure definition time, if an initial value form is

constanp and doesn't satisfy the :type specification, a warning message

is printed.

Oddly enough, Lucid's interpreter ensures that SETF's of slots obey the

:type specifier, even though init-forms aren't checked. Furthermore, in

safety levels 2 or higher, the compiled code will do minimal "memory-

integrity" type checking for SETF's (which is what I suspect the various

special-purpose microcoded machines do); however except for low-level numeric

types, this is rarely equivalent to what a full type check would do.

I have long suggested that there should be at least one mode of operation

such that all :type information is checked when setting values into structure

slots (setf as well as initialization). Some have suggested that this mode

could be "when running interpretively, or when when compiled with the highest

degree of SAFETY and lower degrees of SPEED." However, since the wording of

CLtL p310 suggests that the :type slot options is merely a DECLARE, and since

some vendors effectively ignore any and all declarations [except for SPECIAL],

then this suggestion hasn't reached proposal stage yet.

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