Lecture 03

Include some useful libraries.

List provides the cons notation "::": x :: xs is the same as cons x xs

List provides the append notation "++": xs ++ ys is the same as app xs ys

Prop is the type we give to propositions. Prop basically works the same as Type. In fact, its type is Type:

Prop
     : Type

The difference is that Coq ensures our programs never depend on inputs whose type is in Prop. This helps when we extract programs: we can ensure that all Prop-related computations are only done at compile time and that our extracted programs never compute over data whose type is in Prop. myTrue is a proposition. It has a single constructor, I, which takes no arguments. This means we can always produce a value of type myTrue by just using the I constructor. In Coq, we say that a proposition P is true if we can produce some term t that has type P. That is, P is true if there exists t : P.

We use the constructor tactic to ask Coq to find a constructor that satisfies the goal.

Alternatively, we could have explicitly told Coq exactly which constructor to use with:

        exact I.

myFalse is also a proposition. It has ZERO constructors. That means there is no way to produce a value of type myFalse. Since a proposition P is true only when we can produce a value of type P, we know that myFalse is in fact false.

Given a proof of myFalse, we can prove anything.

Inversion performs case analysis on a hypothesis. Suppose our goal is G and we ask Coq to do inversion on hypothesis H : T. For each constructor C of T that could have produced H, we get a new subgoal requiring us to prove G under the assumption that H = C x1 x2 ... for some arguments x1 x2 ... to C. Often it will be the case that some constructors of T could not have produced H. Coq will automatically dispatch those subgoals for us which greatly simplifies proofs. This is the primary difference between destruct and inversion. For False (the builtin equivalent to myFalse), there are 0 constructors, so when we perform inversion, we end up with 0 subgoals and the proof is done!

When we write a definition using "Lemma" or "Theorem", what we're actually doing is giving a type T and then using tactics to construct a term of type T. So far, we generally only do this for types whose type is in Prop, but we can do it for "normal" types too:

exact (list nat). exact nat.

Having a contradiction in a hypothesis will let us prove any goal.

discriminate is a tactic that looks for mismatching constructors in a hypothesis and uses that contradiction to prove any goal. It is a less-general version of the congruence tactic we saw in lecture last time. In Coq, there are often many tactics that can solve a particular goal. Sometimes we will use a less general tactic because it can help a reader understand our proof and will usually be faster. Under the hood, 1 looks like S 0 and 2 looks like S (S 0). discriminate will peel off one S, to get 0 = S 0. Since 0 and S are different constructors of an inductive type (where all constructors are distinct) they are not equal, and Coq can use the contradiction to complete our proof.

Note that even equality is defined, not builtin.

Here's yo, another definition of an empty type.

We will have to do a little more work to show that yo is empty though.

well, that didn't work

but that did!

Negation in Coq is encoded in the not type. It sort of works like our yoyo proof above.

Expression Syntax

Use String and Z notations.

Now let's build a programming language. We can define the syntax of a language as an inductive datatype.

constant expressions, like 3 or 0

program variables, like "x" or "foo"

adding expressions, e1 + e2

multiplying expressions, e1 * e2

comparing expressions, e1 <= e2

On paper, we would typically write this type down using a "BNF grammar" as:

    expr ::= Z
          |  Var
          |  expr + expr
          |  expr * expr
          |  expr <= expr

Coq provides mechanisms to define your own notation which we can use to get "concrete syntax". Feel free to ignore most of this, especially the "level" and "associativity" stuff.

Parsing is a classic CS topic, but won't say much more about it in this course. Parsing is still a rich and active research topic, and there are many decent tools out there to help practioners build good parsers. Note that all we've done so far is define the syntax of expressions in our language. We have said NOTHING about what these expressions mean. In upcoming lectures we will spend some time studying how we can describe the meanings of programs by giving semantics for our programming languages. To make this clear, note that operations like addition and multiplication are NOT commutative in syntax. They will only be commutative in the meaning of expressions later.

The specialize tactic gives concrete arguments to a forall quantified hypothesis.

inversion is smart

Although we have not yet defined what programs mean, we can write some functions to analyze their syntax. Here we simply count the number of Eint subexpressions in a given expression.

same as S O

same as O

same as plus (nconsts e1) (nconsts e2)

We can also use existential quantifiers in Coq. To prove an existential, you must provide a witness, that is, a concrete example of the type you're existentially quantifying.

Here we give a concrete example.

Now we have to show that the example satisfies the property

Compute the size of an expression.

Notice how we grouped similar cases together in the definition of esize. This is just sugar, you can see the full definition with:

esize = 
fix esize (e : expr) : nat :=
  match e with
  | Eint _ => 1%nat
  | Evar _ => 1%nat
  | e1 [+] e2 => (esize e1 + esize e2)%nat
  | e1 [*] e2 => (esize e1 + esize e2)%nat
  | e1 [<=] e2 => (esize e1 + esize e2)%nat
  end
     : expr -> nat

We can use our analyses to prove properties of the syntax of programs. For example, always have at least as many nodes in the AST as constants.

The auto tactic will solve many simple goals, including those that reflexivity would solve. auto also has the property that it will never fail. If it cannot solve your goal, then it just does nothing. This will be particularly useful when we start chaining together sequences of tactics to operate simultaneously over multiple subgoals.

The omega will solve many arithemetic goals. Unlike auto, omega will fail if it cannot solve your goal.

that proof had a lot of copy-pasta :(

Here we see our first "tactic combinator", the powerful semicolon ";". For any tactics a and b, a; b runs a on the goal and then runs b on all of the subgoals generate by a. We can chain tactics toghether in this way to make shorter, more automated proofs. In the case of this lemma, we'd like to:

     do induction, then
     on every resulting subgoal do simpl, then
     on every resulting subgoal do auto, then
     on every resulting subgoal do omega

Note that after the auto, only the Eadd, Emul, and Elte subgoals remain, but it's hard to tell since the proof does not "pause".

Notice how sometime we have to use the scope specifier "

This generates a lot of output. In this file we really only care about the nat and Z entries:

    "x <= y" := Z.le x y : Z_scope (default interpretation)
    "n <= m" := le n m   : nat_scope

We can also print the definition of le:

Inductive le (n : nat) : nat -> Prop :=
  | le_n : (n <= n)%nat
  | le_S : forall m : nat,
             (n <= m)%nat -> (n <= S m)%nat

le is a relation defined as an "inductive predicate". We give rules for when the relation holds: (1) all nats are less than or equal to themselves and (2) if n <= m, then also n <= S m. All proofs of le are built up from just these two constructors! We can define our own relations to encode properties of expressions. In the has_const inductive predicate below, each constructor corresponds to one way you could prove that an expression has a constant.

Similarly, we can define a relation that holds on expressions that contain a variable.

We can also write boolean functions that check the same properties. Note that orb is disjuction over booleans:

We can write that a little more compactly using the "||" notation for orb provided by the Bool library.

That looks way easier! However, as the quarter progresses, we'll see that sometime defining a property as an inductive relation is more convenient. We can prove that our relational and functional versions agree. This shows that the hasConst function is COMPLETE with respect to the relation has_const. Thus, anything that satisfies the relation evaluates to "true" under the function hasConst.

uh oh, trying to prove something false! it's OK though because we have a bogus hyp!

inversion lets us do case analysis on how a hypothesis of an inductive type may have been built. In this case, there is no way to build a value of type "has_const (Var s)", so we complete the proof of this subgoal for all zero ways of building such a value

here we use inversion to consider how a value of type "has_const (Add e1 e2)" could have been built

built with hc_add_l

subst rewrites all equalities it can

remember notation "||" is same as orb

built with hc_add_r

use fact that orb is commutative

you can find this by turning on auto completion or using a search query

Mul case is similar

Lte case is similar

Now for the other direction. Here we'll prove that the hasConst function is SOUND with respect to the relation. That is, if hasConst produces true, then there is some proof of the inductive relation has_const.

we can prove this case with a constructor

this uses hc_const

Uh oh, no constructor for has_const can possibly produce a value of our goal type! It's OK though because we have a bogus hypothesis.

now do Add case

either e1 or e2 had a Const

consider cases for H

e1 had a Const

e2 had a Const

Mul case is similar

constructor will just use hc_mul_l

constructor will screw up and try hc_mul_l again! constructor is rather dim

OOPS!

Lte case is similar

we can stitch these two lemmas together

• >

<-

Notice all that work was only for the "true" cases! We can prove analogous facts for the "false" cases too. Here we will prove the "false" cases directly. However, note that you could use has_const_iff_hasConst to get a much simpler proof.

uh oh, trying to prove something bogus better exploit a bogus hypothesis

proof by contradiction

prove conjunction by proving left and right

Mul case is similar

Lte case is similar

Here is a more direct proof based on the iff we proved for the true case.

do case analysis on hasConst e eqn:? remembers the result in a hypothesis

now we have hasConst e = true in our hypothesis We have a contradiction in our hypotheses discriminate won't work this time though

For the other case, this is easy

Now the other direction of the false case

crunch down everything in subgoals

get both proofs out of a conjunction by destructing it

case analysis on H0 DISCUSS: how do we know to do this?

auto will chain things for us

Mul case similar

Lte case similar

Since we've proven the iff for the true case We can use it to prove the false case This is the same lemma as above, but using our previous results

~ X is just X -> False

We can also do all the same sorts of proofs for has_var and hasVar

TODO: try this without copying from above

TODO: try this without copying from above

TODO: try this without copying from above

we can also prove things about expressions

prove left side of disjunction

prove right side of disjunction

case analysis on IHe1

Mul case similar

Cmp case similar

we could have gotten some of the has_const lemmas by being a little clever! (but then we wouldn't have learned as many tactics ;) )

or even better

NOTE: we got another subgoal!

In general: Relational defns are nice when you want to use inversion. Functional defns are nice when you want to use simpl.