Re: Issue: DATA-IO (version 7)

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

    Date: Mon, 19 Jun 89 11:21:36 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    I have two remarks on this proposal.

    In section 1a, it says:

      If *PRINT-READABLY* is true, then printing any object produces a
      printed representation that the reader will accept.

    This seems underspecified to me.  At least for implementation-defined
    print methods, it ought to be stated what the relationship is between
    the object that is printed and the object that is read in again is.

I had assumed this was already specified for PRINT, independent of
*PRINT-READABLY*.  CLtL p.333 mentions the issue but its off-handed
comment about "obscure technical exceptions" does not make me feel secure.
"What the Print Function Produces" (CLtL p.365) says some fairly specific
things.

    Can we use "similar as constants" here?

Probably.  I'll have to go re-read its definition before I can so for
sure.  I'll see if I can find the time to prepare an amendment to bring
to the meeting (although if someone else volunteers to do it, I am 
unlikely to complain!)

    In sections 1c, 1d, and 1e, it uses "might" to describe the
    interaction between *PRINT-READABLY*, *PRINT-LEVEL*, *PRINT-LENGTH*,
    and *PRINT-ESCAPE*.  Is there some reason that we can't tie this behavior
    down more definitely?

Only that I didn't think it was important and didn't want to spend the time
to try to find something that made sense and was consistent with all forms
of current practice (if possible).  I think an amendment would be good
if you have definite behavior you'd like to propose.  I'll see if I can
find the time to think about this, but I can't promise anything.