-
Notifications
You must be signed in to change notification settings - Fork 18
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
Handling equalities is way too painful #131
Comments
Equality as an assumption in Abella is treated via unification. Your example The only way I see to prove your theorem I would rather paraphrase your criticism not as a critique of equality in Abella but more as a critique about how it treats flexible terms in equations. Since flex-flex pairs have seldom appeared in most applications, we have not tried to propose a means to treat such pairs better. Your theorem |
Yes, we have a theorem where the issue appears all over the place. (We are not yet ready to disclose the full development, sorry.) The consequent of the theorem looks like
I see. That said, in our case, it does not seem like we need something sophisticated. If This leaves open the question on how to deal with the last 3 subcases. But, given that we had to use |
One thing apparent from your example using
Thus, your sample can be simplified by proving several simple congruence-like theorems, such as
and then using
Although these are logically equal, backchaining will only need to generate instances for Regarding your suggestion of "turning a goal |
That is how I did it initially. But once I noticed that
That is interesting. Abella tries very hard to discourage the user from ever parenthesizing That said, I do not see any difference. It seems Abella is just as happy with
and
Moreover, I am getting really confused by the fact that the following fails:
while the following succeeds:
Parenthesizing |
I guess I need to take back my claim about putting a scope on nabla to help backchaining. I tried to find my counterexample and haven't been able to reproduce it. I'm glad that the implementation is more robust than I thought it might be. Looking forward to seeing your examples (when they are ready). |
The intros tactic does not do any left-asynchronous rules, whereas search does some obvious cases. Basically, intros preserves the hypothesis (A x = B x), while search automatically applies (the equivalent of) case on it. The search tactic was extended in this way after a number of users complained that search was stupidly going down branches that can be obviously closed, making writing large proofs either slow or tedious. As to why this discrepancy between the two tactics exists: making intros also do left-asynchronous rules breaks all our existing example proofs. As usual, backwards compatibility forces us to make non-optimal design choices. |
That makes sense, and it explains why |
I am also experiencing some of the problems discussed here. I wonder if a For example,
|
The following code is a workaround. Since Abella will not reason forward from an assumption of the form
Having said this, it seems odd to be proving |
Thanks for the reply. I am aware of this type of wordaround and have used the technique several times before. What I suggested was to add a new logic rule (or just a tactic) that explicitly rewrites the left-hand-side/right-hand-side term in hypotheses or goal, which might not solve all the problems discussed above, but at least some. |
Consider the following simplified testcase:
This goal should be trivial to prove by doing
case H1
. Unfortunately it does not work. Doingcase H1
does not modify the goal, it just creates a new hypothesisH2: T U = T V
, which is justH1
again. No progress was made at all!So, let us try it another way. Let us first assert a simpler goal and then try to apply it:
Unfortunately, it still does not work. Doing
apply
just createsH3: T U = T V
(noabs
!). So, yet again, no progress was made.The only way to succeed (that I found) was:
Not only is it ugly, but it does not scale. On more complicated goals, it is just impossible to use
backchain
(if only because the goal is not an equality). This leads to very contrived proofs for goals that would have been trivial to discharge ifcase
worked correctly.The text was updated successfully, but these errors were encountered: