[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.