<p dir="ltr">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.</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Nov 17, 2016 11:40 AM, "Conal Elliott" <<a href="mailto:conal@conal.net">conal@conal.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p style="margin-bottom:1em;font-family:serif;color:rgb(0,0,0);font-size:medium">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 <a href="https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#how-rules-interact-with-class-methods" style="color:rgb(153,153,204)" target="_blank">GHC Users Guide docs say no</a>, 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. <br></p><p style="margin-bottom:1em;font-family:serif;color:rgb(0,0,0);font-size:medium">In <code class="m_6898307389108568202gmail-sourceCode m_6898307389108568202gmail-haskell" style="white-space:pre-wrap;font-size:19.55px;background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial;background-color:transparent;border:none;overflow:auto;border-radius:0.2em"><span class="m_6898307389108568202gmail-dt" style="color:rgb(144,32,0)">Control.Category</span></code> and <code class="m_6898307389108568202gmail-sourceCode m_6898307389108568202gmail-haskell" style="white-space:pre-wrap;font-size:19.55px;background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial;background-color:transparent;border:none;overflow:auto;border-radius:0.2em"><span class="m_6898307389108568202gmail-dt" style="color:rgb(144,32,0)">Contro<wbr>l.Arrow</span></code>, 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”.</p><p style="margin-bottom:1em;font-family:serif;color:rgb(0,0,0);font-size:medium">I’d appreciate a reality check about my conclusions as well as any strategies for using class laws in optimization.</p><p style="margin-bottom:1em;font-family:serif;color:rgb(0,0,0);font-size:medium">Thanks, -- Conal</p></div>
<br>______________________________<wbr>_________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.<wbr>org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/glasgow-<wbr>haskell-users</a><br>
<br></blockquote></div></div>