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 <simonpj@microsoft.com> 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:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Conal Elliott
Sent: 17 November 2016 16:40
To: glasgow-haskell-users@haskell.org
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