Bug #1398290 reported by Mark Cox on 2014-12-02
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

PRINT-UNREADABLE-OBJECT makes decisions about layout that cannot be changed by the user.

    (defun pprint-demo (object)
      (pprint-logical-block (*standard-output* nil)
        (print-unreadable-object (object *standard-output* :type t :identity t)
          (write-string (make-string (1+ *print-right-margin*) :initial-element #\!)))))

    (pprint-demo 1)

This produces


where the following is expected
    #<bit !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! {2}>

Mark Cox (markcox80) on 2014-12-03
Douglas Katzman (dougk) wrote :

While I personally agree that the current behavior seems undesirable, it's certainly a matter of opinion and not a conformance bug.
The note to the example in CLHS says "the precise form of the output is implementation-dependent."

At least one other implementation inserts a conditional newline:
* (pprint-demo 1)

Mark Cox (markcox80) wrote :

From the description in the CLHS:

"If type is true, the output from forms is preceded by a brief description of the object's type and a space character."

"If identity is true, the output from forms is followed by a space character and a representation of the object's identity, typically a storage address."

There is no mention of new line characters or the pretty printer.

I would argue that the text "the precise form of the output is implementation-dependent" and the example refers to how the type and/or identity are printed.

Anyway, I am not passionate about the issue. I am just thinking of another person wasting time reading (and rereading) the pretty printer documentation trying to understand why new lines are being printed when they were not requested.

Douglas Katzman (dougk) wrote :

Sadly this bug countermands which asked for the newlines.

I'm pondering which behavior is better, and I'm inclined to say I still agree with you.

"one man's trash is another man's treasure" or something like that.

Douglas Katzman (dougk) wrote :

You wanted the newlines removed, as did the primary SBCL maintainer 12 years ago, doubly emphasized by a commit message saying that they ought to have been removed earlier:

  commit ba34717602d80e5fd74d10e61f4729fb0d019a0c
  Author: Christophe Rhodes <email address hidden>
  Date: Mon Aug 9 23:04:17 2004 +0000
       ... OK, do the ugly thing that seems to be specified in ANSI:
        include spaces even in illogical places.
       ... also delete the conditional newlines, even though they
        claimed to have been removed in Weird.

And the NEWS entry for 0.8.14 announced this:
   ** PRINT-UNREADABLE-OBJECT inserts spaces as specified (and only
      as specified: it no longer includes conditional newlines).

The patch which added them in again said that it makes *right-margin* work.
That may be true, but my feeling is that it is less pretty to insert unanticipated line breaks for most uses of print-unreadable-object.

In light of the above, removing them seems like the right thing to do.
So I'll apply this patch with additional comments reminding future maintainers to think twice about reversing this again.

Douglas Katzman (dougk) wrote :
Changed in sbcl:
assignee: nobody → Douglas Katzman (dougk)
status: New → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
Stas Boukarev (stassats) on 2016-05-29
Changed in sbcl:
assignee: Douglas Katzman (dougk) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers