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

[Dan L. Pierson <pierson%mist@multimax.ARPA>]

                                   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.
    
I want to be able to redefine all of the above, in particular I want
to be able to force all interaction, including REP loops, debugger,
tracer, etc. to use my pretty print function.  Of course it will
always be possible for a sufficiently dedicated implementation or
application to defeat this either by rebinding *PRINT-PRETTY* or by
using internal print functions which don't follow the normal rules,
but there will be much less chance of an implementation or application
unintentionally preventing me from specifying my own pretty printer.
Also of course, if I do this I take the risk that my pretty printer
will interact unfavorably with the implementation in other ways, but
as one vendor likes to say: "Here's the gun, there's my foot".

    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.

Well, if the *PRINT-PRETTY* value hack won't work I'm open to
suggestions.  One possibility is to add a new variable, say
*PRINT-PRETTY-FUNCTION*.  Another, which will cause screams of
outrage, is to fbind *PRINT-PRETTY* as well as bind it.  User
redefinition of PPRINT is probably not a good choice.