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

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.

*To*: srfi-105@xxxxxxxxxxxxxxxxx*Subject*: Re: SRFI 105: Curly-infix-expressions*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Sun, 26 Aug 2012 11:54:30 -0400 (EDT)*Delivered-to*: srfi-105@xxxxxxxxxxxxxxxxx*In-reply-to*: <y9l4nnpyfg8.fsf@xxxxxxxxxxxxxxx> (srfi-editors@xxxxxxxxxxxxxxxxx)*References*: <y9l4nnpyfg8.fsf@xxxxxxxxxxxxxxx>

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.

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

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

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