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


Issue DEFSTRUCT-INCLUDE-DEFTYPE Writeup

Issue:        DEFSTRUCT-INCLUDE-DEFTYPE

Forum: Editorial

References: DEFSTRUCT's :INCLUDE option (pp312-314)

Category: CLARIFICATION

Edit history: 01-Mar-91, Version 1 by Pitman

Status: For X3J13 consideration

Problem Description:

From time to time, people ask whether they can specify in a :INCLUDE

to DEFSTRUCT the name of a type which is defined by DEFTYPE to expand

into a type that was defined by DEFSTRUCT.

Proposal (DEFSTRUCT-INCLUDE-DEFTYPE:EXPLICITLY-UNDEFINED):

Clarify that the only names which are permissible as type names to

the :INCLUDE option of DEFSTRUCT are actual names previously defined

by DEFSTRUCT.

Clarify that one implication of this is that the consequences are

undefined if a type given to DEFSTRUCT's :INCLUDE option is a type

defined by DEFTYPE, even if it expands into a type defined by DEFSTRUCT.

Test Case:

(DEFSTRUCT FOO A B)

(DEFTYPE FU () 'FOO)

(DEFSTRUCT (BAR (:INCLUDE FU)) C)

Rationale:

Permitting DEFTYPE-defined types here might open the door to other

inconsistencies with DEFTYPE-defined types not being accepted in other

`reasonable' places.

Most implementations probably don't allow this and a change would

be extra work for implementors.

Current Practice:

Symbolics Genera signals an error if the :INCLUDE'd type was not

specifically defined by DEFSTRUCT.

Cost to Implementors:

None. "The consequences are undefined" leaves implementations free to

do whatever they want.

Cost to Users:

None. Users de facto can't really rely on this now so portable

programs shouldn't be effected.

Cost of Non-Adoption:

Some users will continue to be puzzled about whether the perceived-to-be

fascist behavior of some implementations is what was intended.

Benefits:

Users will know what to expect.

Aesthetics:

Doing the full job of making DEFTYPE-defined types acceptable in any

place might be aesthetic, but that's not what is proposed here, and making

a lot of little special case exceptions probably isn't so aesthetic.

Discussion:

Pitman supports this proposal.


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