Shiro Kawai:
> Probably because of my lack of experience of teaching Lisp family
> languages to non-Lispers, it is difficult for me to swallow the
> reasoning of "not having infix notations alienates people".

People typically find familiar notations (or similar ones) easier to use.  It's not that one notation is more "natural" in a cosmic sense, it's familiarity.  But that MATTERS if someone  uses a notation a lot.

The world has *standardized*, and has for hundreds of years, on infix notation for math, especially at the pre-college level.  That WILL NOT CHANGE.  Almost every modern person receives at least a decade of training in the use infix notation, making them very familiar with infix notation for math.  Programmers typically receive even MORE training using infix math.  That will not change either.  So any developer starts off having a 10+ years of experience with infix, and 0 with strictly-prefix.  Even if a developer is happy with strictly-prefix, other developers will not, and that inhibits collaboration.

> I know many argues that infix is more natural or people are used
> to it, but in user interface, what users tell literally may not
> reflect what users really want.

Sure, but in absence of better evidence, it would be good to listen to users :-).  I don't know of any experimental results.  I suspect no one has bothered, as the answer is  painfully obvious.  There certainly are experienced Lispers who still think this is a problem.  I've been using Lisp off-and-on for 30 years, and I think it's still a problem.  The fact that so many people have created infix notations also shows that many people think it's a problem. So, let's solve it.

I think the problem has been that most infix notations weren't general, or weren't homoiconic, making them not useful in a Lisp like Scheme.  But curly-infix is both general and homoiconic, fixing that problem.

> My personal impression is that the intrinsic readability of
> conventional notation comes from the ability to use denseness
> of expressions to represent the tree structure.

That *could* be true, but I believe the real issue is familiarity.  The world has standardized on infix math, and everyone's trained on it.

It's obviously *possible* to have a notation without infix math.  But many languages are Turing-complete; that doesn't mean that people want to *use* them :-).

>   p*x + q*y + r*z
>
> is more readable from
>
>   (+ (* p x) (* q y) (* r z))
>
> because the former uses visual queue for tighter grouping of
> p*x, q*y and r*z than '+'.   If you write the former
>
>   p * x + q * y + r * z
>
> or
>
>   (p * x) + (q * y) + (r * z)
>
> then readability gradually deteriorates to the point that
> the merit of having infix notation becomes marginal compared
> to the prefix notation.
>
>
> That is, it's not the infix notation alone, but the combination
> of infix, operator precedence, and tokenization that contributes
> to the readability.

That is an intriguing claim, but I don't think it's true.

Some coding standards require whitespace around an operator, e.g., here's one for C: http://www.psgd.org/paul/docs/cstyle/cstyle10.htm

In practice, lots of developers surround infix operators by whitespace in languages that don't require them.   Many will use the precedence of * and / over + and -, but beyond that, a lot of people will group operators even when they aren't required.

I see little evidence that people use more-and-less whitespace in *programs* to indicate precedence.  Generally, people put a space on each side of the infix operator and move on with their drab, wretched lives :-).

> (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.

--- David A. Wheeler