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:

-------