Shiro Kawai:
> Read the document carefully.  It actually supports my point.
> It requires not to insert whitespaces between unary operators
> and its operand,

I believe that, by definition, unary operations cannot be infix.  In an infix notation, the operator is placed between the operands.  There is no pair of operands to stick the operator "between" a unary operation!  So no, that document doesn't support the point.

Now it's certainly true that traditional notation, unary operations like "-" are written as -(...) instead of (- ...).  I'm guessing that's what you mean when you say "infix notation".  But that's technically not infix notation; both Lisp and traditional math use prefix notations for unary operations.

A key purpose of neoteric-expressions is to add f(...) as an alternative representation of (f ...).  However, notice that this is just an alternative prefix notation.  Also, in neoteric-expressions, there cannot be a whitespace between the unary operator and the leading opening paren either.

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

Sure.  But these are stylistic exceptions because of C's syntax.  I think the proposed approach works better for Scheme.

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

Sure.  What this suggests to me is that once you're inside a curly-infix expression {...}, at least some people would like to always *require* what I call neoteric-expressions, so that you could say f(x) and -(q).

That's easily done.  Once you enter {...}, you're clearly not in traditional notation anyway, so we may as well always support f(x) inside it.  Thanks for the feedback, I'll think about it, but I'm positively disposed to the idea.

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

Obviously, it means you have to group everything (I'm sure you knew that).  So the question is, is that a *problem*?

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.

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

Well, I've made no secret of that.  The draft SRFI specifically notes the "readable" project with its 3 notations, and the rationale even notes the other two pieces.  You can go to our website (referenced in the SRFI) to see how they fit together.  These pieces really do fit together quite cleanly.

But curly-infix is quite useful all by itself, and since the other things build on it, it seemed appropriate to start there.

--- David A. Wheeler