References: DEFSTRUCT; CLtL p. 309, 311, 315-316
Edit History: V1, 11 Oct 1989, Sandra Loosemore
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
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
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.