princ & *print-readably* 
Author Message
 princ & *print-readably*

| what should (let ((*print-readably* t)) (princ "zz")) print?  "zz" or zz?

 "PRINC is just like PRIN1 except that the output has no escape characters.
  It binds *PRINT-ESCAPE* to false and *PRINT-READABLY* to false."

  that's quoted from the HyperSpec (with symbol names upcased by me).

  religious cult update in light of new scientific discoveries:
  "when we cannot go to the comet, the comet must come to us."

Sat, 09 Sep 2000 03:00:00 GMT  
 princ & *print-readably*


> what should (let ((*print-readably* t)) (princ "zz"))
> print? "zz" or zz?
> ACL says zz, CMU says "zz", and CLISP said "zz" untill the today's patch
> wich changed this to zz. Who is right?

Remember that Lisp is somewhat schizo about the use of the names print
and prin1.   PRINT-OBJECT, for example, implements PRIN1, not PRINT.

PRIN1 is only so-called for ancient reasons.  It ought to have been named
PRINT and PRINT should have been named PRINT-ON-OWN-LINE or something.
But for reasons of history and compatibility, it wasn't.

*PRINT-READABLY* is best understood as *PRIN1-READABLY*.  Its role in life
is to bridge the gap between the fact that many things have a printed
representation that is re-readble, but many do not.  In particular,
hash tables, streams, etc. are not re-readable.  So there is nothing
more annoying than writing a program that does


only to find out  what was saved to a file was

  (FOO BAR ...)


  (FOO BAR #<STREAM ...>)

because tomorrow when I'm going to do


I'm going to get a syntax error.  So *PRINT-READABLY* tells Lisp
that programs doing printing should err at PRINT-time when they
fully well know that the result will not be re-readable.  Much better
to know your save failed and that you need to take alternate action
(while the image is still running on day 1) than to find out later.

This has happened to me more than once in the olden days.  I'm sure
to others as well.  The fix was:


[Actually, there are aalso "typical bugs" related to mismatch of
package, etc, too.  Hence really,


is better; it binds not only *PRINT-READABLY* but a number of
other things people often forget to bind that they should.

Now comes the problem of PRINC.

Here's a fact worth noting:

      No one calls PRINC ever in files to be
      re-readable so it's just nutty to change it's behavior.
      That is, if a program does:
      or even (PRINC *SOME-OF-MY-DATA* STREAM)
      we know that one of these things is true:
        (a) you're lost whether or not you're using *print-readably*
        (b) you're not re-reading with READ
        (c) you're implementing PRINT using PRINC as a sub-primitive.

Here's another observation:

 print-object methods often call PRINC out of tradition, often where
 write-string is desired.    Some of this is tradition.  Some is
 becuase ~A in format is used and there is no write-string operation
 in format.  Having *print-readably* randomly turn a ~A into ~S would
 be an unmitigated disaster becuase it would break print-object
 methods everywhere, making them insert quotes, backslashes, etc.
 all over the place.

As Erik points out, as far as the spec goes, there is no question
(PRINC "FOO") should print FOO, not "FOO" no matter the binding of
*PRINT-ESCAPE* or *PRINT-READABLY* that prevails outside the call to
PRINC, since PRINC binds both of these variables to false while it
executes, and so no code within it would be aware of the values
prevailing outside.

But I thought you might want to see the history/motivation so you
could feel comfortable that this is not an accident or typo.

Sat, 09 Sep 2000 03:00:00 GMT  
 princ & *print-readably*


>  Now I will be
> using with-standard-io-syntax.  But I have a question about it: CHKS says
> that it binds *print-circle* to nil.  Why?  Although it is the default
> value, this will prevent the reader from reading in the exact copy of
> the data that I wrote!

There's not much of a satisfying answer to this.  Some people think
*print-circle* being T is the only correct setting. Some do not work
with circular data structures and think the entire issue is not about
correctness but efficiency.

In fairness, if circular structure fails to print out correctly, it's
because it was circular and it probably doesn't terminate so probably
you get something close to an error (at least you get a "problem of
some kind").

Then again, you might have set *PRINT-CIRCLE* globally to T knowing
you were working with circular objects, and it's pretty obnoxious for
a system macro to helpfully bind that back to NIL for no other purpose
than "normalizing the value".  I bet someone didn't anticipate that
particular problem.

It happened that sometimes when I made edits to the spec to simply add
a new thing, I forgot to use change markers, so you don't get a pointer from
issue DATA-IO in the hyperspec back to WITH-STANDARD-IO-SYNTAX even though
DATA-IO was the issue that introduced it.  But you can go to that issue
and read the text about it and not that it says that it was an "arbitrary"
choice and that you can bind it back manually if you care.

Probably the safest thing would be for this macro not to be binding
that particular variable at all...  But maybe someone else thought that
would also be inelegant.  I dunno.  Anyway, issue DATA-IO (which is in
CLHS) gives you the official read.

Sun, 10 Sep 2000 03:00:00 GMT  
 [ 3 post ] 

 Relevant Pages 

1. Gambit - PRINC & PRINT

2. *print-readably* and printing numbers

3. princ/print in DrScheme

4. The history of print, prin1, and princ?

5. *print-readably* and structures

6. (write 1f0 :readably t) prints what?

7. printing arrays readably

8. *print-readably* and hash tables

9. *print-readably* and functions

10. Can PRINC insert gratuitous newlines?

11. Strange princ behavior in clisp

12. read-line / princ problems


Powered by phpBB® Forum Software