Re: Issue: PRINT-PRETTY-HOOK (version 1)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 21 Sep 88 23:27 PDT
    From: masinter.pa@Xerox.COM

    I thought at one time that extensions to prettyprint were going to be handled as
    specializations to a standard generic function in the same way that print-object
    is specializable.

If you read the writeup of print-object (88-002R p.2-67) you'll see that the
pretty printer is required to call the print-object generic function, just as
the ugly printer does.  Perhaps this wasn't said clearly enough.

As Pierson pointed out, this form of extension to the printer is orthogonal
to he wants to do.  I haven't figured out whether what he really wants is to
be allowed to redefine the unnamed function that WRITE, PRINT, PRINC, FORMAT,
etc. all call, or whether he wants to be able to redefine the unnamed function
that the read-eval-print loop calls to print things.  Either way, the
desire is for a standardized way to redefine a system function wholesale,
not to make it generic on its arguments.  This seems like a reasonable idea,
although there is likely to be a surprising number of implementation-dependent
difficulties.

Using the value of *PRINT-PRETTY* to enable a user-defined pretty printer is
incompatible with Symbolics' current practice, where the value of *PRINT-PRETTY*
tells the pretty printer additional information about the value being printed,
for instance whether it is a program or data.  This should be orthogonal to
the choice of which pretty printer to use.  This pretty printer was written
by Dick Waters, so perhaps his current portable pretty printer uses the same
technique.