Re: SRFI 105: Curly-infix-expressions
Shiro Kawai
(26 Aug 2012 20:58 UTC)
|
Re: SRFI 105: Curly-infix-expressions
David A. Wheeler
(27 Aug 2012 00:45 UTC)
|
Re: SRFI 105: Curly-infix-expressions
Alan Manuel Gloria
(27 Aug 2012 00:54 UTC)
|
Re: SRFI 105: Curly-infix-expressions
David A. Wheeler
(27 Aug 2012 01:06 UTC)
|
Re: SRFI 105: Curly-infix-expressions Shiro Kawai (27 Aug 2012 04:28 UTC)
|
Re: SRFI 105: Curly-infix-expressions
Alan Manuel Gloria
(27 Aug 2012 06:14 UTC)
|
Re: SRFI 105: Curly-infix-expressions Shiro Kawai 27 Aug 2012 04:23 UTC
>From: "David A. Wheeler" <xxxxxx@dwheeler.com> Subject: Re: SRFI 105: Curly-infix-expressions Date: Sun, 26 Aug 2012 20:45:28 -0400 (EDT) > Shiro Kawai: >> 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". > > People typically find familiar notations (or similar ones) easier to use. It's not that one notation is more "natural" in a cosmic sense, it's familiarity. But that MATTERS if someone uses a notation a lot. > > The world has *standardized*, and has for hundreds of years, on infix notation for math, especially at the pre-college level. That WILL NOT CHANGE. Don't take me wrong. I'm not arguing that. In plain words, I'm questioning if you are trying to solve a right problem in this srfi. Surely infix op is a part of a solution, but disregarding other things that has made infix op actually work, the partial solution may not be as useful as we hope for, or even harmful. > The fact that so many people have created infix notations also shows that many people think it's a problem. Yes, and the fact that none of them got popularity suggests there are other factors involved. > I think the problem has been that most infix notations weren't general, or weren't homoiconic, making them not useful in a Lisp like Scheme. But curly-infix is both general and homoiconic, fixing that problem. Which may be one of the factors. > Some coding standards require whitespace around an operator, e.g., here's one for C: http://www.psgd.org/paul/docs/cstyle/cstyle10.htm Read the document carefully. It actually supports my point. It requires not to insert whitespaces between unary operators and its operand, 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.) That means people do tend to drop whitespaces in "leaf" nodes of the expressions, making each of them dense and cluster. Those coding standards are merely drawing a line. 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. Same thing in operator precedence. Surely, no precedence is simpler and we like simpler rules. But what do we lose for not having precedence? * * * 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.) --shiro