Email list hosting service & mailing list manager

Re: SRFI 105: Curly-infix-expressions Alan Manuel Gloria (26 Aug 2012 21:38 UTC)
Re: SRFI 105: Curly-infix-expressions John Cowan (26 Aug 2012 22:04 UTC)
Re: SRFI 105: Curly-infix-expressions Alan Manuel Gloria (26 Aug 2012 22:23 UTC)
Re: SRFI 105: Curly-infix-expressions John Cowan (26 Aug 2012 22:39 UTC)
Re: SRFI 105: Curly-infix-expressions David A. Wheeler (27 Aug 2012 00:04 UTC)
Re: SRFI 105: Curly-infix-expressions Alan Manuel Gloria (26 Aug 2012 22:11 UTC)

Re: SRFI 105: Curly-infix-expressions Alan Manuel Gloria 26 Aug 2012 21:33 UTC

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

The point of `nfx` is to be a hook for the *end user* of the implementation,
**not** the implementation.

> Furthermore, the draft allows
> implementations to implement any precedence behavior using NFX.

The draft specifically makes no allowance for the *Scheme*
implementation to implement `nfx`: it makes no mention that an
implementation *may*, *should*, or *must* provide `nfx`, only that
its reader insert that symbol.

Perhaps we'll clarify in the SRFI that an implementation *must
not* provide `nfx` (with the exception that a *future* SRFI *may*
mandate that implementations provide `nfx` at some level).