<div dir="ltr"><div>In the proposals for relative precedences that I've heard before, it would be a syntactic error to use two operators that *don't* have explicitly defined relationships without parentheses. + and * would work together the way you would expect from math, but you simply wouldn't be able to mix them with ++ without parentheses. Seems like this would avoid spooky action at a distance since operators that aren't clearly related simply don't have relative precedences at all. Not sure how to handle operators like $ in a system like that though.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 3, 2020 at 12:01 PM Ben Franksen <<a href="mailto:ben.franksen@online.de">ben.franksen@online.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 03.09.20 um 00:29 schrieb John Cotton Ericson:<br>
> I definitely prefer this approach. I do not like absolutely levels,<br>
> whether natural numbers or fractional. At the end of the day, that's all<br>
> order-maintance for a *global* total preorder, and such a design will<br>
> always result in unforeseeable interactions between<br>
> independently-developed operators, not to mention increasingly<br>
> ludicrously-precise fractions.<br>
> <br>
> This may sound like low-priority design pedantry, but I suspect<br>
> (probably because I myself was taught with scheme) that<br>
> spooky-action-at-a-distance precedence greatly harms beginning<br>
> programmers, causing confusion or at least delaying the understanding<br>
> that expressions are arbitrarily deep trees.<br>
<br>
Isn't declaring relative precedences between operators also somewhat<br>
spooky-action-at-a-distance for (human) readers of the code? I think the<br>
idea is nice in principle, but I guess to make it practical requires IDE<br>
support in order to figure out the relative precedences of operators in<br>
an expression.<br>
<br>
As soon as you can define new operators, precendence is a huge problem.<br>
And the problem here is *not* designing the most flexible way to assign<br>
precedences, but rather the opposite: to *limit* flexibility so that<br>
humans can still correctly parse code at a glance. That is, IMO, the<br>
main reason why having a small and fixed number of precedences is a good<br>
thing. And yes, I have often been in a situation where I would have<br>
liked to say "make this operator bind stronger than X, but weaker than<br>
Y", but couldn't because there was no level in between X and Y. So now I<br>
have to write a few more parentheses then I would like. I still think<br>
that code is more readable with a fixed number of precendence levels, so<br>
I am willing to pay that price.<br>
<br>
Cheers<br>
Ben<br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>