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
Introduce class MonadSimplify #691
Conversation
These instances were Technically Correct, but didn't do what one would like. `mapListT` should replace most uses of `hoist`. No replacement is offered for `embed`.
@Vladciobanu I fixed the SMT problems I was having, but I seem to have introduced more failures in unification. |
@@ -231,13 +229,8 @@ test_onePathStrategy = | |||
) | |||
, substitution = mempty | |||
} | |||
, Bottom |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@virgil-serbanuta Is it OK if this test no longer explicitly outputs Bottom
? I don't actually know what it represents in this case, but it's in a disjunction anway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, for these tests, Bottom
means either a branch that we managed to prove, or a branch that ended up as bottom, but we couldn't figure that out early enough (e.g. we applied an axiom, before simplification we didn't know that the result was bottom, but simplification made that clear).
Based on the comments at the top, my guess is that this was the second kind of bottom, perhaps because we applied first the coinductive rule constr11(a) => g(a)
, then we applied constr11(a) => g(a)
to the remainder, without being able to tell that the predicate will become bottom.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the second explanation makes sense, too. The change that precipitated this change is that we are now using a real simplifier here instead of a mock simplifier for predicates, because the mock simplifier was misbehaving. I switched to using a real simplifier instead of trying to debug the mock; this was the only test output which was affected. I think I know what's happening with the mock simplifier now, so if this test change isn't acceptable I can take another look.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My comment is too late, but: this change is fine.
@Vladciobanu I'm going to go ahead and merge this to prevent more conflicts. I think this is already significant progress in the planned refactoring, and it's self-contained (mainly, it just adds
|
Reviewer checklist
stack test --coverage
stack haddock
stylish-haskell