Re: Issue: DATA-IO (version 7)

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> 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.

Right.  What I want to know is, does the addition of *PRINT-READABLY*
cause changes or additions to anything already stated in this section?
For example, if *PRINT-READABLY* is true, are arrays still required to
print using #A syntax even though it loses information about
attributes such as the element type?  (For that matter, is there an
interaction between *PRINT-ARRAY* and *PRINT-READABLY*?)  I question
whether this proposal is really ready to be voted on in its current
state.

>     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 mostly just want to see one rule that is applied consistently when
*PRINT-READABLY* is true and the value of any of the other variables
is such that the object would otherwise be printed in an unreadable
manner.  The two obvious choices are that either the other variable is
ignored, or that an error is signalled.  The first might be slightly
easier to implement but I don't really have a strong preference one
way or the other.  (Even if it's decided to leave this behavior
unspecified, I think describing it in this way instead of as a bunch
of special cases would improve the presentation.)

-Sandra
-------