> I think that specifying a write-unreadable procedure is the wrong way to achieve the goal of writing unreadable data.  The problem is that unreadable data may be nested at arbitrary depth in a container object that is written.  With write-unreadable it is necessary to implement a custom “write” procedure that walks the object to be written and calls write-unreadable when it detects that an unreadable data is encountered.  This is not ideal because any system specific feature of the Scheme system’s “write” procedure will no longer be available.

Ah, that's right.

The `write-unreadable` routine would be intended for use in custom
"write object of type foo" procedures called by `write`. Custom writers
aren't standardized in Scheme, not even in a SRFI, but some
implementations have them. Common Lisp is a standard with prior art.

Since we don't have the framework standardized, perhaps a SRFI about
this minor piece of the machinery is not useful.

> An approach which avoids this problem is based on read-macro “inversion” by the write procedure.  By this I mean detecting lists that begin with the symbols “quote”, “unquote”, etc and outputing the more compact read-macro form instead of the normal list form. [...]

> So I think a better path would be to start by specifying a read-macro inversion SRFI for the standard R7RS read-macros.  Then another SRFI could specify an extension for writing unreadable data as in the above example using the |#<...>| special symbol.  Another SRFI could also specify the case of |[...]| and |{...}|.

Thanks for the detailed and clear explanation!

While this is clever, some schemers regard unhygienic
quote/quasiquote/unquote/unquote-splicing as a misfeature of the
language and would prefer to fix that instead of adding more of the
same. I tend to be in this camp, so I won't write a SRFI recommending
it, but I won't object if somebody else does.

My stance on the general topic is that syntax must move from textual to
structural, and the sooner we can start the better. Consequently textual
S-expressions should be simplified by regularizing it, not complicated.
Complexity and special cases should be moved from lexical syntax into
macros, and the presentation layer that we should to make macro
invocations look friendly. Once this ships, it will blow Haskell- and
Racket-style syntax trickery out of the water. There will be no looking
back.