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" <conal at conal.net> 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
> <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#how-rules-interact-with-class-methods>,
> 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
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20161117/bb3c7219/attachment.html>