On Mon, Aug 27, 2012 at 8:45 AM, David A. Wheeler <xxxxxx@dwheeler.com> wrote:
> Shiro Kawai:
>> (I'm aware of the readable S-expression project, and I see
>> n-expressions allows this denseness visual queue.  If so,
>> I think it is actually better idea to submit one srfi for
>> both in it, instead of having c-expr and n-expr individually.
>> It's the *combination* that addresses the problem).
>
> Fair point.  We actually debated whether or not to put them together, or write them separately.
>
> Neoteric-expressions are strictly more succinct than curly-expressions, because they also add a traditional-like function call notation f(...), and because they provide a simplification for a common case, f{...} ("calculate infix, then pass the result to f").
>
> We decided to write them separately (in another SRFI not yet submitted) because curly-infix does NOT require a change to the Scheme specification.  The Scheme spec doesn't include {...} at all, so curly-infix as written is strictly backwards-compatible.  In contrast, at the top level, neoteric-expressions change the language, because f(x) is interpreted as (f x) instead of as two datums (f and (x)).  Granted, anyone who is writing "f(x)" for two datums is nuts, and I've never seen Scheme code written in such a bizarre way.  But I was trying to be conservative.  Perhaps we've been too conservative, and we should just standardize neoteric-expressions (with curly-infix as a subset).  We could just rename the SRFI, and bundle them together; that'd be easy to do.

On the other hand, *I* (almkglor) have seen Scheme code that looks like this:

(let ([x foo][y bar])
 ...)

(I'll have to hunt down that link again, but Ive seen that syntax used
consistently as a coding style)

The [x foo][y bar] bit gets interpreted differently in n-exprs vs.
s-exprs or c-exprs.

Sincerely,
AmkG