-
Notifications
You must be signed in to change notification settings - Fork 3
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
RULES exploration #34
Comments
If lift m >>= f ==> fromView $ m >>= toView . f looks promising. In combination with that, we might want to reassociate binds: (m >>= n) >>= f ==> m >>= \x -> n x >>= f The big question is whether we can convince either of these rules to fire. There may also be ways to change the |
My understanding of how RULES would work for this (since almost everything here is a type class method) is that we'll need to provide standalone functions that implement those methods and write the RULES against those. Phase control might help with some of the ordering of applying the rules. Phases start at some high number and go until phase 0 runs. So you could have a I really like these kinds of optimizations but having multiple rules does come at a cost. As you know, when you have multiple rules you have to make sure they are confluent. And they have to respect strictness. So it's not just the normal term equality confluence but I believe it's a stronger version that respects strictness? |
As part of the |
Confluence is a desirable property, but not something we can generally guarantee within the confines of GHC's system. In particular, rules firing can affect inlining decisions and such that may affect whether other rules will fire. Even rules that appear confluent, therefore, may not actually be. I'm guessing you're actually concerned about the much weaker guarantee that rules should not change program meaning. That is very important, yes. I don't think that should really be particularly hard, including with regard to strictness, under the assumption that the underlying |
Confluence is the property mentioned in the papers and documentation. I forget exactly where I read it, but I know I saw confluence and preserving strictness both mentioned. |
Confluence is discussed on the Haskell Wiki. It's mentioned in the GHC documentation, but only in passing. The basic idea is that you should try to avoid writing rules in such a way that the choice of which rule to fire next (when there are multiple choices) will have a dramatic impact on performance. |
And yes, we should be careful to preserve strictness. But as I said above, we can do very little without assuming strictly lawful |
Awkwardly, |
Or do we want to just say that users shouldn't |
I just realized that |
I realized we actually can use a slightly more limited rule even without assuming the user's toView (fromView m) = m >>= \x -> return x This is the result of just inlining and reducing. In principle, GHC could do this without a rule, but I don't know if it does. |
Indeed, GHC seems not to do this itself, so let's try. |
Opening this up to explore some things we might want to smash with RULES.
toView (lift m) = m >>= single
. I believe this should helplift m <|> n
andm <|> lift n
.toView (fromView m) = m
. Among other things, this should improvepure a <|> m
andm <|> pure a
.The text was updated successfully, but these errors were encountered: