<div dir="ltr"><div>Thanks for explaining Simon!</div><div><br></div><div>So I personally could live with a situation
where it is controllable for each classop individually - and I'd do the work to get that in.<br></div><div>Where if the developer doesn't specify an INLINE pragma, it defaults to AlwaysActive.</div><div>That way, the change only affects users who have currently annotated their class op with an {-# INLINE[N] op #-}</div><div>(I would have to scour hackage to see if anyone has currently doing that... I hope not...)<br></div><div><br></div><div>But now that this has been brought up: currently, does adding an {-# INLINE op #-} (with or without phase) for a class op actually do anything?</div><div>Or is it basically superfluous because the class op already gets a BuiltInRule that's equal to INLINE AlwaysActive?</div><div>Or does it affect whether a default implementation for the method gets inlined into the dictionary?</div><div>If the latter, I guess we should use SPECIALIZE instead of INLINE for controlling the rule phase of the class op... unless that SPECIALIZE also has an effect on the class op default implementation...<br></div><div><br></div><div>Thanks,</div><div>Christiaan<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 7 Mar 2020 at 00:02, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB">
<div class="gmail-m_-8459479282043687378WordSection1">
<p class="MsoNormal">Here’s how it works:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-8459479282043687378MsoListParagraph" style="margin-left:0cm">The rewrite from opi (D m1 … mn)
<span style="font-family:Wingdings">à</span> mi<u></u><u></u></li></ul>
<p class="gmail-m_-8459479282043687378MsoListParagraph">is done by a BuiltinRule: see MkId.mkDictSelId, and the BuiltinRule that is made there.<u></u><u></u></p>
<p class="gmail-m_-8459479282043687378MsoListParagraph"><u></u> <u></u></p>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-8459479282043687378MsoListParagraph" style="margin-left:0cm">At the moment, BuiltinRules are always active (in all phases), see GHC.Core.ruleActivation. To allow them to be selectively active, we’d have to give them a ru_act fiels, like ordinary
Rules. That would not be hard.<u></u><u></u></li></ul>
<p class="MsoNormal"><u></u> <u></u></p>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-8459479282043687378MsoListParagraph" style="margin-left:0cm">The phases go<u></u><u></u></li><ul style="margin-top:0cm" type="circle">
<li class="gmail-m_-8459479282043687378MsoListParagraph" style="margin-left:0cm">InitialPhase<u></u><u></u></li><li class="gmail-m_-8459479282043687378MsoListParagraph" style="margin-left:0cm">2<u></u><u></u></li><li class="gmail-m_-8459479282043687378MsoListParagraph" style="margin-left:0cm">1<u></u><u></u></li><li class="gmail-m_-8459479282043687378MsoListParagraph" style="margin-left:0cm">0<u></u><u></u></li></ul>
</ul>
<p class="MsoNormal"><u></u> <u></u></p>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-8459479282043687378MsoListParagraph" style="margin-left:0cm">We could make classop rules active only in phase 1 and 0, say. I don’t know what the consequences would be; running the classop to pick a method out of a dictionary in turn reveals
new function applications that might want to work in phase 2, say.<u></u><u></u></li></ul>
<p class="MsoNormal"><u></u> <u></u></p>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-8459479282043687378MsoListParagraph" style="margin-left:0cm">Of course you can always add more phases, but that adds compile time.<u></u><u></u></li></ul>
<p class="MsoNormal"><u></u> <u></u></p>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-8459479282043687378MsoListParagraph" style="margin-left:0cm">Would you want the classop phase to be fixed for every classop? Or controllable for each classop individually. E.g. class C a where { op :: <bype> {-# INLINE [2] op #-} }<u></u><u></u></li></ul>
<p class="gmail-m_-8459479282043687378MsoListParagraph">Here the intent is that, since the pragmas is in the class decl, the pragma applies to the method selector.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I remember Conal raising this before, but I’ve forgotten the resolution. I’m entirely open to changes here, if someone is willing to do the work, including checking for consequences.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Simon<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-color:currentcolor currentcolor currentcolor blue;border-style:none none none solid;border-width:medium medium medium 1.5pt;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-devs <<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a>>
<b>On Behalf Of </b>Conal Elliott<br>
<b>Sent:</b> 06 March 2020 17:37<br>
<b>To:</b> Christiaan Baaij <<a href="mailto:christiaan.baaij@gmail.com" target="_blank">christiaan.baaij@gmail.com</a>><br>
<b>Cc:</b> ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>><br>
<b>Subject:</b> Re: Class op rules<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Thank you for raising this issue, Christiaan! The current policy (very early class-op inlining) is a major difficulty and the main source of fragility in my compiling-to-categories implementation. I have a tediously programmed and delicately balanced collection
of techniques to intercept and transform class ops to non-ops early and then transform back late for elimination, but it doesn't work in all situations. Since class operations roughly correspond to operations in various algebraic abstractions---interfaces
with laws---I often want to exploit exactly those laws as rewrite rules, and yet those rules currently cannot be used dependably. - Conal<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
On Fri, Mar 6, 2020 at 7:22 AM Christiaan Baaij <<a href="mailto:christiaan.baaij@gmail.com" target="_blank">christiaan.baaij@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Hello,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
The other day I was experimenting with RULES and got this warning:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
src/Clash/Sized/Vector.hs:2159:11: warning: [-Winline-rule-shadowing]<br>
Rule "map Pack" may never fire<br>
because rule "Class op pack" for ‘pack’ might fire first<br>
Probable fix: add phase [n] or [~n] to the competing rule<br>
|<br>
2159 | {-# RULES "map Pack" map pack = id #-}<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
The warning seems to suggests two things:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
1. "Class op" -> "dictionary projection" are implemented as rewrite rules and executed the same way as other user-defined RULES<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
2. These rules run first, and you cannot run anything before them<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Now my question is, is 1. actually true? or is that warning just a (white) lie?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
If 1. is actually true, would there be any objections to adding a "-1" phase: where RULES specified to start from phase "-1" onward fire before any of the Class op rules.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
I'm quite willing to implement the above if A) Class op rules are actually implemented as builtin RULES; B) there a no objections to this "-1" phase.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Christiaan<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote></div>