Email list hosting service & mailing list manager


Re: SRFI 105: Curly-infix-expressions Aubrey Jaffer 26 Aug 2012 15:54 UTC

I like the idea of Curly-infix-expressions; but I think it needs some
adjustments.  Looking at "some examples of c-expressions", there is a
mixture of parentheses and curly braces (and no NFX example).  Is the
syntax { f(x) } not handled?  Knowing when to use parentheses with
prefix notation versus curly braces with infix notation requires more
detailed syntactic understanding than should be assumed from
parenthephobes.  A (perhaps additional) specification should be
written for parenthephobes telling them how to program in Scheme using
curly-braces.  It should explicitly state when parentheses with prefix
notation must be used instead of curly-braces.

You give a good justification for why precedence isn't supported, yet
the specification doesn't enforce this by requiring an error be
signaled for ambiguous expressions.  Furthermore, the draft allows
implementations to implement any precedence behavior using NFX.  If
SRFI-105 is going to be an alternate syntax for Scheme, it should
force uniformity among supporting implementations.  Less radical than
not allowing ambiguous expressions would be having left-associative be
the default precedence.

I'm okay with "We think that precedence is overrated."  But I think
that infix-of-more-than-2-arguments is also overrated.  There are many
popular infix languages which don't understand:

  0 <= x <= n

Those infix languages (and SRFI-105) also don't allow what I really
want to write:

  0 <= x < n

I think eliminating the infix-of-more-than-2-arguments would further
simplify SRFI-105 while only slightly reducing its utility.