Class op rules

[Simon Peyton Jones]

Here’s how it works:


  *   The rewrite from    opi (D m1 … mn)   -->   mi

is done by a BuiltinRule: see MkId.mkDictSelId, and the BuiltinRule that is made there.



  *   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.


  *   The phases go
     *   InitialPhase
     *   2
     *   1
     *   0


  *   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.


  *   Of course you can always add more phases, but that adds compile time.


  *   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 #-} }

Here the intent is that, since the pragmas is in the class decl, the pragma applies to the method selector.

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.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Conal Elliott
Sent: 06 March 2020 17:37
To: Christiaan Baaij <christiaan.baaij at gmail.com>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: Re: Class op rules

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

On Fri, Mar 6, 2020 at 7:22 AM Christiaan Baaij <christiaan.baaij at gmail.com<mailto:christiaan.baaij at gmail.com>> wrote:
Hello,

The other day I was experimenting with RULES and got this warning:

src/Clash/Sized/Vector.hs:2159:11: warning: [-Winline-rule-shadowing]
    Rule "map Pack" may never fire
      because rule "Class op pack" for ‘pack’ might fire first
    Probable fix: add phase [n] or [~n] to the competing rule
     |
2159 | {-# RULES "map Pack" map pack = id #-}

The warning seems to suggests two things:
1. "Class op" -> "dictionary projection" are implemented as rewrite rules and executed the same way as other user-defined RULES
2. These rules run first, and you cannot run anything before them

Now my question is, is 1. actually true? or is that warning just a (white) lie?
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.
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.

Thanks,
Christiaan

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200306/f6636f40/attachment.html>