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 <co...@conal.net> 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 < > george.colpi...@gmail.com> 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 <glasgow-haskell-users@haskell.org> 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-boun...@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 > <https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fglasgow_exts.html%23how-rules-interact-with-class-methods&data=02%7C01%7Csimonpj%40microsoft.com%7C8678611c4c57499f97be08d40f08662a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636149976146128136&sdata=GjkFhlWdNkT6eo85FvcLKkJYoir7Dui9xJ9kMTYKVmU%3D&reserved=0>, > 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
