Lecture 02

Infer some type arguments automatically.

Note that the type constructor for functions (arrow "->") associates to the right:

    A -> B -> C = A -> (B -> C)

So far, Coq will not infer the type argument for nil:

Check (cons 1 nil).

Error: The term "nil" has type "forall A : Type, list A"
 while it is expected to have type "list nat".

We can tell Coq to always try though:

countdown is a useful function for testing. countdown n produces the list:

  n :: (n - 1) :: (n - 2) :: .. :: 1 :: 0 :: nil

We can run our countdown function on some example inputs:

     = cons 0 nil
     : list nat

     = cons 3 (cons 2 (cons 1 (cons 0 nil)))
     : list nat

     = cons 10
       (cons 9
        (cons 8
         (cons 7
          (cons 6
           (cons 5 
            (cons 4
             (cons 3
              (cons 2
               (cons 1
                (cons 0 nil))))))))))
     : list nat

map takes a function f and list l and produces a new list by applying f to each element of l. (Note that because Gallina is a pure functional programming language, the original input list is completely unchanged.)

     = cons 4 (cons 3 (cons 2 (cons 1 nil)))
     : list nat

     = cons true (cons true (cons true (cons true nil)))
     : list bool

     = cons false (cons false (cons false (cons true nil)))
     : list bool

     = cons false (cons true (cons false (cons true nil)))
     : list bool

map produces an output list which is exactly the same length as its input list. (Note that this proof uses bullets (+). See the course web page for more info.)

Replace "length (map f l)" with "length l"

To prove properties about all elements of a type, we typically use induction. We do this by proving that the property holds on the "base cases", that is, for nonrecursive constructors. For example, (O : nat) and (nil : list A) are base cases for nat and list respectively. Then, we prove that the property is preserved by each of the recursive constructors, assuming it holds for all the recursive arguments to that constructor. To prove the inductive case for a property P of nats, we need to prove

    forall n, P n -> P (S n)

For lists, we need to prove

    forall l x, P l -> P (cons x l)

Function composition, like from math class.

Mapping two functions one after the other over a list is the same as just mapping their composition over the list.

need to "unfold" compose so simpl can grind

Often we'd like to process a list by "crunching" it down into a single value. foldr does this by taking a function f, a list cons e1 (cons e2 (cons e3 ... (cons eN nil) ...)), and an initial "accumulator" or "state" b and computing:

  f e1 (f e2 (f e3 ... (f eN b) ...))

Again, foldr works by putting a function f in for each cons:

  foldr f (cons 1 (cons 2 (cons 3 nil))) x
  -->
  f 1 (f 2 (f 3 x))

See how foldr replaces cons with f and nil with x. foldr plus sums a list of nats. Let's sum the values from 0 to 10

     = 55
     : nat

Consider our good friend the factorial function:

We can write it slightly differently using foldr:

As an exercise, please prove these two versions of factorial equivalent:

challenge problem

It turns out we can write many list function just in terms of foldr. Here's a definition of map using foldr:

We can prove our "foldr" version of map equivalent to the direct definition:

again, need to unfold so simpl can grind

Note: this proof is very sensitive to the order of rewrite and unfold!

We can also define another flavor of fold, called foldl, that starts applying f to the first element of the list instead of the last. What's the difference? When would you use foldl instead of foldr?

When working with lists, appending one list onto the end of another is very useful. This app function does exactly that. Notice how similar it is to adding nats.

     = cons 1 (cons 2 (cons 3 nil))
     : list nat

This is the analog of our lemma about (n + 0) from Lecture 01, but for appending nil onto a list. Notice how similar the proofs are! We have seen this pattern several times already.

app is associative, meaning we can freely re-associate (move parens around). There's the same proof pattern again!

Sometimes a list is "backward" from the order we would prefer it in. Here is a simple but "inefficient" way to reverse a list.

We say that the version of rev above is "inefficient" because it is not tail recursive. A function is tail recursive when all recursive calls are the final action of the function. You can read more about tail recursion here: https://en.wikipedia.org/wiki/Tail_call Tail recursion is generally faster and leads to less stack space consumption, but it is more complicated and therefore often trickier to reason about. Below we define a tail recursive function to reverse a list. We first define a helper function fast_rev_aux which takes an additional argument acc ("acc" is short for "accumulator"). We "accumulate" the resulting reversed list with each recursive call. Note how fast_rev_aux only calls itself in tail position, i.e., as its result. Tail recursion is typically faster because compilers for functional programming languages often perform tail-call optimization ("TCO"), in which stack frames are re-used by recursive calls.

We can make sure our faster, tail-recursive version of reverse is right by proving it equivalent to the simpler, non-tail-recursive version. However, as we see below, we will not be able to do this directly. We will first need to prove a helper lemma with a stronger induction hypothesis.

reduces rev, but does nothing to rev_fast

unfold fast_rev to fast_rev_aux

now we can simplify the term

TIP: if simpl doesn't work, try unfolding!

this looks like it could be trouble...

STUCK! need to know about the rev_aux accumulator (acc) TIP: if your IH seems weak, try proving something more general

STUCK AGAIN! need to know for *any* l2 TIP: if your IH seems weak, only intro up to the induction variable

Compare the induction hypothesis (IHl1) here with the one we had before. What's different? Why is this called "generalizing" the induction hypothesis?

Note that we can rewrite by IHl1 even though it is universally quantified (i.e., there's a forall). Coq will figure out what to replace l2 with in IHl1 (cons a foo).

With our stronger induction hypothesis from the lemma, we can now prove rev_ok as a special case of rev_aux_ok.

Here we'll stop for an in class exercise!

	                            ~-.
          ,,,;            ~-.~-.~-
         (.../           ~-.~-.~-.~-.~-.
         } o~`,         ~-.~-.~-.~-.~-.~-.
         (/    \      ~-.~-.~-.~-.~-.~-.~-.
          ;    \    ~-.~-.~-.~-.~-.~-.~-.
         ;     {_.~-.~-.~-.~-.~-.~-.~
        ;:  .-~`    ~-.~-.~-.~-.~-.
       ;.: :'    ._   ~-.~-.~-.~-.~-
        ;::`-.    '-._  ~-.~-.~-.~-
         ;::. `-.    '-,~-.~-.~-.
          ';::::.`''-.-'
            ';::;;:,:'
               '||"
               / |
             ~` ~"'

add an element to the end of a list

Another simple but inefficient way to reverse a list

We'll finish off with some example lemmas about rev and length. Note how often the same proof pattern keeps emerging!