[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: srfi-105@xxxxxxxxxxxxxxxxx*Subject*: Re: SRFI 105: Curly-infix-expressions*From*: Shiro Kawai <shiro@xxxxxxxx>*Date*: Sun, 26 Aug 2012 10:50:59 -1000 (HST)*Delivered-to*: srfi-105@xxxxxxxxxxxxxxxxx

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". I know many argues that infix is more natural or people are used to it, but in user interface, what users tell literally may not reflect what users really want. So, if there are experience or experimental results that show the suggested notation does make non-lispers easier to learn, and/or more experienced lispers like it, it would be nice to refer it from the srfi. I know prominent lispers refer to the awkwardness of prefix notations. But that doesn't assert *any* infix notation is good. My personal impression is that the intrinsic readability of conventional notation comes from the ability to use denseness of expressions to represent the tree structure. That is, p*x + q*y + r*z is more readable from (+ (* p x) (* q y) (* r z)) because the former uses visual queue for tighter grouping of p*x, q*y and r*z than '+'. If you write the former p * x + q * y + r * z or (p * x) + (q * y) + (r * z) then readability gradually deteriorates to the point that the merit of having infix notation becomes marginal compared to the prefix notation. That is, it's not the infix notation alone, but the combination of infix, operator precedence, and tokenization that contributes to the readability. It doesn't mean infix alone is useless. But I suspect this is a part of the resion that the previous infix syntax in Lisp didn't fly. If srfi-105 is different, I'd like to see the how. (I'm aware of the readable S-expression project, and I see n-expressions allows this denseness visual queue. If so, I think it is actually better idea to submit one srfi for both in it, instead of having c-expr and n-expr individually. It's the *combination* that addresses the problem). --shiro

**Follow-Ups**:**Re: SRFI 105: Curly-infix-expressions***From:*David A. Wheeler

- Prev by Date:
**Re: SRFI 105: Curly-infix-expressions** - Next by Date:
**Re: SRFI 105: Curly-infix-expressions** - Previous by thread:
**Re: SRFI 105: Curly-infix-expressions** - Next by thread:
**Re: SRFI 105: Curly-infix-expressions** - Index(es):