PRINT-UNREADABLE-OBJECT contains PPRINT-NEWLINE.

[Mark Cox]

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

        #<bit
      !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
      {2}>

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

[Douglas Katzman (dougk)]

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)
#<BIT
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  #x00000087>

[Mark Cox (markcox80)]

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)]

Sadly this bug countermands https://bugs.launchpad.net/sbcl/+bug/488979 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)]

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

      0.8.13.45:
       PRINT-UNREADABLE-OBJECT fixes
       ... 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 0.8.0.80. 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)]

https://sourceforge.net/p/sbcl/sbcl/ci/e3e33bf133530cc12208ec5a280fd6a89016f921/