>From: "David A. Wheeler" <xxxxxx@dwheeler.com>
Subject: Re: SRFI 105: Curly-infix-expressions
Date: Sun, 26 Aug 2012 20:45:28 -0400 (EDT)

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

Don't take me wrong.  I'm not arguing that.

In plain words, I'm questioning if you are trying to solve a
right problem in this srfi.

Surely infix op is a part of a solution, but disregarding other
things that has made infix op actually work, the partial solution
may not be as useful as we hope for, or even harmful.

> The fact that so many people have created infix notations also shows that many people think it's a problem.

Yes, and the fact that none of them got popularity suggests
there are other factors involved.

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

Which may be one of the factors.

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

Read the document carefully.  It actually supports my point.
It requires not to insert whitespaces between unary operators
and its operand, and makes an exception for two high-precedence
binary operators, '.' and '->'.   (If you count [] as an operator,
I'm pretty sure those people wouldn't put whitespaces before it.)

That means people do tend to drop whitespaces in "leaf" nodes
of the expressions, making each of them dense and cluster.  Those
coding standards are merely drawing a line.

In a sense, srfi-105 sets this line to the very end---every
opreators and operands should be delimited by whitespaces
(or parentheses).   Which is necessary to keep Lisp tokenization
rules, but we should be aware of what we lose.  Each compromise
reduces the advantage of infix notation per se, and better to be
accompanied with some good mechanism to recover the loss.

Same thing in operator precedence.  Surely, no precedence is
simpler and we like simpler rules.  But what do we lose for not
having precedence?

* * *

Regarding whether splitting or bundling srfis---it's fine if
splitting it makes things easier; what I concern more is a clearer
goal setting.  We can think of lots of ways to realize
infix syntax and we can argue on fine points technically,
but without the grand design, I'm afraid that discussion will
degenerate for the matter of taste.   (So, if readable S-expression
project is the grand design, I suggest to make it prominent and
decisions should be adjusted toward that goal.)

--shiro