FYI:

The current version of SRFI-105 includes a new citation and discussion of Derek M. Jones' "Developer beliefs about binary operator precedence (part 1)".  I added this because Jones' paper has quantitative data that justifies why it's reasonable to *not* have a built-in precedence system.  Here's a quick summary of Jones' results:

* After measuring many large C programs, they found that only
1.9% of all expressions had at least two binary operators
(where precedence would make a difference).
In those cases where precedence could have been used
(the 1.9% of all expressions), 67%
(102,822/154,575) of the operator pairs were explicitly parenthesized
(making any precedence rule moot).

* They also surveyed developers
at the 2006 ACCU conference, to apply the precedence and associativity of
the binary operators common to C, C++, C#, Java, Perl, and PHP.
In this experiment only 66.7% of the answers were correct (standard
deviation 8.8, poorest performer 45.2% correct, best performer 80.5% correct);
this was not much better than random chance (50%).
Even many widely-used operator pairs had relatively poor results;
only 94% of the problems were correctly solved when they combined * and +,
92% when they combined * and -,
and 69% when they combined / and +. Eeeek.

I'm a big believer in trying to get quantitative data when you can, and that's an interesting set of data.

This doesn't make precedence systems evil.  Indeed, you can implement one in curly-infix-expressions by defining $nfx$.  But it's a reasonable justification for not building one in, at least as a default for now.

--- David A. Wheeler