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 David A. Wheeler 27 Aug 2012 00:04 UTC

(Quick aside to John Cowan: Thanks for joining the SRFI 105 discussion, and also thanks for your hard work on R7RS!)

Anyway, John Cowan said:
> An implementation might, for example, want to provide nfx as a macro
> which looks for user-written precedence definitions and does the Right
> Thing with them.  This ought not to be forbidden.  Just like any
> other identifier provided by an implementation, the user would be
> free to redefine it, after all.

I think that's the key thing - "nfx" is intended to be an application-level hook so that users can define their own precedence system.

I should note that while I think it's important to *enable* precedence using "nfx", it's quite easy to write useful programs without requiring precedence at all.

--- David A. Wheeler