-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite rules for Data.Map.Merge.Lazy interface #3
Comments
Interesting problem! I was trying
(expecting it to fire when the types match) but ghc says
How can I even change "the context of the rule"? I cannot write a type for the rule - only for variables used in the rule? |
Note that this rule does fire (for your test case mentioned above)
I think the problem is discussed here https://stackoverflow.com/questions/19745038/ghc-rewrite-rule-specialising-a-function-for-a-type-class |
Thanks for lending a hand. Following this other SO question, GHC seems to accept it if I add a context to the type variable like this:
However, I don't think it is firing. This could be because:
I'd appreciate any more help you can offer. |
"-ddump-rule-firings" etc., see https://downloads.haskell.org/~ghc/8.8.1/docs/html/users_guide/glasgow_exts.html#rewrite-rules |
That SO question is good reading material, thanks for the link. I think that specialisation happens before the polymorphic rewrite rule gets a look-in. This might be why the monomorphic rewrite rule works. The SO question referenced the |
There are some obvious specialisations for
Data.Semialign.Diff.diff
andData.Semialign.Diff.diffNoEq
, using the high-perfomance interface inData.Map.Merge.Lazy
:And some rewrite rules:
Using
inspection-testing
and this code:It appears that neither rewrite rule is firing.
There are likely similar rules available for patching maps using maps, if I can get them to fire.
The text was updated successfully, but these errors were encountered: