Quantcast

GHC rewrite rules for class operations & laws

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

GHC rewrite rules for class operations & laws

Conal Elliott

Is it possible to apply GHC rewrite rules to class methods? From what I’ve read and seen, class methods get eliminated early by automatically-generated rules. Is there really no way to postpone such inlining until a later simplifier stage? The GHC Users Guide docs say no, and suggests instead giving a duplicate vocabulary with somewhat awkward names for class methods. I’ve not seen this practice in libraries. I gather that we cannot therefore use class laws as optimizations in the form of rewrite rules, which seems a terrible loss. 

In Control.Category and Control.Arrow, I see rules for class laws but also header comments saying “The RULES for the methods of class Arrow may never fire e.g. compose/arr; see Trac #10528”.

I’d appreciate a reality check about my conclusions as well as any strategies for using class laws in optimization.

Thanks, -- Conal


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC rewrite rules for class operations & laws

David Feuer

The containers package uses the awkward double name approach. See, for example, the way that Data.Map and Data.Sequence fuse (indexed) maps and indexed) traversals. I know that Edward Kmett is very much opposed to class-based rules as found in Control.Arrow because non-law-abiding instances will behave differently when optimized.


On Nov 17, 2016 11:40 AM, "Conal Elliott" <[hidden email]> wrote:

Is it possible to apply GHC rewrite rules to class methods? From what I’ve read and seen, class methods get eliminated early by automatically-generated rules. Is there really no way to postpone such inlining until a later simplifier stage? The GHC Users Guide docs say no, and suggests instead giving a duplicate vocabulary with somewhat awkward names for class methods. I’ve not seen this practice in libraries. I gather that we cannot therefore use class laws as optimizations in the form of rewrite rules, which seems a terrible loss. 

In Control.Category and Control.Arrow, I see rules for class laws but also header comments saying “The RULES for the methods of class Arrow may never fire e.g. compose/arr; see Trac #10528”.

I’d appreciate a reality check about my conclusions as well as any strategies for using class laws in optimization.

Thanks, -- Conal


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: GHC rewrite rules for class operations & laws

Haskell - Glasgow-haskell-users mailing list
In reply to this post by Conal Elliott

Conal

 

Is it possible to apply GHC rewrite rules to class methods?

 

Not currently.  See https://ghc.haskell.org/trac/ghc/ticket/11688, esp comment:7 which gives links to similar examples.  https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13  gives more background.

 

It’d be great if someone wanted to think through all this.

 

Simon

 

From: Glasgow-haskell-users [mailto:[hidden email]] On Behalf Of Conal Elliott
Sent: 17 November 2016 16:40
To: [hidden email]
Subject: GHC rewrite rules for class operations & laws

 

Is it possible to apply GHC rewrite rules to class methods? From what I’ve read and seen, class methods get eliminated early by automatically-generated rules. Is there really no way to postpone such inlining until a later simplifier stage? The GHC Users Guide docs say no, and suggests instead giving a duplicate vocabulary with somewhat awkward names for class methods. I’ve not seen this practice in libraries. I gather that we cannot therefore use class laws as optimizations in the form of rewrite rules, which seems a terrible loss. 

In Control.Category and Control.Arrow, I see rules for class laws but also header comments saying “The RULES for the methods of class Arrow may never fire e.g. compose/arr; see Trac #10528”.

I’d appreciate a reality check about my conclusions as well as any strategies for using class laws in optimization.

Thanks, -- Conal


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC rewrite rules for class operations & laws

Conal Elliott
Thanks, Simon. For now, I've added a module with aliases for all of my class methods and law-based rewrite rules in terms of those aliases.

- Conal

On Tue, Nov 22, 2016 at 4:06 AM, Simon Peyton Jones <[hidden email]> wrote:

Conal

 

Is it possible to apply GHC rewrite rules to class methods?

 

Not currently.  See https://ghc.haskell.org/trac/ghc/ticket/11688, esp comment:7 which gives links to similar examples.  https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13  gives more background.

 

It’d be great if someone wanted to think through all this.

 

Simon

 

From: Glasgow-haskell-users [mailto:[hidden email]] On Behalf Of Conal Elliott
Sent: 17 November 2016 16:40
To: [hidden email]
Subject: GHC rewrite rules for class operations & laws

 

Is it possible to apply GHC rewrite rules to class methods? From what I’ve read and seen, class methods get eliminated early by automatically-generated rules. Is there really no way to postpone such inlining until a later simplifier stage? The GHC Users Guide docs say no, and suggests instead giving a duplicate vocabulary with somewhat awkward names for class methods. I’ve not seen this practice in libraries. I gather that we cannot therefore use class laws as optimizations in the form of rewrite rules, which seems a terrible loss. 

In Control.Category and Control.Arrow, I see rules for class laws but also header comments saying “The RULES for the methods of class Arrow may never fire e.g. compose/arr; see Trac #10528”.

I’d appreciate a reality check about my conclusions as well as any strategies for using class laws in optimization.

Thanks, -- Conal



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC rewrite rules for class operations & laws

George Colpitts
In reply to this post by Haskell - Glasgow-haskell-users mailing list
Do you want me to add a task ticket to remove this restriction that rewrite rules can't be used for class methods?

On Tue, Nov 22, 2016 at 8:06 AM Simon Peyton Jones via Glasgow-haskell-users <[hidden email]> wrote:

Conal

 

Is it possible to apply GHC rewrite rules to class methods?

 

Not currently.  See https://ghc.haskell.org/trac/ghc/ticket/11688, esp comment:7 which gives links to similar examples.  https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13  gives more background.

 

It’d be great if someone wanted to think through all this.

 

Simon

 

From: Glasgow-haskell-users [mailto:[hidden email]] On Behalf Of Conal Elliott
Sent: 17 November 2016 16:40
To: [hidden email]
Subject: GHC rewrite rules for class operations & laws

 

Is it possible to apply GHC rewrite rules to class methods? From what I’ve read and seen, class methods get eliminated early by automatically-generated rules. Is there really no way to postpone such inlining until a later simplifier stage? The GHC Users Guide docs say no, and suggests instead giving a duplicate vocabulary with somewhat awkward names for class methods. I’ve not seen this practice in libraries. I gather that we cannot therefore use class laws as optimizations in the form of rewrite rules, which seems a terrible loss. 

In Control.Category and Control.Arrow, I see rules for class laws but also header comments saying “The RULES for the methods of class Arrow may never fire e.g. compose/arr; see Trac #10528”.

I’d appreciate a reality check about my conclusions as well as any strategies for using class laws in optimization.

Thanks, -- Conal

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC rewrite rules for class operations & laws

Conal Elliott
Hi, George. Yes, please do add a task, hopefully to serve as a conversation anchor until the issues and path forward are clearer. From my perspective, class methods are among the most natural and useful candidates for rewrite rules, since they tend to have associated laws, many (but not all) of which are helpful in optimization. The alternative I know (and am using) is fairly inconvenient: replicating entire APIs just in order to delay inlining long enough to apply rules.

Thanks,  - Conal


On Sun, Dec 11, 2016 at 7:24 AM, George Colpitts <[hidden email]> wrote:
Do you want me to add a task ticket to remove this restriction that rewrite rules can't be used for class methods?

On Tue, Nov 22, 2016 at 8:06 AM Simon Peyton Jones via Glasgow-haskell-users <[hidden email]> wrote:

Conal

 

Is it possible to apply GHC rewrite rules to class methods?

 

Not currently.  See https://ghc.haskell.org/trac/ghc/ticket/11688, esp comment:7 which gives links to similar examples.  https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13  gives more background.

 

It’d be great if someone wanted to think through all this.

 

Simon

 

From: Glasgow-haskell-users [mailto:[hidden email]] On Behalf Of Conal Elliott
Sent: 17 November 2016 16:40
To: [hidden email]
Subject: GHC rewrite rules for class operations & laws

 

Is it possible to apply GHC rewrite rules to class methods? From what I’ve read and seen, class methods get eliminated early by automatically-generated rules. Is there really no way to postpone such inlining until a later simplifier stage? The GHC Users Guide docs say no, and suggests instead giving a duplicate vocabulary with somewhat awkward names for class methods. I’ve not seen this practice in libraries. I gather that we cannot therefore use class laws as optimizations in the form of rewrite rules, which seems a terrible loss. 

In Control.Category and Control.Arrow, I see rules for class laws but also header comments saying “The RULES for the methods of class Arrow may never fire e.g. compose/arr; see Trac #10528”.

I’d appreciate a reality check about my conclusions as well as any strategies for using class laws in optimization.

Thanks, -- Conal

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC rewrite rules for class operations & laws

Ben Gamari-2
On December 28, 2016 7:27:20 PM EST, Conal Elliott <[hidden email]> wrote:

>Hi, George. Yes, please do add a task, hopefully to serve as a
>conversation
>anchor until the issues and path forward are clearer. From my
>perspective,
>class methods are among the most natural and useful candidates for
>rewrite
>rules, since they tend to have associated laws, many (but not all) of
>which
>are helpful in optimization. The alternative I know (and am using) is
>fairly inconvenient: replicating entire APIs just in order to delay
>inlining long enough to apply rules.
>
Indeed, we could eliminate several hundred lines of boilerplate in GHC if we could lift this restriction.

Cheers,

- Ben


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GHC rewrite rules for class operations & laws

George Colpitts
In reply to this post by Conal Elliott
Done: https://ghc.haskell.org/trac/ghc/ticket/13044#ticket

Not sure if it fully captures what you want so people should feel free to edit.

Cheers
George


On Wed, Dec 28, 2016 at 8:27 PM Conal Elliott <[hidden email]> wrote:
Hi, George. Yes, please do add a task, hopefully to serve as a conversation anchor until the issues and path forward are clearer. From my perspective, class methods are among the most natural and useful candidates for rewrite rules, since they tend to have associated laws, many (but not all) of which are helpful in optimization. The alternative I know (and am using) is fairly inconvenient: replicating entire APIs just in order to delay inlining long enough to apply rules.

Thanks,  - Conal


On Sun, Dec 11, 2016 at 7:24 AM, George Colpitts <[hidden email]> wrote:
Do you want me to add a task ticket to remove this restriction that rewrite rules can't be used for class methods?

On Tue, Nov 22, 2016 at 8:06 AM Simon Peyton Jones via Glasgow-haskell-users <[hidden email]> wrote:

Conal

 

Is it possible to apply GHC rewrite rules to class methods?

 

Not currently.  See https://ghc.haskell.org/trac/ghc/ticket/11688, esp comment:7 which gives links to similar examples.  https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13  gives more background.

 

It’d be great if someone wanted to think through all this.

 

Simon

 

From: Glasgow-haskell-users [mailto:[hidden email]] On Behalf Of Conal Elliott
Sent: 17 November 2016 16:40
To: [hidden email]
Subject: GHC rewrite rules for class operations & laws

 

Is it possible to apply GHC rewrite rules to class methods? From what I’ve read and seen, class methods get eliminated early by automatically-generated rules. Is there really no way to postpone such inlining until a later simplifier stage? The GHC Users Guide docs say no, and suggests instead giving a duplicate vocabulary with somewhat awkward names for class methods. I’ve not seen this practice in libraries. I gather that we cannot therefore use class laws as optimizations in the form of rewrite rules, which seems a terrible loss. 

In Control.Category and Control.Arrow, I see rules for class laws but also header comments saying “The RULES for the methods of class Arrow may never fire e.g. compose/arr; see Trac #10528”.

I’d appreciate a reality check about my conclusions as well as any strategies for using class laws in optimization.

Thanks, -- Conal

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: GHC rewrite rules for class operations & laws

Haskell - Glasgow-haskell-users mailing list
In reply to this post by Ben Gamari-2
|  Indeed, we could eliminate several hundred lines of boilerplate in GHC if we
|  could lift this restriction.

Can you be more specific?  Which hundreds of lines?

Do add this info to the ticket when Gorge makes it.  Or just make one!

Simon

|  -----Original Message-----
|  From: Ben Gamari [mailto:[hidden email]]
|  Sent: 29 December 2016 14:50
|  To: Conal Elliott <[hidden email]>; George Colpitts
|  <[hidden email]>
|  Cc: [hidden email]; Simon Peyton Jones
|  <[hidden email]>
|  Subject: Re: GHC rewrite rules for class operations & laws
|  
|  On December 28, 2016 7:27:20 PM EST, Conal Elliott <[hidden email]> wrote:
|  >Hi, George. Yes, please do add a task, hopefully to serve as a
|  >conversation anchor until the issues and path forward are clearer. From
|  >my perspective, class methods are among the most natural and useful
|  >candidates for rewrite rules, since they tend to have associated laws,
|  >many (but not all) of which are helpful in optimization. The
|  >alternative I know (and am using) is fairly inconvenient: replicating
|  >entire APIs just in order to delay inlining long enough to apply rules.
|  >
|  Indeed, we could eliminate several hundred lines of boilerplate in GHC if we
|  could lift this restriction.
|  
|  Cheers,
|  
|  - Ben
|  

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: GHC rewrite rules for class operations & laws

Ben Gamari-2
Welcome back, Simon!

Simon Peyton Jones <[hidden email]> writes:

> |  Indeed, we could eliminate several hundred lines of boilerplate in GHC if we
> |  could lift this restriction.
>
> Can you be more specific?  Which hundreds of lines?
>
In particular the bindings in Data.Int and Data.Word (e.g. GHC.Int.eqInt8,
GHC.Word.gtWord64).

> Do add this info to the ticket when Gorge makes it.  Or just make one!
>
The ticket is #13044.

Cheers,

- Ben

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

signature.asc (497 bytes) Download Attachment
Loading...