Fractional precedences? Re: Operator precedence help

[Carter Schonwald]

These are really nice examples to motivate why you definitely want a total
order!

(I’ve definitely pondered wanting partial order shenanigans in the past and
these simple example do a very nice job illustrating why I wouldn’t ! ).

On Thu, Sep 3, 2020 at 3:28 PM David Feuer <david.feuer at gmail.com> wrote:

> `seq` would be an issue too.
>
> On Thu, Sep 3, 2020, 3:11 PM Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
>
>>
>>
>>
>> On Thu, 3 Sep 2020, Tikhon Jelvis 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.
>>
>>
>>
>>
>>
>> right
>>
>>
>>
>>
>>
>> > Not sure how to handle operators like $ in a system like that though.
>>
>>
>>
>>
>>
>> ($) in GHC is already an exception because it works with
>> forall-quantified
>>
>>
>> operands, too.
>>
>>
>> _______________________________________________
>>
>>
>> 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/20200904/aa31c4b2/attachment.html>