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

Re: SRFI 105: Curly-infix-expressions

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.

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


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