Surprising behavior in The Printer

[Ryan Kramer]

I have a small program that demonstrates some surprising behavior regarding `prop:custom-print-quotable 'never`. Perhaps it could be considered a bug, although I haven't seen anything in the docs that this violates. I've found that

1. When I call `(println y)`, my `custom-display` is called first. And what I do in `custom-display` affects the result of `(println y)`

2. The printer is doing something with `eq?` rather than `equal?`. (Does this mean that constructing any new data structure, even a list, during printing is an anti-pattern?)

In the example below, if `(maybe-rebuild lst)` returns `(identity lst)` then `prop:custom-print-quotable 'never` works as I expected. But if `(maybe-rebuild lst)` returns `(apply list lst)` which is a list that is equal? but not eq? to the original list, then `prop:custom-print-quotable 'never` surprises me.

#lang racket

(require racket/struct)

(struct my-struct (item) #:transparent
  #:property prop:custom-print-quotable 'never)

(define (go port mode val)
  (let ([proc (make-constructor-style-printer
               (λ (me) 'my-class%)
               (λ (me) (list val)))])
    (proc (void) port mode)))

(define (maybe-rebuild lst)
  ; Works as expected if we return the same list
  #;(identity lst)
  ; But this breaks prop:custom-print-quotable 'never
  (apply list lst))

(define my-class%
  (class* object% (printable<%>)
    (super-new)
    (init-field content)
    (define/public (custom-print port mode)
      (go port mode content))
    (define/public (custom-write port)
      (go port #t content))
    (define/public (custom-display port)
      (go port #f (maybe-rebuild content)))))

(define x (list 'CONTENT (my-struct '(1 a))))
(println x)
(define y (new my-class% [content x]))
(println y)

[Matthew Flatt]

The short answer is that you're right: creating new values at
custom-print time creates trouble for graph detection and `print`
quoting. Those operations perform a pass to make decisions about graphs
and quoting based on `eq?` identity, and then they make another pass to
actually print. I'll update the documentation to clarify.

A longer answer is that your example and variations expose several
mismatches between the `racket/pretty` printer, the built-in printer
for current Racket, and the built-in printer for Racket CS. I'm working
on changes and tests to make them more consistent, but the changes
don't produce the result you wanted. If you put `maybe-rebuild` in
`custom-print`, then they more consistently produce the output that you
don't want.

Of course, an even better improvement would collapse the three
different implementations of the printer. One day, we may be able to
use the Racket CS I/O layer in place of the implementation in current
Racket, and then folding in pretty-print support may become practical.