#

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

Copyright 1996-2001, Xanalys Inc. All rights reserved.