Shiro Kawai:
> My point is "readability of infix notation owes the ability to make
> each leaf node 'dense' visually."  Grouping higher-precedence
> operators (including unary operators) without whitespaces is one way
> people do so.

I think that operators need to be delimited in a Lisp (e.g., by whitespace).  There are just too many operator symbols with embedded -, =, and so on.  Any other rule would be too  complex and brittle.  In contrast, the whitespace-delimited rule is simple, clear, and consistent with Lisp history.

And in practice, expressions like:
  {{a * b}  +  {c * d}}
Seem extremely readable to me.  That's subjective, but I think many people would have little trouble guessing what that expression "probably" means. That's not the most important test, but it does hint that it's a reasonable approach.

> (More broader point is that people take advantage of ability to
> control density, in traditional notations, to improve readability.
> This density control not only means whitespaces, but also the liberal
> use of grouping parentheses (predefined operator precedence allows
> one to omit parens; otoh, one can use redundant parens to emphasize
> the tree structure visually.)

Exactly so.  Lisps focus on lists, so emphasizing the tree structure seems to me to be the better approach.  Thus, the curly-infix lists are intentionally NOT redundant; the parens and curly braces have semantic meaning, in that they both create lists.  This isn't hard to use, because EVERY time you want an operator, you have to create a new list. It's extremely regular, so it takes almost no time to get used to them (in our experience).  The only question is, "do I want to use operators in infix or prefix position?" and then use {..} or (..) based on the answer.

> I'm not opposing to infix notations.  I'm trying to bring up why infix
> notation is traditionally preferred (other than "because people are
> used to it", which is obvious), and to see if those factors
> can be carried into the srfi to make it better.

I appreciate all efforts to improve the SRFI.  Thanks!

I will say, though, that I think the "people are used to it" is the absolutely dominant reason.  There may be reasons that certain social customs were chosen over others, but once they become common, those original reasons often become less important than familiarity itself.

> About operator precedence:
>
> > The best approach to answer that question is to write actual programs using the notation.  Alan Manuel Gloria and I have both written actual programs using this notation (and some others).  They aren't millions of lines of code, but they are at least actual experience.  What we found is that you really don't miss precedence much in practice. In fact, explicit grouping has advantages in terms of clarity - it is abundantly clear to later readers what will happen.
>
> This is the sort of things I'd like to listen to.  Thanks for sharing.

Thanks.  I didn't think it would be appropriate to list specific programs in a SRFI, but in the interest of maximizing disclosure, I should mention them here.

As part of our experiments with our notations, both Alan Manuel Gloria and I agreed to write at least one program using Scheme and our notation:
* I wrote "sweeten", a program that translates traditional s-expressions into the sweet-expression notation (this notation includes curly-infix as a subset).  The key point is that this program is heavy on list processing and text output.  To see a copy, get the file "src/sweeten.sscm" in http://sourceforge.net/projects/readable/files/
* Alan Manuel Gloria wrote letterfall, a GUI typing practice game.  Code is here: https://github.com/AmkG/letterfall

Notice that these are really different domains, written by two different people.  In both cases, we think the result works nicely.  To be fair, we are using a *set* of notations, not just curly-infix, but curly-infix is critical part of it.

No such exercise can prove that a notation is the "best possible", but it at least shows that the notation works.  We both think it's a terrific improvement from traditional notation.

> Yes, actually I knew the "readable" project before seeing this srfi.
> I merely suggest emphasizing that combining those notations empowers
> each, even though individual features may be useful with its own.

Oh, I completely agree with you there.  In the readable project we've designed all three tiers to work well with each other.  But curly-infix doesn't change the meaning of any existing portable Scheme code, so I thought it would be a reasonable piece to submit and discuss separately.

--- David A. Wheeler