Issue DEFSTRUCT-CONSTRUCTOR-OPTIONS Writeup

Forum:		Cleanup

Issue:		DEFSTRUCT-CONSTRUCTOR-OPTIONS

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

Category:	CLARIFICATION

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

function?


Does specifying an explicit :constructor option inhibit DEFSTRUCT from

creating the default keyword constructor or does one have to

explicitly say (:constructor nil)?



Proposal (DEFSTRUCT-CONSTRUCTOR-OPTIONS:EXPLICIT):


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.



Rationale:


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

understand.



Current Practice:


Varies widely.


Lucid Common Lisp and Kyoto Common Lisp appear to implement this

proposal.


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.



Benefits:


Increased portability of application code using DEFSTRUCT.



Discussion:


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

to conform to it.

-------