#

## Issue DEFSTRUCT-PRINT-FUNCTION-AGAIN Writeup

    Forum:		Public Review
    Issue:		DEFSTRUCT-PRINT-FUNCTION-AGAIN
    References:	Loosemore's public review comment #25 (X3J13/92-1325)
    		Norvig's public review comment #8.1 (X3J13/92-2208)
    		Pitman's public review comment #7 (X3J13/92-2707)
    		Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
    		DEFSTRUCT :PRINT-FUNCTION option  (p 8-10 and 8-11)
    		PRINT-OBJECT (p 22-55)
    Category:	CHANGE
    Edit history:	24 Dec 1992, Version 1 by Loosemore
                    01 Jan 1993, Version 2 by Loosemore (fix references,
    		  add method signature for print-object)
    Status:         Parts (2),(3),(4) only passed 6-1, March 1993

    Problem description:

      Supplying the :PRINT-FUNCTION option to DEFSTRUCT is supposed to
      be equivalent to defining a PRINT-OBJECT method, but the two can't
      be entirely equivalent since the :PRINT-FUNCTION takes a third
      argument (the current recursive printing depth) that the PRINT-OBJECT
      method does not.

      It is also not clear whether the inheritance of structure
      :PRINT-FUNCTIONs by the :INCLUDE option works in such a way that
      one may use CALL-NEXT-METHOD and the like.

    Proposal (DEFSTRUCT-PRINT-FUNCTION-AGAIN:REPLACE-OPTION):

      (1) Remove the :PRINT-FUNCTION option to DEFSTRUCT.

      (2) Add a new DEFSTRUCT option, :PRINT-OBJECT, and document it
          as follows:

          This option can be used only if :TYPE is not supplied.  The
          argument to :PRINT-OBJECT should be in a form acceptable to
          FUNCTION, and is used when printing structures of this type.
          The function is called with two arguments: the structure to
          be printed and the stream to print to.

          Supplying (:PRINT-OBJECT fn) in a DEFSTRUCT definition for
          a structure named s is equivalent to executing

          (defmethod print-object ((object s) stream)
            (funcall (function fn) object stream))

          The :PRINT-OBJECT option can also be supplied without an
          argument.  This is equivalent to defining a PRINT-OBJECT
          method which calls a function that prints the structure in
          the default #S notation.  [Kent Pitman's comment #7 proposes
          to name this function PRINT-OBJECT-USING-SLOTS.]

          If no :PRINT-OBJECT option is provided, then DEFSTRUCT does
          not generate a PRINT-OBJECT method specialized on the named
          structure class.

      (3) Change places in chapter 22 that refer to "print functions"
          to refer to "PRINT-OBJECT methods" instead.

      (4) Add to the "Method Signatures" section for PRINT-OBJECT:

          print-object (object structure-object) stream

          In the "Description" section for PRINT-OBJECT, state that the
          method on the class structure-object prints the object in the
          default #S notation as described in section 22.1.3.15.

    Rationale:

      The addition of PRINT-OBJECT and the pretty-printing protocol makes
      it clear that *PRINT-LEVEL* truncation is handled automatically by
      the printer, so the third argument to :PRINT-FUNCTION functions is
      useless.

      Simply redefining :PRINT-FUNCTION to take functions of two arguments
      rather than of three would break existing programs.  Replacing it
      with a new option with a different name permits implementations to
      continue to support the old :PRINT-FUNCTION as an extension, and/or
      issue diagnostics about obsolete usages.

      Specifying the behavior of :PRINT-OBJECT entirely in terms of
      PRINT-OBJECT and normal method definition means that the standard
      doesn't have to discuss :PRINT-OBJECT functions as a special case.
      This makes the standard conceptually simpler.

    Current practice:

      Nobody ever does anything useful with the third argument to
      :PRINT-FUNCTION functions anyway.

    Cost to implementors:

      Some implementations will doubtless have to change, but the addition
      of the PRINT-OBJECT and pretty-printer protocols already means that
      many implementations will have to rework their printers anyway.

    Cost to users:

      This is an incompatible change, but one that can be detected
      easily.  Implementations may continue to support :PRINT-FUNCTION
      as an extension for backward compatibility.

    Aesthetics:

      I like it.

    Editorial impact:

      The references to :PRINT-FUNCTION in the structures and printers
      chapters will have to be changed.

    Discussion:

      Barrett notes that the description for the PRINT-OBJECT method on
      standard-object doesn't say anything about how it actually prints
      the objects.  Presumably this is covered by section 22.1.3.16, which
      says that "other objects are printed in an implementation-dependent
      manner".

Copyright 1996-2005, LispWorks Ltd. All rights reserved.