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.
As promised, here's a precedence thread.
I think precedence is overrated for an infix notation in Scheme. In real code, more than two-thirds of actual examples didn't even mix operators, and thus by definition had no need for precedence. In the rest, every different operator adds only two new characters, { and }, which would often be used anyway for clarity. So while precedence support is *common* elsewhere, actual code use doesn't give much evidence for the utility of precedence in Scheme. Expressions where it merely *might* be useful are probably less than 10% of all cases, given the sample set of actual code we have (posted earlier).
That said, it *would* be possible to add support for precedence to curly-infix. Such approaches are documented in the current SRFI draft, and code to do it is trivial.
So, is adding precedence critically important to gain widespread implementation and use of curly-infix? Would adding precedence harm its adoption? Would it be a wash? If you think precedence is critically necessary, what operators should be supported? Are we just talking *, /, +, - (I'll grant that everyone agrees on THEIR precedence and direction)? More? Why? There are many options if we went down that road - what would be the principle to decide between them? In particular: Would anyone use curly-infix *if* it had precedence, and *not* otherwise?
I am not committing to add precedence (obviously), indeed, I'm rather skeptical on the grounds that the additional complexity doesn't seem justified. But I'd be curious to hear people's thoughts.
--- David A. Wheeler