When developing a big system in Coq, I usually admit many lemmas and see whether the important theorem works or not, and then solve lemmas one by one.
Coq accepts Qed. even with admitted lemmas, so sometimes I'm not 100% sure whether I solve all the admits and need to seek help with text search admit and Admitted, is there a more strict version of Qed. which doesn't allow theorems to be proved with admitted lemmas?
Print Assumptions lemma_names.
seems a feasible way to check, are there other solutions?
Related
I like using the move=> tactic from the ssreflect library in cases when the goal is an implication (e.g. A -> B), to make the premise a hypothesis, and make the conclusion the new goal. However, I don't always want to use ssreflect.
Is there another Coq tactic that does the same thing without using ssreflect?
You can always use intros: intros pat is roughly equivalent to move=> pat. Unfortunately, Coq and ssreflect use a different syntax for introduction patterns, so the two are not interchangeable.
Note that nowadays ssreflect is part of the Coq distribution, so you can use the tactic language by simply doing From Coq Require Import ssreflect., without the need for installing a separate library.
I want to prove following lemma.
Require Import Reals.Reals.
Open Scope R_scope.
Lemma trivial_lemma (r1 r2:R) : r1 - (r1 - r2) = r2.
Proof.
rewrite <- Ropp_minus_distr.
rewrite Ropp_plus_distr.
rewrite Ropp_involutive.
rewrite Ropp_minus_distr'.
Abort.
I know Rplus_opp_l, but I cannot apply it to my goal because of r2.
Please tell me your solution.
First you should know that the automatic tactic ring solves this kind of goals autommatically. In the long run, you should rely on this tactic often if you wish to be productive.
Second, it appears (through Search) that the library does not contain many lemmas about subtraction. In this case, you may have to unfold this operator to end up with a goal that has the more primitive addition and opposite operations. Here is a sequence of rewrites that does your work.
unfold Rminus.
rewrite Ropp_plus_distr.
rewrite Ropp_involutive.
rewrite <- Rplus_assoc.
rewrite Rplus_opp_r.
rewrite Rplus_0_l.
easy.
The fact that the library does not contain basic lemmas like this is an indication that the library designers intend users to rely more on the ring tactic.
I am working through Software Foundations, and am currently on the IndProp section. Note: I'm doing this alone, this isn't homework.
I am still struggling to get my mind around how to work with these inductive types.
In the process of proving the pumping lemma (which I failed at :|), I tried to prove some lemmas...these lemmas ended up being unnecessary, but it still feels like they should be provable.
Lemma start_to_exists: forall (T:Type) (re: #reg_exp T) (s: list T),
s =~ Star re -> exists (s':list T), s' =~ re.
Edit: per the comments, it was noted thtat start_to_exists can't be proven because of EmptySet. If we added a hypothesis that re isn't EmptySet, then I think it could be, yes? I guess I'm mainly interested in how to prove such propositions, because I wasn't able to figure out how to "use" Star re.
Lemma star_empty_is_empty: forall (T:Type) (s:list T),
s =~ Star EmptyStr -> s =~ EmptyStr.
Lemma star_empty: forall (T:Type) (s:list T),
s =~ Star EmptyStr -> s = [].
They're all fairly similar, really: trying to use the nature of star to tell us something about the nature of s. inversion doesn't seem to get me anywhere, because the Star definition will just unwrap to more Stars.
While I ended up looking up an answer to the pumping lemma and have moved on, I feel like understanding where I'm going wrong with the above proofs will help me work better with these sorts of types.
The stub of the solution of the weak pumping lemma in SF shows that you need induction to solve it. If you use just inversion, as you noted, you will end up getting more hypotheses with Star, which will not get you far.
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.