CLHS: Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE Writeup

#

## Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE Writeup

    Issue:          DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
    References:     CLtL p. 312-314
    Category:       CLARIFICATION
    Edit History:   V1, 5 Aug 1988, Sandra Loosemore
                    V2, 15 Sep 1988, Sandra Loosemore
                    V3, 7 Dec 1988, Masinter

    Problem Description:

    CLtL doesn't make clear whether defstructs that :INCLUDE another
    structure type and do not specify a :PRINT-FUNCTION inherit the
    :PRINT-FUNCTION of the parent structure type.  While it is stated on
    page 314 that #S syntax is used if a :PRINT-FUNCTION is not specified,
    the language on page 313 indicates that all operations on the parent
    type will also work on objects of the child type.  Because of the
    ambiguity, existing implementations have gone both ways, and users
    cannot depend on either #S syntax or the parent type's :PRINT-FUNCTION
    being used.

    Proposal: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES

    Clarify that defstruct types which :INCLUDE another type but do not
    specify an explicit :PRINT-FUNCTION inherit the structure print
    function from the :INCLUDE'd type.  A print function that uses the
    default #S syntax (overriding any print function for the parent type)
    can be specified by providing the :PRINT-FUNCTION option without an
    argument.

    Supplying a :PRINT-FUNCTION in a DEFSTRUCT is equivalent
    to defining an appropriate method on the PRINT-OBJECT generic
    function.

    Rationale:

    Users typically specify a print function for a structure type because
    its slots will contain circular objects or large internal data
    structures which are confusing when printed.  Any structure type that
    :INCLUDEs this type will also contain the same slots; it seems more
    reasonable to inherit the parent's print function than to use the
    default #S syntax.

    Current Practice:

    Lucid Common Lisp makes structures inherit print functions.
    VaxLisp uses #S syntax unless an explicit :PRINT-FUNCTION
    is specified.

    Cost to implementors:

    The changes to non-conforming implementations should be fairly minor
    and localized.

    Cost to users:

    It can't be any worse than the status quo.

    Benefits:

    An area of ambiguity in the language will be removed.

    Discussion:

    Pitman and VanRoggen support this proposal.

    The original version of the proposal did not provide for a way to
    force #S syntax to be used.  This functionality was added to the
    current version because there seemed to be general agreement that it
    would be useful.  Other alternatives would be to name the function
    that does what the #S printer does, or to provide a function that
    returns the #S information as a list (as suggested by Waters) so users
    can write their own.

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