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.