When I run the following script:
Definition inv (a: Prop): Prop :=
match a with
| False => True
| True => False
end.
I get "Error: This clause is redundant." Any idea why this happens?
Thanks,
Marcus.
There are quite a few wrong things about this.
False is not a data constructor, and since there is no syntactic difference between data constructors and variable names in Coq, it understands your | False => as a pattern matching anything and giving it the name False, in the same way as you could have written:
Definition inv (a: Prop): Prop :=
match a with
| x => True
| y => False
end.
This is why it tells you that the second clause is redundant (since the first pattern matches everything).
Now another thing you should know is that the type Prop is not inductively-defined, and therefore values of type Prop cannot be matched against anything: in fact it would not make sense, since it is an open type that you keep expanding everytime you define a new inductive property.
So there is no way to write a function inv the way you write it.
Related
In many parts of the standard library, there are a bunch of OCaml-native functions with no Coq counterpart. I implemented a Coq version of some of them (with added proofs to show that the Coq versions behave as I think they ought to), but now how do I check that this actually matches the OCaml version's behavior?
The easiest / most "obvious" way I can think of would be to take a test input x, compute f x in Coq, and extract a comparison f x = [[f x]] (where [[…]] marks evaluation in Coq), then repeat for some number of test cases. Unfortunately, I can't find a way to force evaluation in Coq.
Is there a trick to make this possible? Or is there some other standard way for testing behavior across extraction? (Manually going Compute (f x). and plugging the resulting terms as literals back into the sanity checks would be an ugly fallback… Unfortunately, those won't update automatically when the function is changed, and it would also be a lot of manual work that doesn't exactly encourage exhaustive tests…)
Minimal sample:
Definition foo (b : bool) : bool :=
match b with | true => false | false => true end.
Extract Inlined Constant foo => "not".
Extract Inlined Constant bool_eq => "(=)".
Definition foo_true := foo true.
Definition foo_false := foo false.
Definition foo_test : bool :=
andb (bool_eq (foo true) foo_true) (bool_eq (foo false) foo_false).
Recursive Extraction foo_test.
results in
(** val foo_true : bool **)
let foo_true = not true
(** val foo_false : bool **)
let foo_false = not false
(** val foo_test : bool **)
let foo_test = (&&) ((=) (not true) foo_true) ((=) (not false) foo_false)
which is unhelpful. All the ways I could think of to change the definition of foo_true/foo_false to try and have them pre-evaluated didn't work. I can't find any flag in the extraction mechanism to force evaluation… Both the reference manual's attribute index and the flags/options/tables index didn't contain anything that looks useful. Is there anything that I missed?
Starting a definition with Eval compute in evaluates it before registering the definition.
Definition foo_true := Eval compute in foo true.
Definition foo_false := Eval compute in foo false.
Definition foo_test : bool :=
andb (bool_eq (foo true) foo_true) (bool_eq (foo false) foo_false).
Recursive Extraction foo_test.
I am very new to Coq, and hope my question is not too basic. I am simply wondering how I define dependent functions in Coq. For example, how could I define a function from Booleans that sends true to true and false to the natural number seven ? I assume one can use the usual (f x) notation to apply a dependent function f to an input x.
To define dependent functions in Coq, you refer back to the parameter when specifying the type. In your example, you take a Boolean, let's call it b, and your return type is match b with true => bool | false => nat end (or if b then bool else nat).
In code, that looks like the following:
Definition foo (b : bool)
: match b with true => bool | false => nat end
:= match b with true => true | false => 7 end.
Compute foo true. (* = true *)
Compute foo false. (* = 7 *)
There is a little bit of magic that goes on in figuring out the type of the match construct here, if you give more type annotations it looks like
Definition foo'
: forall b : bool, match b return Set with true => bool | false => nat end
:= fun b : bool =>
match b as b'
return match b' return Set with true => bool | false => nat end
with true => true | false => 7 end.
Here, since the match construct can have different types depending on the value of b (which can be an arbitrary term, not just a variable), we use the annotation as b' return ... to give b a new name, and then specify the type of the match depending on the value of b'.
However, particularly when matching on a variable, Coq can often figure out the return ... annotation on it's own.
You can find some documentation of the match construct here, in the reference manual
I want to define the syntax of the time delay in Coq as follows:
Inductive tcs : Type :=
| delay : nat -> tcs
| atomic : nat-> tcs.
But the natural number 0 is not allowed in the constructor delay. I also find using the subset type to define the syntax. However, the introduction of subset type leads to more complications for defining semantics. Is there an easy way to define such sytax?
In your particular case, I think the easiest thing to do is to change the interpretation of the number in the delay constructor: note that nat is isomorphic to {n : nat | n > 0} via the successor function. Therefore, all you have to do is add one to the argument of delay whenever you use it in a match expression. For instance:
Definition nat_of_tcs t :=
match t with
| delay n => S n
| atomic n => n
end.
Alternatively, you can replace nat by positive, a type defined in the standard library to represent numbers greater than 0.
In general, subset types would be the way to go. You could add a n != 0 constraint in the type of delay, or define a separate predicate on elements of tcs describing when elements are well-formed:
Definition well_formed t :=
match t with
| delay 0 => false
| _ => true
end.
Definition wftcs := { t : tcs | well_formed t = true }.
The Mathematical Components and related libraries use this pattern pervasively; check the subType class in the eqtype module, for instance. In my extensional structures library, I use the subType class to define a type of finite sets (here) by packaging a list with a proof that the list is sorted.
match x with
| Some x => Some (Ref x)
| None => None
end.
I have to do this quite a lot, nested matches make code look bad. Is there some more elegant, one liner sort of way to lift things out of Option?
There is option_map function in Coq.Init.Datatypes defined as follows:
Definition option_map (A B:Type) (f:A->B) (o : option A) : option B :=
match o with
| Some a => #Some B (f a)
| None => #None B
end.
You can use it just like #ejgallego showed in the comments: option_map Ref x.
Here is how you can discover this function:
Search (option _ -> option _).
More generally, you may want to consider using monadic syntax; it is easy to define some yourself with a couple of Notation declarations, or you can use a more featureful library like Gregory Malecha's ExtLib.
I have a finite enumerated type (say T) in COQ and want to check elements for equality. This means, I need a function
bool beq_T(x:T,y:T)
The only way I managed to define such a function, is with a case by case analysis. This results in lots of match statements and looks very cumbersome. Therefore, I wonder if there is not a simpler way to achieve this.
Even simpler: Scheme Equality for ... generates two functions returning respectively a boolean and a sumbool.
The bad news is that the program that implements beq_T must necessarily consist of a large match statement on both of its arguments. The good news is that you can automatically generate/synthesize this program using Coq's tactic language. For example, given the type:
Inductive T := t0 | t1 | t2 | t3.
You can define beq_T as follows. The first two destruct tactics synthesize the code necessary to match on both x and y. The match tactic inspects the branch of the match that it is in, and depending on whether x = y, the tactic either synthesises the program that returns true or false.
Definition beq_T (x y:T) : bool.
destruct x eqn:?;
destruct y eqn:?;
match goal with
| _:x = ?T, _:y = ?T |- _ => exact true
| _ => exact false
end.
Defined.
If you want to see the synthesized program, run:
Print beq_T.
Thankfully, Coq already comes with a tactic that does almost what you want. It is called decide equality. It automatically synthesizes a program that decides whether two elements of a type T are equal. But instead of just returning a boolean value, the synthesized program returns a proof of the (in)equality of the two elements.
Definition eqDec_T (x y:T) : {x = y} + {x <> y}.
decide equality.
Defined.
With that program synthesized, it is easy to implement beq_T.
Definition beq_T' {x y:T} : bool := if eqDec_T x y then true else false.