List provides the cons notation "::" and the append notation "++".

Prop is the type we give to propositions.

constructor.

apply list. apply nat. exact list. exact (list bool). exact bool.

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.

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

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

weird

Compute the size of an expression.

that proof had a lot of copy-pasta :(

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 (Evar 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 (Eadd 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.