[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: printing structures
- To: Masinter.pa@Xerox.COM
- Subject: Re: printing structures
- From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
- Date: Tue, 7 Oct 86 00:01 EDT
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: <861005-200551-3386@Xerox>
Date: 5 Oct 86 20:08 PDT
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.