BasicsFunctional Programming in Coq
Introduction
Enumerated Types
Days of the Week
Inductive day : Type :=
| monday : day
| tuesday : day
| wednesday : day
| thursday : day
| friday : day
| saturday : day
| sunday : day.
| monday : day
| tuesday : day
| wednesday : day
| thursday : day
| friday : day
| saturday : day
| sunday : day.
The type is called day, and its members are monday,
tuesday, etc. The second and following lines of the definition
can be read "monday is a day, tuesday is a day, etc."
Having defined day, we can write functions that operate on
days.
Definition next_weekday (d:day) : day :=
match d with
| monday ⇒ tuesday
| tuesday ⇒ wednesday
| wednesday ⇒ thursday
| thursday ⇒ friday
| friday ⇒ monday
| saturday ⇒ monday
| sunday ⇒ monday
end.
match d with
| monday ⇒ tuesday
| tuesday ⇒ wednesday
| wednesday ⇒ thursday
| thursday ⇒ friday
| friday ⇒ monday
| saturday ⇒ monday
| sunday ⇒ monday
end.
One thing to note is that the argument and return types of
this function are explicitly declared. Like most functional
programming languages, Coq can often figure out these types for
itself when they are not given explicitly — i.e., it can do type
inference — but we'll generally include them to make reading
easier.
Having defined a function, we should check that it works on
some examples. There are actually three different ways to do this
in Coq. First, we can use the command Compute to evaluate a
compound expression involving next_weekday.
Compute (next_weekday friday).
(* ==> monday : day *)
Compute (next_weekday (next_weekday saturday)).
(* ==> tuesday : day *)
(* ==> monday : day *)
Compute (next_weekday (next_weekday saturday)).
(* ==> tuesday : day *)
(We show Coq's responses in comments, but, if you have a
computer handy, this would be an excellent moment to fire up the
Coq interpreter under your favorite IDE — either CoqIde or Proof
General — and try this for yourself. Load this file, Basics.v,
from the book's Coq sources, find the above example, submit it to
Coq, and observe the result.)
Second, we can record what we expect the result to be in the
form of a Coq example:
This declaration does two things: it makes an
assertion (that the second weekday after saturday is tuesday),
and it gives the assertion a name that can be used to refer to it
later. Having made the assertion, we can also ask Coq to verify
it, like this:
Proof. simpl. reflexivity. Qed.
The details are not important for now (we'll come back to
them in a bit), but essentially this can be read as "The assertion
we've just made can be proved by observing that both sides of the
equality evaluate to the same thing, after some simplification."
Third, we can ask Coq to extract, from our Definition, a
program in some other, more conventional, programming language
(OCaml, Scheme, or Haskell) with a high-performance compiler.
This facility is very interesting, since it gives us a way to go
from proved-correct algorithms written in Gallina to efficient
machine code. (Of course, we are trusting the correctness of the
OCaml/Haskell/Scheme compiler, and of Coq's extraction facility
itself, but this is still a big step forward from the way most
software is developed today.) Indeed, this is one of the main uses
for which Coq was developed. We won't really talk about
extraction more in this course.
Homework Submission Guidelines
- The grading scripts work by extracting marked regions of the .v files that you submit. It is therefore important that you do not alter the "markup" that delimits exercises: the Exercise header, the name of the exercise, the "empty square bracket" marker at the end, etc. Please leave this markup exactly as you find it.
- Do not delete exercises. If you skip an exercise (e.g., because it is marked Optional, or because you can't solve it), it is OK to leave a partial proof in your .v file, but in this case please make sure it ends with Admitted (not, for example Abort).
- It is fine to use additional definitions (of helper functions, useful lemmas, etc.) in your solutions. You can put these between the exercise header and the theorem you are asked to prove.
Booleans
Although we are rolling our own booleans here for the sake
of building up everything from scratch, Coq does, of course,
provide a default implementation of the booleans, together with a
multitude of useful functions and lemmas. (Take a look at
Coq.Init.Datatypes in the Coq library documentation if you're
interested.) Whenever possible, we'll name our own definitions
and theorems so that they exactly coincide with the ones in the
standard library.
Functions over booleans can be defined in the same way as
above. First, we can use booleans to define a predicate, a
function that identifies some subset of a given set:
Definition is_weekday (d:day) : bool :=
match d with
| monday ⇒ true
| tuesday ⇒ true
| wednesday ⇒ true
| thursday ⇒ true
| friday ⇒ true
| saturday ⇒ false
| sunday ⇒ false
end.
match d with
| monday ⇒ true
| tuesday ⇒ true
| wednesday ⇒ true
| thursday ⇒ true
| friday ⇒ true
| saturday ⇒ false
| sunday ⇒ false
end.
We can also define some of the usual operations on
booleans. First comes not or negation, which is often written
as the operator !.
Another common way of expressing functions from booleans to
booleans is with a truth table.
Each row of the truth table gives a possible assignment: you can
read the first row as saying that if b = true, then negb b =
false; the second row says that if b = false, then negb b =
true.
|---|--------| | b | negb b | |---|--------| | T | F | | F | T | |---|--------|Each column of the truth table represents an expression of type bool. Here the first column represents an arbitrary input b, which can be true (written T) or false (written F). It's typical to consider the initial columns of a truth table as representing inputs and the final column as representing an output.
When constructing a truth table with more than one input,
it's important to make sure your truth table has every possible
input configuration accounted for. People have different ways of
doing so, but I tend to like the following format, where we
exhaust all of the possibilities for the first column to be true,
and then we consider the cases where the first column is
false. Electrical engineers, however, like to do it the opposite
way: when false is 0 and true is 1, it makes sense to count "up".
It doesn't particularly matter which method you choose, but it's
important to be consistent!
|----|----|------------| | b1 | b2 | andb b1 b2 | |----|----|------------| | T | T | T | | T | F | F | | F | T | F | | F | F | F | |----|----|------------|
|----|----|-----------| | b1 | b2 | orb b1 b2 | |----|----|-----------| | T | T | T | | T | F | T | | F | T | T | | F | F | F | |----|----|-----------|
Example test_orb1: (orb true false) = true.
Proof. simpl. reflexivity. Qed.
Example test_orb2: (orb false false) = false.
Proof. simpl. reflexivity. Qed.
Example test_orb3: (orb false true) = true.
Proof. simpl. reflexivity. Qed.
Example test_orb4: (orb true true) = true.
Proof. simpl. reflexivity. Qed.
Proof. simpl. reflexivity. Qed.
Example test_orb2: (orb false false) = false.
Proof. simpl. reflexivity. Qed.
Example test_orb3: (orb false true) = true.
Proof. simpl. reflexivity. Qed.
Example test_orb4: (orb true true) = true.
Proof. simpl. reflexivity. Qed.
We can also introduce some familiar syntax for the boolean
operations we have just defined. The Notation command defines a new
symbolic notation for an existing definition.
Notation "x && y" := (andb x y).
Notation "x || y" := (orb x y).
Example test_orb5: false || false || true = true.
Proof. simpl. reflexivity. Qed.
Notation "x || y" := (orb x y).
Example test_orb5: false || false || true = true.
Proof. simpl. reflexivity. Qed.
A note on notation: In .v files, we use square brackets
to delimit fragments of Coq code within comments; this convention,
also used by the coqdoc documentation tool, keeps them visually
separate from the surrounding text. In the html version of the
files, these pieces of text appear in a different font.
The command Admitted can be used as a placeholder for an
incomplete proof. We'll use it in exercises, to indicate the
parts that we're leaving for you — i.e., your job is to replace
Admitteds with real proofs.
Exercise: 1 star (nandb)
Remove "Admitted." and complete the definition of the following function; then make sure that the Example assertions below can each be verified by Coq. (Remove "Admitted." and fill in each proof, following the model of the orb tests above.) The function should return true if either or both of its inputs are false.
Definition nandb (b1:bool) (b2:bool) : bool
(* REPLACE THIS LINE WITH ":= _your_definition_ ." *). Admitted.
☐
(* REPLACE THIS LINE WITH ":= _your_definition_ ." *). Admitted.
Exercise: 1 star (nandb_truth_table)
Write the truth table for nandb. Make sure to leave it in a comment, or your file won't compile!
(* FILL IN HERE *)
☐
Example test_nandb1: (nandb true false) = true.
(* FILL IN HERE *) Admitted.
Example test_nandb2: (nandb false false) = true.
(* FILL IN HERE *) Admitted.
Example test_nandb3: (nandb false true) = true.
(* FILL IN HERE *) Admitted.
☐
(* FILL IN HERE *) Admitted.
Example test_nandb2: (nandb false false) = true.
(* FILL IN HERE *) Admitted.
Example test_nandb3: (nandb false true) = true.
(* FILL IN HERE *) Admitted.
|---|--------|-----------------| | b | negb b | orb b (negb b) | |---|--------|-----------------| | T | F | T | | F | T | T | |---|--------|-----------------|
Exercise: 1 star (compound_truthtable)
Write the truth table for the expression orb (negb b1) b2.
(* FILL IN HERE *)
☐
Exercise: 1 star (impb)
Write a function impb such that impb b1 b2 has the same truth table as orb (negb b1) b2. Don't just trivially define it as orb (negb b1) b2, though! Try using a match.
Definition impb (b1:bool) (b2:bool) : bool
(* REPLACE THIS LINE WITH ":= _your_definition_ ." *). Admitted.
☐
(* REPLACE THIS LINE WITH ":= _your_definition_ ." *). Admitted.
Exercise: 1 star (andb3)
Do the same for the andb3 function below: write the definition and the truth table. This function should return true when all of its inputs are true, and false otherwise.
Definition andb3 (b1:bool) (b2:bool) (b3:bool) : bool
(* REPLACE THIS LINE WITH ":= _your_definition_ ." *). Admitted.
(* FILL IN HERE *)
☐
(* REPLACE THIS LINE WITH ":= _your_definition_ ." *). Admitted.
(* FILL IN HERE *)
Example test_andb31: (andb3 true true true) = true.
(* FILL IN HERE *) Admitted.
Example test_andb32: (andb3 false true true) = false.
(* FILL IN HERE *) Admitted.
Example test_andb33: (andb3 true false true) = false.
(* FILL IN HERE *) Admitted.
Example test_andb34: (andb3 true true false) = false.
(* FILL IN HERE *) Admitted.
(* FILL IN HERE *) Admitted.
Example test_andb32: (andb3 false true true) = false.
(* FILL IN HERE *) Admitted.
Example test_andb33: (andb3 true false true) = false.
(* FILL IN HERE *) Admitted.
Example test_andb34: (andb3 true true false) = false.
(* FILL IN HERE *) Admitted.
Function Types
Functions like negb itself are also data values, just like
true and false. Their types are called function types, and
they are written with arrows.
The type of negb, written bool → bool and pronounced
"bool arrow bool," can be read, "Given an input of type
bool, this function produces an output of type bool."
Similarly, the type of andb, written bool → bool → bool, can
be read, "Given two inputs, both of type bool, this function
produces an output of type bool."
Compound Types
Inductive rgb : Type :=
| red : rgb
| green : rgb
| blue : rgb.
Inductive color : Type :=
| black : color
| white : color
| primary : rgb → color.
| red : rgb
| green : rgb
| blue : rgb.
Inductive color : Type :=
| black : color
| white : color
| primary : rgb → color.
Let's look at this in a little more detail.
Every inductively defined type (day, bool, rgb, color,
etc.) contains a set of constructor expressions built from
constructors like red, primary, true, false, monday,
etc. The definitions of rgb and color say how expressions in
the sets rgb and color can be built:
We can define functions on colors using pattern matching just as
we have done for day and bool.
- red, green, and blue are the constructors of rgb;
- black, white, and primary are the constructors of color;
- the expression red belongs to the set rgb, as do the expressions green and blue;
- the expressions black and white belong to the set color;
- if p is an expression belonging to the set rgb, then primary p (pronounced "the constructor primary applied to the argument p") is an expression belonging to the set color; and
- expressions formed in these ways are the only ones belonging to the sets rgb and color.
Definition monochrome (c : color) : bool :=
match c with
| black ⇒ true
| white ⇒ true
| primary p ⇒ false
end.
match c with
| black ⇒ true
| white ⇒ true
| primary p ⇒ false
end.
Since the primary constructor takes an argument, a pattern
matching primary should include either a variable (as above) or
a constant of appropriate type (as below).
How does monochrome white evaluate? We can write out the
computation like so, simulating the way Coq works:
The scrutinee will always be a value; the pattern will be a mix of
constructors and variable names. The match construct tries to
match the scrutinee to each pattern, where a match is when every
constructor is matched with an identical constructor or a
variable.
Concretely, the scrutinee white doesn't match the pattern
black, because white and black are different
constructors. So Coq will skip that case, and keep evaluating:
The next pattern is white, which matches our scrutinee white,
so our pattern matches and we can execute the code in that branch
of the match:
monochrome white
computes to
match white with
| black ⇒ true
| white ⇒ true
| primary p ⇒ false
end
Coq considers each case in turn, comparing the scrutinee (here,
white) against the patterns (here, black, white, and
primary p).
| black ⇒ true
| white ⇒ true
| primary p ⇒ false
end
match white with
| black ⇒ true
| white ⇒ true
| primary p ⇒ false
end
| black ⇒ true
| white ⇒ true
| primary p ⇒ false
end
computes to
match white with
| white ⇒ true
| primary p ⇒ false
end
We're being particularly careful with our computation steps—-as
we gain facility with Coq, we won't need to step each case. But
here it helps us see that each pattern is considered in turn, from
top to bottom.
| white ⇒ true
| primary p ⇒ false
end
match white with
| white ⇒ true
| primary p ⇒ false
end
| white ⇒ true
| primary p ⇒ false
end
computes to
true
In this case, there were no variables in the match to keep track
of, but in general, Coq will bind each variable in a pattern to
the corresponding part of the scrutinee. For example, suppose we
had run monochrome (primary blue):
monochrome (primary blue)
computes to
match (primary blue) with
| black ⇒ true
| white ⇒ true
| primary p ⇒ false
end
| black ⇒ true
| white ⇒ true
| primary p ⇒ false
end
computes to
match (primary blue) with
| white ⇒ true
| primary p ⇒ false
end
| white ⇒ true
| primary p ⇒ false
end
computes to
match (primary blue) with
| primary p ⇒ false
end
At this point, the argument to the primary constructor, blue,
in the scrutinee corresponds to the variable p in the pattern
primary p. So what Coq will do is evaluate the corresponding
branch of the match, remember that p is equal to blue. (In
this case, p doesn't occur at all on the right-hand side of
⇒, so it doesn't matter. But it could!)
| primary p ⇒ false
end
match (primary blue) with
| primary p ⇒ false
end
| primary p ⇒ false
end
computes to
false (* with p bound to blue *)
Definition isred (c : color) : bool :=
match c with
| black ⇒ false
| white ⇒ false
| primary red ⇒ true
| primary _ ⇒ false
end.
match c with
| black ⇒ false
| white ⇒ false
| primary red ⇒ true
| primary _ ⇒ false
end.
The pattern primary _ here is shorthand for "primary applied
to any rgb constructor except red." Recall again that Coq
applies patterns in order. For example:
computes to
computes to
computes to
computes to
computes to
isred (primary green)
match (primary green) with
| black ⇒ false
| white ⇒ false
| primary red ⇒ true
| primary _ ⇒ false
| black ⇒ false
| white ⇒ false
| primary red ⇒ true
| primary _ ⇒ false
match (primary green) with
| white ⇒ false
| primary red ⇒ true
| primary _ ⇒ false
| white ⇒ false
| primary red ⇒ true
| primary _ ⇒ false
match (primary green) with
| primary red ⇒ true
| primary _ ⇒ false
At this point, our scrutinee primary green doesn't match the
pattern primary red: while the outermost constructors are both
primary, the arguments differ: green and red are different
constructors of color. So Coq will skip this pattern:
| primary red ⇒ true
| primary _ ⇒ false
match (primary green) with
| primary red ⇒ true
| primary _ ⇒ false
| primary red ⇒ true
| primary _ ⇒ false
match (primary green) with
| primary _ ⇒ false
| primary _ ⇒ false
false
In this case, the wildcard pattern _ has the same effect as the
dummy pattern variable p in the definition of monochrome. Both
functions don't actually use the argument to primary. We could
have written isred a different way:
Definition isred' (c : color) : bool :=
match c with
| black ⇒ false
| white ⇒ false
| primary p ⇒
match p with
| red ⇒ true
| _ ⇒ false
end
end.
match c with
| black ⇒ false
| white ⇒ false
| primary p ⇒
match p with
| red ⇒ true
| _ ⇒ false
end
end.
In this definition, we explicitly name the primary color we're
working with and do a nested pattern match. We can compute
isred' (primary green) as follows:
computes to
computes to
computes to
computes to
computes to
computes to
It's also good practice to try to condense pattern matching: the
definition of isred is cleaner than that of isred'.
isred' (primary green)
match (primary green) with
| black ⇒ false
| white ⇒ false
| primary p ⇒
match p with
| red ⇒ true
| _ ⇒ false
end
end
| black ⇒ false
| white ⇒ false
| primary p ⇒
match p with
| red ⇒ true
| _ ⇒ false
end
end
match (primary green) with
| white ⇒ false
| primary p ⇒
match p with
| red ⇒ true
| _ ⇒ false
end
end
| white ⇒ false
| primary p ⇒
match p with
| red ⇒ true
| _ ⇒ false
end
end
match (primary green) with
| primary p ⇒
match p with
| red ⇒ true
| _ ⇒ false
end
end
| primary p ⇒
match p with
| red ⇒ true
| _ ⇒ false
end
end
match green with
| red ⇒ true
| _ ⇒ false
end
| red ⇒ true
| _ ⇒ false
end
match green with
| _ ⇒ false
end
| _ ⇒ false
end
false
It's good practice to use wildcards when you don't need to name
the variable—-it helps prevent mistakes, like referring to the
wrong variable.
Modules
Numbers
- zero (i.e., no tick marks), or
- a natural number followed by another tick mark.
The clauses of this definition can be read:
Again, let's look at this in a little more detail. The definition
of nat says how expressions in the set nat can be built:
The same rules apply for our definitions of day, bool,
color, etc.
The above conditions are the precise force of the Inductive
declaration. They imply that the expression O, the expression
S O, the expression S (S O), the expression S (S (S O)), and
so on all belong to the set nat, while other expressions built
from data constructors, like true, andb true false, S (S
false), and O (O (O S)) do not.
A critical point here is that what we've done so far is just to
define a representation of numbers: a way of writing them down.
The names O and S are arbitrary, and at this point they have
no special meaning — they are just two different marks that we
can use to write down numbers (together with a rule that says any
nat will be written as some string of S marks followed by an
O). If we like, we can write essentially the same definition
this way:
- O is a natural number (note that this is the letter "O," not the numeral "0").
- S can be put in front of a natural number to yield another one — if n is a natural number, then S n is too.
- O and S are constructors;
- the expression O belongs to the set nat;
- if n is an expression belonging to the set nat, then S n is also an expression belonging to the set nat; and
- expressions formed in these two ways are the only ones belonging to the set nat.
The interpretation of these marks comes from how we use them to
compute. We use O and S rather than these longer names because
(a) concision is nice, (b) we'll be using nat quite a bit, and
(c) that's how the Coq standard library defines them.
We interpret by writing functions that pattern match on
representations of natural numbers just as we did above with
booleans and days — for example, here is the predecessor
function, which takes a given number and returns one less than
that number, i.e.,
pred (S n) should compute to n
For example, pred (S O) computes to O, i.e., 0 is the predecessor
of 1.
Our definition has an unfortunate property: pred O computes to
O, i.e., 0 is its own predecessor. A mathematician might take a
different course of action, saying that pred O is
undefined—-there really is no natural number that comes before 0,
since 0 is the first one! Coq won't let us leave anything
undefined, though, so we'll simply have to be careful to remember
that pred O = O.
The second branch can be read: "if n has the form S n'
for some n', then return n'."
Because natural numbers are such a pervasive form of data,
Coq provides a tiny bit of built-in magic for parsing and printing
them: ordinary arabic numerals can be used as an alternative to
the "unary" notation defined by the constructors S and O. Coq
prints numbers in arabic form by default:
Check (S (S (S (S O)))).
(* ===> 4 : nat *)
Definition minustwo (n : nat) : nat :=
match n with
| O ⇒ O
| S O ⇒ O
| S (S n') ⇒ n'
end.
Compute (minustwo 4).
(* ===> 2 : nat *)
(* ===> 4 : nat *)
Definition minustwo (n : nat) : nat :=
match n with
| O ⇒ O
| S O ⇒ O
| S (S n') ⇒ n'
end.
Compute (minustwo 4).
(* ===> 2 : nat *)
The constructor S has the type nat → nat, just like
pred and functions like minustwo:
These are all things that can be applied to a number to yield a
number. However, there is a fundamental difference between the
first one and the other two: functions like pred and minustwo
come with computation rules — e.g., the definition of pred
says that pred 2 can be simplified to 1 — while the
definition of S has no such behavior attached. Although it is
like a function in the sense that it can be applied to an
argument, it does not do anything at all! It is just a way of
writing down numbers. (Think about standard arabic numerals: the
numeral 1 is not a computation; it's a piece of data. When we
write 111 to mean the number one hundred and eleven, we are
using 1, three times, to write down a concrete representation of
a number.)
For most function definitions over numbers, just pattern matching
is not enough: we also need recursion, i.e., functions that
refer to themselves. For example, to check that a number n is
even, we may need to recursively check whether n-2 is even. To
write such functions, we use the keyword Fixpoint.
In your prior programming experience, you may not have spent a lot
of thought on recursion. Many languages use loops (using words
like while or for) rather than recursion. Coq doesn't have
loops—-only recursion. Don't worry if you're not particularly
familiar with recursion... you'll get lots of practice!
The call to evenb n' is a recursive call. One might
worry: is it okay to define a function in terms of itself? How do
we know that evenb terminates?
We can check an example: is 3 even?
is the same as
computes to
computes to
computes to
computes to
is the same as
computes to
computes to
computes to
A surprising fact: Coq will only let us write functions that are
guaranteed to terminate on all inputs. A good rule of thumb is
that every recursive function should make a recursive call only on
subparts of its input.
We can define oddb by a similar Fixpoint declaration, but here
is a simpler definition:
evenb 3
evenb (S (S (S O)))
match (S (S (S O))) with
| O ⇒ true
| S O ⇒ false
| S (S n') ⇒ evenb n'
end
| O ⇒ true
| S O ⇒ false
| S (S n') ⇒ evenb n'
end
match (S (S (S O))) with
| S O ⇒ false
| S (S n') ⇒ evenb n'
end
| S O ⇒ false
| S (S n') ⇒ evenb n'
end
match (S (S (S O))) with
| S (S n') ⇒ evenb n'
end
| S (S n') ⇒ evenb n'
end
evenb n' (* with n' bound to S O *)
evenb (S 0)
match (S O) with
| O ⇒ true
| S O ⇒ false
| S (S n') ⇒ evenb n'
end
| O ⇒ true
| S O ⇒ false
| S (S n') ⇒ evenb n'
end
match (S O) with
| S O ⇒ false
| S (S n') ⇒ evenb n'
end
| S O ⇒ false
| S (S n') ⇒ evenb n'
end
false
More generally, evenb only ever makes recursive calls on smaller
inputs: if we put in the number n, we'll make a recursive call
on two less than n.
Definition oddb (n:nat) : bool := negb (evenb n).
Example test_oddb1: oddb 1 = true.
Proof. simpl. reflexivity. Qed.
Example test_oddb2: oddb 4 = false.
Proof. simpl. reflexivity. Qed.
Example test_oddb1: oddb 1 = true.
Proof. simpl. reflexivity. Qed.
Example test_oddb2: oddb 4 = false.
Proof. simpl. reflexivity. Qed.
(You will notice if you step through these proofs that
simpl actually has no effect on the goal — all of the work is
done by reflexivity. We'll see more about why that is shortly.)
Naturally, we can also define multi-argument functions by
recursion.
Module NatPlayground2.
Fixpoint plus (n : nat) (m : nat) : nat :=
match n with
| O ⇒ m
| S n' ⇒ S (plus n' m)
end.
Fixpoint plus (n : nat) (m : nat) : nat :=
match n with
| O ⇒ m
| S n' ⇒ S (plus n' m)
end.
Adding three to two now gives us five, as we'd expect.
The simplification that Coq performs to reach this
conclusion can be visualized as follows, a little more succinctly
than what we wrote above:
(* plus (S (S (S O))) (S (S O))
==> S (plus (S (S O)) (S (S O)))
by the second clause of the match
==> S (S (plus (S O) (S (S O))))
by the second clause of the match
==> S (S (S (plus O (S (S O)))))
by the second clause of the match
==> S (S (S (S (S O))))
by the first clause of the match
*)
==> S (plus (S (S O)) (S (S O)))
by the second clause of the match
==> S (S (plus (S O) (S (S O))))
by the second clause of the match
==> S (S (S (plus O (S (S O)))))
by the second clause of the match
==> S (S (S (S (S O))))
by the first clause of the match
*)
As a notational convenience, if two or more arguments have
the same type, they can be written together. In the following
definition, (n m : nat) means just the same as if we had written
(n : nat) (m : nat).
Fixpoint mult (n m : nat) : nat :=
match n with
| O ⇒ O
| S n' ⇒ plus m (mult n' m)
end.
Example test_mult1: (mult 3 3) = 9.
Proof. simpl. reflexivity. Qed.
match n with
| O ⇒ O
| S n' ⇒ plus m (mult n' m)
end.
Example test_mult1: (mult 3 3) = 9.
Proof. simpl. reflexivity. Qed.
You can match two expressions at once by putting a comma
between them:
Fixpoint minus (n m:nat) : nat :=
match (n, m) with
| (O , _) ⇒ O
| (S _ , O) ⇒ n
| (S n', S m') ⇒ minus n' m'
end.
match (n, m) with
| (O , _) ⇒ O
| (S _ , O) ⇒ n
| (S n', S m') ⇒ minus n' m'
end.
Our minus function has the same problem pred does: minus 0 n
results in 0! This 'truncating' subtraction is necessary because
we're working with natural numbers, i.e., there are no negative
numbers.
Keep in mind: these definitions have suggestive names, but it's up
to us as humans to agree that minus corresponds to our notion of
subtraction. I would wager that it does: if we pick an n and an
m such that m ≤ n, then minus n m yields n - m. We
don't have the tools to prove this... yet!
Again, the _ in the first line is a wildcard pattern. Writing
_ in a pattern is the same as writing some variable that doesn't
get used on the right-hand side. This avoids the need to invent a
variable name.
The exp function defines exponentiation: exp n m should yield
n to the mth power.
Fixpoint exp (base power : nat) : nat :=
match power with
| O ⇒ S O
| S p ⇒ mult base (exp base p)
end.
match power with
| O ⇒ S O
| S p ⇒ mult base (exp base p)
end.
Exercise: 1 star (factorial)
Here's the standard mathematical factorial function:factorial(0) = 1 factorial(n) = n * factorial(n-1) (if n>0)
Fixpoint factorial (n:nat) : nat
(* REPLACE THIS LINE WITH ":= _your_definition_ ." *). Admitted.
Example test_factorial1: (factorial 3) = 6.
(* FILL IN HERE *) Admitted.
Example test_factorial2: (factorial 5) = (mult 10 12).
(* FILL IN HERE *) Admitted.
☐
(* REPLACE THIS LINE WITH ":= _your_definition_ ." *). Admitted.
Example test_factorial1: (factorial 3) = 6.
(* FILL IN HERE *) Admitted.
Example test_factorial2: (factorial 5) = (mult 10 12).
(* FILL IN HERE *) Admitted.
Notation "x + y" := (plus x y)
(at level 50, left associativity)
: nat_scope.
Notation "x - y" := (minus x y)
(at level 50, left associativity)
: nat_scope.
Notation "x * y" := (mult x y)
(at level 40, left associativity)
: nat_scope.
Check ((0 + 1) + 1).
(at level 50, left associativity)
: nat_scope.
Notation "x - y" := (minus x y)
(at level 50, left associativity)
: nat_scope.
Notation "x * y" := (mult x y)
(at level 40, left associativity)
: nat_scope.
Check ((0 + 1) + 1).
(The level, associativity, and nat_scope annotations
control how these notations are treated by Coq's parser. The
details are not important for our purposes, but interested readers
can refer to the optional "More on Notation" section at the end of
this chapter.)
Note that these do not change the definitions we've already made:
they are simply instructions to the Coq parser to accept x + y
in place of plus x y and, conversely, to the Coq pretty-printer
to display plus x y as x + y.
When we say that Coq comes with almost nothing built-in, we really
mean it: even equality testing for numbers is a user-defined
operation! We now define a function beq_nat, which tests
natural numbers for equality, yielding a boolean. Note the
use of nested matches (we could also have used a simultaneous
match, as we did in minus.)
Fixpoint beq_nat (n m : nat) : bool :=
match n with
| O ⇒ match m with
| O ⇒ true
| S m' ⇒ false
end
| S n' ⇒ match m with
| O ⇒ false
| S m' ⇒ beq_nat n' m'
end
end.
match n with
| O ⇒ match m with
| O ⇒ true
| S m' ⇒ false
end
| S n' ⇒ match m with
| O ⇒ false
| S m' ⇒ beq_nat n' m'
end
end.
The leb function tests whether its first argument is less than or
equal to its second argument, yielding a boolean.
Fixpoint leb (n m : nat) : bool :=
match n with
| O ⇒ true
| S n' ⇒
match m with
| O ⇒ false
| S m' ⇒ leb n' m'
end
end.
Example test_leb1: (leb 2 2) = true.
Proof. simpl. reflexivity. Qed.
Example test_leb2: (leb 2 4) = true.
Proof. simpl. reflexivity. Qed.
Example test_leb3: (leb 4 2) = false.
Proof. simpl. reflexivity. Qed.
match n with
| O ⇒ true
| S n' ⇒
match m with
| O ⇒ false
| S m' ⇒ leb n' m'
end
end.
Example test_leb1: (leb 2 2) = true.
Proof. simpl. reflexivity. Qed.
Example test_leb2: (leb 2 4) = true.
Proof. simpl. reflexivity. Qed.
Example test_leb3: (leb 4 2) = false.
Proof. simpl. reflexivity. Qed.
Exercise: 1 star (blt_nat)
The blt_nat function tests natural numbers for less-than, yielding a boolean. Instead of making up a new Fixpoint for this one, define it in terms of a previously defined function.
Definition blt_nat (n m : nat) : bool
(* REPLACE THIS LINE WITH ":= _your_definition_ ." *). Admitted.
Example test_blt_nat1: (blt_nat 2 2) = false.
(* FILL IN HERE *) Admitted.
Example test_blt_nat2: (blt_nat 2 4) = true.
(* FILL IN HERE *) Admitted.
Example test_blt_nat3: (blt_nat 4 2) = false.
(* FILL IN HERE *) Admitted.
☐
(* REPLACE THIS LINE WITH ":= _your_definition_ ." *). Admitted.
Example test_blt_nat1: (blt_nat 2 2) = false.
(* FILL IN HERE *) Admitted.
Example test_blt_nat2: (blt_nat 2 4) = true.
(* FILL IN HERE *) Admitted.
Example test_blt_nat3: (blt_nat 4 2) = false.
(* FILL IN HERE *) Admitted.
Proof by Simplification
What's happening here? It's worth stepping through the proof
slowly, looking at the various views: there's the main script
screen, the screen with the goal and context, and a response
screen.
We write Theorem and then a name for our theorem—-here
plus_O_n. Then we write a proposition, in this case ∀n
: nat, 0 + n = n, i.e., for any possible natural number n, it
is the case that 0 + n is equal to n. We'll talk more about
what counts as a proposition later in the course.
After we type the Proof. keyword, we're shown a screen like the
following:
Then there's a line. Beneath the line is our *goal*—-that's what
we're trying to prove. Above the line is our *context*, which is
currently empty.
The way a proof works is that we try to show that given our
context, our goal *holds*, that is, that our goal is a true
proposition.
In Coq, we use tactics to manipulate the goal and context, where
Coq will keep track of the goal and context for us. On paper (or a
chalkboard or in person), we'll use natural language (for CS 54,
English) to to manipulate the goal and context, which we'll keep
track of ourselves.
Throughout the course, we'll try to keep parallel tracks in mind:
how does proof work in Coq and how does it work on paper? After
this course, you'll probably only use paper proofs. We'll be using
Coq as a tool to help you learn the ropes of paper proof. One of
the hardest things about paper proof is that it can be very easy to
get confused and make mistakes, breaking the "rules". Coq enforces
the rules! Using Coq will help you internalize the rules.
After the Proof. keyword comes our *proof script*, a series of
*tactics* telling Coq how to manipulate the proof state. Each
tactic is followed by a period.
Before explaining the proof script, let's see the above proof in
English.
Our next tactic is simpl, which asks Coq to simplify our goal,
running a few steps of computation:
When we run the tactic, we get a new readout:
(You may notice that the above statement looks different in
the .v file in your IDE than it does in the HTML rendition in
your browser, if you are viewing both. In .v files, we write the
∀universal quantifier using the reserved identifier
"forall." When the .v files are converted to HTML, this gets
transformed into an upside-down-A symbol.)
This is a good place to mention that reflexivity is a bit
more powerful than we have admitted. In the examples we have seen,
the calls to simpl were actually not needed, because
reflexivity can perform some simplification automatically when
checking that two sides are equal; simpl was just added so that
we could see the intermediate state — after simplification but
before finishing the proof. Here is a shorter proof of the
theorem:
1 subgoal, subgoal 1 (ID 50)
============================
∀ n : nat, 0 + n = n
The first line says how many cases we're considering in our proof
at present: there's 1 subgoal, and we're currently working on
it. That is: our proof has only one case.
============================
∀ n : nat, 0 + n = n
- Theorem: For any natural number n,
0 + n = n.Proof: Let n be given. We must show that0 + n = n.By the definition of plus, we know that 0+n reduces to n. Finally, we haven = nimmediately. Qed.
1 subgoal, subgoal 1 (ID 51)
n : nat
============================
0 + n = n
We could have chosen a different name—-go back and change it to
read intros m and see what goal you get! (It's generally good
style to use the name in the quantifier, since it's a little
clearer.)
n : nat
============================
0 + n = n
1 subgoal, subgoal 1 (ID 53)
n : nat
============================
n = n
Our context remains the same, but our new goal is to show that n
= n. To do so, we use the reflexivity tactic, named after the
property of equality: all things are equal to themselves.
n : nat
============================
n = n
No more subgoals.
(dependent evars: (printing disabled) )
Coq is being a little too lowkey here: we proved it! To celebrate
(and tell Coq that we're satisfied with our proof), we say Qed.,
which is short for quod erat demonstrandum, which is Latin for
"that which was to be proved" which is perhaps better said as "and
we've proved what we want to" or "and that's the proof" or "I told
you so!" or "mic drop". Then Coq acknowledges that we're truly done:
(dependent evars: (printing disabled) )
plus_O_n is defined
The paper and Coq proofs are very much in parallel. Here's the
paper proof annotated with Coq tactics:
- Theorem: For any natural number n,
0 + n = n.Proof: Let n be given (intros n.). We must show that0 + n = n.By the definition of plus, we know that 0+n reduces to n (simpl.). Finally, we haven = nimmediately (reflexivity.). Qed.
Moreover, it will be useful later to know that reflexivity
does somewhat more simplification than simpl does — for
example, it tries "unfolding" defined terms, replacing them with
their right-hand sides. The reason for this difference is that,
if reflexivity succeeds, the whole goal is finished and we don't
need to look at whatever expanded expressions reflexivity has
created by all this simplification and unfolding; by contrast,
simpl is used in situations where we may have to read and
understand the new goal that it creates, so we would not want it
blindly expanding definitions and leaving the goal in a messy
state.
The form of the theorem we just stated and its proof are almost
exactly the same as the simpler examples we saw earlier; there are
just a few differences.
First, we've used the keyword Theorem instead of Example.
This difference is mostly a matter of style; the keywords
Example and Theorem (and a few others, including Lemma,
Fact, and Remark) mean pretty much the same thing to Coq.
Second, we've added the quantifier ∀n:nat, so that our
theorem talks about all natural numbers n. Informally, to
prove theorems of this form, we generally start by saying "Suppose
n is some number..." Formally, this is achieved in the proof by
intros n, which moves n from the quantifier in the goal to a
context of current assumptions.
The keywords intros, simpl, and reflexivity are examples of
tactics. A tactic is a command that is used between Proof and
Qed to guide the process of checking some claim we are making.
We will see several more tactics in the rest of this chapter and
yet more in future chapters.
Other similar theorems can be proved with the same pattern.
Theorem plus_1_l : ∀ n:nat, 1 + n = S n.
Proof.
intros n. reflexivity. Qed.
Theorem mult_0_l : ∀ n:nat, 0 * n = 0.
Proof.
intros n. reflexivity. Qed.
Proof.
intros n. reflexivity. Qed.
Theorem mult_0_l : ∀ n:nat, 0 * n = 0.
Proof.
intros n. reflexivity. Qed.
The _l suffix in the names of these theorems is
pronounced "on the left."
It is worth stepping through these proofs to observe how the
context and the goal change. You may want to add calls to simpl
before reflexivity to see the simplifications that Coq performs
on the terms before checking that they are equal.
Instead of making a universal claim about all numbers n
and m, it talks about a more specialized property that only
holds when n = m. The arrow symbol is pronounced "implies."
We've already defined a notion of implies on booleans impb; now
we have a notion of implies on propositions.
The way a proof with implies works is: you have to prove what's to
the right of the arrow... but you may assume what's to the
left. That is, to show that n + n = m + m, we know (in our
context) not only that n and m are natural numbers, but in
fact it is the case that n = m.
As before, we need to be able to reason by assuming we are given
such numbers n and m. We also need to assume the hypothesis
n = m. The intros tactic will serve to move all three of these
from the goal into assumptions in the current context.
Since n and m are arbitrary numbers, we can't just use
simplification to prove this theorem. Instead, we prove it by
observing that, if we are assuming n = m, then we can replace
n with m in the goal statement and obtain an equality with the
same expression on both sides. The tactic that tells Coq to
perform this replacement is called rewrite.
Proof.
(* move both quantifiers into the context: *)
intros n m.
(* move the hypothesis into the context: *)
intros H.
(* rewrite the goal using the hypothesis: *)
rewrite → H.
reflexivity. Qed.
(* move both quantifiers into the context: *)
intros n m.
(* move the hypothesis into the context: *)
intros H.
(* rewrite the goal using the hypothesis: *)
rewrite → H.
reflexivity. Qed.
The first line of the proof moves the universally quantified
variables n and m into the context. The second moves the
hypothesis n = m into the context and gives it the name H.
The third tells Coq to rewrite the current goal (n + n = m + m)
by replacing the left side of the equality hypothesis H with the
right side.
(The arrow symbol in the rewrite has nothing to do with
implication: it tells Coq to apply the rewrite from left to right.
To rewrite from right to left, you can use rewrite <-. Try
making this change in the above proof and see what difference it
makes.) Here's a paper proof of the same theorem, with the tactics
interwoven.
- Theorem: For any natural numbers n and m,
if
n = mthenn + n = m + m.n + n = m + m.m + m = m + mimmediately (reflexivity.). Qed.
Exercise: 1 star (plus_id_exercise)
Remove "Admitted." and fill in the proof.
Theorem plus_id_exercise : ∀ n m o : nat,
n = m → m = o → n + m = m + o.
Proof.
(* FILL IN HERE *) Admitted.
☐
n = m → m = o → n + m = m + o.
Proof.
(* FILL IN HERE *) Admitted.
Theorem mult_0_plus : ∀ n m : nat,
(0 + n) * m = n * m.
Proof.
intros n m.
rewrite → plus_O_n.
reflexivity. Qed.
(0 + n) * m = n * m.
Proof.
intros n m.
rewrite → plus_O_n.
reflexivity. Qed.
Note that we've just rewritten by an existing theorem: the proof
of mult_0_plus uses the proof of plus_O_n.
In an informal proof, we might use language by "by plus_0_n, we
know...". For example:
- Theorem: For any natural number n and m,
(0 + n) * m = n * m.(0 + n) * m = n * m.n * m = n * mimmediately (reflexivity.). Qed.
Exercise: 2 stars (mult_S_1)
Theorem mult_S_1 : ∀ n m : nat,
m = S n →
m * (1 + n) = m * m.
Proof.
(* FILL IN HERE *) Admitted.
(* (N.b. This proof can actually be completed without using rewrite,
but please do use rewrite for the sake of the exercise.) *)
☐
m = S n →
m * (1 + n) = m * m.
Proof.
(* FILL IN HERE *) Admitted.
(* (N.b. This proof can actually be completed without using rewrite,
but please do use rewrite for the sake of the exercise.) *)
Proof by Case Analysis
Theorem plus_1_neq_0_firsttry : ∀ n : nat,
beq_nat (n + 1) 0 = false.
Proof.
intros n.
simpl. (* does nothing! *)
Abort.
beq_nat (n + 1) 0 = false.
Proof.
intros n.
simpl. (* does nothing! *)
Abort.
The reason for this is that the definitions of both
beq_nat and + begin by performing a match on their first
argument. But here, the first argument to + is the unknown
number n and the argument to beq_nat is the compound
expression n + 1; neither can be simplified.
To make progress, we need to consider the possible forms of n
separately. If n is O, then we can calculate the final result
of beq_nat (n + 1) 0 and check that it is, indeed, false. And
if n = S n' for some n', then, although we don't know exactly
what number n + 1 yields, we can calculate that, at least, it
will begin with one S, and this is enough to calculate that,
again, beq_nat (n + 1) 0 will yield false.
The tactic that tells Coq to consider, separately, the cases where
n = O and where n = S n' is called destruct.
Theorem plus_1_neq_0 : ∀ n : nat,
beq_nat (n + 1) 0 = false.
Proof.
intros n. destruct n as [| n'].
- reflexivity.
- reflexivity. Qed.
beq_nat (n + 1) 0 = false.
Proof.
intros n. destruct n as [| n'].
- reflexivity.
- reflexivity. Qed.
The destruct generates two subgoals, which we must then
prove, separately, in order to get Coq to accept the theorem. The
annotation "as [| n']" is called an intro pattern. It tells
Coq what variable names to introduce in each subgoal. In general,
what goes between the square brackets is a list of lists of
names, separated by |. In this case, the first component is
empty, since the O constructor is nullary (it doesn't have any
arguments). The second component gives a single name, n', since
S is a unary constructor.
The - signs on the second and third lines are called bullets,
and they mark the parts of the proof that correspond to each
generated subgoal. The proof script that comes after a bullet is
the entire proof for a subgoal. In this example, each of the
subgoals is easily proved by a single use of reflexivity, which
itself performs some simplification — e.g., the first one
simplifies beq_nat (S n' + 1) 0 to false by first rewriting
(S n' + 1) to S (n' + 1), then unfolding beq_nat, and then
simplifying the match.
Marking cases with bullets is entirely optional: if bullets are
not present, Coq simply asks you to prove each subgoal in
sequence, one at a time. But it is a good idea to use bullets.
For one thing, they make the structure of a proof apparent, making
it more readable. Also, bullets instruct Coq to ensure that a
subgoal is complete before trying to verify the next one,
preventing proofs for different subgoals from getting mixed
up. These issues become especially important in large
developments, where fragile proofs lead to long debugging
sessions.
There are no hard and fast rules for how proofs should be
formatted in Coq — in particular, where lines should be broken
and how sections of the proof should be indented to indicate their
nested structure. However, if the places where multiple subgoals
are generated are marked with explicit bullets at the beginning of
lines, then the proof will be readable almost no matter what
choices are made about other aspects of layout.
This is also a good place to mention one other piece of somewhat
obvious advice about line lengths. Beginning Coq users sometimes
tend to the extremes, either writing each tactic on its own line
or writing entire proofs on one line. Good style lies somewhere
in the middle. One reasonable convention is to limit yourself to
80-character lines.
The destruct tactic can be used with any inductively defined
datatype. For example, we use it next to prove that boolean
negation is involutive — i.e., that negation is its own
inverse.
We've encounted our first significant divergence (of many!)
between how Coq and paper proofs work. Coq keeps track of the
context for you, so Coq proof scripts can leave quite a bit
implicit. Paper proofs are meant to communicate an idea from one
human to another, so it's important to check in and make sure
everyone is on the same page—-by, for example, saying what each
case is up front.
Finally, note that we're not "transliterating" the Coq: the two
uses of reflexivity in each branch are written slightly
differently in the paper proof.
- Theorem: For any natural number n,
beq_nat (n + 1) 0 = false.- First, suppose n=0. We must show that beq_nat (0 + 1) 0 = false, which we have by definition (reflexivity).
- Next, suppose n=S n'. We must show that beq_nat ((S n') + 1) 0 = false, which holds
by the definition of beq_nat (reflexivity).
Theorem negb_involutive : ∀ b : bool,
negb (negb b) = b.
Proof.
intros b. destruct b.
- reflexivity.
- reflexivity. Qed.
negb (negb b) = b.
Proof.
intros b. destruct b.
- reflexivity.
- reflexivity. Qed.
Note that the destruct here has no as clause because
none of the subcases of the destruct need to bind any variables,
so there is no need to specify any names. (We could also have
written as [|], or as [].) In fact, we can omit the as
clause from any destruct and Coq will fill in variable names
automatically. This is generally considered bad style, since Coq
often makes confusing choices of names when left to its own
devices. In a paper proof, it'd be good to announce that b=false
in the first case and b=true in the second case.
It is sometimes useful to invoke destruct inside a subgoal,
generating yet more proof obligations. In this case, we use
different kinds of bullets to mark goals on different "levels."
For example:
Theorem andb_commutative : ∀ b c, andb b c = andb c b.
Proof.
intros b c. destruct b.
- destruct c.
+ reflexivity.
+ reflexivity.
- destruct c.
+ reflexivity.
+ reflexivity.
Qed.
Proof.
intros b c. destruct b.
- destruct c.
+ reflexivity.
+ reflexivity.
- destruct c.
+ reflexivity.
+ reflexivity.
Qed.
Each pair of calls to reflexivity corresponds to the
subgoals that were generated after the execution of the destruct c
line right above it.
Besides - and +, we can use * (asterisk) as a third kind of
bullet. We can also enclose sub-proofs in curly braces, which is
useful in case we ever encounter a proof that generates more than
three levels of subgoals:
Theorem andb_commutative' : ∀ b c, andb b c = andb c b.
Proof.
intros b c. destruct b.
{ destruct c.
{ reflexivity. }
{ reflexivity. } }
{ destruct c.
{ reflexivity. }
{ reflexivity. } }
Qed.
Proof.
intros b c. destruct b.
{ destruct c.
{ reflexivity. }
{ reflexivity. } }
{ destruct c.
{ reflexivity. }
{ reflexivity. } }
Qed.
Since curly braces mark both the beginning and the end of a
proof, they can be used for multiple subgoal levels, as this
example shows. Furthermore, curly braces allow us to reuse the
same bullet shapes at multiple levels in a proof:
Theorem andb3_exchange :
∀ b c d, andb (andb b c) d = andb (andb b d) c.
Proof.
intros b c d. destruct b.
- destruct c.
{ destruct d.
- reflexivity.
- reflexivity. }
{ destruct d.
- reflexivity.
- reflexivity. }
- destruct c.
{ destruct d.
- reflexivity.
- reflexivity. }
{ destruct d.
- reflexivity.
- reflexivity. }
Qed.
∀ b c d, andb (andb b c) d = andb (andb b d) c.
Proof.
intros b c d. destruct b.
- destruct c.
{ destruct d.
- reflexivity.
- reflexivity. }
{ destruct d.
- reflexivity.
- reflexivity. }
- destruct c.
{ destruct d.
- reflexivity.
- reflexivity. }
{ destruct d.
- reflexivity.
- reflexivity. }
Qed.
Before closing the chapter, let's mention one final convenience.
As you may have noticed, many proofs perform case analysis on a variable
right after introducing it:
intros x y. destruct y as [|y].
This pattern is so common that Coq provides a shorthand for it: we
can perform case analysis on a variable when introducing it by
using an intro pattern instead of a variable name. For instance,
here is a shorter proof of the plus_1_neq_0 theorem above.
Theorem plus_1_neq_0' : ∀ n : nat,
beq_nat (n + 1) 0 = false.
Proof.
intros [|n].
- reflexivity.
- reflexivity. Qed.
☐
beq_nat (n + 1) 0 = false.
Proof.
intros [|n].
- reflexivity.
- reflexivity. Qed.
Theorem andb_commutative'' :
∀ b c, andb b c = andb c b.
Proof.
intros [] [].
- reflexivity.
- reflexivity.
- reflexivity.
- reflexivity.
Qed.
∀ b c, andb b c = andb c b.
Proof.
intros [] [].
- reflexivity.
- reflexivity.
- reflexivity.
- reflexivity.
Qed.
Exercise: 2 stars (andb_true_elim2)
Prove the following claim, marking cases (and subcases) with bullets when you use destruct.
Theorem andb_true_elim2 : ∀ b c : bool,
andb b c = true → c = true.
Proof.
(* FILL IN HERE *) Admitted.
☐
andb b c = true → c = true.
Proof.
(* FILL IN HERE *) Admitted.
Theorem nandb__negb_andb : ∀ b1 b2 : bool,
nandb b1 b2 = negb (andb b1 b2).
Proof.
(* FILL IN HERE *) Admitted.
☐
nandb b1 b2 = negb (andb b1 b2).
Proof.
(* FILL IN HERE *) Admitted.
(* Prove the previous theorem on paper, i.e., show that
[ ∀b1 b2 : bool, nandb b1 b2 = negb (andb b1 b2). ]
Write your proof in a comment, following the format seen in
the paper proofs so far. Keep in mind that your paper proof can do
cases on more than one thing at once, or you can do cases inside
other cases. *)
(* FILL IN HERE *)
☐
[ ∀b1 b2 : bool, nandb b1 b2 = negb (andb b1 b2). ]
Write your proof in a comment, following the format seen in
the paper proofs so far. Keep in mind that your paper proof can do
cases on more than one thing at once, or you can do cases inside
other cases. *)
(* FILL IN HERE *)
Theorem impb_spec : ∀ b1 b2 : bool,
impb b1 b2 = orb (negb b1) b2.
Proof.
(* FILL IN HERE *) Admitted.
☐
impb b1 b2 = orb (negb b1) b2.
Proof.
(* FILL IN HERE *) Admitted.
Theorem zero_nbeq_plus_1 : ∀ n : nat,
beq_nat 0 (n + 1) = false.
Proof.
(* FILL IN HERE *) Admitted.
☐
beq_nat 0 (n + 1) = false.
Proof.
(* FILL IN HERE *) Admitted.
Exercise: 2 stars (zero_nbeq_plus_1_paper)
Prove the previous theorem on paper, i.e., show that
∀ n : nat,
beq_nat 0 (n + 1) = false.
Write your proof in a comment, following the format seen in
the paper proofs so far.
beq_nat 0 (n + 1) = false.
(* FILL IN HERE *)
☐
More on Notation (Optional)
Notation "x + y" := (plus x y)
(at level 50, left associativity)
: nat_scope.
Notation "x * y" := (mult x y)
(at level 40, left associativity)
: nat_scope.
(at level 50, left associativity)
: nat_scope.
Notation "x * y" := (mult x y)
(at level 40, left associativity)
: nat_scope.
For each notation symbol in Coq, we can specify its precedence
level and its associativity. The precedence level n is
specified by writing at level n; this helps Coq parse compound
expressions. The associativity setting helps to disambiguate
expressions containing multiple occurrences of the same
symbol. For example, the parameters specified above for + and
* say that the expression 1+2*3*4 is shorthand for
(1+((2*3)*4)). Coq uses precedence levels from 0 to 100, and
left, right, or no associativity. We will see more examples
of this later, e.g., in the Lists
chapter.
Each notation symbol is also associated with a notation scope.
Coq tries to guess what scope is meant from context, so when it
sees S(O*O) it guesses nat_scope, but when it sees the
cartesian product (tuple) type bool*bool (which we'll see in
later chapters) it guesses type_scope. Occasionally, it is
necessary to help it out with percent-notation by writing
(x*y)%nat, and sometimes in what Coq prints it will use %nat
to indicate what scope a notation is in.
Notation scopes also apply to numeral notation (3, 4, 5,
etc.), so you may sometimes see 0%nat, which means O (the
natural number 0 that we're using in this chapter), or 0%Z,
which means the Integer zero (which comes from a different part of
the standard library).
Pro tip: Coq's notation mechanism is not especially powerful.
Don't expect too much from it!
When Coq checks this definition, it notes that plus' is
"decreasing on 1st argument." What this means is that we are
performing a structural recursion over the argument n — i.e.,
that we make recursive calls only on strictly smaller values of
n. This implies that all calls to plus' will eventually
terminate. Coq demands that some argument of every Fixpoint
definition is "decreasing."
This requirement is a fundamental feature of Coq's design: In
particular, it guarantees that every function that can be defined
in Coq will terminate on all inputs. However, because Coq's
"decreasing analysis" is not very sophisticated, it is sometimes
necessary to write functions in slightly unnatural ways.
Exercise: 2 stars, optional (decreasing)
To get a concrete sense of this, find a way to write a sensible Fixpoint definition (of a simple function on numbers, say) that does terminate on all inputs, but that Coq will reject because of this restriction.
(* FILL IN HERE *)
☐
More Exercises
Exercise: 2 stars (boolean_functions)
Use the tactics you have learned so far to prove the following theorem about boolean functions.
Theorem identity_fn_applied_twice :
∀ (f : bool → bool),
(∀ (x : bool), f x = x) →
∀ (b : bool), f (f b) = b.
Proof.
(* FILL IN HERE *) Admitted.
∀ (f : bool → bool),
(∀ (x : bool), f x = x) →
∀ (b : bool), f (f b) = b.
Proof.
(* FILL IN HERE *) Admitted.
Now state and prove a theorem in Coq; call it
negation_fn_applied_twice. It should be similar to the previous
one but where the second hypothesis says that the function f has
the property that f x = negb x.
(* FILL IN HERE *)
☐
Exercise: 3 stars, optional (andb_eq_orb)
Prove the following theorem. (Hint: This one can be a bit tricky, depending on how you approach it. You will probably need both destruct and rewrite, but destructing everything in sight is not the best way.)
Theorem andb_eq_orb :
∀ (b c : bool),
(andb b c = orb b c) →
b = c.
Proof.
(* FILL IN HERE *) Admitted.
☐
∀ (b c : bool),
(andb b c = orb b c) →
b = c.
Proof.
(* FILL IN HERE *) Admitted.
Exercise: 3 stars, optional (binary)
Consider a different, more efficient representation of natural numbers using a binary rather than unary system. That is, instead of saying that each natural number is either zero or the successor of a natural number, we can say that each binary number is either- zero,
- twice a binary number, or
- one more than twice a binary number.
Inductive nat : Type := | O : nat | S : nat → nat.
says nothing about what O and S "mean." It just says "O
is in the set called nat, and if n is in the set then so
is S n." The interpretation of O as zero and S as
successor/plus one comes from the way that we use nat
values, by writing functions to do things with them, proving
things about them, and so on. Your definition of bin should
be correspondingly simple; it is the functions you will write
next that will give it mathematical meaning.)
(* FILL IN HERE *)
☐