I have a hypothesis in the local context, let's call it H which is of the form true=true -> conclusion. Which tactic can I use to discard the premise and retain only the conclusion?
This asserts the premise as a subgoal and then tries to prove both it, and the original goal with the conclusion of H prepended, using the trivial tactic.
lapply H; trivial.
Use the specialize tactic: http://coq.inria.fr/doc/Reference-Manual011.html##tactic35
specialize (H (eq_refl true)).
I came up with the following. Either of these works:
assert (H2 : conclusion). apply H. reflexivity.
assert (H2 : true->true). reflexivity. apply H in H2.
assert (H2 := H (eq_refl true)). also works. I would still like to know about cleaner solutions.
Related
I'm interested in how the Coq tactics symmetry and transitivity actually work. I've read the Coq manual but this only describes what they do, not how they operate on a proof and change the proof states. As an example of what I'm looking for, in Interactive Theorem Proving and Program Development, the authors state that
"The reflexivity tactic actually is synonymous with apply refl_equal" (p. 124).
But, the author refers the reader to the reference manual for symmetry and transitivity. I haven't found a good description of things that these two tactics are synonymous with in the same way.
For clarification, the reason why I ask is that I have defined a path space paths {A : UU} : A -> A -> UU notated a = b (like in UniMath) which acts like an equivalence relation except for that a = b is not a proposition but a type. For this reason I was unable to add this relation as an equivalence relation using Add Parametric Relation. I'm trying to cook up a version of symmetry and transitivity with Ltac for this path space relation but I don't know how to change the proof state; knowing how symmetry and transitivity actually work might help.
These tactics only apply the lemmas corresponding to symmetry and transitivity of the relation it finds in the goal.
These are found using the type classes mechanism.
For instance you could declare
From Coq Require Import RelationClasses.
Instance trans : Transitive R.
which would ask you to prove R is transitive and then you would be able to use the tactic transitivity to prove R x y.
I'm a beginner of Coq and learning how to make codes with video https://www.youtube.com/watch?v=oJm5TH0GdSo&list=PLt7hcIEdZLAnCoZePG60qgVP4ddP0s3WZ&index=2 .
I made a program following that video (one that starts from almost 29 minutes in video) but it doesn't run as I expected. Could you please tell me why does that happen? I always get stuck in Case.
Program I made is given below:
Theorem shugouonajidesho :
forall P Q : Prop,
P/\Q->Q/\P.
Proof.
intros P Q H. split.
Case "Q".
inversion H as [HP HQ]. imply HQ.
Case "P". inversion H as {HP HQ]. imply HP.
Qed.
There are three problems in your proof, but they're mostly syntactic.
The Case "Q" and Case "P" syntax comes from Software Foundations. You'd need to import some particular library to be able to use it. If you don't want to do that, it's not necessary. To focus goals, you can use bullets (typically -, + or *). There are other ways too, but this is the most typical.
The imply tactic doesn't exist (at least in the standard library). The way you're using it, though, makes me think that you meant apply.
In inversion H as {HP HQ]., both brackets should be square brackets.
Making those changes allows the theorem to work, but I'd also suggest a few changes for idiomaticity.
Using inversion is probably overkill here. All you're doing is destructing a conjunction into its parts, so destruct H as [HP HQ]. would work just as well.
I would also highly recommend separating your proof with line breaks, rather than just putting everything on one line (this might have just been an artifact of how you formatted your question. If so, ignore this). It's fine to put some tactics on the same line, but it should be grouped into logical sections.
Finally, a minor one: I'd suggest putting spaces around ->. It just makes things a little easier to read.
Theorem shugouonajidesho: forall P Q : Prop, P/\Q -> Q/\P.
Proof.
intros P Q H.
split.
- inversion H as [HP HQ].
apply HQ.
- inversion H as [HP HQ].
apply HP.
Qed.
I can't tell in which situations I should use Theorem over Lemma or the opposite. Is there any difference (despite syntactical) between this
Theorem l : 2 = 2.
trivial.
Qed.
and this
Lemma l : 2 = 2.
trivial.
Qed.
?
There is no difference between Theorem and Lemma as far as the language is concerned. The reasons to choose one over another are purely psychological.
You can also use Remark, Fact, Corollary, Proposition according to the importance you attribute to the result. Here is the relevant link in the Coq reference manual.
Some projects' code style guides only allow one keyword to be used for uniformity. This might help reading source code and allow using simple grep-like tools to extract some statistics from it.
In the program https://rise4fun.com/Dafny/tlpls Dafny is not able to infer the induction hypothesis from the recursive call to the lemma.
Moreover, what is more surprising is in MVS, if you change assert by assume, and again by assert, then the problem disappears.
Lastly, what astonish me even more is that the second lemma in https://rise4fun.com/Dafny/hNZg works perfectly.
Paqui
They seem to serve similar purposes. The one difference I've noticed so far is that while Program Fixpoint will accept a compound measure like {measure (length l1 + length l2) }, Function seems to reject this and will only allow {measure length l1}.
Is Program Fixpoint strictly more powerful than Function, or are they better suited for different use cases?
This may not be a complete list, but it is what I have found so far:
As you already mentioned, Program Fixpoint allows the measure to look at more than one argument.
Function creates a foo_equation lemma that can be used to rewrite calls to foo with its RHS. Very useful to avoid problems like Coq simpl for Program Fixpoint.
In some (simple?) cases, Function can define a foo_ind lemma to perform induction along the structure of recursive calls of foo. Again, very useful to prove things about foo without effectively repeating the termination argument in the proof.
Program Fixpoint can be tricked into supporting nested recursion, see https://stackoverflow.com/a/46859452/946226. This is also why Program Fixpoint can define the Ackermann function when Function cannot.