I am new to Coq. I noticed it was possible to define the empty set in Coq using
Inductive Empty_set : Set :=.
Is it also possible to define the function from the empty set to another general set/type ?
If so how ?
Yes. Just use pattern matching:
Definition of_Empty_set T (x : Empty_set) : T :=
match x with end.
Related
I was looking at IndProp and I saw:
Fail Inductive wrong_ev (n : nat) : Prop :=
| wrong_ev_0 : wrong_ev 0
| wrong_ev_SS : ∀ n, wrong_ev n → wrong_ev (S (S n)).
(* ===> Error: A parameter of an inductive type n is not
allowed to be used as a bound variable in the type
of its constructor. *)
except that it seems to behave exactly as if it was taking an argument but it seems to throw an error. Why is this?
The text provides some explanation but I don't understand it:
what I don't understand specifically it. The part I don't understand is the part it says:
it is allowed to take different values in the types
why is it saying "in the types"? Types are NOT the input, values are. Why is it saying this? It seems extremely confusing. I know (extremely vaguely) that there is such a thing as "dependent types" but is that what it's referring too? Shouldn't it be arguments? Don't constructors take value or "stuff" and return an object of some type?
Why does it seem that the signature of the Inductive type (which really I just view it as a function that builds things are returns objects of some type) missing the arguments?
More context from text where explanation seems to appear:
This definition is different in one crucial respect from previous uses of Inductive: its result is not a Type, but rather a function from nat to Prop — that is, a property of numbers. Note that we've already seen other inductive definitions that result in functions, such as list, whose type is Type → Type. What is new here is that, because the nat argument of ev appears unnamed, to the right of the colon, it is allowed to take different values in the types of different constructors: 0 in the type of ev_0 and S (S n) in the type of ev_SS.
In contrast, the definition of list names the X parameter globally, to the left of the colon, forcing the result of nil and cons to be the same (list X). Had we tried to bring nat to the left in defining ev, we would have seen an error ... We can think of the definition of ev as defining a Coq property ev : nat → Prop, together with primitive theorems ev_0 : ev 0 and ev_SS : ∀n, ev n → ev (S (S n)).
Such "constructor theorems" have the same status as proven theorems.
why is it saying "in the types"? Types are NOT the input, values are
You need to read the whole expression: "in the types of different constructors".
And, indeed, the natural number is different in the return type of the two constructors:
It is 0 for ev_0
And it is S (S n) for ev_SS
I'm a bit confused trying to define some structures using the math-comp library. I want to define a structure that has a function ranging from a set of values and returning lists of other values. I'm trying to define this structure as finType but it is failing (I assume it is because I am returning a list of unknown size).
For example:
Section MySection.
Variables F V : finType.
Structure m := M {
f : {ffun F -> seq V};
...
}.
(* Using the PcanXXXMixin family of lemmas *)
Lemma can_m_of_prod : cancel prod_of_m m_of_prod.
Proof. by case. Qed.
...
Definition m_finMixin := CanFinMixin can_m_of_prod.
This throws the error Unable to unify.
I think the issue is that I am using seq and this is not finite. I am not sure how to describe that it will only return finite lists. I thought I might use n-tuples but this would require specifying a size beforehand (I could include the size along with the F value perhaps? I'm not sure how that would look in this notation).
Is there something I am missing or is there another approach that seems more adequate?
Thanks in advance!
I suggest you specify the bound function directly on the type. This is for example used in Stefania Dumbrava's PhD to bound the maximum arity of a signature and works well if you know the trick:
f : {ffun n -> (bound ...).-tuple A}
Usually bound := \max_S ..., so it works well with the rest of the theory.
I have defined a nested inductive data type and have defined a custom inductive principle for it. However, automated tactics from a library I'm using (specifically, DBLib for de Bruijn indices) expects induction is on the usual inductive principle. Since I never intend to use the originally-generated inductive principle, is there any way to either replace the automatically-generated principle? Or, if not, is there a way to temporarily turn off this automatic generation?
You can do it using Elimination Schemes option. For instance,
Unset Elimination Schemes.
Inductive nat_tree : Set :=
| NNode' : nat -> list nat_tree -> nat_tree.
Set Elimination Schemes.
In addition, if you had a simpler (non-recursive) inductive type, you could have used the Variant keyword to make Coq not generate the induction principles:
Variant foo : Type := Foo.
I'm working on a single .v file and I found it convenient to define things with parameters and definitions like this:
Parameter n : nat.
Definition n_plus_1 := n + 1.
rather than Definition n_plus_1 (n : nat) = n + 1.
My use cases are more complicated than this, but the idea is the same. Although defining things with parameters helped me write some proofs I'm interested in, sometimes I'd like to just test the definitions with actual values to make sure they actually compute what I intended. For example, with the example I just wrote, I can't do Compute n_plus_1 3. In some sense, I want to instantiate the parameter n. What'd be the best way to do it?
The quickest way is to use the Section mechanism [modules would also work]:
Section With_N.
Variable n : nat.
Definition n_plus_1 := n + 1.
End With_N.
Compute (n_plus_1 3).
I'm still puzzled what the sort Set means in Coq. When do I use Set and when do I use Type?
In Hott a Set is defined as a type, where identity proofs are unique.
But I think in Coq it has a different interpretation.
Set means rather different things in Coq and HoTT.
In Coq, every object has a type, including types themselves. Types of types are usually referred to as sorts, kinds or universes. In Coq, the (computationally relevant) universes are Set, and Type_i, where i ranges over natural numbers (0, 1, 2, 3, ...). We have the following inclusions:
Set <= Type_0 <= Type_1 <= Type_2 <= ...
These universes are typed as follows:
Set : Type_i for any i
Type_i : Type_j for any i < j
Like in Hott, this stratification is needed to ensure logical consistency. As Antal pointed out, Set behaves mostly like the smallest Type, with one exception: it can be made impredicative when you invoke coqtop with the -impredicative-set option. Concretely, this means that forall X : Set, A is of type Set whenever A is. In contrast, forall X : Type_i, A is of type Type_(i + 1), even when A has type Type_i.
The reason for this difference is that, due to logical paradoxes, only the lowest level of such a hierarchy can be made impredicative. You may then wonder then why Set is not made impredicative by default. This is because an impredicative Set is inconsistent with a strong form of the axiom of the excluded middle:
forall P : Prop, {P} + {~ P}.
What this axiom allows you to do is to write functions that can decide arbitrary propositions. Note that the {P} + {~ P} type lives in Set, and not Prop. The usual form of the excluded middle, forall P : Prop, P \/ ~ P, cannot be used in the same way, because things that live in Prop cannot be used in a computationally relevant way.
In addition to Arthur's answer:
From the fact that Set is located at the bottom of the hierarchy,
it follows that Set is the type of the “small” datatypes and function types, i.e. the ones whose values do not directly or indirectly involve types.
That means the following will fail:
Fail Inductive Ts : Set :=
| constrS : Set -> Ts.
with this error message:
Large non-propositional inductive types must be in Type.
As the message suggests, we can amend it by using Type:
Inductive Tt : Type :=
| constrT : Set -> Tt.
Reference:
The Essence of Coq as a Formal System by B. Jacobs (2013), pdf.