>From: "David A. Wheeler" <xxxxxx@dwheeler.com>
Subject: Re: SRFI 105: Curly-infix-expressions
Date: Mon, 27 Aug 2012 08:14:05 -0400 (EDT)

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

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.

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

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.   Obviously some
directly conflict to Lisp's tradition so we have to yield, but
are there any other?

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

It's not C-specific.  They made exceptions because those are
higher precedence and they want to cluster those nodes.

Scheme also has accessors.  Unfortunately they're very verbose
and visually distracting, always annoyed me greatly.   I've been
pondering how to make them terse.  (I've come to the point that
overloading many accessors in a generic function named '~', which
works, but not yet enough.)

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.

About the grand design:

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

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.

btw, I alias 'lambda' as '^' and write (lambda (x y) ...) as
(^[x y] ...) and I'm very very happy with it; but I realized this
would interfere with n-exprs.  Gah.