This page is part of the web mail archives of SRFI 110 from before July 7th, 2015. The new archives for SRFI 110 are here. Eventually, the entire history will be moved there, including any new messages.
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