Conditions and *PRINT-READABLY*

[Steve Haflich]

The dictionary page for *print-readably* says

   Individual *methods
<http://franz.com/support/documentation/current/ansicl/glossary/m.htm#method>*
 for *print-object*
<http://franz.com/support/documentation/current/ansicl/dictentr/print-ob.htm>,
including user-defined *methods
<http://franz.com/support/documentation/current/ansicl/glossary/m.htm#method>*,
are responsible for implementing these requirements.

so the implementation's applicable print-object method for class condition
violates this requirement.

The explanation of *print-readably* unwritten in the ANS is that it's
purpose is to provide a guarantee that something written will later be
rereadable without error, producing an object that is the "same" as the
original.  (The definition of "same" is a different Lisp execution
complicated, but not the central focus here.)  Mostly *print-readably*
guarantees that the emitted sequence of character can be reread without
signalling error.

All this depends on a bunch of other assumptions, and the necessary details
are incomplete in the ANS.  Here are just some of the issues:

What about *print-pretty* and dispatches defined in the current
pprint-dispatch?  If there is some such dispatch that would violate
rereadability, should the printer ignore that *print-pretty* is true?  A
naive reading of the standard suggests this is a requirement (despite being
operationally ridiculous) but perhaps the intention was that
*print-readably* ought just bind *print-pretty* false.  But if so, the ANS
would have said so.

What about other printer variables?  One might define a print-object method
that assumes that *print-base* will be the same at reread time -- but the
ANS doesn't say this.

Perhaps the ANS missed requiring that *print-readably* can assume the
emitted sexpr will be reread inside a with-standard-io-syntax?  But the ANS
doesn't say this.

What about the package system?  Whether the printed representation of a
symbol has zero, one, or two colons depends on the current state of the
package system.  Should *print-readably* assume the package system will be
the same at read time?  Perhaps, but the ANS doesn't say this.  And
with-standard-io-syntax doesn't help with this.

There are a great many more potential issues.  We must conclude that
*print-readably* is only a hook for user code to provide a _weak_ guarantee
that no _other_ user code will do things that prevent printed output from
being rereadable without likely notification at write time.  But to achieve
even this weak guarantee, user code must cooperate with what it knows about
the printer and reader.  That it applies to the printer representation of
conditions might protect a mostly-numeric output file from containing an
unreadable #<floating-point-underflow> object where a float is expected.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20150906/b0aed85d/attachment.html>