I'm new to Coq. Currently I'm totally lost in how a workflow should look like.
I prove a theorem in Coqtop using tactics and then want to save the result code. But when I run Print my_theorem. it shows me a long and rather low-level output instead of the list of tactics applied. How should I persist proof results?
And are there any useful resources to learn more about Coq workflow?
Related
I am trying to implement a dependently typed evaluator of STLC in Coq using Program Fixpoint. Since the language does not have fixed point operator, I think the evaluator should terminate, though the termination condition is not structural.
During my development, I find one source of headache is I simply can't keep track of too many variables at the same time, and pattern matching is too nested.
If it were about a mere Fixpoint, I can just implement the body using tactics, but when using Program Fixpoint or Function, I just cannot. Is there any trick to build body using tactics in this case?
I am stuck at very end: https://gist.github.com/HuStmpHrrr/0d92e646916ae9ec7ced3ff21724ba2d
When using Program, you can simply leave underscores for parts of your term you want to fill in using proof mode. Any underscores that can be inferred will automatically be filled in and the remaining will produce obligations. For example, you can write all of run in proof mode by writing Program Fixpoint run ... {measure ...} := _. The measure will show up as an argument to run in the context.
What's the best approach to do interactive theorem proving in Coq without specifying a Theorem definition first? I'd like to state some initial assumptions and definitions, and then interactively explore transformations to see if I can prove any interesting theorems without knowing them ahead of time. I'd like Coq to help me keep track of the transformed assumptions and check that my rewrites are valid, like when proving explicit theorems in interactive mode. Does Coq have support for this use case?
One convenient method is to use the Variable/Hypothesis commands (they do the same thing) to add assumptions and introduce example objects (eg, Variable n:nat. introduces a nat you can now work with). Then to get into theorem proving mode what I do occasionally is Goal False. to start proving False, just to make sure I don't accidentally prove the theorem. You can also assert and admit things to get additional assumptions without restarting the proof.
So, I've got a proof that looks like this:
induction t; intros; inversion H ; crush.
It solves all my goals, but when I do Qed, I get the following error:
Cannot guess decreasing argument of fix.
So somewhere in the generated proof term, there's non-well-founded recursion. The problem is, I have no idea where.
Is there a way to debug this kind of error, or to see the (possibly non halting) proof term that the tactics script generates?
You can use Show Proof. to view the proof term so far.
Another command that can help with seeing where the recursion went wrong is Guarded., which runs the termination checker on the proof term so far. You'll need to break apart the tactic script into independent sentences to use it, though. Here's an example:
Fixpoint f (n:nat) : nat.
Proof.
apply plus.
exact (f n).
Guarded.
(* fails with:
Error:
Recursive definition of f is ill-formed.
...
*)
Defined.
You can use the Show Proof. command inside proof mode to print the proof term produced so far.
In addition to the other excellent answers, I also want to point out that using induction inside an interactive-mode Fixpoint is usually a mistake, because you're recursing twice. Writing fixpoints in interactive mode is often tricky because most automation tools will happily make a recursive call at every possible opportunity, even when it would be ill-founded.
I would advise to use Definition instead of Fixpoint and use induction in the proof script. This invokes the explicit recursor, which allows for much better control of automation. The disadvantage is decreased flexibility since fixpoints have fewer restrictions than recursors - but as we've seen, that is both a blessing and a curse.
During a proof, I come to a situation where the current goal/subgoal turned out to be useful in a later stage of the same theorem.
Is there a tactic to "save" the current goal as a lemma as if the current goal is asserted?
Of course, I can copy&paste to assert the goal explicitly, or write a separate Lemma before the current theorem. But I am just curious if shortcuts exist.
Thanks.
To my knowledge, there is no such feature in Coq, and neither CoqIDE nor ProofGeneral seems to provide one.
Leaving this answer for future reference.
I don't know since when it exists, but maybe the abstract tactic could help.
It allows you to name a part of the proof and re-use it later, even if you are in a different sub-goal.
If you are using Proof General, you can install a company-coq extension which provides this functionality. It is bound the C-c C-a C-x key sequence.
I'm learning Coq and the book I'm learning from, (CPDT) makes heavy use of auto in proofs.
Since I'm learning I think it might be helpful for me to see exactly what auto is doing under the hood (the less magic early on the better). Is there any way to force it to display exactly what tactics or techniques it's using to compute the proof?
If not, is there a place which details exactly what auto does?
There are multiple ways to get a glance at what is going on under the hood.
TLDR: Put info before your tactic, or use Show Proof. before and after calling the tactic and spot the differences.
To see what a particular tactic invocation has been doing, you can prefix is with info, so as to show the particular proof steps it has taken.
(This might be broken with Coq 8.4, I see that they provide info_ versions of some tactics, read the error message if you need to.)
This is probably what you want at a beginner level, it can already be quite terse.
Another way to see what is currently going on within a proof is to use the command Show Proof.. It will show you the currently built term with holes, and show you which hole each of your current goals is supposed to fill.
This is probably more advanced, especially if you use tactic such as induction or inversion, as the term being built is going to be fairly involved, and will require you to understand the underlying nature of induction schemes or dependent pattern-matching (which CPDT should teach you soon enough).
Once you have finished a proof with Qed. (or Defined.), you can also ask to look at the term that was built by using Print term. where term is the name of the theorem/term.
This will often be a big and ugly term, and it needs some training to be able to read these for involved terms. In particular, if the term has been built via the use of powerful tactics (such as omega, crush, etc.), it is probably going to be unreadable. You'd basically only use that to scan at some particular place of the term you're interested in. If it's more than 10 lines long, don't even bother reading it in such a crude format! :)
With all of the previous, you can use Set Printing All. beforehand, so that Coq prints the unfolded, explicit versions of everything. It is additionally verbose but can help when you wonder what the values of implicit parameters are.
These are all the ones I can think of on the top of my head, there might be more though.
As for what a tactic does, the usual best answer is found in the documentation:
http://coq.inria.fr/distrib/V8.4/refman/Reference-Manual011.html##tactic155
Basically, auto tries to use all the hints provided (depending on the database you use), and to solve your goal combining them up to some depth (that you can specify). By default, the database is core and the depth is 5.
More info on that can be found here:
http://coq.inria.fr/distrib/V8.4/refman/Reference-Manual011.html#Hints-databases