CLHS: Issue DEFTYPE-DESTRUCTURING Writeup

#

## Issue DEFTYPE-DESTRUCTURING Writeup

    Issue:            DEFTYPE-DESTRUCTURING
    References:       DEFTYPE
    Related issues:   DEFTYPE-KEY
    Category:         CLARIFICATION, CHANGE
    Edit history:     V1, 23 May 90, Sandra Loosemore

    Problem description:

      The specification of DEFTYPE is not clear on the issue of whether
      it is supposed to support destructuring.  The description in CLtL
      twice compares its syntax to that of DEFMACRO, leading some
      people to think that it does support destructuring.  However,
      since destructuring is not explicitly mentioned, other people
      think it does not.

      There are two proposals, YES and NO.

    Proposal (DEFTYPE-DESTRUCTURING:YES):

      Clarify that DEFTYPE does support destructuring of the lambda list.
      The lambda-list syntax for DEFTYPE is identical to that of
      DEFMACRO.

      Rationale for proposal YES:
        Some people think this is the way it was really supposed to
        work, and that supporting destructuring makes the syntax of
        DEFTYPE more consistent with other defining macros.

    Proposal (DEFTYPE-DESTRUCTURING:NO):

      Clarify that DEFTYPE does not support destructuring of the lambda
      list.

      Rationale for proposal NO:
        This requires minimal changes for implementors.  The use of
        destructuring with DEFTYPE is rare and since some
        implementations do not support it now, code that relies on
        it working is already nonportable.

    Current Practice:

      Spice Lisp implemented a destructuring DEFTYPE, and a number
      of implementations have copied this behavior.  Other
      implementations do not support destructuring in DEFTYPE.

    Cost to Implementors:

      For proposal YES, fairly small, since every implementation
      already has support for destructuring for other parts of
      the language.

      For proposal NO, none.  Implementations that now support
      destructuring can continue to do so as an extension.

    Cost to Users:

      None for either proposal.  Code that relies on destructuring
      with DEFTYPE is already not portable, but on the other hand
      adding destructing support shouldn't break code that doesn't
      use it.

    Cost of non-adoption:

      Continuing vagueness in this part of the language specification.

    Performance impact:

      Probably insignificant.

    Benefits:

      This part of the language specification is made more clear.

    Esthetics:

      Seems to be a matter of personal taste.

    Discussion:
    -------

Copyright 1996-2005, LispWorks Ltd. All rights reserved.