References: DEFSTRUCT's :INCLUDE option (pp312-314)
Edit history: 01-Mar-91, Version 1 by Pitman
Status: For X3J13 consideration
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.
Clarify that the only names which are permissible as type names to
the :INCLUDE option of DEFSTRUCT are actual names previously defined
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.
(DEFSTRUCT FOO A B)
(DEFTYPE FU () 'FOO)
(DEFSTRUCT (BAR (:INCLUDE FU)) C)
Permitting DEFTYPE-defined types here might open the door to other
inconsistencies with DEFTYPE-defined types not being accepted in other
Most implementations probably don't allow this and a change would
be extra work for implementors.
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.
Users will know what to expect.
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.
Pitman supports this proposal.