[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.

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.