> On May 14, 2026, at 4:19 PM, Sergei Egorov <xxxxxx@acm.org> wrote:
>
> It is more or less customary for SRFIs to propose names already in use for features that lack standardization. In this case, the proposed definition for 'pp' can be easily made backward-compatible with the current definitions. Implementors can do the following without breaking their existing code base:
>
> Bigloo: (pp obj [output-port])   -- can be just extended in a backwards-compatible way
> Gambit: (pp obj [output-port [readtable]])  -- can be extended to allow an optional readtable between port and keyword arguments

Gambit’s pp and pretty-print procedures only support an optional output-port second parameter. The readtable, which has an effect on the printed representation, is attached to the port. For example:

 > (output-port-readtable-set! (current-output-port)
                               (readtable-max-write-length-set (current-readtable) 20))
 > (pretty-print (list (iota 10) (iota 40) (iota 100)))
 ((0 1 2 3 4 5 6 7 8 9)
  (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ...)
  (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ...))

Moreover, the pp procedure is meant for debugging, where the short name is convenient. It behaves slightly differently from pretty-print: when the parameter is a procedure, it pretty-prints the source code of that procedure, if available:

 > (define (foo x) (+ x 1))
 > (pretty-print foo)
 #<procedure #2 foo>
 > (pp foo)
 (lambda (x) (+ x 1))

Please don’t use pp as the name of the main pretty-printing procedure. This would complicate debugging when this SRFI is imported.

Marc