This page is part of the web mail archives of SRFI 105 from before July 7th, 2015. The new archives for SRFI 105 contain all messages, not just those from before July 7th, 2015.
From: "David A. Wheeler" <dwheeler@xxxxxxxxxxxx> 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.