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