[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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:

-------


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.