Operator precedence help

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Operator precedence help

David Feuer
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Operator precedence help

Andreas Abel
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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Operator precedence help

David Feuer
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 <[hidden email]> 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Operator precedence help

Henning Thielemann

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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Operator precedence help

David Feuer
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Operator precedence help

Henning Thielemann

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 ++
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Operator precedence help

David Feuer
On Sun, Aug 16, 2020, 1:30 AM Henning Thielemann <[hidden email]> 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?

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Operator precedence help

Henning Thielemann

On Sun, 16 Aug 2020, David Feuer wrote:

> On Sun, Aug 16, 2020, 1:30 AM Henning Thielemann <[hidden email]> wrote:
>
>       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 have no idea.

Sometimes I think it would be better to omit infix operators and let
people define custom infix operators as appropriate for their application.
They still can do it by not importing the operators from the library.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Fractional precedences? Re: Operator precedence help

Carter Schonwald
In reply to this post by David Feuer
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Fractional precedences? Re: Operator precedence help

Henning Thielemann

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Fractional precedences? Re: Operator precedence help

Carter Schonwald
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Fractional precedences? Re: Operator precedence help

Lennart Augustsson
The Pretty class (from Text.PrettyPrint.HughesPJClass) uses Rational.

On Mon, Aug 17, 2020 at 9:12 AM Carter Schonwald <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Fractional precedences? Re: Operator precedence help

Andreas Abel
In reply to this post by Carter Schonwald
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
> <[hidden email] <mailto:[hidden email]>>
> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Fractional precedences? Re: Operator precedence help

John Ericson-2
In reply to this post by Carter Schonwald

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

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Fractional precedences? Re: Operator precedence help

Jeffrey Brown
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
Jeff Brown | Jeffrey Benjamin Brown
Website   |   Facebook   |   LinkedIn(spammy, so I often miss messages here)   |   Github   

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Fractional precedences? Re: Operator precedence help

Jeffrey Brown
In fact if one wanted to override part of the global precedence scheme using such a graph, it wouldn't even need to affect the final format of their code. That scheme could just be a different lens onto the same abstract syntax tree. Someone else looking at your code wouldn't have to know that you see a different ordering.

(The global ordering doesn't actually bother me. I'm just throwing ideas out there.)

On Wed, Sep 2, 2020 at 6:54 PM Jeffrey Brown <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
Jeff Brown | Jeffrey Benjamin Brown
Website   |   Facebook   |   LinkedIn(spammy, so I often miss messages here)   |   Github   


--
Jeff Brown | Jeffrey Benjamin Brown
Website   |   Facebook   |   LinkedIn(spammy, so I often miss messages here)   |   Github   

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Fractional precedences? Re: Operator precedence help

Ben Franksen
In reply to this post by John Ericson-2
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Fractional precedences? Re: Operator precedence help

Tikhon Jelvis
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Fractional precedences? Re: Operator precedence help

Henning Thielemann
In reply to this post by Tikhon Jelvis

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
12