I find a pattern inside my goal through a tactic.
Why does this fail:
Tactic Notation "my_context_match" uconstr(g) :=
match goal with
| |- context[g] => idtac
end.
my_context_match _.
While this succeeds?
match goal with
| |- context[_] => idtac
end.
Is there any way to write a my_context_match, such that I can pass incomplete patterns (with _ on them) and see if anything inside my goal matches the patter?
Support for uconstr is very patchy. I've just reported #9321. Note that even this fails:
Goal True.
let v := uconstr:(True) in
lazymatch constr:(v) with
| v => idtac
end. (* Error: No matching clauses for match. *)
As suggested by #eponier in a comment, you can use open_constr instead of uconstr. However, this will leave unresolved evars. Here is a tactic that will work, and will not leave unresolved evars:
Tactic Notation "my_context_match" uconstr(g) :=
(* [match] does not support [uconstr], cf COQBUG(https://github.com/coq/coq/issues/9321),
so we use [open_constr] *)
let g := open_constr:(g) in
(* turning [g] into an [open_constr] creates new evars, so we must
eventually unify them with the goal *)
let G := match goal with |- ?G => G end in
(* We now search for [g] in the goal, and then replace the matching
subterm with the [open_constr] [g], so that we can unify the
result with the goal [G] to resolve the new evars we created *)
match G with
| context cG[g]
=> let G' := context cG[g] in
unify G G'
end.
Goal True /\ True.
my_context_match _.
my_context_match (_ /\ _).
Fail my_context_match (_ \/ _).
my_context_match True.
exact (conj I I).
Qed.
Related
It seems that at some point there was a file SfLib.v that was used for the Software Foundations course. However, the case command proposed in this file is not getting through in my case:
Require Omega. (* needed for using the [omega] tactic *)
Require Export Bool.
Require Export List.
Require Export Arith.
Require Export Arith.EqNat. (* Contains [beq_nat], among other things *)
(** * From Basics.v *)
Require String. Open Scope string_scope.
Ltac move_to_top x :=
match reverse goal with
| H : _ |- _ => try move x after H
end.
Tactic Notation "assert_eq" ident(x) constr(v) :=
let H := fresh in
assert (x = v) as H by reflexivity;
clear H.
Tactic Notation "Case_aux" ident(x) constr(name) :=
first [
set (x := name); move_to_top x
| assert_eq x name; move_to_top x
| fail 1 "because we are working on a different case" ].
Tactic Notation "Case" constr(name) := Case_aux Case name.
Tactic Notation "SCase" constr(name) := Case_aux SCase name.
Tactic Notation "SSCase" constr(name) := Case_aux SSCase name.
Tactic Notation "SSSCase" constr(name) := Case_aux SSSCase name.
Tactic Notation "SSSSCase" constr(name) := Case_aux SSSSCase name.
Tactic Notation "SSSSSCase" constr(name) := Case_aux SSSSSCase name.
Tactic Notation "SSSSSSCase" constr(name) := Case_aux SSSSSSCase name.
Tactic Notation "SSSSSSSCase" constr(name) := Case_aux SSSSSSSCase name.
Fixpoint ble_nat (n m : nat) : bool :=
match n with
| O => true
| S n' =>
match m with
| O => false
| S m' => ble_nat n' m'
end
end.
Theorem andb_true_elim1 : forall b c,
andb b c = true -> b = true.
Proof.
intros b c H.
destruct b.
Case "b = true".
reflexivity.
Case "b = false".
rewrite <- H. reflexivity. Qed.
In the first case, I'm getting No interpretation for string "b = true".
This was previously addressed in coq error when trying to use Case. Example from Software Foundations book. However, the solution there does no longer work. Should I get rid of all the case statements?
Maybe something changed since then, but now we need to Import notations.
(* 8.9, 8.10, and newer *)
From Coq Require String.
Export String.StringSyntax. (* [Export] means to [Import] the StringSyntax module, but also make it automatically available to whoever imports this file as well. *)
Open Scope string_scope.
(* 8.8 and older (still works with 8.9, 8.10, but pollutes the namespace) *)
From Coq Require Export String.
Open Scope string_scope.
However, as evidenced by the removal of the module, the benefit of this trick is quite minor. Most people just use bullets, with comments to indicate the cases if they even care to comment.
Above, Open Scope is used, which may be fine for self-contained projects like SF, but for big and open projects, to avoid surprises with notations, I would recommend only using Local Open Scope (which then needs to appear in every file), or keeping Open Scope inside inner modules (that still need to be imported explicitly, but can be reexported together with others).
Consider the following development:
Definition done {T : Type} (x : T) := True.
Goal Test.
pose 1 as n.
assert (done n) by constructor.
Fail ltac:(
match goal with
| [ H : done _ |- _ ] => fail
| [ H : _ |- _ ] =>
match goal with
| [ _: done H |- _ ] => idtac "H == n"
| [ _: done n |- _ ] => idtac "H != n"; fail 2
end
end
).
Abort.
This prints H != n. I'm finding this very surprising, since the only hypothesis in scope are n and done n - and done n was already dispatched by the first branch of the top-level match.
How can I match done n without explicitly referring to n, as in the first branch of the second match?
I think you are confused by the way match works. The first branch of the matching is matched against every hypothesis, and if it always fails, the second branch is tested, and so on. In your example, the first branch matches hypothesis H, but the execution of the corresponding tactic (fail) fails, thus the second branch is tried that also matches hypothesis H.
Actually, the first branch of the outer match seems to do what you want (i.e. matches on a hypothesis of the form done _) so I don't really get the point of your inner match.
For instance,
match goal with
| [ H' : done _ |- _ ] => idtac H'
end.
prints H, showing that the right hypothesis is matched.
Note that you don't need the ltac:() expression to use Fail on a tactic. For example, Fail fail. works.
I have come by this problem many times: I have a proof state in Coq that includes matches on both sides of an equality that are the same.
Is there a standard way to rewrite multiple matches into one?
Eg.
match expression_evaling_to_Z with
Zarith.Z0 => something
Zartih.Pos _ => something_else
Zarith.Neg _ => something_else
end = yet_another_thing.
And if I destruct on expresion_evaling_to_Z I get two identical goals. I would like to find a way to get only one of the goals.
A standard solution is to define "a view" of your datatype using a type family that will introduce the proper conditions and cases when destructed. For your particular case, you could do:
Require Import Coq.ZArith.ZArith.
Inductive zero_view_spec : Z -> Type :=
| Z_zero : zero_view_spec Z0
| Z_zeroN : forall z, z <> Z0 -> zero_view_spec z.
Lemma zero_viewP z : zero_view_spec z.
Proof. now destruct z; [constructor|constructor 2|constructor 2]. Qed.
Lemma U z : match z with
Z0 => 0
| Zpos _ | Zneg _ => 1
end = 0.
Proof.
destruct (zero_viewP z).
Abort.
This is a common idiom in some libraries like math-comp, which provides special support for instantiating the z argument of the type family.
You can write the match expression more succinctly:
match expression_evaling_to_Z with
| Z0 => something
| Zpos _ | Zneg _ => something_else
end = yet_another_thing.
But that will give you 3 subgoals when using destruct.
In this particular case we may use the fact that you actually need to distinguish the zero and non-zero cases, and it looks like a job for the Z.abs_nat : Z -> nat function.
Require Import Coq.ZArith.BinIntDef.
match Z.abs_nat (expression_evaling_to_Z) with
| O => something
| S _ => something_else
end = yet_another_thing.
This will get you only two subcases, but you need to destruct on Z.abs_nat (expression_evaling_to_Z) or introduce a new variable. If you choose the 1st variant, then you'll probably need destruct (...) eqn:Heq. to put the equation into context.
Basically this approach is about finding a new datatype (or defining one) and a suitable function to map from the old type to the new one.
If you don't mind typing you can use replace to replace the RHS with the LHS of your goal, which makes it trivial to solve, and then you just have to prove once that the rewrite is indeed ok.
Open Scope Z.
Lemma L a b :
match a + b with
Z0 => a + b
| Zpos _ => b + a
| Zneg _ => b + a
end = a + b.
replace (b+a) with (a+b). (* 1. replace the RHS with something trivially true *)
destruct (a+b); auto. (* 2. solve the branches in one fell swoop *)
apply Z.add_comm. (* 3. solve only once what is required for the two brances *)
Qed.
Perhaps you can use some Ltac-fu or other lemma to not have to type in the RHS manually too.
Suppose I have the following tactic to check if a term is the literal zero:
Ltac isZero x :=
match x with
| O => constr:true
| _ => constr:false
end.
Goal Set.
let isz := isZero O in pose isz.
(* adds true to the context *)
Now imagine that I want the tactic to accept a bit more; maybe any term that is convertible with zero. If this was a tactic acting on the goal, I would do
Ltac isZero x :=
match x with
| ?v => unify v 0; constr:true
| _ => constr:false
end.
but this fails for a tactic producing terms:
Error: Value is a term. Expected a tactic.
How can I check for convertibility in a tactic producing terms? In this specific example reducing x or computing it (let xx := eval compute in x) may work, but in more complex example the cost of computing could be prohibitive, especially as I would need to reduce the two terms of the comparison.
PS: For reference, the unsimplified issue is that I'm trying to efficiently lookup a key probably matching a value in an FMap built by sequences of calls to add, and the tactic looks like
Ltac find_key value :=
match fmap with
| add ?k value _ => constr:(Some k)
| add _ _ ?m => find_key value m
| _ => constr:None
end
With this implementation, if instead of value the map contains a term convertible to value but not syntactically equal to it, the tactic will incorrectly return None.
You can try to construct a term that triggers the conversion check; for instance:
Goal 2 + 2 = 4.
match goal with
| |- ?a = ?b =>
let e := constr:(eq_refl a : a = b) in
idtac "equal"
| |- _ => idtac "not equal"
end.
Normally, this prints "equal". However, if you replace 4 by, say, 3 in the goal above, the inner branch fails, printing "not equal".
I want to apply a rule in a case when some hypothesis present, and another is not. How can I check for this condition?
For example:
Variable X Y : Prop.
Axiom A: X -> Y.
Axiom B: X -> Z.
Ltac more_detail :=
match goal with
|[H1:X,<not H2:Y>|-_] =>
let H' := fresh "DET" in assert Y as H'
by (apply A;assumption)
|[H1:X,<not H2:Z>|-_] =>
let H' := fresh "DET" in assert Z as H'
by (apply B;assumption)
end.
Such that, for this goal:
> Goal X->True. intros.
H:X
=====
True
more_detail. would introduce a second hypothesis DET:
H:X
DET:Y
DET0:Z
=====
True
And a successive invocation more_detail. would fail.
However more_detail. should always ensure, that both Y and Z are there, i.e. if only one of them present, it should run a rule for another:
Goal X->Y->True. intros.
H:X
H1:Y
=====
True
> more_detail.
H:X
H1:Y
DET:Z
=====
True
And:
> Goal X->Z->True. intros.
H:X
H0:Z
=====
True
> more_detail.
H:X
H0:Z
DET:Y
=====
True
This is a common Ltac pattern. You can use the fail tactic to avoid executing a branch when some condition matches:
Variable X Y Z : Prop.
Hypothesis A : X -> Y.
Hypothesis B : X -> Z.
Ltac does_not_have Z :=
match goal with
| _ : Z |- _ => fail 1
| |- _ => idtac
end.
Ltac more_detail :=
match goal with
| H : X |- _ =>
first [ does_not_have Y;
let DET := fresh "DET" in
assert (DET := A H)
| does_not_have Z;
let DET := fresh "DET" in
assert (DET := B H) ]
end.
Goal X -> True.
intros X. more_detail. more_detail.
(* This fails *)
more_detail.
Abort.
The does_not_have tactic acts as a negative match: it only succeeds if its argument is not present in the context. Here's how it works: if H : Z is present in the context, the first branch will match. Calling simply fail or fail 0 would cause that branch to fail, but would allow Ltac to try other branches of the same match. Using fail 1 causes the current branch and the entire match to fail. If H : Z is not present in the context, the first branch will never match, and Coq will skip it and try the second branch. Since this branch doesn't do anything, execution will proceed with whichever tactics come after the match.
In more_detail, the first tactical can be used to combine several invocations of does_not_have; since each branch of first will fail if the context contains the corresponding hypothesis, the construction as a whole will have the effect of your match with negative patterns.