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" <co...@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@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users