1) I don't know what "XP-style" means.  It needs a reference.

Sure, I will clarify it. XP is Richard Waters' pretty printer that became the part of CL specification. It is described in chapter
27 of CLtL2.

2) For "machine-readable output" read "output readable by `read`.

OK.

3) By convention, angle brackets are used around macro arguments, not procedure arguments, in synopses.

True, but there is no conventional way to specify alternating key-value argument lists without confusion; (foo key value ...) may be
read as a single key followed by multiple values. I am open to suggestions.

4) I am inclined to think that there should be no level that doesn't
provide guarantees for shared and circular references.  One problem is
that this sacrifices re-readability on Schemes that don't have #n= and
#n# lexical syntax.  This would also mean that higher levels of
support wouldn't work on systems (especially R6RS ones) without such
syntax. This question is orthogonal to support levels

The way I see it, if some approach to specifying things was good enough for R5RS, it has a right to exist till this day. Not
providing users guarantees of a certain kind is a guarantee that they can continue using the systems they already have, while making
a step forward that gets them closer to speaking a common language -- that's why (srfi 272) basically follows R5RS here. There is no
obvious solution for more capable libraries, but I thought that the future standards are guaranteed to support data labels, so it
may make sense to support them explicitly at the 'basic' level. Chez supports them, so I think other R6RS implementers will likely
follow.

5) You should mention the ability to request hex floats on systems
that support them.

OK.

6) The reason for the "#" stubs is that no reasonable Lisp supports
"#)" as lexical syntax.  This is not true of "...", although more than
one dot is an invalid identifier in CL (see 2.3.3 at
https://www.lispworks.com/documentation/HyperSpec/Body/02_cc.htm).  If
you are going to suggest something, "###" would be safer.

I will mention that the implementers are encouraged to consider using stubs that 1) are different from regular notations, and 2)
guarantee that reading them back fails. The "..." length stub is unfortunately commonplace (as far as I can tell, all existing
printers use it), but it hurts my brain seeing it used to abbreviate syntax definitions. I would prefer ". . ." (with spaces) as a
length stub.

7) I think the advanced, fancy, and colorize libraries should be
postponed to a future SRFI.  Having them here rather undermines the
rationale for something much simpler than CL.

It may help the adoption, but it will complicate collecting the feedback. I'll probably delegate this decision to the Editor.

8) The measure library should IMO be defined with reference to UAX #11
East Asian Width at https://www.unicode.org/reports/tr11. This is much
better defined than wcwidth, which is entirely
implementation-dependent.  The data file for this spec is at
https://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt.

I will definitely mention it and make a reference to it, but it can't solve the problem completely. It does not cover anything but
EA by design, and nowadays there is such thing as emoji. So the whole idea of referencing wcwidth alongside the EAW is to be
implementation-dependent: wcwidth co-evolves with terminal software and has the best chance to describe the reality when it
solidifies.

On Thu, May 14, 2026 at 12:08 AM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>
> Scheme Request for Implementation 272,
> "Pretty Printing",
> by Sergei Egorov,
> is now available for discussion.
>
> Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-272/.
>
> You can join the discussion of the draft by filling out the subscription form on that page.
>
> You can contribute a message to the discussion by sending it to xxxxxx@srfi.schemers.org.
>
> Here's the abstract:
>
> This SRFI follows the traditional Scheme model of pretty printing, which treats it as a process distinct from general controlled
> formatting. While general-purpose formatters often prioritize specialized presentation at the expense of machine-readability,
> Scheme’s pretty-printers (such as those of SLIB and MIT Scheme) have traditionally treated pretty printing as a variant of write,
> differing primarily in the insertion of whitespace to make the presentation more palatable to humans. Common Lisp’s
> pretty-printer, by contrast, fills two roles simultaneously by integrating pretty printing with both its format facility and its
> generalized write procedures. This unified approach offers great power, but at the cost of complexity that can make it difficult
> to use effectively. We propose a specialized, layered approach, specifying five libraries of increasing functionality, where all
> but the first are optional. The libraries are downward-compatible: more powerful libraries satisfy all requirements of the simpler
> ones while adding new features. Implementors may choose to support a maximum level of functionality appropriate for their systems.
> Integration with monadic and string-based formatting libraries is supported.
>
> Regards,
>
> SRFI Editor