CLHS: Issue DEFSTRUCT-INCLUDE-DEFTYPE Writeup

#

## 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.

Copyright 1996-2001, Xanalys Inc. All rights reserved.