Fractional precedences? Re: Operator precedence help

[Ben Franksen]

Am 03.09.20 um 00:29 schrieb John Cotton Ericson:
> I definitely prefer this approach. I do not like absolutely levels,
> whether natural numbers or fractional. At the end of the day, that's all
> order-maintance for a *global* total preorder, and such a design will
> always result in unforeseeable interactions between
> independently-developed operators, not to mention increasingly
> ludicrously-precise fractions.
> 
> This may sound like low-priority design pedantry, but I suspect
> (probably because I myself was taught with scheme) that
> spooky-action-at-a-distance precedence greatly harms beginning
> programmers, causing confusion or at least delaying the understanding
> that expressions are arbitrarily deep trees.

Isn't declaring relative precedences between operators also somewhat
spooky-action-at-a-distance for (human) readers of the code? I think the
idea is nice in principle, but I guess to make it practical requires IDE
support in order to figure out the relative precedences of operators in
an expression.

As soon as you can define new operators, precendence is a huge problem.
And the problem here is *not* designing the most flexible way to assign
precedences, but rather the opposite: to *limit* flexibility so that
humans can still correctly parse code at a glance. That is, IMO, the
main reason why having a small and fixed number of precedences is a good
thing. And yes, I have often been in a situation where I would have
liked to say "make this operator bind stronger than X, but weaker than
Y", but couldn't because there was no level in between X and Y. So now I
have to write a few more parentheses then I would like. I still think
that code is more readable with a fixed number of precendence levels, so
I am willing to pay that price.

Cheers
Ben