Data.Sequence uses the same precedence for both, which strikes me as a bit sad. Surprisingly, I am not seeing other packages on Hackage that define similar operators. On Thu, Aug 13, 2020 at 2:50 PM Andreas Abel wrote:

My hunch would be too look at what the others do to form an opinion.

On 2020-08-13 19:26, David Feuer wrote:

...

I'm trying to work out appropriate precedences for operators and pattern synonyms in my brand-new compact-sequences package. I currently have stacks and queues, but I will soon have deques, so let's pretend. For consistency, operators will match pattern synonyms.

(<|), pattern (:<) :: a -> Deque a -> Deque a (|>), pattern (:>) :: Deque a -> a -> Deque a

:< and :> need to have different precedence to allow things like

a :< b :< xs :> c :> d

to work nicely, but what numbers should I pick?

I also have cons and snoc functions. Should I give their backticked spellings fixity declarations? If so, with what precedences?

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

It sure does seem crowded around there. I'd love to have 4.5 or 5.5. Going up to 6 runs into arithmetic. Going down to 4 hits up against Functor and Applicative stuff, which is a tad unfortunate but I think probably not as bad in practice. So I think I'll go with 4 and 5. Thanks, y'all! On Sun, Aug 16, 2020, 1:04 AM Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Sat, 15 Aug 2020, David Feuer wrote:

...

Data.Sequence uses the same precedence for both, which strikes me as a bit sad. Surprisingly, I am not seeing other packages on Hackage that define similar operators.

I have the same problem in the 'lapack' bindings.

I like to allow people to write

(row) vector -*# matrix #*# matrix #*| (column) vector

I had no good idea, though, and also chose equal precedence for all operators.

...

On Thu, Aug 13, 2020 at 2:50 PM Andreas Abel wrote:

...

My hunch would be too look at what the others do to form an opinion.

On 2020-08-13 19:26, David Feuer wrote:

...

I'm trying to work out appropriate precedences for operators and

pattern

...

...

synonyms in my brand-new compact-sequences package. I currently have stacks and queues, but I will soon have deques, so let's pretend. For consistency, operators will match pattern synonyms.

(<|), pattern (:<) :: a -> Deque a -> Deque a (|>), pattern (:>) :: Deque a -> a -> Deque a

:< and :> need to have different precedence to allow things like

a :< b :< xs :> c :> d

to work nicely, but what numbers should I pick?

I also have cons and snoc functions. Should I give their backticked spellings fixity declarations? If so, with what precedences?

I would give them the precedence of their infix counterparts.

On Sun, Aug 16, 2020, 1:30 AM Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Sun, 16 Aug 2020, David Feuer wrote:

...

It sure does seem crowded around there. I'd love to have 4.5 or 5.5. Going up to 6 runs into arithmetic. Going down to 4 hits up against Functor and Applicative stuff, which is a tad unfortunate but I think probably not as bad in practice. So I think I'll go with 4 and 5. Thanks, y'all!

I would use 5 for cons, like : and ++

My queues use snoc and uncons. Using 5 for :< means using 4 for |>, which is the thing that can show up in an expression context and therefore clash with Applicative stuff. So I'd be tempted to go the other way. Of course, that doesn't help deques, but I want consistency. Where might that go wrong?

I do think that the work needed to actually support fractional precedence in ghc is pretty minimal. Or at least I remember having a conversation about it a few years ago, and the conclusion was that adding precedence would be super easy to do, but just lacked any good motivating example from real libraries. David, maybe you could help with that from the examples side of things? On Sun, Aug 16, 2020 at 1:27 AM David Feuer wrote:

It sure does seem crowded around there. I'd love to have 4.5 or 5.5. Going up to 6 runs into arithmetic. Going down to 4 hits up against Functor and Applicative stuff, which is a tad unfortunate but I think probably not as bad in practice. So I think I'll go with 4 and 5. Thanks, y'all!

On Sun, Aug 16, 2020, 1:04 AM Henning Thielemann < lemming@henning-thielemann.de> wrote:

...

On Sat, 15 Aug 2020, David Feuer wrote:

...

Data.Sequence uses the same precedence for both, which strikes me as a bit sad. Surprisingly, I am not seeing other packages on Hackage that define similar operators.

I have the same problem in the 'lapack' bindings.

I like to allow people to write

(row) vector -*# matrix #*# matrix #*| (column) vector

I had no good idea, though, and also chose equal precedence for all operators.

...

On Thu, Aug 13, 2020 at 2:50 PM Andreas Abel wrote:

...

My hunch would be too look at what the others do to form an opinion.

On 2020-08-13 19:26, David Feuer wrote:

...

I'm trying to work out appropriate precedences for operators and

pattern

...

...

synonyms in my brand-new compact-sequences package. I currently have stacks and queues, but I will soon have deques, so let's pretend. For consistency, operators will match pattern synonyms.

(<|), pattern (:<) :: a -> Deque a -> Deque a (|>), pattern (:>) :: Deque a -> a -> Deque a

:< and :> need to have different precedence to allow things like

a :< b :< xs :> c :> d

to work nicely, but what numbers should I pick?

I also have cons and snoc functions. Should I give their backticked spellings fixity declarations? If so, with what precedences?

I would give them the precedence of their infix counterparts.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Oh yeah! I feel like everyone’s wondered about that approach. But it definitely would need some experiments to validate. But in some ways it’d be super fascinating. On Mon, Aug 17, 2020 at 9:40 AM Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Sun, 16 Aug 2020, Carter Schonwald wrote:

...

I do think that the work needed to actually support fractional precedence in ghc is pretty minimal. Or at least I remember having a conversation about it a few years ago, and the conclusion was that adding precedence would be super easy to do, but just lacked any good motivating example from real libraries.

I remember this discussion, too, and I guess that it was started by Simon Marlow and it ended with recalling that decades ago something more advanced was discussed: Groups of equal precedence and relations between the groups. But that one was too complicated to be implemented.

For Agda, it was very little work to implement fractional precedences: https://github.com/agda/agda/pull/3992 On 2020-08-17 18:12, Carter Schonwald wrote:

Oh yeah! I feel like everyone’s wondered about that approach. But it definitely would need some experiments to validate. But in some ways it’d be super fascinating.

On Mon, Aug 17, 2020 at 9:40 AM Henning Thielemann mailto:lemming@henning-thielemann.de> wrote:

On Sun, 16 Aug 2020, Carter Schonwald wrote:

> I do think that the work needed to actually support fractional > precedence in ghc is pretty minimal.  Or at least I remember having a > conversation about it a few years ago, and the conclusion was that >  adding precedence would be super easy to do, but just lacked any good > motivating example from real libraries.

I remember this discussion, too, and I guess that it was started by Simon Marlow and it ended with recalling that decades ago something more advanced was discussed: Groups of equal precedence and relations between the groups. But that one was too complicated to be implemented.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

What if the global numeric precedence scheme was retained, but users could overlay their own precedence graph? The nodes in that graph could be the operators one wants to treat differently, plus the usual 10 precedence levels. It wouldn't have to be connected. On Wed, Sep 2, 2020 at 5:30 PM John Cotton Ericson wrote:

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.

John On 8/17/20 12:12 PM, Carter Schonwald wrote:

Oh yeah! I feel like everyone’s wondered about that approach. But it definitely would need some experiments to validate. But in some ways it’d be super fascinating.

On Mon, Aug 17, 2020 at 9:40 AM Henning Thielemann < lemming@henning-thielemann.de> wrote:

...

On Sun, 16 Aug 2020, Carter Schonwald wrote:

...

I do think that the work needed to actually support fractional precedence in ghc is pretty minimal. Or at least I remember having a conversation about it a few years ago, and the conclusion was that adding precedence would be super easy to do, but just lacked any good motivating example from real libraries.

I remember this discussion, too, and I guess that it was started by Simon Marlow and it ended with recalling that decades ago something more advanced was discussed: Groups of equal precedence and relations between the groups. But that one was too complicated to be implemented.

_______________________________________________ Libraries mailing listLibraries@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Jeff Brown | Jeffrey Benjamin Brown Website https://msu.edu/~brown202/ | Facebook https://www.facebook.com/mejeff.younotjeff | LinkedIn https://www.linkedin.com/in/jeffreybenjaminbrown(spammy, so I often miss messages here) | Github https://github.com/jeffreybenjaminbrown

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

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 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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

`seq` would be an issue too. On Thu, Sep 3, 2020, 3:11 PM Henning Thielemann < lemming@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries