Are we done? Are other changes needed to maximize adoption? David A. Wheeler (16 Sep 2012 19:49 UTC)
Re: Are we done? Are other changes needed to maximize adoption? Alan Manuel Gloria (17 Sep 2012 00:25 UTC)
Re: Are we done? Are other changes needed to maximize adoption? David A. Wheeler (17 Sep 2012 00:52 UTC)
Re: Are we done? Are other changes needed to maximize adoption? David A. Wheeler (17 Sep 2012 01:17 UTC)
Re: Are we done? Are other changes needed to maximize adoption? David A. Wheeler (17 Sep 2012 00:30 UTC)
Re: Are we done? Are other changes needed to maximize adoption? David A. Wheeler (17 Sep 2012 01:32 UTC)
Re: Are we done? Are other changes needed to maximize adoption? Alan Manuel Gloria (19 Sep 2012 01:35 UTC)
Re: Are we done? Are other changes needed to maximize adoption? David A. Wheeler (18 Sep 2012 02:45 UTC)

Re: Are we done? Are other changes needed to maximize adoption? David A. Wheeler 17 Sep 2012 00:30 UTC

Shiro Kawai:
> The only comment so far is that the rather lengthy rational section;
> I understand you have lots to say and they're all useful, but
> the first time readers may wonder why you need so much rationals,
> before she actually read the specification.

Okay.  Maybe a "why is this so long?" paragraph belongs early in the rationale.  (If you skip the rationale, then you don't care how long it is.)

>  It occurred to me that
> it might help if examples are presented before rationals.
> (But the reader can click the link to jump to the specfication anyways,
> so the order may not be important so much...)

The order is specified by the SRFI template.  And yes, I think a lot of people will just jump to the spec, and that's fine.

How about adding this to the intro part of the rationale?  (the examples are a subset of the examples in the specification):

====

<p>A few examples of c-expressions and their mappings are:</p>
<ul>
<li><samp>{n&nbsp;&lt;=&nbsp;5}</samp> &#8658;
    <samp>(&lt;=&nbsp;n&nbsp;5)</samp></li>
<li><samp>{a * {b + c}}</samp> &#8658; <samp>(* a (+ b c))</samp></li>
<li><samp>{x eqv? &#96;a}</samp> &#8658; <samp>(eqv? x &#96;a)</samp></li>
<li><samp>{-(a) / b}</samp> &#8658; <samp>(/ (- a) b)</samp></li>
<li><samp>{f(a b) + g(h)}</samp> &#8658; <samp>(+ (f a b) (g h))</samp></li>
<li><samp>{{a &gt; 0} and {b &gt;= 1}}</samp> &#8658;
<samp>(and (&gt; a 0) (&gt;= b 1))</samp></li>
<li>
<samp>{length(x)&nbsp;&gt;=&nbsp;6}</samp>
&#8658;
<samp>(&gt;=&nbsp;(length&nbsp;x)&nbsp;6)</samp>
</ul>

<p>
This SRFI rationale is unusually long, especially when you compare it to
the simplicity of its specification.
However, the notation described in this SRFI builds on the
lessons learned from the many previous infix mechanisms that have been
developed for Scheme and related Lisp-based languages.
The authors believe that it is important to document why various
decisions were made, in particular, to show why this approach is
an improvement over past approaches and more likely to gain wide acceptance.
</p>

====

> A general comment---I don't know if future lispers will use this
> alternative notation a lot, but when I provide a capability
> to extend applications written in Gauche, customers sometimes
> asked more traditional notation than bare S-exprs, and I needed
> to hack up some crude syntax every time.  I wished if
> there were an off-the-shelf alternative syntax that maps nicely
> to S-expr.  This srfi (plus sweet-expressions) may serve as a
> good option.

I hope so!!  I think curly-infix is great approach if you can't change the syntax.

If you're allowed to *change* the syntax of Scheme (e.g., to make indentation syntactically important) I think you can do more, and what's more, curly-infix is still useful as a critically-important subset.  That's what sweet-expressions are all about, but they build on the c-expressions and n-expressions defined in this SRFI.  The main thing that sweet-expressions do is (1) use indentation as syntactically important, and (2) allow the use of neoteric-expressions at *any* point (not just inside {...}).  But that would be a *different* SRFI.

--- David A. Wheeler