-
Notifications
You must be signed in to change notification settings - Fork 24
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
Proof obligations, even on closed programs #4
Comments
Ok, so here is the problem with fixpoints. A simplified version of the type rule of fixpoints is :
If you "translate" the premise, you obtain (where [|.|] is the translation):
Now, if you translate fixpoints:
If we would have F (fix F) === fix F (where === is definitionnal equality), then we could translate fixpoints by
Unfortunately, F (fix F) === fix F does not hold (it would make coq definitional equality undecidable). With "nice" fixpoints, there's a work-around to avoid all this "proof-obligation mess". A nice fixpoint is a fixpoint that is of the shape 'fixpoint f x1 ... xn (i : I y1 ... ym) := "nested match ... with ... with one of them destructing i". Note that all inductive principles are of this shape. Finally, sometimes there's no way to get around these problems (the proof obligations are not provable). Here is an example:
Try to convince yourself that you will not be able to prove (without axioms) that
or
|
Thanks Marc. Indeed, However, I think that the this example ( Finally, I noticed that it helps to preprocess the branches of pattern matches to replace the occurrences of the dicriminee with appropriate constructors. For example, here is
It seems that the translation described in the paper will produce something like:
which doesn't typecheck.
Perhaps we can do this preprocessing before translating matches? Is there already a function in Coq's plugin API to do this kind of preprocessing? |
Update the Readme (Add doc for "qualified" & Improve details)
Hi, what is the current status of the
I could prove:
but not:
I wonder whether there is a general rule to characterize these fixpoints, or, alternatively, if there is a way to type |
I would say: same status as five years ago, when this was opened. |
Based on the description of the plugin in [1], I expected it to not need any user input when translating closed terms. However, sometimes, it leaves me with strange proof obligations.
Why does this happen? Is there a way to ensure that no user input is needed for closed terms?
Here is an example where user imput is needed:
[1] http://arxiv.org/abs/1209.6336
The text was updated successfully, but these errors were encountered: