Open ehildenb opened 2 years ago
Requires modifying kore-exec
to detect "functional claims", which will be encoded as REQ -> (LHS #Equals (RHS #And ENS))
(in order to be very similar to actual simplification rules) inside spec modules. If the proof fails, return the claim as part of the stuck claims conjunction (as we do with the other type of claims).
If implication simplification works as expected for this feature this should be small
@JKTKops We need to make sure that https://github.com/runtimeverification/haskell-backend/issues/3121 is supported in this feature. A similar test should be added when implementing this.
What would be the best way to represent EquationalClaim
s?
It's an implication, always of the form \\implies(requires, \\equals(leftTerm, \\and(rightTerm, ensures)))
.
simplify :: Pattern -> OrPattern
checkImplication :: claim -> LogicT m (CheckImplicationResult claim)
We want trans1 :: EquationalClaim -> Pattern
and trans2 :: OrPattern -> EquationalClaim
For now let's go with EquationalClaim ~ OrPattern
.
We will refactor class Claim
later to make it more general.
https://github.com/runtimeverification/haskell-backend/blob/b06757e252ee01fdd5ab8f07de2910711997d845/kore/test/Test/ConsistentKore.hs#L204 is our Pattern generator
@radumereuta let us know when you have a working branch with the frontend support so that we can start integration testing.
Front end changes: https://github.com/runtimeverification/k/pull/2733
Part of https://github.com/runtimeverification/k/issues/2491
Should the backend be allowed to use these functional claims as lemmas directly? When discharging other proof goals, we could treat these functional claims as lemmas, to assist in those proofs.