Aubrey Jaffer
> I think an examples section should include an example of every
> supported syntax.  It's often easier to understand a comprehensive set
> of examples than prose.

Okay, that's reasonable enough.

... regarding f(x) ...
> I am unconvinced by that argument.  It would be useful to be able to
> paste infix expressions into a program source code without having to
> rewrite them.

I don't share that goal.  My goal is for this notation to support infix order lists, not for it to be identical to some other notation such as C's.  I think a lot of past efforts have foundered because they were trying to slavishly duplicate some other notation (like C's).

A {...} creates a list, exactly the way (...) creates a list; the only difference is that {...} creates lists with elements in a slightly different order, infix order.  (With the exception of {e} as described in the rationale.)

For example, (...) creates a list in Scheme.  That behavior continues UNCHANGED inside {...}, by design.  As a result, all of Scheme's capabilities go on undiminished, including quasiquoting, macros, etc.  The goal is a general and homoiconic notation, not one that duplicates C (or Algol).

For example, this is a perfectly acceptable curly-infix expression:
  {5 + (fib 7)}
this maps, intentionally, to:
  (+ 5 (fib 7))

Parentheses are *NOT* just grouping operators as they are in some other languages.  This is Scheme, not C.  In Scheme, (...) creates lists, and they continue to have that meaning inside curly-infix.

> Parenthophobes are these people who refuse to use Scheme because of
> its syntax.  If they are the population SRFI-105 is meant to address,
...

This is not the ONLY population.  There are many people who use Lisps (including Scheme) and still find the lack of infix to be a problem.  I've used Lisps for 30 years, and still think it's a big weakness.  Paul Graham does too.  We're not the only ones.  (I have no idea what Graham thinks about my proposed *solution*, but he's on the record that lack of infix is a problem.)

> then they will only be convinced if programs can be written mostly infix.

This is a reader extension, so you can use infix any time.  For example, this would work:
(define {x +++ y} ...)

> If parenthophobes are not the intended beneficiaries, then you should
> rewrite your abstract.

Okay, thanks for the feedback.

The intended beneficiaries are "anyone who wants to use infix in Scheme".  That includes people who today refuse to use Scheme because it lacks infix - your "parenthophobes".  But it also includes people who use or know Scheme and would *like* to use infix.

> So a+b*c must be written {a + {b * c}}.  It's not any more trouble to
> write a+b+c as {{a + b} + c}.

It's not *trouble*, it's that this creates an unnecessary and undesirable limitation.  That unnecessary limitation would make it would be IMPOSSIBLE to write the infix form of:
  (+ a b c)

> In fact, it is sometimes desirable to do
> so because floating-point addition is not associative.

Sure, but when you want that, use nested operations just like you always would.

In short, just write this:
  {{a + b} + c}
if you want:
  (+ (+ a b) c)

And write this:
  {a + b + c}
if you want:
  (+ a b c)

You have complete control over the list structures you want to create.  If you want a list inside a list, use another (...) or {...} inside.

Curly-infix does NOT replace Scheme with some new incompatible C language.  Curly-infix is just another way to write lists; it is almost the same as (...), except that you write the lists in infix order instead of direct order.   I think that for a language based on lists (like Scheme), a simple notation for writing lists in infix order is a far better approach than historical approaches.  It's also general and homoiconic.

--- David A. Wheeler