Should we MAY a "curly-write" and "neoteric-write"? Or even "sweet-write"? David A. Wheeler 09 Apr 2013 21:56 UTC
Re: Should we MAY a "curly-write" and "neoteric-write"? Or even "sweet-write"? Mark H Weaver 09 Apr 2013 23:34 UTC
Re: Should we MAY a "curly-write" and "neoteric-write"? Or even "sweet-write"? David A. Wheeler 10 Apr 2013 00:14 UTC
Re: Should we MAY a "curly-write" and "neoteric-write"? Or even "sweet-write"? David A. Wheeler 10 Apr 2013 00:24 UTC
Re: Should we MAY a "curly-write" and "neoteric-write"? Or even "sweet-write"? David A. Wheeler 10 Apr 2013 04:11 UTC
Re: Should we MAY a "curly-write" and "neoteric-write"? Or even "sweet-write"? John Cowan 10 Apr 2013 01:56 UTC
Re: Should we MAY a "curly-write" and "neoteric-write"? Or even "sweet-write"? David A. Wheeler 10 Apr 2013 03:00 UTC
Re: Should we MAY a "curly-write" and "neoteric-write"? Or even "sweet-write"? John Cowan 10 Apr 2013 06:29 UTC
Re: Should we MAY a "curly-write" and "neoteric-write"? Or even "sweet-write"? David A. Wheeler 11 Apr 2013 02:26 UTC
Re: Should we MAY a "curly-write" and "neoteric-write"? Or even "sweet-write"? David A. Wheeler 11 Apr 2013 22:37 UTC
First cut at "curly-write" and "neoteric-write" with -shared and -cyclic versions David A. Wheeler 14 Apr 2013 22:29 UTC
Draft updated SRFI-110 and reference implementation David A. Wheeler 15 Apr 2013 04:09 UTC
Re: First cut at "curly-write" and "neoteric-write" with -shared and -cyclic versions beni.cherniavsky@xxxxxx 02 May 2013 08:00 UTC
Re: First cut at "curly-write" and "neoteric-write" with -shared and -cyclic versions David A. Wheeler 02 May 2013 22:46 UTC
Re: First cut at "curly-write" and "neoteric-write" with -shared and -cyclic versions David A. Wheeler 14 May 2013 00:47 UTC

Should we MAY a "curly-write" and "neoteric-write"? Or even "sweet-write"? David A. Wheeler 09 Apr 2013 21:56 UTC

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