Fractional precedences? Re: Operator precedence help

[David Feuer]

It seems useful to know that arithmetic binds more tightly than list
constructors.

a+b : c+d : es

seems a bit nicer to me than

(a+b) : (c+d) : es

though I suppose that's not the worst thing.

On Thu, Sep 3, 2020, 3:06 PM Tikhon Jelvis <tikhon at jelv.is> wrote:

> 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.
>
> On Thu, Sep 3, 2020 at 12:01 PM Ben Franksen <ben.franksen at online.de>
> wrote:
>
>> 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
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200903/1aa64771/attachment.html>