# A hands-on introduction to cubicaltt

Some months ago I gave a series of hands-on lectures on cubicaltt at Inria Sophia Antipolis that can be found at:

https://github.com/mortberg/cubicaltt/tree/master/lectures

The lectures cover the main features of the system and don’t assume any prior knowledge of Homotopy Type Theory or Univalent Foundations. Only basic familiarity with type theory and proof assistants based on type theory is assumed. The lectures are in the form of cubicaltt files and can be loaded in the cubicaltt proof assistant.

cubicaltt is based on a novel type theory called Cubical Type Theory that provides new ways to reason about equality. Most notably it makes various extensionality principles, like function extensionality and Voevodsky’s univalence axiom, into theorems instead of axioms. This is done such that these principles have computational content and in particular that we can transport structures between equivalent types and that these transports compute. This is different from when one postulates the univalence axiom in a proof assistant like Coq or Agda. If one just adds an axiom there is no way for Coq or Agda to know how it should compute and one looses the good computational properties of type theory. In particular canonicity no longer holds and one can produce terms that are stuck (e.g. booleans that are neither true nor false but don’t reduce further). In other words this is like having a programming language in which one doesn’t know how to run the programs. So cubicaltt provides an operational semantics for Homotopy Type Theory and Univalent Foundations by giving a computational justification for the univalence axiom and (some) higher inductive types.

Cubical Type Theory has a model in cubical sets with lots of structure (symmetries, connections, diagonals) and is hence consistent. Furthermore, Simon Huber has proved that Cubical Type Theory satisfies canonicity for natural numbers which gives a syntactic proof of consistency. Many of the features of the type theory are very inspired by the model, but for more syntactically minded people I believe that it is definitely possible to use cubicaltt without knowing anything about the model. The lecture notes are hence written with almost no references to the model.

The cubicaltt system is based on Mini-TT:

```"A simple type-theoretic language: Mini-TT" (2009)
Thierry Coquand, Yoshiki Kinoshita, Bengt Nordström and Makoto Takeya
In "From Semantics to Computer Science; Essays in Honour of Gilles Kahn"```

Mini-TT is a variant Martin-Löf type theory with datatypes and cubicaltt extends Mini-TT with:

1. Path types
2. Compositions
3. Glue types
4. Id types
5. Some higher inductive types

The lectures cover the first 3 of these and hence correspond to sections 2-7 of:

```"Cubical Type Theory: a constructive interpretation of the univalence axiom"
Cyril Cohen, Thierry Coquand, Simon Huber and Anders Mörtberg
To appear in post-proceedings of TYPES 2016
https://arxiv.org/abs/1611.02108```

I should say that cubicaltt is mainly meant to be a prototype implementation of Cubical Type Theory in which we can do experiments, however it was never our goal to implement a competitor to any of the more established proof assistants. Because of this there are no implicit arguments, type classes, proper universe management, termination checker, etc… Proofs in cubicaltt hence tend to get quite verbose, but it is definitely possible to do some fun things. See for example:

• binnat.ctt – Binary natural numbers and isomorphism to unary numbers. Example of data and program refinement by doing a proof for unary numbers by computation with binary numbers.
• setquot.ctt – Formalization of impredicative set quotients á la Voevodsky.
• hz.ctt defined as an (impredicative set) quotient of `nat * nat`.
• category.ctt – Categories. Structure identity principle. Pullbacks. (Due to Rafaël Bocquet)
• csystem.ctt – Definition of C-systems and universe categories. Construction of a C-system from a universe category. (Due to Rafaël Bocquet)

For a complete list of all the examples see:

https://github.com/mortberg/cubicaltt/tree/master/examples

For those who cannot live without implicit arguments and other features of modern proof assistants there is now an experimental cubical mode shipped with the master branch of Agda. For installation instructions and examples see:

In this post I will give some examples of the main features of cubicaltt, but for a more comprehensive introduction see the lecture notes. As cubicaltt is an experimental prototype things can (and probably will) change in the future (e.g. see the paragraph on HITs below).

## The basic type theory

The basic type theory on which cubicaltt is based has Π and ∑ types (with eta and surjective pairing), a universe `U`, datatypes, recursive definitions and mutually recursive definitions (in particular inductive-recursive definitions). Note that general datatypes and (mutually recursive) definitions are not part of the version of Cubical Type Theory in the paper.

Below is an example of how natural numbers and addition are defined:

```data nat = zero
| suc (n : nat)

add (m : nat) : nat -> nat = split
zero -> m
suc n -> suc (add m n)
```

If one loads this in the cubicaltt read-eval-print-loop one can compute things:

```> add (suc zero) (suc zero)
EVAL: suc (suc zero)
```

## Path types

The homotopical interpretation of equality tells us that we can think of an equality proof between a and b in a type A as a path between a and b in a space A. cubicaltt takes this literally and adds a primitive Path type that should be thought of as a function out of an abstract interval with fixed endpoints.

We call the elements of the interval names/directions/dimensions and typically use i, j, k to denote them. The elements of the interval are generated by the following grammar (where dim is a dimension like i, j, k…):

```r,s := 0
| 1
| dim
| - r
| r /\ s
| r \/ s```

The endpoints are `0` and `1`, – corresponds to symmetry (r in is mapped to `1-r`), while `/\` and `\/` are so called “connections”. The connections can be thought of mapping r and s in to `min(r,s)` and `max(r,s)` respectively. As Path types behave like functions out of the interval there is both path abstraction and application (just like for function types). Reflexivity is written:

```refl (A : U) (a : A) : Path A a a = <i> a
```

and corresponds to a constant path:

```        <i> a
a -----------> a
```

with the intuition is that `<i> a` is a function `\(i : ) -> a`. However for deep reasons the interval isn’t a type (as it isn’t fibrant) so we cannot write functions out of it directly and hence we have this special notation for path abstraction.

If we have a path from a to b then we can compute its left end-point by applying it to `0`:

```face0 (A : U) (a b : A) (p : Path A a b) : A = p @ 0
```

This is of course convertible to `a`. We can also reverse a path by using symmetry:

```sym (A : U) (a b : A) (p : Path A a b) : Path A b a =
<i> p @ -i
```

Assuming that some arguments could be made implicit this satisfies the equality

```sym (sym p) == p
```

judgmentally. This is one of many examples of equalities that hold judgmentally in cubicaltt but not in standard type theory where sym would be defined by induction on p. This is useful for formalizing mathematics, for example we get the judgmental equality `C^op^op == C` for a category `C` that cannot be obtained in standard type theory with the usual definition of category without using any tricks (see opposite.ctt for a formal proof of this).

We can also directly define `cong` (or `ap` or `mapOnPath`):

```cong (A B : U) (f : A -> B) (a b : A) (p : Path A a b) :
Path B (f a) (f b) = <i> f (p @ i)
```

Once again this satisfies some equations judgmentally that we don’t get in standard type theory where this would have been defined by induction on p:

```cong id p == p
cong g (cong f p) == cong (g o f) p
```

Finally the connections can be used to construct higher dimensional cubes from lower dimensional ones (e.g. squares from lines). If `p : Path A a b` then ` <i j> p @ i /\ j` is the interior of the square:

```                  p
a -----------------> b
^                    ^
|                    |
|                    |
<j> a |                    | p
|                    |
|                    |
|                    |
a -----------------> a
<i> a
```

Here i corresponds to the left-to-right dimension and j corresponds to the down-to-up dimension. To compute the left and right sides just plug in `i=0` and `i=1` in the term inside the square:

```<j> p @ 0 /\ j = <j> p @ 0 = <j> a   (p is a path from a to b)
<j> p @ 1 /\ j = <j> p @ j = p       (using eta for Path types)
```

These give a short proof of contractibility of singletons (i.e. that the type `(x : A) * Path A a x` is contractible for all `a : A`), for details see the lecture notes or the paper. Because connections allow us to build higher dimensional cubes from lower dimensional ones they are extremely useful for reasoning about higher dimensional equality proofs.

Another cool thing with Path types is that they allow us to give a direct proof of function extensionality by just swapping the path and lambda abstractions:

```funExt (A B : U) (f g : A -> B)
(p : (x : A) -> Path B (f x) (g x)) :
Path (A -> B) f g = <i> \(a : A) -> (p a) @ i
```

To see that this makes sense we can compute the end-points:

````(<i> \(a : A) -> (p a) @ i) @ 0 = \(a : A) -> (p a) @ 0`
`                               = \(a : A) -> f a`
`                               = f````

and similarly for the right end-point. Note that the last equality follows from eta for Π types.

We have now seen that Path types allows us to define the constants of HoTT (like `cong` or `funExt`), but when doing proofs with Path types one rarely uses these constants explicitly. Instead one can directly prove things with the Path type primitives, for example the proof of function extensionality for dependent functions is exactly the same as the one for non-dependent functions above.

We cannot yet prove the principle of path induction (or `J`) with what we have seen so far. In order to do this we need to be able to turn any path between types A and B into a function from A to B, in other words we need to be able to define `transport` (or `cast` or `coe`):

```transport : Path U A B -> A -> B
```

## Composition, filling and transport

The computation rules for the transport operation in cubicaltt is introduced by recursion on the type one is transporting in. This is quite different from traditional type theory where the identity type is introduced as an inductive family with one constructor (`refl`). A difficulty with this approach is that in order to be able to define transport in a Path type we need to keep track of the end-points of the Path type we are transporting in. To solve this we introduce a more general operation called composition.

Composition can be used to define the composition of paths (hence the name). Given paths `p : Path A a b` and `q : Path A b c` the composite is obtained by computing the missing top line of this open square:

```        a                   c
^                   ^
|                   |
|                   |
<j> a |                   | q
|                   |
|                   |
|                   |
a ----------------> b
p @ i
```

In the drawing I’m assuming that we have a direction `i : ` in context that goes left-to-right and that the j goes down-to-up (but it’s not in context, rather it’s implicitly bound by the comp operation). As we are constructing a Path from a to c we can use the i and put `p @ i` as bottom. The code for this is as follows:

```compPath (A : U) (a b c : A)
(p : Path A a b) (q : Path A b c) : Path A a c =
<i> comp (<_> A) (p @ i)
[ (i = 0) -> <j> a
, (i = 1) -> q ]
```

One way to summarize what compositions gives us is the so called “box principle” that says that “any open box has a lid”. Here “box” means (n+1)-dimensional cube and the lid is an n-dimensional cube. The comp operation takes as second argument the bottom of the box and then a list of sides. Note that the collection of sides doesn’t have to be exhaustive (as opposed to the original cubical set model) and one way to think about the sides is as a collection of constraints that the resulting lid has to satisfy. The first argument of comp is a path between types, in the above example this path is constant but it doesn’t have to be. This is what allows us to define transport:

```transport (A B : U) (p : Path U A B) (a : A) : B =
comp p a []
```

Combining this with the contractibility of singletons we can easily prove the elimination principle for Path types. However the computation rule does not hold judgmentally. This is often not too much of a problem in practice as the Path types satisfy various judgmental equalities that normal Id types don’t. Also, having the possibility to reason about higher equalities directly using path types and compositions is often very convenient and leads to very nice and new ways to construct proofs about higher equalities in a geometric way by directly reasoning about higher dimensional cubes.

The composition operations are related to the filling operations (as in Kan simplicial sets) in the sense that the filling operations takes an open box and computes a filler with the composition as one of its faces. One of the great things about cubical sets with connections is that we can reduce the filling of an open box to its composition. This is a difference compared to the original cubical set model and it provides a significant simplification as we only have to explain how to do compositions in open boxes and not also how to fill them.

## Glue types and univalence

The final main ingredient of cubicaltt are the Glue types. These are what allows us to have a direct algorithm for composition in the universe and to prove the univalence axiom. These types add the possibility to glue types along equivalences (i.e. maps with contractible fibers) onto another type. In particular this allows us to directly define one of the key ingredients of the univalence axiom:

```ua (A B : U) (e : equiv A B) : Path U A B =
<i> Glue B [ (i = 0) -> (A,e)
, (i = 1) -> (B,idEquiv B) ]
```

This corresponds to the missing line at the top of:

```        A           B
|           |
e |           | idEquiv B
|           |
V           V
B --------> B
B
```

The sides of this square are equivalences while the bottom and top are lines in direction i (so this produces a path from A to B as desired).

We have formalized three proofs of the univalence axiom in cubicaltt:

1. A very direct proof due to Simon Huber and me using higher dimensional glueing.
2. The more conceptual proof from section 7.2 of the paper in which we show that the `unglue` function is an equivalence (formalized by Fabian Ruch).
3. A proof from `ua` and its computation rule (`uabeta`). Both of these constants are easy to define and are sufficient for the full univalence axiom as noted in a post by Dan Licata on the HoTT google group.

All of these proofs can be found in the file univalence.ctt and are explained in the paper (proofs 1 and 3 are in Appendix B).

Note that one often doesn’t need full univalence to do interesting things. So just like for Path types it’s often easier to just use the Glue primitives directly instead of invoking the full univalence axiom. For instance if we have proved that negation is an involution for bool we can directly get a non-trivial path from bool to bool using ua (which is just a Glue):

```notEq : Path U bool bool = ua boob bool notEquiv
```

And we can use this non-trivial equality to transport true and compute the result:

```> transport notEq true
EVAL: false
```

This is all that the lectures cover, in the rest of this post I will discuss the two extensions of cubicaltt from the paper and their status in cubicaltt.

## Identity types and higher inductive types

As pointed out above the computation rule for Path types doesn’t hold judgmentally. Luckily there is a neat trick due to Andrew Swan that allows us to define a new type that is equivalent to `Path A a b` for which the computation rule holds judgmentally. For details see section 9.1 of the paper. We call this type `Id A a b` as it corresponds to Martin-Löf’s identity type. We have implemented this in cubicaltt and proved the univalence axiom expressed exclusively using Id types, for details see idtypes.ctt.

For practical formalizations it is probably often more convenient to use the Path types directly as they have the nice primitives discussed above, but the fact that we can define Id types is very important from a theoretical point of view as it shows that cubicaltt with Id is really an extension of Martin-Löf type theory. Furthermore as we can prove univalence expressed using Id types we get that any proof in univalent type theory (MLTT extended with the univalence axiom) can be translated into cubicaltt.

The second extension to cubicaltt are HITs. We have a general syntax for adding these and some of them work fine on the master branch, see for example:

• circle.ctt – The circle as a HIT. Computation of winding numbers.
• helix.ctt – The loop space of the circle is equal to Z.
• susp.ctt – Suspension and n-spheres.
• torsor.ctt – Torsors. Proof that S1 is equal to BZ, the classifying
space of Z. (Due to Rafaël Bocquet)
• torus.ctt – Proof that Torus = S1 * S1 in only 100 loc (due to Dan
Licata).

However there are various known issues with how the composition operations compute for recursive HITs (e.g. truncations) and HITs where the end-points contain function applications (e.g. pushouts). We have a very experimental branch that tries to resolve these issues called “hcomptrans”. This branch contains some new (currently undocumented) primitives that we are experimenting with and so far it seems like these are solving the various issues for the above two classes of more complicated HITs that don’t work on the master branch. So hopefully there will soon be a new cubical type theory with support for a large class of HITs.

That’s all I wanted to say about cubicaltt in this post. If someone plays around with the system and proves something cool don’t hesitate to file a pull request or file issues if you find some bugs.