Re: printing structures

[Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>]

    Date: 5 Oct 86 20:08 PDT
    From: Masinter.pa@Xerox.COM

    Separating out I/O for for inter-program communication and the
    user-interface is a good idea, but your proposal puts the burden on
    inter-program communication ("wrap this one form around the portion of
    your program which does I/O.") rather than on the user interface.

I claim that's where the burden belongs.  Programs interact
with the user a lot more than they interact with other programs
via read/print.  And these interactions happen in a myriad
unpredictable way (consider tracing, for example).  The
user-interface is global, it's the inter-program I/O that's
localized, so that's why it gets the form wrapped around it.

Besides and every time programms communicate, you have to think about
whether what is being communicated can be communicated via read/print,
whether you need *print-circle*, etc, anyway.

    Wouldn't it be simpler to suggest that implementors of a
    "top-level-loop" might want to bind a separate I/O environment for
    reading and printing (but not for execution)?  
That doesn't solve the problem.  It isn't just a matter of
printing the return values, it's error messages, messages from
the program, debugging, etc. etc.

    Back onto the original discussion: we added a variable *print-structure*
We called ours *print-structure-contents*

    which controlled how structures were printed by the default structure
    printer, in the same way that *print-array* controls array output. I'm
    reluctant to propose additions to the language, but if one was wanted,
    this seems like a logical choice.
Indeed.