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


Forum:		Cleanup


References: DEFSTRUCT; CLtL p. 309, 311, 315-316


Edit History: V1, 11 Oct 1989, Sandra Loosemore

Problem Description:

It is permitted to specify multiple :constructor options to DEFSTRUCT,

but the interactions between them are unclear.

Is it legitimate to specify multiple (:constructor <name>) options to

DEFSTRUCT to get multiple copies of the default keyword constructor


Does specifying an explicit :constructor option inhibit DEFSTRUCT from

creating the default keyword constructor or does one have to

explicitly say (:constructor nil)?


Clarify that DEFSTRUCT creates the default keyword constructor only if

no explicit :constructor options are specified, or if the :constructor

option is specified without an argument.

(:constructor nil) is meaningful only when there are no other

:constructor options specified. It prevents DEFSTRUCT from generating

any constructors at all.

Otherwise, DEFSTRUCT builds a constructor function corresponding to

each supplied :constructor option. It is permissible to specify both

multiple BOA constructors and multiple keyword constructors.


This proposal treats all of the :constructor options uniformly as a

group. Instead of viewing each individual option as something that

adds to or modifies the behavior, the entire set of specified

:constructor options taken as a whole tell DEFSTRUCT to do something

*instead of* its default behavior. Treating all :constructor options

uniformly in this respect should make the behavior easier to


Current Practice:

Varies widely.

Lucid Common Lisp and Kyoto Common Lisp appear to implement this


Utah Common Lisp currently allows only one keyword constructor. If a

(:constructor name) option appears more than once, it ignores all but

one. It always makes a keyword constructor unless (:constructor nil)

is explicitly specified, even if BOA constructors are explicitly

requested. CMU Common Lisp appears to behave in the same way.

HPCL-I signals an error if multiple (:constructor name) options appear.

It also always makes a keyword constructor unless (:constructor nil) is

explicitly specified.

Cost to implementors:

Probably wouldn't take more than a few hours to fix.

Cost to users:

Code (that is currently nonportable anyway) that assumes the default

keyword constructor will be created unless it is explictly disabled

with (:constructor nil) would have to be changed.


Increased portability of application code using DEFSTRUCT.


Loosemore supports this proposal even though she would have to fix UCL

to conform to it.


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