# ProofObjectsThe Curry-Howard Correspondence

"

*Algorithms are the computational content of proofs*." —Robert Harper
The type of ev_SS says that it is a

*function*(better: a data*constructor*) taking two arguments (one number n plus evidence for even n) and returning evidence that S (S n) is even.
Check ev_SS.

(* ===> ev_SS : forall n,

even n ->

even (S (S n)) *)

(* ===> ev_SS : forall n,

even n ->

even (S (S n)) *)

Theorem ev_4 : even 4.

Proof.

apply ev_SS. apply ev_SS. apply ev_0. Qed.

Proof.

apply ev_SS. apply ev_SS. apply ev_0. Qed.

As with ordinary data values and functions, we can use the Print
command to see the

*proof object*that results from this proof script.
Print ev_4.

(* ===> ev_4 = ev_SS 2 (ev_SS 0 ev_0)

: even 4 *)

(* ===> ev_4 = ev_SS 2 (ev_SS 0 ev_0)

: even 4 *)

### Indeed, we can also write down this proof object

*directly*, without the need for a separate proof script:

Check (ev_SS 2 (ev_SS 0 ev_0)).

(* ===> even 4 *)

(* ===> even 4 *)

# Proof Scripts

Theorem ev_4'' : even 4.

Proof.

Show Proof.

apply ev_SS.

Show Proof.

apply ev_SS.

Show Proof.

apply ev_0.

Show Proof.

Qed.

Proof.

Show Proof.

apply ev_SS.

Show Proof.

apply ev_SS.

Show Proof.

apply ev_0.

Show Proof.

Qed.

### Tactic proofs are useful and convenient, but they are not essential: in principle, we can always construct the required evidence by hand, as shown above. Then we can use Definition (rather than Theorem) to give a global name directly to this evidence.

Definition ev_4''' : even 4 :=

ev_SS 2 (ev_SS 0 ev_0).

ev_SS 2 (ev_SS 0 ev_0).

# Quantifiers, Implications, Functions

*constructors*introduced by Inductively defined data types, and

*functions*.

### For example, consider this statement:

Theorem ev_plus4 : ∀n, even n → even (4 + n).

Proof.

intros n H. simpl.

apply ev_SS.

apply ev_SS.

apply H.

Qed.

Proof.

intros n H. simpl.

apply ev_SS.

apply ev_SS.

apply H.

Qed.

### What is the proof object corresponding to ev_plus4?

*type*is ∀ n, even n → even (4 + n) — that is, a

*function*that takes two arguments (one number and a piece of evidence) and returns a piece of evidence!

Definition ev_plus4' : ∀n, even n → even (4 + n) :=

fun (n : nat) ⇒ fun (H : even n) ⇒

ev_SS (S (S n)) (ev_SS n H).

fun (n : nat) ⇒ fun (H : even n) ⇒

ev_SS (S (S n)) (ev_SS n H).

Or:

Definition ev_plus4'' (n : nat) (H : even n)

: even (4 + n) :=

ev_SS (S (S n)) (ev_SS n H).

Check ev_plus4''.

(* ===>

: forall n : nat, even n -> even (4 + n) *)

: even (4 + n) :=

ev_SS (S (S n)) (ev_SS n H).

Check ev_plus4''.

(* ===>

: forall n : nat, even n -> even (4 + n) *)

### When we view the proposition being proved by ev_plus4 as a function type, one interesting point becomes apparent: The second argument's type, even n, mentions the

*value*of the first argument, n.

*dependent types*are not found in conventional programming languages, they can be useful in programming too, as the recent flurry of activity in the functional programming community demonstrates.

### Notice that both implication (→) and quantification (∀) correspond to functions on evidence. In fact, they are really the same thing: → is just a shorthand for a degenerate use of ∀ where there is no dependency, i.e., no need to give a name to the type on the left-hand side of the arrow:

∀(x:nat), nat

= ∀(_:nat), nat

= nat → nat

= ∀(_:nat), nat

= nat → nat

Recall the definition of even:
(1) ∀ n, even n
(2) ∀ n, even (2 + n)
(3) ∀ n, even n → even n
(4) ∀ n, even n → even (2 + n)
(5) ∀ n, even n → even (4 + n)
(6) Not typeable

Inductive even : nat → Prop :=

| ev_0 : even 0

| ev_SS : ∀n, even n → even (S (S n)).

What is the type of this expression?
| ev_0 : even 0

| ev_SS : ∀n, even n → even (S (S n)).

fun (n : nat) ⇒

fun (H : even n) ⇒

ev_SS (2 + n) (ev_SS n H)

fun (H : even n) ⇒

ev_SS (2 + n) (ev_SS n H)

# Programming with Tactics

*programs*using

*tactics*rather than explicit terms. Naturally, the answer is yes!

Definition add1 : nat → nat.

intro n.

Show Proof.

apply S.

Show Proof.

apply n. Defined.

Print add1.

(* ==>

add1 = fun n : nat => S n

: nat -> nat

*)

Compute add1 2.

(* ==> 3 : nat *)

intro n.

Show Proof.

apply S.

Show Proof.

apply n. Defined.

Print add1.

(* ==>

add1 = fun n : nat => S n

: nat -> nat

*)

Compute add1 2.

(* ==> 3 : nat *)

### Notice that we terminate the Definition with a . rather than with := followed by a term. This tells Coq to enter

*proof scripting mode*to build an object of type nat → nat. Also, we terminate the proof with Defined rather than Qed; this makes the definition

*transparent*so that it can be used in computation like a normally-defined function. (Qed-defined objects are opaque during computation.)

# Logical Connectives as Inductive Types

## Conjunction

Inductive and (P Q : Prop) : Prop :=

| conj : P → Q → and P Q.

| conj : P → Q → and P Q.

Notice the similarity with the definition of the prod type,
given in chapter Poly; the only difference is that prod takes
Type arguments, whereas and takes Prop arguments.

Print prod.

(* ===>

Inductive prod (X Y : Type) : Type :=

| pair : X -> Y -> X * Y. *)

(* ===>

Inductive prod (X Y : Type) : Type :=

| pair : X -> Y -> X * Y. *)

### This similarity should clarify why destruct and intros patterns can be used on a conjunctive hypothesis. Case analysis allows us to consider all possible ways in which P ∧ Q was proved — here just one (the conj constructor).

Lemma and_comm : ∀P Q : Prop, P ∧ Q ↔ Q ∧ P.

Proof.

intros P Q. split.

- intros [HP HQ]. split.

+ apply HQ.

+ apply HP.

- intros [HQ HP]. split.

+ apply HP.

+ apply HQ.

Qed.

Proof.

intros P Q. split.

- intros [HP HQ]. split.

+ apply HQ.

+ apply HP.

- intros [HQ HP]. split.

+ apply HP.

+ apply HQ.

Qed.

### This shows why the inductive definition of and can be manipulated by tactics as we've been doing. We can also use it to build proofs directly, using pattern-matching. For instance:

Definition and_comm'_aux P Q (H : P ∧ Q) : Q ∧ P :=

match H with

| conj HP HQ ⇒ conj HQ HP

end.

Definition and_comm' P Q : P ∧ Q ↔ Q ∧ P :=

conj (and_comm'_aux P Q) (and_comm'_aux Q P).

match H with

| conj HP HQ ⇒ conj HQ HP

end.

Definition and_comm' P Q : P ∧ Q ↔ Q ∧ P :=

conj (and_comm'_aux P Q) (and_comm'_aux Q P).

What is the type of this expression?
(1) ∀ P Q R, P ∧ Q → Q ∧ R → P ∧ R
(2) ∀ P Q R, Q ∧ P → R ∧ Q → P ∧ R
(3) ∀ P Q R, P ∧ R
(4) ∀ P Q R, P ∨ Q → Q ∨ R → P ∨ R
(5) Not typeable

fun P Q R (H

match (H

| (conj _ _ HP _, conj _ _ _ HR) ⇒ conj P R HP HR

end.

_{1}: and P Q) (H_{2}: and Q R) ⇒match (H

_{1},H_{2}) with| (conj _ _ HP _, conj _ _ _ HR) ⇒ conj P R HP HR

end.

## Disjunction

Inductive or (P Q : Prop) : Prop :=

| or_introl : P → or P Q

| or_intror : Q → or P Q.

| or_introl : P → or P Q

| or_intror : Q → or P Q.

This declaration explains the behavior of the destruct tactic on
a disjunctive hypothesis, since the generated subgoals match the
shape of the or_introl and or_intror constructors.
Once again, we can also directly write proof objects for theorems
involving or, without resorting to tactics.

What is the type of this expression?
(1) ∀ P Q H, Q ∨ P ∨ H
(2) ∀ P Q, P ∨ Q → P ∨ Q
(3) ∀ P Q H, P ∨ Q → Q ∨ P → H
(4) ∀ P Q, P ∨ Q → Q ∨ P
(5) Not typeable

fun P Q H ⇒

match H with

| or_introl HP ⇒ or_intror Q P HP

| or_intror HQ ⇒ or_introl Q P HQ

end.

match H with

| or_introl HP ⇒ or_intror Q P HP

| or_intror HQ ⇒ or_introl Q P HQ

end.

## Existential Quantification

Inductive ex {A : Type} (P : A → Prop) : Prop :=

| ex_intro : ∀x : A, P x → ex P.

| ex_intro : ∀x : A, P x → ex P.

This may benefit from a little unpacking. The core definition is
for a type former ex that can be used to build propositions of
the form ex P, where P itself is a

*function*from witness values in the type A to propositions. The ex_intro constructor then offers a way of constructing evidence for ex P, given a witness x and a proof of P x.### The more familiar form ∃ x, P x desugars to an expression involving ex:

Check ex (fun n ⇒ even n).

(* ===> exists n : nat, even n

: Prop *)

(* ===> exists n : nat, even n

: Prop *)

Here's how to define an explicit proof object involving ex:

Definition some_nat_is_even : ∃n, even n :=

ex_intro even 4 (ev_SS 2 (ev_SS 0 ev_0)).

ex_intro even 4 (ev_SS 2 (ev_SS 0 ev_0)).

Inductive True : Prop :=

| I : True.

| I : True.

It has one constructor (so every proof of True is the same, so
being given a proof of True is not informative.)
False is equally simple — indeed, so simple it may look
syntactically wrong at first glance!

Inductive False : Prop := .

That is, False is an inductive type with

*no*constructors — i.e., no way to build evidence for it.# Equality

Inductive eq {X:Type} : X → X → Prop :=

| eq_refl : ∀x, eq x x.

Notation "x == y" := (eq x y)

(at level 70, no associativity)

: type_scope.

| eq_refl : ∀x, eq x x.

Notation "x == y" := (eq x y)

(at level 70, no associativity)

: type_scope.

The way to think about this definition is that, given a set X,
it defines a
Other types of the form eq x y where x and y are not the
same are thus uninhabited.
The reason is that Coq treats as "the same" any two terms that are
These rules, which are similar to those used by Compute, include
evaluation of function application, inlining of definitions, and
simplification of matches.

*family*of propositions "x is equal to y," indexed by pairs of values (x and y) from X. There is just one way of constructing evidence for members of this family: applying the constructor eq_refl to a type X and a single value x : X, which yields evidence that x is equal to x.### We can use eq_refl to construct evidence that, for example, 2 = 2. Can we also use it to construct evidence that 1 + 1 = 2? Yes, we can. Indeed, it is the very same piece of evidence!

*convertible*according to a simple set of computation rules.
Lemma four: 2 + 2 == 1 + 3.

Proof.

apply eq_refl.

Qed.

Proof.

apply eq_refl.

Qed.

### The reflexivity tactic that we have used to prove equalities up to now is essentially just shorthand for apply eq_refl.

Definition four' : 2 + 2 == 1 + 3 :=

eq_refl 4.

Definition singleton : ∀(X:Type) (x:X), []++[x] == x::[] :=

fun (X:Type) (x:X) ⇒ eq_refl [x].

eq_refl 4.

Definition singleton : ∀(X:Type) (x:X), []++[x] == x::[] :=

fun (X:Type) (x:X) ⇒ eq_refl [x].

## Inversion, Again

- takes a hypothesis H whose type P is inductively defined,
and
- for each constructor C in P's definition,
- generates a new subgoal in which we assume H was
built with C,
- adds the arguments (premises) of C to the context of
the subgoal as extra hypotheses,
- matches the conclusion (result type) of C against the
current goal and calculates a set of equalities that must
hold in order for C to be applicable,
- adds these equalities to the context (and, for convenience,
rewrites them in the goal), and
- if the equalities are not satisfiable (e.g., they involve things like S n = O), immediately solves the subgoal.

- generates a new subgoal in which we assume H was
built with C,

*Example*: If we invert a hypothesis built with or, there are two constructors, so two subgoals get generated. The conclusion (result type) of the constructor (P ∨ Q) doesn't place any restrictions on the form of P or Q, so we don't get any extra equalities in the context of the subgoal.

*Example*: If we invert a hypothesis built with and, there is only one constructor, so only one subgoal gets generated. Again, the conclusion (result type) of the constructor (P ∧ Q) doesn't place any restrictions on the form of P or Q, so we don't get any extra equalities in the context of the subgoal. The constructor does have two arguments, though, and these can be seen in the context in the subgoal.

*Example*: If we invert a hypothesis built with eq, there is again only one constructor, so only one subgoal gets generated. Now, though, the form of the eq_refl constructor does give us some extra information: it tells us that the two arguments to eq must be the same! The inversion tactic adds this fact to the context.