More about programming with dependent types.

Recall the type of lists in Coq's standard library.

Inductive list (A : Type) : Type := nil : list A | cons : A -> list A -> list A In this definition, we call A a *parameter* of the inductive data type. From this definition it is pretty easy to write a function that returns an element from the list. We have to return an option because we could ask for an element off the end of the list.

QUESTION: Can we implement the function if it is total, i.e. has the following type? forall (T : Type) (ls : list T) (n : nat), T. If so, construct it, otherwise, prove that it is impossible to construct in Coq. ADVANCED QUESTION: What is the difference between the above definition and the following alternative definition?

It is subtle since we can prove that they are "equal". Hint: Take a look at the proof in little more detail. Why does Coq need to distinguish the two definitions?

Theorem force_unfold_nth_error' {T} ls n :
   @nth_error' T ls n =
   match ls with
     | nil => None
     | l :: ls' => match n with
                     | 0 => Some l
                     | S n' => nth_error' ls' n'
                   end
   end.
 destruct n; simpl. reflexivity.
Qed.

Goal forall ls x, @nth_error' nat ls x = None.
    intros.
    rewrite force_unfold_nth_error'.
    Show Proof.
    rewrite (force_unfold_nth_error' ls' n').
    unfold nth_error'.

It is pretty easy to use nth_error:

Using Proofs

---

A lot of times we know that nth_error is going to return success or failure. In that case we might want to just get the result instead of being forced to match on the option and do something in the case that we get None. Let's take a look at another definition.

Now, this function is total but we do not get an answer back until we provide a proof.

Here, we cannot construct a proof so we'll never be able to "get an answer out". NOTE: The plumbing of proofs here actually makes the implementation quadratic since we have to construct a new proof every time we make the recursive call.

Encoding Facts in Dependent Types

---

Passing the explicit proof is a little bit cumbersome. An alternative approach is to combine the proof and the index argument using dependent types. To do this, we'll make a type for "numbers up to some max"

Because nat occurs to the right hand side of the ":", it is called a type index and it is allowed to vary between different constructors of the inductive type

This number is similar to the less-than proof that we passed to nth_and_i_know.

Inductive le (n : nat) : nat -> Prop :=
    le_n : le n n | le_S : forall m : nat, le n m -> le n (S m)
Set Printing Notations.

Both types capture the difference between two natural numbers. Now let's try to use this type to implement nth_and_i_know without the extra proof argument. Doing this is going to require some 'dependent typing'-fu. Let's review the 6 pieces to dependent pattern matching:

     match (1) in (2) as (3) return (4) with
       | (5) => (6)
     end

• (1) Is the discriminee, it is the object that we are inspecting
• (2) The in clause allows us to remember aspects about its type. The in clause only matches indices; parameters are not necessary since they are the same in all constructors
• (3) The as clause allows us to remember aspects of its *value*
• (4) The return clause allows us to use the information from (2) and (3) to describe the result type
• (5) The pattern tells us what the different cases are
• (6) The branch tells us what to do in each case
  The power of dependent pattern matching is based on a simple idea of the 'inside' type versus the 'outside' type.
• The entire expression has the 'outside' type which is computed by determining the type of the discriminee and patterning it in the 'in' clause and the value and substituting it in the 'return' clause
• Each branch is typed using the 'inside' type which is computed from the pattern.

First, let's prove that if you have a fin 0 then you can prove anything.

inversion 1 would solve this but let's see if we can write it using a dependent pattern match. inversion 1.

Now we can continue with the implementation of nth_fin.

We can still run our program like we expect.

Note that there is no way to get something that is not in the list.

---

Enriching Types with Properties

---

In the above implementation, we still needed to talk about the length of the list by explicitly calling the length function. An alternative way is to use dependent types to express the type 'lists with a given length'. Traditionally, length-indexed lists are called vectors.

Let's define some more notation.

Now we can get the element by a relatively simple modification of nth_fin.

... and it works.

ASIDE: In the above code we started with a simple data type, e.g. nat and list, and enriched it to express a particular property, e.g. boundedness in fin and length in vector. This is the general idea of ornamentation, which is described by Conor McBride in another proof assistant called Epigram (now integrated with Agda). You can read more about it here: https://personal.cis.strath.ac.uk/conor.mcbride/pub/OAAO/Ornament.pdf But fair warning, it is a pretty dense read.

Heterogeneous Lists **

---

Sometimes you want to have a list that includes elements with different data types. For example, if you have a programming language that includes variables with both numbers and booleans, you will need your variable environment to contain both numbers and boolean values. We cannot do this with simple lists, but we can build a data type that stores elements of different types. QUESTION: What can we index our data type by to solve this problem?

An alternative implementation of this data type is as a function

QUESTIONs:

• What is the practical difference between these two types?
• Why might we prefer one or the other?

The implementation of head and tail are pretty easy for hlist'

Implementing these functions for hlist, however, requires a little bit of dependent pattern-matching-fu.

It takes a little bit more work to describe the type of projecting an arbitrary element from a heterogeneous list. QUESTION: How can we do this? One option is to use fin and nth_fin:

That one turns out to be a little bit more complicated than is reasonable to do, though kudos to you if you come up with an axiom-free solution. The key difficulty in the previous proof is that we have to reason about length, which has great computational properties, but bad matching properties. It turns out that we can dramatically simplify the function by enriching fin with a little bit of extra information.

Conveniently (but actually by design), this type is indexed by the same thing as hlist. Which drastically simplifies our lives. This type not only states that the 'index' is within bounds, but also states what the precise value at that index is. What is the benefit of that? We do not have to reason about the nth_fin function anymore! With this in mind, let's take another crack at hlist_nth.

Here, the pattern is apparent, make the recursive call outside of the match and pass the values in so they are refined outside-in in the dependent match.

A Multi-sorted Language

---

Using heterogeneous lists we can construct the type of environments for programs with multiple types. Let's take a look at a simplely typed language that uses dependent types to track a multi-sorted environment.

Constants of any type

Conditional expressions

Variables are references into the environment

LetIn extends the type environment used for the in clause using the type of let

Function application

Function construction

With our knowledge about dependent types, we can fairly easily write an interpreter for the above language. Note that since the syntax is guaranteed to be well-typed, our denotation function can be total.

Unfortunately, there are not a lot of other functions that we can write to manipulate our syntax. For example, we can't even write a function to decide equality of exprs. * The problem is that our functions cannot inspect the Types that are embedded inside of expressions.

Computational Reflection

---

With a representation that is completely computational we can do a lot of interesting things, for example of extensible computational reflection, see: https://github.com/gmalecha/mirror-core or http://www.people.fas.harvard.edu/~gmalecha/pub/ccr-itp14.pdf The basic idea is the following. Let's say that we want to reason about the Evenness of natural numbers.

Now if we have a constant that we want to prove is Even (or Odd) we can simply use the constructors.

But if we get a big number then we end up with a big proof.

But this is a pretty easy problem to solve by computation. Let's see if we can do something a little bit more efficient.

Now we can use computation to find the proof for us.

But things are still pretty slow. Note that the refine is the slow part, checking the proof is very fast. But, with the appropriate abstraction, we can make things pretty fast.

Here, vm_compute is running our Coq-code more efficiently using some compilation techniques. What does the proof look like?

hmmm... that doesn't look like it is made up of EO, ES, and OS. But it turns out that it is.

It turns out, however, that we can do even better. Can you spot where the inefficiency of even_or_odd comes from? Hint: Do we ever construct something that we don't need? If we avoid constructing the proof object, then we can make things go even faster. Let's take a look. The computational part of the type sumbool (represented with the { _ } + { _ } notation) is just a bool. So, we'll just compute that.

Now, we have to separately prove the procedure sound. The proof requires a stronger inductive hypothesis.

Now how do we do?

Just a little bit better. The more computation we have, the better an improvement we get.

Time (apply (Even_by_refl 4092); vm_compute; reflexivity). vs