bug#30070: 27.0.50; cl-print sometimes prints self-referencing objects as #1=#<thing>

bug#30070: 27.0.50; cl-print sometimes prints self-referencing objects as #1=#<thing>

[Michael Heerdegen]

Hi,

my use case is like this:

--8<---------------cut here---------------start------------->8---
;; -*- lexical-binding: t -*-

(require 'cl-lib)
(require 'cl-print)

(cl-defstruct thing
  thing-object)

(cl-defmethod cl-print-object ((_object thing) stream)
  (princ "#<thing>" stream))

(let ((print-circle t))
  (cl-prin1-to-string
   (letrec ((me (make-thing :thing-object (lambda () me))))
     me)))
--8<---------------cut here---------------end--------------->8---

That gives me "#1=#<thing>".  That's weird because the printed
representation of the thing doesn't refer to itself.  This can happen in
real life: that the thing-object in the example is a closure referencing
the thing itself might be coincidence, so one can't assume that the
printed representation of a self-referential object always includes a
reference to the top-level object.


TIA,

Michael.


In GNU Emacs 27.0.50 (build 11, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
 of 2018-01-10 built on drachen
Repository revision: bf38966965384b07621839db892b90932b8754a6
Windowing system distributor 'The X.Org Foundation', version 11.0.11905000
System Description: Debian GNU/Linux testing (buster)

bug#30070: 27.0.50; cl-print sometimes prints self-referencing objects as #1=#<thing>

[Stefan Monnier]

> That gives me "#1=#<thing>".  That's weird because the printed
> representation of the thing doesn't refer to itself.

Yes, it's a known misfeature (to me at least).  I don't know how we
could fix it, tho: the cycle-detection is done in a preprocessing phase
which doesn't know about any print format (nor about cl-print), so by
the time we learn the the object will be printed as "#<thing>", we have
already printed "#1=".

To fix it, I have the impression that we'd have to make cl-print a lot
more complex, and potentially its API as well (e.g. add a matching
cl-preprocess method additionally to cl-print-object).


        Stefan

bug#30070: 27.0.50; cl-print sometimes prints self-referencing objects as #1=#<thing>

[Michael Heerdegen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> > That gives me "#1=#<thing>".  That's weird because the printed
> > representation of the thing doesn't refer to itself.
>
> Yes, it's a known misfeature (to me at least).  I don't know how we
> could fix it, tho: the cycle-detection is done in a preprocessing phase
> which doesn't know about any print format (nor about cl-print), so by
> the time we learn the the object will be printed as "#<thing>", we have
> already printed "#1=".
>
> To fix it, I have the impression that we'd have to make cl-print a lot
> more complex, and potentially its API as well (e.g. add a matching
> cl-preprocess method additionally to cl-print-object).

Yes, that's what I expected.

Would it make sense to cache what is being printed, post-process it, and
print it at once?


Michael.

bug#30070: 27.0.50; cl-print sometimes prints self-referencing objects as #1=#<thing>

[Stefan Monnier]

> Would it make sense to cache what is being printed, post-process it, and
> print it at once?

We could try, but we'd have to somehow distinguish the "#N=" and "#N#"
that are used for such sharing references from those that may appear as
part of "normal user output".


        Stefan