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