The latest example suggests a question to me...

should we suggest also including "write" procedures?

E.G.:
"Implementations <em>MAY</em> provide the procedures
<var>curly-write</var>, <var>neoteric-write</var>, and/or <var>sweet-write</var>
as writers that can write c-expressions, n-expressions, and t-expressions respectively.
If provided, these procedures <em>SHOULD</em>
take a parameter (the object to write) and an optional second parameter (the port).
<em>SHOULD</em> support an optional port parameter.
They <em>SHOULD</em> otherwise have the semantics of the underlying <var>write</var> procedure.
Implementations <em>MAY</em> also provide -shared and -simple variants of these per R7RS."

I'm not sure about sweet-write, mainly because that's essentially a pretty-printer and should probably be defined in a separate module (and should probably be defined in a separate SRFI, too).  But curly-write and neoteric-write seem like really useful procedures to at least recommend.  People can write their own, of course, but we want them to be *easy* to use.

We actually have implementations of these procedures (without cycle detection); they could be easily moved into the reference implementation.  But the first question is, should they be included in the spec at all?

--- David A. Wheeler