[bitonic-mengthesis.git] / thesis.lagda

\documentclass[report]{article}
\usepackage{etex}

%% Narrow margins
% \usepackage{fullpage}

%% Bibtex
\usepackage{natbib}

%% Links
\usepackage{hyperref}

%% Frames
\usepackage{framed}

%% Symbols
\usepackage[fleqn]{amsmath}
\usepackage{stmaryrd}           %llbracket

%% Proof trees
\usepackage{bussproofs}

%% Diagrams
\usepackage[all]{xy}

%% Quotations
\usepackage{epigraph}

%% Images
\usepackage{graphicx}

%% Subfigure
\usepackage{subcaption}

\usepackage{verbatim}

%% diagrams
\usepackage{tikz}
\usetikzlibrary{shapes,arrows,positioning}
% \usepackage{tikz-cd}
% \usepackage{pgfplots}


%% -----------------------------------------------------------------------------
%% Commands for Agda
\usepackage[english]{babel}
\usepackage[conor]{agda}
\renewcommand{\AgdaKeywordFontStyle}[1]{\ensuremath{\mathrm{\underline{#1}}}}
\renewcommand{\AgdaFunction}[1]{\textbf{\textcolor{AgdaFunction}{#1}}}
\renewcommand{\AgdaField}{\AgdaFunction}
% \definecolor{AgdaBound} {HTML}{000000}
\definecolor{AgdaHole} {HTML} {FFFF33}

\DeclareUnicodeCharacter{9665}{\ensuremath{\lhd}}
\DeclareUnicodeCharacter{964}{\ensuremath{\tau}}
\DeclareUnicodeCharacter{963}{\ensuremath{\sigma}}
\DeclareUnicodeCharacter{915}{\ensuremath{\Gamma}}
\DeclareUnicodeCharacter{8799}{\ensuremath{\stackrel{?}{=}}}
\DeclareUnicodeCharacter{9655}{\ensuremath{\rhd}}

\renewenvironment{code}%
{\noindent\ignorespaces\advance\leftskip\mathindent\AgdaCodeStyle\pboxed}%
{\endpboxed\par\noindent%
\ignorespacesafterend\small}


%% -----------------------------------------------------------------------------
%% Commands

\newcommand{\mysyn}{\AgdaKeyword}
\newcommand{\mytyc}{\AgdaDatatype}
\newcommand{\mydc}{\AgdaInductiveConstructor}
\newcommand{\myfld}{\AgdaField}
\newcommand{\myfun}{\AgdaFunction}
\newcommand{\myb}[1]{\AgdaBound{$#1$}}
\newcommand{\myfield}{\AgdaField}
\newcommand{\myind}{\AgdaIndent}
\newcommand{\mykant}{\textsc{Kant}}
\newcommand{\mysynel}[1]{#1}
\newcommand{\myse}{\mysynel}
\newcommand{\mytmsyn}{\mysynel{term}}
\newcommand{\mysp}{\ }
\newcommand{\myabs}[2]{\mydc{$\lambda$} #1 \mathrel{\mydc{$\mapsto$}} #2}
\newcommand{\myappsp}{\hspace{0.07cm}}
\newcommand{\myapp}[2]{#1 \myappsp #2}
\newcommand{\mysynsep}{\ \ |\ \ }
\newcommand{\myITE}[3]{\myfun{If}\, #1\, \myfun{Then}\, #2\, \myfun{Else}\, #3}

\FrameSep0.2cm
\newcommand{\mydesc}[3]{
  \noindent
  \mbox{
      \vspace{0.1cm}
    \parbox{\textwidth}{
      {\small
        \hfill \textbf{#1} $#2$
        \framebox[\textwidth]{
          \parbox{\textwidth}{
            \vspace{0.1cm}
            \centering{
              #3
            }
            \vspace{0.1cm}
          }
        }
      }
    }
  }
}

\newcommand{\mytmt}{\mysynel{t}}
\newcommand{\mytmm}{\mysynel{m}}
\newcommand{\mytmn}{\mysynel{n}}
\newcommand{\myred}{\leadsto}
\newcommand{\mysub}[3]{#1[#2 / #3]}
\newcommand{\mytysyn}{\mysynel{type}}
\newcommand{\mybasetys}{K}
\newcommand{\mybasety}[1]{B_{#1}}
\newcommand{\mytya}{\myse{A}}
\newcommand{\mytyb}{\myse{B}}
\newcommand{\mytycc}{\myse{C}}
\newcommand{\myarr}{\mathrel{\textcolor{AgdaDatatype}{\to}}}
\newcommand{\myprod}{\mathrel{\textcolor{AgdaDatatype}{\times}}}
\newcommand{\myctx}{\Gamma}
\newcommand{\myvalid}[1]{#1 \vdash \underline{\mathrm{valid}}}
\newcommand{\myjudd}[3]{#1 \vdash #2 : #3}
\newcommand{\myjud}[2]{\myjudd{\myctx}{#1}{#2}}
\newcommand{\myabss}[3]{\mydc{$\lambda$} #1 {:} #2 \mathrel{\mydc{$\mapsto$}} #3}
\newcommand{\mytt}{\mydc{$\langle\rangle$}}
\newcommand{\myunit}{\mytyc{Unit}}
\newcommand{\mypair}[2]{\mathopen{\mydc{$\langle$}}#1\mathpunct{\mydc{,}} #2\mathclose{\mydc{$\rangle$}}}
\newcommand{\myfst}{\myfld{fst}}
\newcommand{\mysnd}{\myfld{snd}}
\newcommand{\myconst}{\myse{c}}
\newcommand{\myemptyctx}{\cdot}
\newcommand{\myhole}{\AgdaHole}
\newcommand{\myfix}[3]{\mysyn{fix} \myappsp #1 {:} #2 \mapsto #3}
\newcommand{\mysum}{\mathbin{\textcolor{AgdaDatatype}{+}}}
\newcommand{\myleft}[1]{\mydc{left}_{#1}}
\newcommand{\myright}[1]{\mydc{right}_{#1}}
\newcommand{\myempty}{\mytyc{Empty}}
\newcommand{\mycase}[2]{\mathopen{\myfun{[}}#1\mathpunct{\myfun{,}} #2 \mathclose{\myfun{]}}}
\newcommand{\myabsurd}[1]{\myfun{absurd}_{#1}}
\newcommand{\myarg}{\_}
\newcommand{\myderivsp}{\vspace{0.3cm}}
\newcommand{\mytyp}{\mytyc{Type}}
\newcommand{\myneg}{\myfun{$\neg$}}
\newcommand{\myar}{\,}
\newcommand{\mybool}{\mytyc{Bool}}
\newcommand{\mytrue}{\mydc{true}}
\newcommand{\myfalse}{\mydc{false}}
\newcommand{\myitee}[5]{\myfun{if}\,#1 / {#2.#3}\,\myfun{then}\,#4\,\myfun{else}\,#5}
\newcommand{\mynat}{\mytyc{$\mathbb{N}$}}
\newcommand{\myrat}{\mytyc{$\mathbb{R}$}}
\newcommand{\myite}[3]{\myfun{if}\,#1\,\myfun{then}\,#2\,\myfun{else}\,#3}
\newcommand{\myfora}[3]{(#1 {:} #2) \myarr #3}
\newcommand{\myexi}[3]{(#1 {:} #2) \myprod #3}
\newcommand{\mypairr}[4]{\mathopen{\mydc{$\langle$}}#1\mathpunct{\mydc{,}} #4\mathclose{\mydc{$\rangle$}}_{#2{.}#3}}
\newcommand{\mylist}{\mytyc{List}}
\newcommand{\mynil}[1]{\mydc{[]}_{#1}}
\newcommand{\mycons}{\mathbin{\mydc{∷}}}
\newcommand{\myfoldr}{\myfun{foldr}}
\newcommand{\myw}[3]{\myapp{\myapp{\mytyc{W}}{(#1 {:} #2)}}{#3}}
\newcommand{\mynodee}{\mathbin{\mydc{$\lhd$}}}
\newcommand{\mynode}[2]{\mynodee_{#1.#2}}
\newcommand{\myrec}[4]{\myfun{rec}\,#1 / {#2.#3}\,\myfun{with}\,#4}
\newcommand{\mylub}{\sqcup}
\newcommand{\mydefeq}{\cong}
\newcommand{\myrefl}{\mydc{refl}}
\newcommand{\mypeq}[1]{\mathrel{\mytyc{=}_{#1}}}
\newcommand{\myjeqq}{\myfun{=-elim}}
\newcommand{\myjeq}[3]{\myapp{\myapp{\myapp{\myjeqq}{#1}}{#2}}{#3}}
\newcommand{\mysubst}{\myfun{subst}}
\newcommand{\myprsyn}{\myse{prop}}
\newcommand{\myprdec}[1]{\mathopen{\mytyc{$\llbracket$}} #1 \mathopen{\mytyc{$\rrbracket$}}}
\newcommand{\myand}{\mathrel{\mytyc{$\wedge$}}}
\newcommand{\myprfora}[3]{\forall #1 {:} #2. #3}
\newcommand{\myimpl}{\mathrel{\mytyc{$\Rightarrow$}}}
\newcommand{\mybot}{\mytyc{$\bot$}}
\newcommand{\mytop}{\mytyc{$\top$}}
\newcommand{\mycoe}{\myfun{coe}}
\newcommand{\mycoee}[4]{\myapp{\myapp{\myapp{\myapp{\mycoe}{#1}}{#2}}{#3}}{#4}}
\newcommand{\mycoh}{\myfun{coh}}
\newcommand{\mycohh}[4]{\myapp{\myapp{\myapp{\myapp{\mycoh}{#1}}{#2}}{#3}}{#4}}
\newcommand{\myjm}[4]{(#1 {:} #2) \mathrel{\mytyc{=}} (#3 {:} #4)}
\newcommand{\myeq}{\mathrel{\mytyc{=}}}
\newcommand{\myprop}{\mytyc{Prop}}
\newcommand{\mytmup}{\mytmsyn\uparrow}
\newcommand{\mydefs}{\Delta}
\newcommand{\mynf}{\Downarrow}
\newcommand{\myinff}[3]{#1 \vdash #2 \Rightarrow #3}
\newcommand{\myinf}[2]{\myinff{\myctx}{#1}{#2}}
\newcommand{\mychkk}[3]{#1 \vdash #2 \Leftarrow #3}
\newcommand{\mychk}[2]{\mychkk{\myctx}{#1}{#2}}
\newcommand{\myann}[2]{#1 : #2}
\newcommand{\mydeclsyn}{\myse{decl}}
\newcommand{\myval}[3]{#1 : #2 \mapsto #3}
\newcommand{\mypost}[2]{\mysyn{abstract}\ #1 : #2}
\newcommand{\myadt}[4]{\mysyn{data}\ #1 #2\ \mysyn{where}\ #3\{ #4 \}}
\newcommand{\myreco}[4]{\mysyn{record}\ #1 #2\ \mysyn{where}\ #3\ \{ #4 \}}
\newcommand{\myelabt}{\vdash}
\newcommand{\myelabf}{\rhd}
\newcommand{\myelab}[2]{\myctx \myelabt #1 \myelabf #2}
\newcommand{\mytele}{\Delta}
\newcommand{\mytelee}{\delta}
\newcommand{\mydcctx}{\Gamma}
\newcommand{\mynamesyn}{\myse{name}}
\newcommand{\myvec}{\overrightarrow}
\newcommand{\mymeta}{\textsc}
\newcommand{\myhyps}{\mymeta{hyps}}
\newcommand{\mycc}{;}
\newcommand{\myemptytele}{\cdot}
\newcommand{\mymetagoes}{\Longrightarrow}
% \newcommand{\mytesctx}{\
\newcommand{\mytelesyn}{\myse{telescope}}
\newcommand{\myrecs}{\mymeta{recs}}
\newcommand{\myle}{\mathrel{\lcfun{$\le$}}}
\newcommand{\mylet}{\mysyn{let}}
\newcommand{\myhead}{\mymeta{head}}
\newcommand{\mytake}{\mymeta{take}}
\newcommand{\myix}{\mymeta{ix}}
\newcommand{\myapply}{\mymeta{apply}}
\newcommand{\mydataty}{\mymeta{datatype}}
\newcommand{\myisreco}{\mymeta{record}}
\newcommand{\mydcsep}{\ |\ }
\newcommand{\mytree}{\mytyc{Tree}}
\newcommand{\myproj}[1]{\myfun{$\pi_{#1}$}}


%% -----------------------------------------------------------------------------

\title{\mykant: Implementing Observational Equality}
\author{Francesco Mazzoli \href{mailto:fm2209@ic.ac.uk}{\nolinkurl{<fm2209@ic.ac.uk>}}}
\date{June 2013}

\begin{document}

\iffalse
\begin{code}
module thesis where
\end{code}
\fi

\maketitle

\begin{minipage}{0.5\textwidth}
  \begin{flushleft} \large
    \emph{Supervisor:}\\
    Dr. Steffen \textsc{van Backel}
  \end{flushleft}
\end{minipage}
\begin{minipage}{0.5\textwidth}
  \begin{flushright} \large
    \emph{Co-marker:} \\
    Dr. Philippa \textsc{Gardner}
  \end{flushright}
\end{minipage}

\clearpage

\begin{abstract}
  The marriage between programming and logic has been a very fertile one.  In
  particular, since the simply typed lambda calculus (STLC), a number of type
  systems have been devised with increasing expressive power.

  Among this systems, Inutitionistic Type Theory (ITT) has been a very
  popular framework for theorem provers and programming languages.
  However, equality has always been a tricky business in ITT and related
  theories.

  In these thesis we will explain why this is the case, and present
  Observational Type Theory (OTT), a solution to some of the problems
  with equality.  We then describe $\mykant$, a theorem prover featuring
  OTT in a setting more close to the one found in current systems.
  Having implemented part of $\mykant$ as a Haskell program, we describe
  some of the implementation issues faced.
\end{abstract}

\clearpage

\renewcommand{\abstractname}{Acknowledgements}
\begin{abstract}
  I would like to thank Steffen van Backel, my supervisor, who was brave
  enough to believe in my project and who provided much advice and
  support.

  I would also like to thank the Haskell and Agda community on
  \texttt{IRC}, which guided me through the strange world of types; and
  in particular Andrea Vezzosi and James Deikun, with whom I entertained
  countless insightful discussions in the past year.  Andrea suggested
  Observational Type Theory as a topic of study: this thesis would not
  exist without him.

  Finally, much of the work stems from the research of Conor McBride,
  who answered many of my doubts through these months.  I also owe him
  the colours.
\end{abstract}

\clearpage

\tableofcontents

\clearpage

\section{Simple and not-so-simple types}
\label{sec:types}

\subsection{The untyped $\lambda$-calculus}

Along with Turing's machines, the earliest attempts to formalise computation
lead to the $\lambda$-calculus \citep{Church1936}.  This early programming
language encodes computation with a minimal syntax and no `data' in the
traditional sense, but just functions.  Here we give a brief overview of the
language, which will give the chance to introduce concepts central to the
analysis of all the following calculi.  The exposition follows the one found in
chapter 5 of \cite{Queinnec2003}.

The syntax of $\lambda$-terms consists of three things: variables, abstractions,
and applications:

\mydesc{syntax}{ }{
  $
  \begin{array}{r@{\ }c@{\ }l}
    \mytmsyn & ::= & \myb{x} \mysynsep \myabs{\myb{x}}{\mytmsyn} \mysynsep (\myapp{\mytmsyn}{\mytmsyn}) \\
    x          & \in & \text{Some enumerable set of symbols}
  \end{array}
  $
}

Parenthesis will be omitted in the usual way:
$\myapp{\myapp{\mytmt}{\mytmm}}{\mytmn} =
\myapp{(\myapp{\mytmt}{\mytmm})}{\mytmn}$.

Abstractions roughly corresponds to functions, and their semantics is more
formally explained by the $\beta$-reduction rule:

\mydesc{reduction:}{\mytmsyn \myred \mytmsyn}{
  $
  \begin{array}{l}
    \myapp{(\myabs{\myb{x}}{\mytmm})}{\mytmn} \myred \mysub{\mytmm}{\myb{x}}{\mytmn}\text{, where} \\
    \myind{1}
    \begin{array}{l@{\ }c@{\ }l}
      \mysub{\myb{x}}{\myb{x}}{\mytmn} & = & \mytmn \\
      \mysub{\myb{y}}{\myb{x}}{\mytmn} & = & y\text{, with } \myb{x} \neq y \\
      \mysub{(\myapp{\mytmt}{\mytmm})}{\myb{x}}{\mytmn} & = & (\myapp{\mysub{\mytmt}{\myb{x}}{\mytmn}}{\mysub{\mytmm}{\myb{x}}{\mytmn}}) \\
      \mysub{(\myabs{\myb{x}}{\mytmm})}{\myb{x}}{\mytmn} & = & \myabs{\myb{x}}{\mytmm} \\
      \mysub{(\myabs{\myb{y}}{\mytmm})}{\myb{x}}{\mytmn} & = & \myabs{\myb{z}}{\mysub{\mysub{\mytmm}{\myb{y}}{\myb{z}}}{\myb{x}}{\mytmn}}, \\
      \multicolumn{3}{l}{\myind{1} \text{with $\myb{x} \neq \myb{y}$ and $\myb{z}$ not free in $\myapp{\mytmm}{\mytmn}$}}
    \end{array}
  \end{array}
  $
}

The care required during substituting variables for terms is required to avoid
name capturing.  We will use substitution in the future for other name-binding
constructs assuming similar precautions.

These few elements are of remarkable expressiveness, and in fact Turing
complete.  As a corollary, we must be able to devise a term that reduces forever
(`loops' in imperative terms):
{\small
\[
  (\myapp{\omega}{\omega}) \myred (\myapp{\omega}{\omega}) \myred \cdots \text{, with $\omega = \myabs{x}{\myapp{x}{x}}$}
\]
}

A \emph{redex} is a term that can be reduced.  In the untyped $\lambda$-calculus
this will be the case for an application in which the first term is an
abstraction, but in general we call aterm reducible if it appears to the left of
a reduction rule.  When a term contains no redexes it's said to be in
\emph{normal form}.  Given the observation above, not all terms reduce to a
normal forms: we call the ones that do \emph{normalising}, and the ones that
don't \emph{non-normalising}.

The reduction rule presented is not syntax directed, but \emph{evaluation
  strategies} can be employed to reduce term systematically. Common evaluation
strategies include \emph{call by value} (or \emph{strict}), where arguments of
abstractions are reduced before being applied to the abstraction; and conversely
\emph{call by name} (or \emph{lazy}), where we reduce only when we need to do so
to proceed---in other words when we have an application where the function is
still not a $\lambda$. In both these reduction strategies we never reduce under
an abstraction: for this reason a weaker form of normalisation is used, where
both abstractions and normal forms are said to be in \emph{weak head normal
  form}.

\subsection{The simply typed $\lambda$-calculus}

A convenient way to `discipline' and reason about $\lambda$-terms is to assign
\emph{types} to them, and then check that the terms that we are forming make
sense given our typing rules \citep{Curry1934}.  The first most basic instance
of this idea takes the name of \emph{simply typed $\lambda$ calculus}, whose
rules are shown in figure \ref{fig:stlc}.

Our types contain a set of \emph{type variables} $\Phi$, which might
correspond to some `primitive' types; and $\myarr$, the type former for
`arrow' types, the types of functions.  The language is explicitly
typed: when we bring a variable into scope with an abstraction, we
declare its type.  Reduction is unchanged from the untyped
$\lambda$-calculus.

\begin{figure}[t]
  \mydesc{syntax}{ }{
    $
    \begin{array}{r@{\ }c@{\ }l}
      \mytmsyn   & ::= & \myb{x} \mysynsep \myabss{\myb{x}}{\mytysyn}{\mytmsyn} \mysynsep
      (\myapp{\mytmsyn}{\mytmsyn}) \\
      \mytysyn   & ::= & \myse{\phi} \mysynsep \mytysyn \myarr \mytysyn  \mysynsep \\
      \myb{x}    & \in & \text{Some enumerable set of symbols} \\
      \myse{\phi} & \in & \Phi
    \end{array}
    $
  }
  
  \mydesc{typing:}{\myjud{\mytmsyn}{\mytysyn}}{
      \begin{tabular}{ccc}
        \AxiomC{$\myctx(x) = A$}
        \UnaryInfC{$\myjud{\myb{x}}{A}$}
        \DisplayProof
        &
        \AxiomC{$\myjudd{\myctx;\myb{x} : A}{\mytmt}{\mytyb}$}
        \UnaryInfC{$\myjud{\myabss{x}{A}{\mytmt}}{\mytyb}$}
        \DisplayProof
        &
        \AxiomC{$\myjud{\mytmm}{\mytya \myarr \mytyb}$}
        \AxiomC{$\myjud{\mytmn}{\mytya}$}
        \BinaryInfC{$\myjud{\myapp{\mytmm}{\mytmn}}{\mytyb}$}
        \DisplayProof
      \end{tabular}
}
  \caption{Syntax and typing rules for the STLC.  Reduction is unchanged from
    the untyped $\lambda$-calculus.}
  \label{fig:stlc}
\end{figure}

In the typing rules, a context $\myctx$ is used to store the types of bound
variables: $\myctx; \myb{x} : \mytya$ adds a variable to the context and
$\myctx(x)$ returns the type of the rightmost occurrence of $x$.

This typing system takes the name of `simply typed lambda calculus' (STLC), and
enjoys a number of properties.  Two of them are expected in most type systems
\citep{Pierce2002}:
\begin{description}
\item[Progress] A well-typed term is not stuck---it is either a variable, or its
  constructor does not appear on the left of the $\myred$ relation (currently
  only $\lambda$), or it can take a step according to the evaluation rules.
\item[Preservation] If a well-typed term takes a step of evaluation, then the
  resulting term is also well-typed, and preserves the previous type.  Also
  known as \emph{subject reduction}.
\end{description}

However, STLC buys us much more: every well-typed term is normalising
\citep{Tait1967}.  It is easy to see that we can't fill the blanks if we want to
give types to the non-normalising term shown before:
\begin{equation*}
  \myapp{(\myabss{\myb{x}}{\myhole{?}}{\myapp{\myb{x}}{\myb{x}}})}{(\myabss{\myb{x}}{\myhole{?}}{\myapp{\myb{x}}{\myb{x}}})}
\end{equation*}

This makes the STLC Turing incomplete.  We can recover the ability to loop by
adding a combinator that recurses:

\noindent
\begin{minipage}{0.5\textwidth}
\mydesc{syntax}{ } {
  $ \mytmsyn ::= \cdots b \mysynsep \myfix{\myb{x}}{\mytysyn}{\mytmsyn} $
  \vspace{0.4cm}
}
\end{minipage} 
\begin{minipage}{0.5\textwidth}
\mydesc{typing:}{\myjud{\mytmsyn}{\mytysyn}} {
    \AxiomC{$\myjudd{\myctx; \myb{x} : \mytya}{\mytmt}{\mytya}$}
    \UnaryInfC{$\myjud{\myfix{\myb{x}}{\mytya}{\mytmt}}{\mytya}$}
    \DisplayProof
}
\end{minipage} 

\mydesc{reduction:}{\myjud{\mytmsyn}{\mytmsyn}}{
    $ \myfix{\myb{x}}{\mytya}{\mytmt} \myred \mysub{\mytmt}{\myb{x}}{(\myfix{\myb{x}}{\mytya}{\mytmt})}$
}

This will deprive us of normalisation, which is a particularly bad thing if we
want to use the STLC as described in the next section.

\subsection{The Curry-Howard correspondence}

It turns out that the STLC can be seen a natural deduction system for
intuitionistic propositional logic.  Terms are proofs, and their types are the
propositions they prove.  This remarkable fact is known as the Curry-Howard
correspondence, or isomorphism.

The arrow ($\myarr$) type corresponds to implication.  If we wish to prove that
that $(\mytya \myarr \mytyb) \myarr (\mytyb \myarr \mytycc) \myarr (\mytya
\myarr \mytycc)$, all we need to do is to devise a $\lambda$-term that has the
correct type:
{\small\[
  \myabss{\myb{f}}{(\mytya \myarr \mytyb)}{\myabss{\myb{g}}{(\mytyb \myarr \mytycc)}{\myabss{\myb{x}}{\mytya}{\myapp{\myb{g}}{(\myapp{\myb{f}}{\myb{x}})}}}}
\]}
That is, function composition.  Going beyond arrow types, we can extend our bare
lambda calculus with useful types to represent other logical constructs, as
shown in figure \ref{fig:natded}.

\begin{figure}[t]
\mydesc{syntax}{ }{
  $
  \begin{array}{r@{\ }c@{\ }l}
    \mytmsyn & ::= & \cdots \\
             &  |  & \mytt \mysynsep \myapp{\myabsurd{\mytysyn}}{\mytmsyn} \\
             &  |  & \myapp{\myleft{\mytysyn}}{\mytmsyn} \mysynsep
                     \myapp{\myright{\mytysyn}}{\mytmsyn} \mysynsep
                     \myapp{\mycase{\mytmsyn}{\mytmsyn}}{\mytmsyn} \\
             &  |  & \mypair{\mytmsyn}{\mytmsyn} \mysynsep
                     \myapp{\myfst}{\mytmsyn} \mysynsep \myapp{\mysnd}{\mytmsyn} \\
    \mytysyn & ::= & \cdots \mysynsep \myunit \mysynsep \myempty \mysynsep \mytmsyn \mysum \mytmsyn \mysynsep \mytysyn \myprod \mytysyn
  \end{array}
  $
}

\mydesc{reduction:}{\mytmsyn \myred \mytmsyn}{
    \begin{tabular}{cc}
      $
      \begin{array}{l@{ }l@{\ }c@{\ }l}
        \myapp{\mycase{\mytmm}{\mytmn}}{(\myapp{\myleft{\mytya} &}{\mytmt})} & \myred &
          \myapp{\mytmm}{\mytmt} \\
        \myapp{\mycase{\mytmm}{\mytmn}}{(\myapp{\myright{\mytya} &}{\mytmt})} & \myred &
          \myapp{\mytmn}{\mytmt}
      \end{array}
      $
      &
      $
      \begin{array}{l@{ }l@{\ }c@{\ }l}
        \myapp{\myfst &}{\mypair{\mytmm}{\mytmn}} & \myred & \mytmm \\
        \myapp{\mysnd &}{\mypair{\mytmm}{\mytmn}} & \myred & \mytmn
      \end{array}
      $
    \end{tabular}
}

\mydesc{typing:}{\myjud{\mytmsyn}{\mytysyn}}{
    \begin{tabular}{cc}
      \AxiomC{\phantom{$\myjud{\mytmt}{\myempty}$}}
      \UnaryInfC{$\myjud{\mytt}{\myunit}$}
      \DisplayProof
      &
      \AxiomC{$\myjud{\mytmt}{\myempty}$}
      \UnaryInfC{$\myjud{\myapp{\myabsurd{\mytya}}{\mytmt}}{\mytya}$}
      \DisplayProof
    \end{tabular}

  \myderivsp

    \begin{tabular}{cc}
      \AxiomC{$\myjud{\mytmt}{\mytya}$}
      \UnaryInfC{$\myjud{\myapp{\myleft{\mytyb}}{\mytmt}}{\mytya \mysum \mytyb}$}
      \DisplayProof
      &
      \AxiomC{$\myjud{\mytmt}{\mytyb}$}
      \UnaryInfC{$\myjud{\myapp{\myright{\mytya}}{\mytmt}}{\mytya \mysum \mytyb}$}
      \DisplayProof

    \end{tabular}

  \myderivsp

    \begin{tabular}{cc}
      \AxiomC{$\myjud{\mytmm}{\mytya \myarr \mytyb}$}
      \AxiomC{$\myjud{\mytmn}{\mytya \myarr \mytycc}$}
      \AxiomC{$\myjud{\mytmt}{\mytya \mysum \mytyb}$}
      \TrinaryInfC{$\myjud{\myapp{\mycase{\mytmm}{\mytmn}}{\mytmt}}{\mytycc}$}
      \DisplayProof
    \end{tabular}

  \myderivsp

    \begin{tabular}{ccc}
      \AxiomC{$\myjud{\mytmm}{\mytya}$}
      \AxiomC{$\myjud{\mytmn}{\mytyb}$}
      \BinaryInfC{$\myjud{\mypair{\mytmm}{\mytmn}}{\mytya \myprod \mytyb}$}
      \DisplayProof
      &
      \AxiomC{$\myjud{\mytmt}{\mytya \myprod \mytyb}$}
      \UnaryInfC{$\myjud{\myapp{\myfst}{\mytmt}}{\mytya}$}
      \DisplayProof
      &
      \AxiomC{$\myjud{\mytmt}{\mytya \myprod \mytyb}$}
      \UnaryInfC{$\myjud{\myapp{\mysnd}{\mytmt}}{\mytyb}$}
      \DisplayProof
    \end{tabular}
}
\caption{Rules for the extendend STLC.  Only the new features are shown, all the
  rules and syntax for the STLC apply here too.}
  \label{fig:natded}
\end{figure}

Tagged unions (or sums, or coproducts---$\mysum$ here, \texttt{Either}
in Haskell) correspond to disjunctions, and dually tuples (or pairs, or
products---$\myprod$ here, tuples in Haskell) correspond to
conjunctions.  This is apparent looking at the ways to construct and
destruct the values inhabiting those types: for $\mysum$ $\myleft{ }$
and $\myright{ }$ correspond to $\vee$ introduction, and
$\mycase{\myarg}{\myarg}$ to $\vee$ elimination; for $\myprod$
$\mypair{\myarg}{\myarg}$ corresponds to $\wedge$ introduction, $\myfst$
and $\mysnd$ to $\wedge$ elimination.

The trivial type $\myunit$ corresponds to the logical $\top$, and dually
$\myempty$ corresponds to the logical $\bot$.  $\myunit$ has one introduction
rule ($\mytt$), and thus one inhabitant; and no eliminators.  $\myempty$ has no
introduction rules, and thus no inhabitants; and one eliminator ($\myabsurd{
}$), corresponding to the logical \emph{ex falso quodlibet}.

With these rules, our STLC now looks remarkably similar in power and use to the
natural deduction we already know.  $\myneg \mytya$ can be expressed as $\mytya
\myarr \myempty$.  However, there is an important omission: there is no term of
the type $\mytya \mysum \myneg \mytya$ (excluded middle), or equivalently
$\myneg \myneg \mytya \myarr \mytya$ (double negation), or indeed any term with
a type equivalent to those.

This has a considerable effect on our logic and it's no coincidence, since there
is no obvious computational behaviour for laws like the excluded middle.
Theories of this kind are called \emph{intuitionistic}, or \emph{constructive},
and all the systems analysed will have this characteristic since they build on
the foundation of the STLC\footnote{There is research to give computational
  behaviour to classical logic, but I will not touch those subjects.}.

As in logic, if we want to keep our system consistent, we must make sure that no
closed terms (in other words terms not under a $\lambda$) inhabit $\myempty$.
The variant of STLC presented here is indeed
consistent, a result that follows from the fact that it is
normalising. % TODO explain
Going back to our $\mysyn{fix}$ combinator, it is easy to see how it ruins our
desire for consistency.  The following term works for every type $\mytya$,
including bottom:
{\small\[
(\myfix{\myb{x}}{\mytya}{\myb{x}}) : \mytya
\]}

\subsection{Inductive data}
\label{sec:ind-data}

To make the STLC more useful as a programming language or reasoning tool it is
common to include (or let the user define) inductive data types.  These comprise
of a type former, various constructors, and an eliminator (or destructor) that
serves as primitive recursor.

For example, we might add a $\mylist$ type constructor, along with an `empty
list' ($\mynil{ }$) and `cons cell' ($\mycons$) constructor.  The eliminator for
lists will be the usual folding operation ($\myfoldr$).  See figure
\ref{fig:list}.

\begin{figure}[h]
\mydesc{syntax}{ }{
  $
  \begin{array}{r@{\ }c@{\ }l}
    \mytmsyn & ::= & \cdots \mysynsep \mynil{\mytysyn} \mysynsep \mytmsyn \mycons \mytmsyn
                     \mysynsep
                     \myapp{\myapp{\myapp{\myfoldr}{\mytmsyn}}{\mytmsyn}}{\mytmsyn} \\
    \mytysyn & ::= & \cdots \mysynsep \myapp{\mylist}{\mytysyn}
  \end{array}
  $
}
\mydesc{reduction:}{\mytmsyn \myred \mytmsyn}{
  $
  \begin{array}{l@{\ }c@{\ }l}
    \myapp{\myapp{\myapp{\myfoldr}{\myse{f}}}{\mytmt}}{\mynil{\mytya}} & \myred & \mytmt \\

    \myapp{\myapp{\myapp{\myfoldr}{\myse{f}}}{\mytmt}}{(\mytmm \mycons \mytmn)} & \myred &
    \myapp{\myapp{\myse{f}}{\mytmm}}{(\myapp{\myapp{\myapp{\myfoldr}{\myse{f}}}{\mytmt}}{\mytmn})}
  \end{array}
  $
}
\mydesc{typing:}{\myjud{\mytmsyn}{\mytysyn}}{
    \begin{tabular}{cc}
      \AxiomC{\phantom{$\myjud{\mytmm}{\mytya}$}}
      \UnaryInfC{$\myjud{\mynil{\mytya}}{\myapp{\mylist}{\mytya}}$}
      \DisplayProof
      &
      \AxiomC{$\myjud{\mytmm}{\mytya}$}
      \AxiomC{$\myjud{\mytmn}{\myapp{\mylist}{\mytya}}$}
      \BinaryInfC{$\myjud{\mytmm \mycons \mytmn}{\myapp{\mylist}{\mytya}}$}
      \DisplayProof
    \end{tabular}
  \myderivsp

    \AxiomC{$\myjud{\mysynel{f}}{\mytya \myarr \mytyb \myarr \mytyb}$}
    \AxiomC{$\myjud{\mytmm}{\mytyb}$}
    \AxiomC{$\myjud{\mytmn}{\myapp{\mylist}{\mytya}}$}
    \TrinaryInfC{$\myjud{\myapp{\myapp{\myapp{\myfoldr}{\mysynel{f}}}{\mytmm}}{\mytmn}}{\mytyb}$}
    \DisplayProof
}
\caption{Rules for lists in the STLC.}
\label{fig:list}
\end{figure}

In section \ref{sec:well-order} we will see how to give a general account of
inductive data.  %TODO does this make sense to have here?

\section{Intuitionistic Type Theory}
\label{sec:itt}

\subsection{Extending the STLC}

The STLC can be made more expressive in various ways.  \cite{Barendregt1991}
succinctly expressed geometrically how we can add expressivity:

$$
\xymatrix@!0@=1.5cm{
  & \lambda\omega \ar@{-}[rr]\ar@{-}'[d][dd]
  & & \lambda C \ar@{-}[dd]
  \\
  \lambda2 \ar@{-}[ur]\ar@{-}[rr]\ar@{-}[dd]
  & & \lambda P2 \ar@{-}[ur]\ar@{-}[dd]
  \\
  & \lambda\underline\omega \ar@{-}'[r][rr]
  & & \lambda P\underline\omega
  \\
  \lambda{\to} \ar@{-}[rr]\ar@{-}[ur]
  & & \lambda P \ar@{-}[ur]
}
$$
Here $\lambda{\to}$, in the bottom left, is the STLC.  From there can move along
3 dimensions:
\begin{description}
\item[Terms depending on types (towards $\lambda{2}$)] We can quantify over
  types in our type signatures.  For example, we can define a polymorphic
  identity function:
  {\small\[\displaystyle
  (\myabss{\myb{A}}{\mytyp}{\myabss{\myb{x}}{\myb{A}}{\myb{x}}}) : (\myb{A} : \mytyp) \myarr \myb{A} \myarr \myb{A}
  \]}
  The first and most famous instance of this idea has been System F.  This form
  of polymorphism and has been wildly successful, also thanks to a well known
  inference algorithm for a restricted version of System F known as
  Hindley-Milner.  Languages like Haskell and SML are based on this discipline.
\item[Types depending on types (towards $\lambda{\underline{\omega}}$)] We have
  type operators.  For example we could define a function that given types $R$
  and $\mytya$ forms the type that represents a value of type $\mytya$ in
  continuation passing style: {\small\[\displaystyle(\myabss{\myb{A} \myar \myb{R}}{\mytyp}{(\myb{A}
    \myarr \myb{R}) \myarr \myb{R}}) : \mytyp \myarr \mytyp \myarr \mytyp\]}
\item[Types depending on terms (towards $\lambda{P}$)] Also known as `dependent
  types', give great expressive power.  For example, we can have values of whose
  type depend on a boolean:
  {\small\[\displaystyle(\myabss{\myb{x}}{\mybool}{\myite{\myb{x}}{\mynat}{\myrat}}) : \mybool
  \myarr \mytyp\]}
\end{description}

All the systems preserve the properties that make the STLC well behaved.  The
system we are going to focus on, Intuitionistic Type Theory, has all of the
above additions, and thus would sit where $\lambda{C}$ sits in the
`$\lambda$-cube'.  It will serve as the logical `core' of all the other
extensions that we will present and ultimately our implementation of a similar
logic.

\subsection{A Bit of History}

Logic frameworks and programming languages based on type theory have a long
history.  Per Martin-L\"{o}f described the first version of his theory in 1971,
but then revised it since the original version was inconsistent due to its
impredicativity\footnote{In the early version there was only one universe
  $\mytyp$ and $\mytyp : \mytyp$, see section \ref{sec:term-types} for an
  explanation on why this causes problems.}.  For this reason he gave a revised
and consistent definition later \citep{Martin-Lof1984}.

A related development is the polymorphic $\lambda$-calculus, and specifically
the previously mentioned System F, which was developed independently by Girard
and Reynolds.  An overview can be found in \citep{Reynolds1994}.  The surprising
fact is that while System F is impredicative it is still consistent and strongly
normalising.  \cite{Coquand1986} further extended this line of work with the
Calculus of Constructions (CoC).

Most widely used interactive theorem provers are based on ITT.  Popular ones
include Agda \citep{Norell2007, Bove2009}, Coq \citep{Coq}, and Epigram
\citep{McBride2004, EpigramTut}.

\subsection{A note on inference}

% TODO do this, adding links to the sections about bidi type checking and
% implicit universes.
In the following text I will often omit explicit typing for abstractions or

Moreover, I will use $\mytyp$ without bothering to specify a
universe, with the silent assumption that the definition is consistent
regarding to the hierarchy.

\subsection{A simple type theory}
\label{sec:core-tt}

The calculus I present follows the exposition in \citep{Thompson1991},
and is quite close to the original formulation of predicative ITT as
found in \citep{Martin-Lof1984}.  The system's syntax and reduction
rules are presented in their entirety in figure \ref{fig:core-tt-syn}.
The typing rules are presented piece by piece.  Agda and \mykant\
renditions of the presented theory and all the examples is reproduced in
appendix \ref{app:itt-code}.

\begin{figure}[t]
\mydesc{syntax}{ }{
  $
  \begin{array}{r@{\ }c@{\ }l}
    \mytmsyn & ::= & \myb{x} \mysynsep
                     \mytyp_{l} \mysynsep
                     \myunit \mysynsep \mytt \mysynsep
                     \myempty \mysynsep \myapp{\myabsurd{\mytmsyn}}{\mytmsyn} \\
             &  |  & \mybool \mysynsep \mytrue \mysynsep \myfalse \mysynsep
                     \myitee{\mytmsyn}{\myb{x}}{\mytmsyn}{\mytmsyn}{\mytmsyn} \\
             &  |  & \myfora{\myb{x}}{\mytmsyn}{\mytmsyn} \mysynsep
                     \myabss{\myb{x}}{\mytmsyn}{\mytmsyn} \mysynsep
                     (\myapp{\mytmsyn}{\mytmsyn}) \\
             &  |  & \myexi{\myb{x}}{\mytmsyn}{\mytmsyn} \mysynsep
                     \mypairr{\mytmsyn}{\myb{x}}{\mytmsyn}{\mytmsyn} \\
             &  |  & \myapp{\myfst}{\mytmsyn} \mysynsep \myapp{\mysnd}{\mytmsyn} \\
             &  |  & \myw{\myb{x}}{\mytmsyn}{\mytmsyn} \mysynsep
                     \mytmsyn \mynode{\myb{x}}{\mytmsyn} \mytmsyn \\
             &  |  & \myrec{\mytmsyn}{\myb{x}}{\mytmsyn}{\mytmsyn} \\
    l        & \in & \mathbb{N}
  \end{array}
  $
}

\mydesc{reduction:}{\mytmsyn \myred \mytmsyn}{
    \begin{tabular}{ccc}
      $
      \begin{array}{l@{ }l@{\ }c@{\ }l}
        \myitee{\mytrue &}{\myb{x}}{\myse{P}}{\mytmm}{\mytmn} & \myred & \mytmm \\
        \myitee{\myfalse &}{\myb{x}}{\myse{P}}{\mytmm}{\mytmn} & \myred & \mytmn \\
      \end{array}
      $
      &
      $
      \myapp{(\myabss{\myb{x}}{\mytya}{\mytmm})}{\mytmn} \myred \mysub{\mytmm}{\myb{x}}{\mytmn}
      $
      &
    $
    \begin{array}{l@{ }l@{\ }c@{\ }l}
      \myapp{\myfst &}{\mypair{\mytmm}{\mytmn}} & \myred & \mytmm \\
      \myapp{\mysnd &}{\mypair{\mytmm}{\mytmn}} & \myred & \mytmn
    \end{array}
    $
    \end{tabular}

    \myderivsp

    $
    \myrec{(\myse{s} \mynode{\myb{x}}{\myse{T}} \myse{f})}{\myb{y}}{\myse{P}}{\myse{p}} \myred
    \myapp{\myapp{\myapp{\myse{p}}{\myse{s}}}{\myse{f}}}{(\myabss{\myb{t}}{\mysub{\myse{T}}{\myb{x}}{\myse{s}}}{
      \myrec{\myapp{\myse{f}}{\myb{t}}}{\myb{y}}{\myse{P}}{\mytmt}
    })}
    $
}
\caption{Syntax and reduction rules for our type theory.}
\label{fig:core-tt-syn}
\end{figure}

\subsubsection{Types are terms, some terms are types}
\label{sec:term-types}

\mydesc{typing:}{\myjud{\mytmsyn}{\mytmsyn}}{
    \begin{tabular}{cc}
      \AxiomC{$\myjud{\mytmt}{\mytya}$}
      \AxiomC{$\mytya \mydefeq \mytyb$}
      \BinaryInfC{$\myjud{\mytmt}{\mytyb}$}
      \DisplayProof
      &
      \AxiomC{\phantom{$\myjud{\mytmt}{\mytya}$}}
      \UnaryInfC{$\myjud{\mytyp_l}{\mytyp_{l + 1}}$}
      \DisplayProof
    \end{tabular}
}

The first thing to notice is that a barrier between values and types that we had
in the STLC is gone: values can appear in types, and the two are treated
uniformly in the syntax.

While the usefulness of doing this will become clear soon, a consequence is
that since types can be the result of computation, deciding type equality is
not immediate as in the STLC.  For this reason we define \emph{definitional
  equality}, $\mydefeq$, as the congruence relation extending
$\myred$---moreover, when comparing types syntactically we do it up to
renaming of bound names ($\alpha$-renaming).  For example under this
discipline we will find that
{\small\[
\myabss{\myb{x}}{\mytya}{\myb{x}} \mydefeq \myabss{\myb{y}}{\mytya}{\myb{y}}
\]}
Types that are definitionally equal can be used interchangeably.  Here
the `conversion' rule is not syntax directed, but it is possible to
employ $\myred$ to decide term equality in a systematic way, by always
reducing terms to their normal forms before comparing them, so that a
separate conversion rule is not needed.  % TODO add section
Another thing to notice is that considering the need to reduce terms to
decide equality, it is essential for a dependently type system to be
terminating and confluent for type checking to be decidable.

Moreover, we specify a \emph{type hierarchy} to talk about `large'
types: $\mytyp_0$ will be the type of types inhabited by data:
$\mybool$, $\mynat$, $\mylist$, etc.  $\mytyp_1$ will be the type of
$\mytyp_0$, and so on---for example we have $\mytrue : \mybool :
\mytyp_0 : \mytyp_1 : \cdots$.  Each type `level' is often called a
universe in the literature.  While it is possible to simplify things by
having only one universe $\mytyp$ with $\mytyp : \mytyp$, this plan is
inconsistent for much the same reason that impredicative na\"{\i}ve set
theory is \citep{Hurkens1995}.  However various techniques can be
employed to lift the burden of explicitly handling universes, as we will
see in section \ref{sec:term-hierarchy}.

\subsubsection{Contexts}

\begin{minipage}{0.5\textwidth}
  \mydesc{context validity:}{\myvalid{\myctx}}{
      \begin{tabular}{cc}
        \AxiomC{\phantom{$\myjud{\mytya}{\mytyp_l}$}}
        \UnaryInfC{$\myvalid{\myemptyctx}$}
        \DisplayProof
        &
        \AxiomC{$\myjud{\mytya}{\mytyp_l}$}
        \UnaryInfC{$\myvalid{\myctx ; \myb{x} : \mytya}$}
        \DisplayProof
      \end{tabular}
  }
\end{minipage} 
\begin{minipage}{0.5\textwidth}
  \mydesc{typing:}{\myjud{\mytmsyn}{\mytmsyn}}{
      \AxiomC{$\myctx(x) = \mytya$}
      \UnaryInfC{$\myjud{\myb{x}}{\mytya}$}
      \DisplayProof
  }
\end{minipage}
\vspace{0.1cm}

We need to refine the notion context to make sure that every variable appearing
is typed correctly, or that in other words each type appearing in the context is
indeed a type and not a value.  In every other rule, if no premises are present,
we assume the context in the conclusion to be valid.

Then we can re-introduce the old rule to get the type of a variable for a
context.

\subsubsection{$\myunit$, $\myempty$}

\mydesc{typing:}{\myjud{\mytmsyn}{\mytmsyn}}{
    \begin{tabular}{ccc}
      \AxiomC{\phantom{$\myjud{\mytya}{\mytyp_l}$}}
      \UnaryInfC{$\myjud{\myunit}{\mytyp_0}$}
      \noLine
      \UnaryInfC{$\myjud{\myempty}{\mytyp_0}$}
      \DisplayProof
      &
      \AxiomC{\phantom{$\myjud{\mytya}{\mytyp_l}$}}
      \UnaryInfC{$\myjud{\mytt}{\myunit}$}
      \noLine
      \UnaryInfC{\phantom{$\myjud{\myempty}{\mytyp_0}$}}
      \DisplayProof
      &
      \AxiomC{$\myjud{\mytmt}{\myempty}$}
      \AxiomC{$\myjud{\mytya}{\mytyp_l}$}
      \BinaryInfC{$\myjud{\myapp{\myabsurd{\mytya}}{\mytmt}}{\mytya}$}
      \noLine
      \UnaryInfC{\phantom{$\myjud{\myempty}{\mytyp_0}$}}
      \DisplayProof
    \end{tabular}
}

Nothing surprising here: $\myunit$ and $\myempty$ are unchanged from the STLC,
with the added rules to type $\myunit$ and $\myempty$ themselves, and to make
sure that we are invoking $\myabsurd{}$ over a type.

\subsubsection{$\mybool$, and dependent $\myfun{if}$}

\mydesc{typing:}{\myjud{\mytmsyn}{\mytmsyn}}{
   \begin{tabular}{ccc}
     \AxiomC{}
     \UnaryInfC{$\myjud{\mybool}{\mytyp_0}$}
     \DisplayProof
     &
     \AxiomC{}
     \UnaryInfC{$\myjud{\mytrue}{\mybool}$}
     \DisplayProof
     &
     \AxiomC{}
      \UnaryInfC{$\myjud{\myfalse}{\mybool}$}
      \DisplayProof
    \end{tabular}
    \myderivsp

    \AxiomC{$\myjud{\mytmt}{\mybool}$}
    \AxiomC{$\myjudd{\myctx : \mybool}{\mytya}{\mytyp_l}$}
    \noLine
    \BinaryInfC{$\myjud{\mytmm}{\mysub{\mytya}{x}{\mytrue}}$ \hspace{0.7cm} $\myjud{\mytmn}{\mysub{\mytya}{x}{\myfalse}}$}
    \UnaryInfC{$\myjud{\myitee{\mytmt}{\myb{x}}{\mytya}{\mytmm}{\mytmn}}{\mysub{\mytya}{\myb{x}}{\mytmt}}$}
    \DisplayProof
}

With booleans we get the first taste of the `dependent' in `dependent
types'.  While the two introduction rules ($\mytrue$ and $\myfalse$) are
not surprising, the typing rules for $\myfun{if}$ are.  In most strongly
typed languages we expect the branches of an $\myfun{if}$ statements to
be of the same type, to preserve subject reduction, since execution
could take both paths.  This is a pity, since the type system does not
reflect the fact that in each branch we gain knowledge on the term we
are branching on.  Which means that programs along the lines of
{\small\[\text{\texttt{if null xs then head xs else 0}}\]}
are a necessary, well typed, danger.

However, in a more expressive system, we can do better: the branches' type can
depend on the value of the scrutinised boolean.  This is what the typing rule
expresses: the user provides a type $\mytya$ ranging over an $\myb{x}$
representing the scrutinised boolean type, and the branches are typechecked with
the updated knowledge on the value of $\myb{x}$.

\subsubsection{$\myarr$, or dependent function}

 \mydesc{typing:}{\myjud{\mytmsyn}{\mytmsyn}}{
     \AxiomC{$\myjud{\mytya}{\mytyp_{l_1}}$}
     \AxiomC{$\myjudd{\myctx;\myb{x} : \mytya}{\mytyb}{\mytyp_{l_2}}$}
     \BinaryInfC{$\myjud{\myfora{\myb{x}}{\mytya}{\mytyb}}{\mytyp_{l_1 \mylub l_2}}$}
     \DisplayProof

     \myderivsp

    \begin{tabular}{cc}
      \AxiomC{$\myjudd{\myctx; \myb{x} : \mytya}{\mytmt}{\mytyb}$}
      \UnaryInfC{$\myjud{\myabss{\myb{x}}{\mytya}{\mytmt}}{\myfora{\myb{x}}{\mytya}{\mytyb}}$}
      \DisplayProof
      &
      \AxiomC{$\myjud{\mytmm}{\myfora{\myb{x}}{\mytya}{\mytyb}}$}
      \AxiomC{$\myjud{\mytmn}{\mytya}$}
      \BinaryInfC{$\myjud{\myapp{\mytmm}{\mytmn}}{\mysub{\mytyb}{\myb{x}}{\mytmn}}$}
      \DisplayProof
    \end{tabular}
}

Dependent functions are one of the two key features that perhaps most
characterise dependent types---the other being dependent products.  With
dependent functions, the result type can depend on the value of the
argument.  This feature, together with the fact that the result type
might be a type itself, brings a lot of interesting possibilities.
Following this intuition, in the introduction rule, the return type is
typechecked in a context with an abstracted variable of lhs' type, and
in the elimination rule the actual argument is substituted in the return
type.  Keeping the correspondence with logic alive, dependent functions
are much like universal quantifiers ($\forall$) in logic.

For example, assuming that we have lists and natural numbers in our
language, using dependent functions we would be able to
write:
{\small\[
\begin{array}{l}
\myfun{length} : (\myb{A} {:} \mytyp_0) \myarr \myapp{\mylist}{\myb{A}} \myarr \mynat \\
\myarg \myfun{$>$} \myarg : \mynat \myarr \mynat \myarr \mytyp_0 \\
\myfun{head} : (\myb{A} {:} \mytyp_0) \myarr (\myb{l} {:} \myapp{\mylist}{\myb{A}})
               \myarr \myapp{\myapp{\myfun{length}}{\myb{A}}}{\myb{l}} \mathrel{\myfun{>}} 0 \myarr
               \myb{A}
\end{array}
\]}

\myfun{length} is the usual polymorphic length function. $\myfun{>}$ is
a function that takes two naturals and returns a type: if the lhs is
greater then the rhs, $\myunit$ is returned, $\myempty$ otherwise.  This
way, we can express a `non-emptyness' condition in $\myfun{head}$, by
including a proof that the length of the list argument is non-zero.
This allows us to rule out the `empty list' case, so that we can safely
return the first element.

Again, we need to make sure that the type hierarchy is respected, which is the
reason why a type formed by $\myarr$ will live in the least upper bound of the
levels of argument and return type.  This trend will continue with the other
type-level binders, $\myprod$ and $\mytyc{W}$.

\subsubsection{$\myprod$, or dependent product}
\label{sec:disju}

\mydesc{typing:}{\myjud{\mytmsyn}{\mytmsyn}}{
     \AxiomC{$\myjud{\mytya}{\mytyp_{l_1}}$}
     \AxiomC{$\myjudd{\myctx;\myb{x} : \mytya}{\mytyb}{\mytyp_{l_2}}$}
     \BinaryInfC{$\myjud{\myexi{\myb{x}}{\mytya}{\mytyb}}{\mytyp_{l_1 \mylub l_2}}$}
     \DisplayProof

     \myderivsp

    \begin{tabular}{cc}
      \AxiomC{$\myjud{\mytmm}{\mytya}$}
      \AxiomC{$\myjud{\mytmn}{\mysub{\mytyb}{\myb{x}}{\mytmm}}$}
      \BinaryInfC{$\myjud{\mypairr{\mytmm}{\myb{x}}{\mytyb}{\mytmn}}{\myexi{\myb{x}}{\mytya}{\mytyb}}$}
      \noLine
      \UnaryInfC{\phantom{$--$}}
      \DisplayProof
      &
      \AxiomC{$\myjud{\mytmt}{\myexi{\myb{x}}{\mytya}{\mytyb}}$}
      \UnaryInfC{$\hspace{0.7cm}\myjud{\myapp{\myfst}{\mytmt}}{\mytya}\hspace{0.7cm}$}
      \noLine
      \UnaryInfC{$\myjud{\myapp{\mysnd}{\mytmt}}{\mysub{\mytyb}{\myb{x}}{\myapp{\myfst}{\mytmt}}}$}
      \DisplayProof
    \end{tabular}
}

If dependent functions are a generalisation of $\myarr$ in the STLC,
dependent products are a generalisation of $\myprod$ in the STLC.  The
improvement is that the second element's type can depend on the value of
the first element.  The corrispondence with logic is through the
existential quantifier: $\exists x \in \mathbb{N}. even(x)$ can be
expressed as $\myexi{\myb{x}}{\mynat}{\myapp{\myfun{even}}{\myb{x}}}$.
The first element will be a number, and the second evidence that the
number is even.  This highlights the fact that we are working in a
constructive logic: if we have an existence proof, we can always ask for
a witness.  This means, for instance, that $\neg \forall \neg$ is not
equivalent to $\exists$.

Another perhaps more `dependent' application of products, paired with
$\mybool$, is to offer choice between different types.  For example we
can easily recover disjunctions:
{\small\[
\begin{array}{l}
  \myarg\myfun{$\vee$}\myarg : \mytyp_0 \myarr \mytyp_0 \myarr \mytyp_0 \\
  \myb{A} \mathrel{\myfun{$\vee$}} \myb{B} \mapsto \myexi{\myb{x}}{\mybool}{\myite{\myb{x}}{\myb{A}}{\myb{B}}} \\ \ \\
  \myfun{case} : (\myb{A}\ \myb{B}\ \myb{C} {:} \mytyp_0) \myarr (\myb{A} \myarr \myb{C}) \myarr (\myb{B} \myarr \myb{C}) \myarr \myb{A} \mathrel{\myfun{$\vee$}} \myb{B} \myarr \myb{C} \\
  \myfun{case} \myappsp \myb{A} \myappsp \myb{B} \myappsp \myb{C} \myappsp \myb{f} \myappsp \myb{g} \myappsp \myb{x} \mapsto \\
  \myind{2} \myapp{(\myitee{\myapp{\myfst}{\myb{b}}}{\myb{x}}{(\myite{\myb{b}}{\myb{A}}{\myb{B}})}{\myb{f}}{\myb{g}})}{(\myapp{\mysnd}{\myb{x}})}
\end{array}
\]}

\subsubsection{$\mytyc{W}$, or well-order}
\label{sec:well-order}

\mydesc{typing:}{\myjud{\mytmsyn}{\mytmsyn}}{
     \AxiomC{$\myjud{\mytya}{\mytyp_{l_1}}$}
     \AxiomC{$\myjudd{\myctx;\myb{x} : \mytya}{\mytyb}{\mytyp_{l_2}}$}
     \BinaryInfC{$\myjud{\myw{\myb{x}}{\mytya}{\mytyb}}{\mytyp_{l_1 \mylub l_2}}$}
     \DisplayProof

     \myderivsp

     \AxiomC{$\myjud{\mytmt}{\mytya}$}
     \AxiomC{$\myjud{\mysynel{f}}{\mysub{\mytyb}{\myb{x}}{\mytmt} \myarr \myw{\myb{x}}{\mytya}{\mytyb}}$}
     \BinaryInfC{$\myjud{\mytmt \mynode{\myb{x}}{\mytyb} \myse{f}}{\myw{\myb{x}}{\mytya}{\mytyb}}$}
     \DisplayProof

     \myderivsp

     \AxiomC{$\myjud{\myse{u}}{\myw{\myb{x}}{\myse{S}}{\myse{T}}}$}
     \AxiomC{$\myjudd{\myctx; \myb{w} : \myw{\myb{x}}{\myse{S}}{\myse{T}}}{\myse{P}}{\mytyp_l}$}
     \noLine
     \BinaryInfC{$\myjud{\myse{p}}{
       \myfora{\myb{s}}{\myse{S}}{\myfora{\myb{f}}{\mysub{\myse{T}}{\myb{x}}{\myse{s}} \myarr \myw{\myb{x}}{\myse{S}}{\myse{T}}}{(\myfora{\myb{t}}{\mysub{\myse{T}}{\myb{x}}{\myb{s}}}{\mysub{\myse{P}}{\myb{w}}{\myapp{\myb{f}}{\myb{t}}}}) \myarr \mysub{\myse{P}}{\myb{w}}{\myb{f}}}}
     }$}
     \UnaryInfC{$\myjud{\myrec{\myse{u}}{\myb{w}}{\myse{P}}{\myse{p}}}{\mysub{\myse{P}}{\myb{w}}{\myse{u}}}$}
     \DisplayProof
}

Finally, the well-order type, or in short $\mytyc{W}$-type, which will
let us represent inductive data in a general (but clumsy) way.  The core
idea is to


\section{The struggle for equality}
\label{sec:equality}

In the previous section we saw how a type checker (or a human) needs a
notion of \emph{definitional equality}.  Beyond this meta-theoretic
notion, in this section we will explore the ways of expressing equality
\emph{inside} the theory, as a reasoning tool available to the user.
This area is the main concern of this thesis, and in general a very
active research topic, since we do not have a fully satisfactory
solution, yet.  As in the previous section, everything presented is
formalised in Agda in appendix \ref{app:agda-itt}.

\subsection{Propositional equality}

\noindent
\begin{minipage}{0.5\textwidth}
\mydesc{syntax}{ }{
  $
  \begin{array}{r@{\ }c@{\ }l}
    \mytmsyn & ::= & \cdots \\
             &  |  & \mytmsyn \mypeq{\mytmsyn} \mytmsyn \mysynsep
                     \myapp{\myrefl}{\mytmsyn} \\
             &  |  & \myjeq{\mytmsyn}{\mytmsyn}{\mytmsyn}
  \end{array}
  $
}
\end{minipage} 
\begin{minipage}{0.5\textwidth}
\mydesc{reduction:}{\mytmsyn \myred \mytmsyn}{
    $
    \myjeq{\myse{P}}{(\myapp{\myrefl}{\mytmm})}{\mytmn} \myred \mytmn
    $
  \vspace{0.87cm}
}
\end{minipage}

\mydesc{typing:}{\myjud{\mytmsyn}{\mytmsyn}}{
    \AxiomC{$\myjud{\mytya}{\mytyp_l}$}
    \AxiomC{$\myjud{\mytmm}{\mytya}$}
    \AxiomC{$\myjud{\mytmn}{\mytya}$}
    \TrinaryInfC{$\myjud{\mytmm \mypeq{\mytya} \mytmn}{\mytyp_l}$}
    \DisplayProof

    \myderivsp

    \begin{tabular}{cc}
      \AxiomC{$\begin{array}{c}\ \\\myjud{\mytmm}{\mytya}\hspace{1.1cm}\mytmm \mydefeq \mytmn\end{array}$}
      \UnaryInfC{$\myjud{\myapp{\myrefl}{\mytmm}}{\mytmm \mypeq{\mytya} \mytmn}$}
      \DisplayProof
      &
      \AxiomC{$
        \begin{array}{c}
          \myjud{\myse{P}}{\myfora{\myb{x}\ \myb{y}}{\mytya}{\myfora{q}{\myb{x} \mypeq{\mytya} \myb{y}}{\mytyp_l}}} \\
          \myjud{\myse{q}}{\mytmm \mypeq{\mytya} \mytmn}\hspace{1.1cm}\myjud{\myse{p}}{\myapp{\myapp{\myapp{\myse{P}}{\mytmm}}{\mytmm}}{(\myapp{\myrefl}{\mytmm})}}
        \end{array}
        $}
      \UnaryInfC{$\myjud{\myjeq{\myse{P}}{\myse{q}}{\myse{p}}}{\myapp{\myapp{\myapp{\myse{P}}{\mytmm}}{\mytmn}}{q}}$}
      \DisplayProof
    \end{tabular}
}

To express equality between two terms inside ITT, the obvious way to do so is
to have the equality construction to be a type-former.  Here we present what
has survived as the dominating form of equality in systems based on ITT up to
the present day.

Our type former is $\mypeq{\mytya}$, which given a type (in this case
$\mytya$) relates equal terms of that type.  $\mypeq{}$ has one introduction
rule, $\myrefl$, which introduces an equality relation between definitionally
equal terms.

Finally, we have one eliminator for $\mypeq{}$, $\myjeqq$.  $\myjeq{\myse{P}}{\myse{q}}{\myse{p}}$ takes
\begin{itemize}
\item $\myse{P}$, a predicate working with two terms of a certain type (say
  $\mytya$) and a proof of their equality
\item $\myse{q}$, a proof that two terms in $\mytya$ (say $\myse{m}$ and
  $\myse{n}$) are equal
\item and $\myse{p}$, an inhabitant of $\myse{P}$ applied to $\myse{m}$, plus
  the trivial proof by reflexivity showing that $\myse{m}$ is equal to itself
\end{itemize}
Given these ingredients, $\myjeqq$ retuns a member of $\myse{P}$ applied to
$\mytmm$, $\mytmn$, and $\myse{q}$.  In other words $\myjeqq$ takes a
witness that $\myse{P}$ works with \emph{definitionally equal} terms, and
returns a witness of $\myse{P}$ working with \emph{propositionally equal}
terms.  Invokations of $\myjeqq$ will vanish when the equality proofs will
reduce to invocations to reflexivity, at which point the arguments must be
definitionally equal, and thus the provided
$\myapp{\myapp{\myapp{\myse{P}}{\mytmm}}{\mytmm}}{(\myapp{\myrefl}{\mytmm})}$
can be returned.

While the $\myjeqq$ rule is slightly convoluted, ve can derive many more
`friendly' rules from it, for example a more obvious `substitution' rule, that
replaces equal for equal in predicates:
{\small\[
\begin{array}{l}
\myfun{subst} : \myfora{\myb{A}}{\mytyp}{\myfora{\myb{P}}{\myb{A} \myarr \mytyp}{\myfora{\myb{x}\ \myb{y}}{\myb{A}}{\myb{x} \mypeq{\myb{A}} \myb{y} \myarr \myapp{\myb{P}}{\myb{x}} \myarr \myapp{\myb{P}}{\myb{y}}}}} \\
\myfun{subst}\myappsp \myb{A}\myappsp\myb{P}\myappsp\myb{x}\myappsp\myb{y}\myappsp\myb{q}\myappsp\myb{p} \mapsto
  \myjeq{(\myabs{\myb{x}\ \myb{y}\ \myb{q}}{\myapp{\myb{P}}{\myb{y}}})}{\myb{p}}{\myb{q}}
\end{array}
\]}
Once we have $\myfun{subst}$, we can easily prove more familiar laws regarding
equality, such as symmetry, transitivity, and a congruence law.

% TODO finish this

\subsection{Common extensions}

Our definitional equality can be made larger in various ways, here we
review some common extensions.

\subsubsection{Congruence laws and $\eta$-expansion}

A simple type-directed check that we can do on functions and records is
$\eta$-expansion.  We can then have

\mydesc{definitional equality:}{\myjud{\mytmm \mydefeq \mytmn}{\mytmsyn}}{
  \begin{tabular}{cc}
    \AxiomC{$\myjud{f \mydefeq (\myabss{\myb{x}}{\mytya}{\myapp{\myse{g}}{\myb{x}}})}{\myfora{\myb{x}}{\mytya}{\mytyb}}$}
    \UnaryInfC{$\myjud{\myse{f} \mydefeq \myse{g}}{\myfora{\myb{x}}{\mytya}{\mytyb}}$}
    \DisplayProof
    &
    \AxiomC{$\myjud{\mytmm \mydefeq \mypair{\myapp{\myfst}{\mytmn}}{\myapp{\mysnd}{\mytmn}}}{\myexi{\myb{x}}{\mytya}{\mytyb}}$}
    \UnaryInfC{$\myjud{\mytmm \mydefeq \mytmn}{\myexi{\myb{x}}{\mytya}{\mytyb}}$}
    \DisplayProof
  \end{tabular}

  \myderivsp

  \AxiomC{$\myjud{\mytmm}{\myunit}$}
  \AxiomC{$\myjud{\mytmn}{\myunit}$}
  \BinaryInfC{$\myjud{\mytmm \mydefeq \mytmn}{\myunit}$}
  \DisplayProof
}

%   \mydesc{definitional equality:}{\mytmsyn \mydefeq \mytmsyn}{
%     \begin{tabular}{cc}
%       \AxiomC{}
%       &
%       foo
%     \end{tabular}
%   }
% \end{description}

\subsubsection{Uniqueness of identity proofs}

% TODO reference the fact that J does not imply J
% TODO mention univalence


\mydesc{definitional equality:}{\myjud{\mytmm \mydefeq \mytmn}{\mytmsyn}}{
  \AxiomC{$
    \begin{array}{@{}c}
      \myjud{\myse{P}}{\myfora{\myb{x}}{\mytya}{\myb{x} \mypeq{\mytya} \myb{x} \myarr \mytyp}} \\\
      \myjud{\myse{p}}{\myfora{\myb{x}}{\mytya}{\myse{P} \myappsp \myb{x} \myappsp \myb{x} \myappsp (\myrefl \myapp \myb{x})}} \hspace{1cm}
      \myjud{\mytmt}{\mytya} \hspace{1cm}
      \myjud{\myse{q}}{\mytmt \mypeq{\mytya} \mytmt}
    \end{array}
    $}
  \UnaryInfC{$\myjud{\myfun{K} \myappsp \myse{P} \myappsp \myse{p} \myappsp \myse{t} \myappsp \myse{q}}{\myse{P} \myappsp \mytmt \myappsp \myse{q}}$}
  \DisplayProof
}

\subsection{Limitations}

\epigraph{\emph{Half of my time spent doing research involves thinking up clever
  schemes to avoid needing functional extensionality.}}{@larrytheliquid}

However, propositional equality as described is quite restricted when
reasoning about equality beyond the term structure, which is what definitional
equality gives us (extension notwithstanding).

The problem is best exemplified by \emph{function extensionality}.  In
mathematics, we would expect to be able to treat functions that give equal
output for equal input as the same.  When reasoning in a mechanised framework
we ought to be able to do the same: in the end, without considering the
operational behaviour, all functions equal extensionally are going to be
replaceable with one another.

However this is not the case, or in other words with the tools we have we have
no term of type
{\small\[
\myfun{ext} : \myfora{\myb{A}\ \myb{B}}{\mytyp}{\myfora{\myb{f}\ \myb{g}}{
    \myb{A} \myarr \myb{B}}{
        (\myfora{\myb{x}}{\myb{A}}{\myapp{\myb{f}}{\myb{x}} \mypeq{\myb{B}} \myapp{\myb{g}}{\myb{x}}}) \myarr
        \myb{f} \mypeq{\myb{A} \myarr \myb{B}} \myb{g}
    }
}
\]}
To see why this is the case, consider the functions
{\small\[\myabs{\myb{x}}{0 \mathrel{\myfun{+}} \myb{x}}$ and $\myabs{\myb{x}}{\myb{x} \mathrel{\myfun{+}} 0}\]}
where $\myfun{+}$ is defined by recursion on the first argument,
gradually destructing it to build up successors of the second argument.
The two functions are clearly extensionally equal, and we can in fact
prove that
{\small\[
\myfora{\myb{x}}{\mynat}{(0 \mathrel{\myfun{+}} \myb{x}) \mypeq{\mynat} (\myb{x} \mathrel{\myfun{+}} 0)}
\]}
By analysis on the $\myb{x}$.  However, the two functions are not
definitionally equal, and thus we won't be able to get rid of the
quantification.

For the reasons above, theories that offer a propositional equality
similar to what we presented are called \emph{intensional}, as opposed
to \emph{extensional}.  Most systems in wide use today (such as Agda,
Coq, and Epigram) are of this kind.

This is quite an annoyance that often makes reasoning awkward to execute.  It
also extends to other fields, for example proving bisimulation between
processes specified by coinduction, or in general proving equivalences based
on the behaviour on a term.

\subsection{Equality reflection}

One way to `solve' this problem is by identifying propositional equality with
definitional equality:

\mydesc{typing:}{\myjud{\mytmsyn}{\mytmsyn}}{
    \AxiomC{$\myjud{\myse{q}}{\mytmm \mypeq{\mytya} \mytmn}$}
    \UnaryInfC{$\myjud{\mytmm \mydefeq \mytmn}{\mytya}$}
    \DisplayProof
}

This rule takes the name of \emph{equality reflection}, and is a very
different rule from the ones we saw up to now: it links a typing judgement
internal to the type theory to a meta-theoretic judgement that the type
checker uses to work with terms.  It is easy to see the dangerous consequences
that this causes:
\begin{itemize}
\item The rule is syntax directed, and the type checker is presumably expected
  to come up with equality proofs when needed.
\item More worryingly, type checking becomes undecidable also because
  computing under false assumptions becomes unsafe.
  Consider for example
  {\small\[
  \myabss{\myb{q}}{\mytya \mypeq{\mytyp} (\mytya \myarr \mytya)}{\myhole{?}}
  \]}
  Using the assumed proof in tandem with equality reflection we could easily
  write a classic Y combinator, sending the compiler into a loop.
\end{itemize}

Given these facts theories employing equality reflection, like NuPRL
\citep{NuPRL}, carry the derivations that gave rise to each typing judgement
to keep the systems manageable.  % TODO more info, problems with that.

For all its faults, equality reflection does allow us to prove extensionality,
using the extensions we gave above.  Assuming that $\myctx$ contains
{\small\[\myb{A}, \myb{B} : \mytyp; \myb{f}, \myb{g} : \myb{A} \myarr \myb{B}; \myb{q} : \myfora{\myb{x}}{\myb{A}}{\myapp{\myb{f}}{\myb{x}} \mypeq{} \myapp{\myb{g}}{\myb{x}}}\]}
We can then derive
\begin{prooftree}
  \small
  \AxiomC{$\hspace{1.1cm}\myjudd{\myctx; \myb{x} : \myb{A}}{\myapp{\myb{q}}{\myb{x}}}{\myapp{\myb{f}}{\myb{x}} \mypeq{} \myapp{\myb{g}}{\myb{x}}}\hspace{1.1cm}$}
  \RightLabel{equality reflection}
  \UnaryInfC{$\myjudd{\myctx; \myb{x} : \myb{A}}{\myapp{\myb{f}}{\myb{x}} \mydefeq \myapp{\myb{g}}{\myb{x}}}{\myb{B}}$}
  \RightLabel{congruence for $\lambda$s}
  \UnaryInfC{$\myjud{(\myabs{\myb{x}}{\myapp{\myb{f}}{\myb{x}}}) \mydefeq (\myabs{\myb{x}}{\myapp{\myb{g}}{\myb{x}}})}{\myb{A} \myarr \myb{B}}$}
  \RightLabel{$\eta$-law for $\lambda$}
  \UnaryInfC{$\hspace{1.45cm}\myjud{\myb{f} \mydefeq \myb{g}}{\myb{A} \myarr \myb{B}}\hspace{1.45cm}$}
  \RightLabel{$\myrefl$}
  \UnaryInfC{$\myjud{\myapp{\myrefl}{\myb{f}}}{\myb{f} \mypeq{} \myb{g}}$}
\end{prooftree}

Now, the question is: do we need to give up well-behavedness of our theory to
gain extensionality?

\subsection{Some alternatives}

% TODO add `extentional axioms' (Hoffman), setoid models (Thorsten)

\section{Observational equality}
\label{sec:ott}

A recent development by \citet{Altenkirch2007}, \emph{Observational Type
  Theory} (OTT), promises to keep the well behavedness of ITT while
being able to gain many useful equality proofs\footnote{It is suspected
  that OTT gains \emph{all} the equality proofs of ETT, but no proof
  exists yet.}, including function extensionality.  The main idea is to
give the user the possibility to \emph{coerce} (or transport) values
from a type $\mytya$ to a type $\mytyb$, if the type checker can prove
structurally that $\mytya$ and $\mytya$ are equal; and providing a
value-level equality based on similar principles.  Here we give an
exposition which follows closely the original paper.

\subsection{A simpler theory, a propositional fragment}

\mydesc{syntax}{ }{
    $\mytyp_l$ is replaced by $\mytyp$. \\\ \\
    $
    \begin{array}{r@{\ }c@{\ }l}
      \mytmsyn & ::= & \cdots \mysynsep \myprdec{\myprsyn} \mysynsep
                       \myITE{\mytmsyn}{\mytmsyn}{\mytmsyn} \\
      \myprsyn & ::= & \mybot \mysynsep \mytop \mysynsep \myprsyn \myand \myprsyn
      \mysynsep \myprfora{\myb{x}}{\mytmsyn}{\myprsyn}
    \end{array}
    $
}

\mydesc{typing:}{\myjud{\mytmsyn}{\mytmsyn}}{
  \begin{tabular}{cc}
    \AxiomC{$\myjud{\myse{P}}{\myprop}$}
    \UnaryInfC{$\myjud{\myprdec{\myse{P}}}{\mytyp}$}
    \DisplayProof
    &
    \AxiomC{$\myjud{\mytmt}{\mybool}$}
    \AxiomC{$\myjud{\mytya}{\mytyp}$}
    \AxiomC{$\myjud{\mytyb}{\mytyp}$}
    \TrinaryInfC{$\myjud{\myITE{\mytmt}{\mytya}{\mytyb}}{\mytyp}$}
    \DisplayProof
  \end{tabular}
}

\mydesc{propositions:}{\myjud{\myprsyn}{\myprop}}{
    \begin{tabular}{cc}
      \AxiomC{\phantom{$\myjud{\myse{P}}{\myprop}$}}
      \UnaryInfC{$\myjud{\mytop}{\myprop}$}
      \noLine
      \UnaryInfC{$\myjud{\mybot}{\myprop}$}
      \DisplayProof
      &
      \AxiomC{$\myjud{\myse{P}}{\myprop}$}
      \AxiomC{$\myjud{\myse{Q}}{\myprop}$}
      \BinaryInfC{$\myjud{\myse{P} \myand \myse{Q}}{\myprop}$}
      \noLine
      \UnaryInfC{\phantom{$\myjud{\mybot}{\myprop}$}}
      \DisplayProof
    \end{tabular}

    \myderivsp

      \AxiomC{$\myjud{\myse{A}}{\mytyp}$}
      \AxiomC{$\myjudd{\myctx; \myb{x} : \mytya}{\myse{P}}{\myprop}$}
      \BinaryInfC{$\myjud{\myprfora{\myb{x}}{\mytya}{\myse{P}}}{\myprop}$}
      \DisplayProof
}

Our foundation will be a type theory like the one of section
\ref{sec:itt}, with only one level: $\mytyp_0$.  In this context we will
drop the $0$ and call $\mytyp_0$ $\mytyp$.  Moreover, since the old
$\myfun{if}\myarg\myfun{then}\myarg\myfun{else}$ was able to return
types thanks to the hierarchy (which is gone), we need to reintroduce an
ad-hoc conditional for types, where the reduction rule is the obvious
one.

However, we have an addition: a universe of \emph{propositions},
$\myprop$.  $\myprop$ isolates a fragment of types at large, and
indeed we can `inject' any $\myprop$ back in $\mytyp$ with $\myprdec{\myarg}$: \\
\mydesc{proposition decoding:}{\myprdec{\mytmsyn} \myred \mytmsyn}{
    \begin{tabular}{cc}
    $
    \begin{array}{l@{\ }c@{\ }l}
      \myprdec{\mybot} & \myred & \myempty \\
      \myprdec{\mytop} & \myred & \myunit
    \end{array}
    $
    &
    $
    \begin{array}{r@{ }c@{ }l@{\ }c@{\ }l}
      \myprdec{&\myse{P} \myand \myse{Q} &} & \myred & \myprdec{\myse{P}} \myprod \myprdec{\myse{Q}} \\
      \myprdec{&\myprfora{\myb{x}}{\mytya}{\myse{P}} &} & \myred &
             \myfora{\myb{x}}{\mytya}{\myprdec{\myse{P}}}
    \end{array}
    $
    \end{tabular}
  } \\
  Propositions are what we call the types of \emph{proofs}, or types
  whose inhabitants contain no `data', much like $\myunit$.  The goal of
  doing this is twofold: erasing all top-level propositions when
  compiling; and to identify all equivalent propositions as the same, as
  we will see later.

  Why did we choose what we have in $\myprop$?  Given the above
  criteria, $\mytop$ obviously fits the bill.  A pair of propositions
  $\myse{P} \myand \myse{Q}$ still won't get us data. Finally, if
  $\myse{P}$ is a proposition and we have
  $\myprfora{\myb{x}}{\mytya}{\myse{P}}$ , the decoding will be a
  function which returns propositional content.  The only threat is
  $\mybot$, by which we can fabricate anything we want: however if we
  are consistent there will be nothing of type $\mybot$ at the top
  level, which is what we care about regarding proof erasure.

\subsection{Equality proofs}

\mydesc{syntax}{ }{
    $
    \begin{array}{r@{\ }c@{\ }l}
      \mytmsyn & ::= & \cdots \mysynsep
      \mycoee{\mytmsyn}{\mytmsyn}{\mytmsyn}{\mytmsyn} \mysynsep
      \mycohh{\mytmsyn}{\mytmsyn}{\mytmsyn}{\mytmsyn} \\
      \myprsyn & ::= & \cdots \mysynsep \mytmsyn \myeq \mytmsyn \mysynsep
      \myjm{\mytmsyn}{\mytmsyn}{\mytmsyn}{\mytmsyn}
    \end{array}
    $
}

\mydesc{typing:}{\myjud{\mytmsyn}{\mytmsyn}}{
  \begin{tabular}{cc}
    \AxiomC{$\myjud{\myse{P}}{\myprdec{\mytya \myeq \mytyb}}$}
    \AxiomC{$\myjud{\mytmt}{\mytya}$}
    \BinaryInfC{$\myjud{\mycoee{\mytya}{\mytyb}{\myse{P}}{\mytmt}}{\mytyb}$}
    \DisplayProof
    &
  \AxiomC{$\myjud{\myse{P}}{\myprdec{\mytya \myeq \mytyb}}$}
  \AxiomC{$\myjud{\mytmt}{\mytya}$}
  \BinaryInfC{$\myjud{\mycohh{\mytya}{\mytyb}{\myse{P}}{\mytmt}}{\myprdec{\myjm{\mytmt}{\mytya}{\mycoee{\mytya}{\mytyb}{\myse{P}}{\mytmt}}{\mytyb}}}$}
  \DisplayProof

  \end{tabular}
}

\mydesc{propositions:}{\myjud{\myprsyn}{\myprop}}{
    \begin{tabular}{cc}
      \AxiomC{$
        \begin{array}{l}
          \ \\
          \myjud{\myse{A}}{\mytyp} \hspace{1cm} \myjud{\myse{B}}{\mytyp}
        \end{array}
        $}
      \UnaryInfC{$\myjud{\mytya \myeq \mytyb}{\myprop}$}
      \DisplayProof
      &
      \AxiomC{$
        \begin{array}{c}
          \myjud{\myse{A}}{\mytyp} \hspace{1cm} \myjud{\mytmm}{\myse{A}} \\
          \myjud{\myse{B}}{\mytyp} \hspace{1cm} \myjud{\mytmn}{\myse{B}}
        \end{array}
        $}
    \UnaryInfC{$\myjud{\myjm{\mytmm}{\myse{A}}{\mytmn}{\myse{B}}}{\myprop}$}
    \DisplayProof

    \end{tabular}
}


While isolating a propositional universe as presented can be a useful
exercises on its own, what we are really after is a useful notion of
equality.  In OTT we want to maintain the notion that things judged to
be equal are still always repleaceable for one another with no
additional changes.  Note that this is not the same as saying that they
are definitionally equal, since as we saw extensionally equal functions,
while satisfying the above requirement, are not definitionally equal.

Towards this goal we introduce two equality constructs in
$\myprop$---the fact that they are in $\myprop$ indicates that they
indeed have no computational content.  The first construct, $\myarg
\myeq \myarg$, relates types, the second,
$\myjm{\myarg}{\myarg}{\myarg}{\myarg}$, relates values.  The
value-level equality is different from our old propositional equality:
instead of ranging over only one type, we might form equalities between
values of different types---the usefulness of this construct will be
clear soon.  In the literature this equality is known as `heterogeneous'
or `John Major', since

\begin{quote}
  John Major's `classless society' widened people's aspirations to
  equality, but also the gap between rich and poor. After all, aspiring
  to be equal to others than oneself is the politics of envy. In much
  the same way, forms equations between members of any type, but they
  cannot be treated as equals (ie substituted) unless they are of the
  same type. Just as before, each thing is only equal to
  itself. \citep{McBride1999}.
\end{quote}

Correspondingly, at the term level, $\myfun{coe}$ (`coerce') lets us
transport values between equal types; and $\myfun{coh}$ (`coherence')
guarantees that $\myfun{coe}$ respects the value-level equality, or in
other words that it really has no computational component: if we
transport $\mytmm : \mytya$ to $\mytmn : \mytyb$, $\mytmm$ and $\mytmn$
will still be the same.

Before introducing the core ideas that make OTT work, let us distinguish
between \emph{canonical} and \emph{neutral} types.  Canonical types are
those arising from the ground types ($\myempty$, $\myunit$, $\mybool$)
and the three type formers ($\myarr$, $\myprod$, $\mytyc{W}$).  Neutral
types are those formed by
$\myfun{If}\myarg\myfun{Then}\myarg\myfun{Else}\myarg$.
Correspondingly, canonical terms are those inhabiting canonical types
($\mytt$, $\mytrue$, $\myfalse$, $\myabss{\myb{x}}{\mytya}{\mytmt}$,
...), and neutral terms those formed by eliminators\footnote{Using the
  terminology from section \ref{sec:types}, we'd say that canonical
  terms are in \emph{weak head normal form}.}.  In the current system
(and hopefully in well-behaved systems), all closed terms reduce to a
canonical term, and all canonical types are inhabited by canonical
terms.

\subsubsection{Type equality, and coercions}

The plan is to decompose type-level equalities between canonical types
into decodable propositions containing equalities regarding the
subterms, and to use coerce recursively on the subterms using the
generated equalities.  This interplay between type equalities and
\myfun{coe} ensures that invocations of $\myfun{coe}$ will vanish when
we have evidence of the structural equality of the types we are
transporting terms across.  If the type is neutral, the equality won't
reduce and thus $\myfun{coe}$ won't reduce either.  If we come an
equality between different canonical types, then we reduce the equality
to bottom, making sure that no such proof can exist, and providing an
`escape hatch' in $\myfun{coe}$.

\begin{figure}[t]

\mydesc{equality reduction:}{\myprsyn \myred \myprsyn}{
    $
      \begin{array}{c@{\ }c@{\ }c@{\ }l}
        \myempty & \myeq & \myempty & \myred \mytop \\
        \myunit  & \myeq &  \myunit & \myred  \mytop \\
        \mybool  & \myeq &  \mybool &   \myred  \mytop \\
        \myexi{\myb{x_1}}{\mytya_1}{\mytyb_1} & \myeq & \myexi{\myb{x_2}}{\mytya_2}{\mytya_2} & \myred \\
        \multicolumn{4}{l}{
          \myind{2} \mytya_1 \myeq \mytyb_1 \myand 
                  \myprfora{\myb{x_1}}{\mytya_1}{\myprfora{\myb{x_2}}{\mytya_2}{\myjm{\myb{x_1}}{\mytya_1}{\myb{x_2}}{\mytya_2}} \myimpl \mytyb_1 \myeq \mytyb_2}
                  } \\
      \myfora{\myb{x_1}}{\mytya_1}{\mytyb_1} & \myeq & \myfora{\myb{x_2}}{\mytya_2}{\mytyb_2} & \myred \cdots \\
      \myw{\myb{x_1}}{\mytya_1}{\mytyb_1} & \myeq & \myw{\myb{x_2}}{\mytya_2}{\mytyb_2} & \myred \cdots \\
      \mytya & \myeq & \mytyb & \myred \mybot\ \text{if $\mytya$ and $\mytyb$ are canonical.}
      \end{array}
    $
}
\myderivsp
\mydesc{reduction}{\mytmsyn \myred \mytmsyn}{
  $
  \begin{array}[t]{@{}l@{\ }l@{\ }l@{\ }l@{\ }l@{\ }c@{\ }l@{\ }}
    \mycoe & \myempty & \myempty & \myse{Q} & \myse{t} & \myred & \myse{t} \\
    \mycoe & \myunit  & \myunit  & \myse{Q} & \mytt & \myred & \mytt \\
    \mycoe & \mybool  & \mybool  & \myse{Q} & \mytrue & \myred & \mytrue \\
    \mycoe & \mybool  & \mybool  & \myse{Q} & \myfalse & \myred & \myfalse \\
    \mycoe & (\myexi{\myb{x_1}}{\mytya_1}{\mytyb_1}) &
             (\myexi{\myb{x_2}}{\mytya_2}{\mytyb_2}) & \myse{Q} &
             \mytmt_1 & \myred & \\
             \multicolumn{7}{l}{
             \myind{2}\begin{array}[t]{l@{\ }l@{\ }c@{\ }l}
               \mysyn{let} & \myb{\mytmm_1} & \mapsto & \myapp{\myfst}{\mytmt_1} : \mytya_1 \\
                           & \myb{\mytmn_1} & \mapsto & \myapp{\mysnd}{\mytmt_1} : \mysub{\mytyb_1}{\myb{x_1}}{\myb{\mytmm_1}} \\
                           & \myb{Q_A}      & \mapsto & \myapp{\myfst}{\myse{Q}} : \mytya_1 \myeq \mytya_2 \\
                           & \myb{\mytmm_2} & \mapsto & \mycoee{\mytya_1}{\mytya_2}{\myb{Q_A}}{\myb{\mytmm_1}} : \mytya_2 \\
                           & \myb{Q_B}      & \mapsto & (\myapp{\mysnd}{\myse{Q}}) \myappsp \myb{\mytmm_1} \myappsp \myb{\mytmm_2} \myappsp (\mycohh{\mytya_1}{\mytya_2}{\myb{Q_A}}{\myb{\mytmm_1}}) : \\ & & & \myprdec{\mysub{\mytyb_1}{\myb{x_1}}{\myb{\mytmm_1}} \myeq \mysub{\mytyb_2}{\myb{x_2}}{\myb{\mytmm_2}}} \\
                           & \myb{\mytmn_2} & \mapsto & \mycoee{\mysub{\mytyb_1}{\myb{x_1}}{\myb{\mytmm_1}}}{\mysub{\mytyb_2}{\myb{x_2}}{\myb{\mytmm_2}}}{\myb{Q_B}}{\myb{\mytmn_1}} : \mysub{\mytyb_2}{\myb{x_2}}{\myb{\mytmm_2}} \\
               \mysyn{in}  & \multicolumn{3}{@{}l}{\mypair{\myb{\mytmm_2}}{\myb{\mytmn_2}}}
              \end{array}} \\

    \mycoe & (\myfora{\myb{x_1}}{\mytya_1}{\mytyb_1}) &
             (\myfora{\myb{x_2}}{\mytya_2}{\mytyb_2}) & \myse{Q} &
             \mytmt & \myred &
           \cdots \\

    \mycoe & (\myw{\myb{x_1}}{\mytya_1}{\mytyb_1}) &
             (\myw{\myb{x_2}}{\mytya_2}{\mytyb_2}) & \myse{Q} &
             \mytmt & \myred &
           \cdots \\

    \mycoe & \mytya & \mytyb & \myse{Q} & \mytmt & \myred &  \\
    \multicolumn{7}{l}{
      \myind{2}\myapp{\myabsurd{\mytyb}}{\myse{Q}}\ \text{if $\mytya$ and $\mytyb$ are canonical.}
    }
  \end{array}
  $
}
\caption{Reducing type equalities, and using them when
  $\myfun{coe}$rcing.}
\label{fig:eqred}
\end{figure}

Figure \ref{fig:eqred} illustrates this idea in practice.  For ground
types, the proof is the trivial element, and \myfun{coe} is the
identity.  For the three type binders, things are similar but subtly
different---the choices we make in the type equality are dictated by
the desire of writing the $\myfun{coe}$ in a natural way.

$\myprod$ is the easiest case: we decompose the proof into proofs that
the first element's types are equal ($\mytya_1 \myeq \mytya_2$), and a
proof that given equal values in the first element, the types of the
second elements are equal too
($\myprfora{\myb{x_1}}{\mytya_1}{\myprfora{\myb{x_2}}{\mytya_2}{\myjm{\myb{x_1}}{\mytya_1}{\myb{x_2}}{\mytya_2}}
  \myimpl \mytyb_1 \myeq \mytyb_2}$)\footnote{We are using $\myimpl$ to
  indicate a $\forall$ where we discard the first value.  Also note that
  the $\myb{x_1}$ in the $\mytyb_1$ inside the $\forall$ is re-bound to
  the quantification, and similarly for $\myb{x_2}$ and $\mytyb_2$.}.
This also explains the need for heterogeneous equality, since in the
second proof it would be awkward to express the fact that $\myb{A_1}$ is
the same as $\myb{A_2}$.  In the respective $\myfun{coe}$ case, since
the types are canonical, we know at this point that the proof of
equality is a pair of the shape described above.  Thus, we can
immediately coerce the first element of the pair using the first element
of the proof, and then instantiate the second element with the two first
elements and a proof by coherence of their equality, since we know that
the types are equal.  The cases for the other binders are omitted for
brevity, but they follow the same principle.

\subsubsection{$\myfun{coe}$, laziness, and $\myfun{coh}$erence}

It is important to notice that in the reduction rules for $\myfun{coe}$
are never obstructed by the proofs: with the exception of comparisons
between different canonical types we never pattern match on the pairs,
but always look at the projections.  This means that, as long as we are
consistent, and thus as long as we don't have $\mybot$-inducing proofs,
we can add propositional axioms for equality and $\myfun{coe}$ will
still compute.  Thus, we can take $\myfun{coh}$ as axiomatic, and we can
add back familiar useful equality rules:

\mydesc{typing:}{\myjud{\mytmsyn}{\mytmsyn}}{
  \AxiomC{$\myjud{\mytmt}{\mytya}$}
  \UnaryInfC{$\myjud{\myapp{\myrefl}{\mytmt}}{\myprdec{\myjm{\myb{x}}{\myb{\mytya}}{\myb{x}}{\myb{\mytya}}}}$}
  \DisplayProof
  
  \myderivsp
  
  \AxiomC{$\myjud{\mytya}{\mytyp}$}
  \AxiomC{$\myjudd{\myctx; \myb{x} : \mytya}{\mytyb}{\mytyp}$}
  \BinaryInfC{$\myjud{\mytyc{R} \myappsp (\myb{x} {:} \mytya) \myappsp \mytyb}{\myfora{\myb{y}\, \myb{z}}{\mytya}{\myprdec{\myjm{\myb{y}}{\mytya}{\myb{z}}{\mytya} \myimpl \mysub{\mytyb}{\myb{x}}{\myb{y}} \myeq \mysub{\mytyb}{\myb{x}}{\myb{z}}}}}$}
  \DisplayProof
}

$\myrefl$ is the equivalent of the reflexivity rule in propositional
equality, and $\mytyc{R}$ asserts that if we have a we have a $\mytyp$
abstracting over a value we can substitute equal for equal---this lets
us recover $\myfun{subst}$.  Note that while we need to provide ad-hoc
rules in the restricted, non-hierarchical theory that we have, if our
theory supports abstraction over $\mytyp$s we can easily add these
axioms as abstracted variables.

\subsubsection{Value-level equality}

\mydesc{equality reduction:}{\myprsyn \myred \myprsyn}{
  $
  \begin{array}{r@{ }c@{\ }c@{\ }c@{}l@{\ }c@{\ }r@{}c@{\ }c@{\ }c@{}l@{\ }l}
    (&\mytmt_1 & : & \myempty&) & \myeq & (&\mytmt_2 & : & \myempty &) & \myred \mytop \\
    (&\mytmt_1 & : & \myempty&) & \myeq & (&\mytmt_2 & : & \myempty&) & \myred \mytop \\
    (&\mytrue & : & \mybool&) & \myeq & (&\mytrue & : & \mybool&) & \myred \mytop \\
    (&\myfalse & : & \mybool&) & \myeq & (&\myfalse & : & \mybool&) & \myred \mytop \\
    (&\mytmt_1 & : & \mybool&) & \myeq & (&\mytmt_1 & : & \mybool&) & \myred \mybot \\
    (&\mytmt_1 & : & \myexi{\mytya_1}{\myb{x_1}}{\mytyb_1}&) & \myeq & (&\mytmt_2 & : & \myexi{\mytya_2}{\myb{x_2}}{\mytyb_2}&) & \myred \\
     & \multicolumn{11}{@{}l}{
      \myind{2} \myjm{\myapp{\myfst}{\mytmt_1}}{\mytya_1}{\myapp{\myfst}{\mytmt_2}}{\mytya_2} \myand
      \myjm{\myapp{\mysnd}{\mytmt_1}}{\mysub{\mytyb_1}{\myb{x_1}}{\myapp{\myfst}{\mytmt_1}}}{\myapp{\mysnd}{\mytmt_2}}{\mysub{\mytyb_2}{\myb{x_2}}{\myapp{\myfst}{\mytmt_2}}}
    } \\
   (&\myse{f}_1 & : & \myfora{\mytya_1}{\myb{x_1}}{\mytyb_1}&) & \myeq & (&\myse{f}_2 & : & \myfora{\mytya_2}{\myb{x_2}}{\mytyb_2}&) & \myred \\
     & \multicolumn{11}{@{}l}{
       \myind{2} \myprfora{\myb{x_1}}{\mytya_1}{\myprfora{\myb{x_2}}{\mytya_2}{
           \myjm{\myb{x_1}}{\mytya_1}{\myb{x_2}}{\mytya_2} \myimpl
           \myjm{\myapp{\myse{f}_1}{\myb{x_1}}}{\mytyb_1}{\myapp{\myse{f}_2}{\myb{x_2}}}{\mytyb_2}
         }}
    } \\
   (&\mytmt_1 \mynodee \myse{f}_1 & : & \myw{\mytya_1}{\myb{x_1}}{\mytyb_1}&) & \myeq & (&\mytmt_1 \mynodee \myse{f}_1 & : & \myw{\mytya_2}{\myb{x_2}}{\mytyb_2}&) & \myred \cdots \\
    (&\mytmt_1 & : & \mytya_1&) & \myeq & (&\mytmt_2 & : & \mytya_2 &) & \myred \\
    & \multicolumn{11}{@{}l}{
      \myind{2} \mybot\ \text{if $\mytya_1$ and $\mytya_2$ are canonical.}
    }
  \end{array}
  $
}

As with type-level equality, we want value-level equality to reduce
based on the structure of the compared terms.

\subsection{Proof irrelevance}

% \section{Augmenting ITT}
% \label{sec:practical}

% \subsection{A more liberal hierarchy}

% \subsection{Type inference}

% \subsubsection{Bidirectional type checking}

% \subsubsection{Pattern unification}

% \subsection{Pattern matching and explicit fixpoints}

% \subsection{Induction-recursion}

% \subsection{Coinduction}

% \subsection{Dealing with partiality}

% \subsection{Type holes}

\section{\mykant : the theory}
\label{sec:kant-theory}

\mykant\ is an interactive theorem prover developed as part of this thesis.
The plan is to present a core language which would be capable of serving as
the basis for a more featureful system, while still presenting interesting
features and more importantly observational equality.

The author learnt the hard way the implementations challenges for such a
project, and while there is a solid and working base to work on, observational
equality is not currently implemented.  However, a detailed plan on how to add
it this functionality is provided, and should not prove to be too much work.

The features currently implemented in \mykant\ are:

\begin{description}
\item[Full dependent types] As we would expect, we have dependent a system
  which is as expressive as the `best' corner in the lambda cube described in
  section \ref{sec:itt}.

\item[Implicit, cumulative universe hierarchy] The user does not need to
  specify universe level explicitly, and universes are \emph{cumulative}.

\item[User defined data types and records] Instead of forcing the user to
  choose from a restricted toolbox, we let her define inductive data types,
  with associated primitive recursion operators; or records, with associated
  projections for each field.

\item[Bidirectional type checking] While no `fancy' inference via unification
  is present, we take advantage of an type synthesis system in the style of
  \cite{Pierce2000}, extending the concept for user defined data types.

\item[Type holes] When building up programs interactively, it is useful to
  leave parts unfinished while exploring the current context.  This is what
  type holes are for.
\end{description}

The planned features are:

\begin{description}
\item[Observational equality] As described in section \ref{sec:ott} but
  extended to work with the type hierarchy and to admit equality between
  arbitrary data types.

\item[Coinductive data] ...
\end{description}

We will analyse the features one by one, along with motivations and tradeoffs
for the design decisions made.

\subsection{Bidirectional type checking}

We start by describing bidirectional type checking since it calls for fairly
different typing rules that what we have seen up to now.  The idea is to have
two kind of terms: terms for which a type can always be inferred, and terms
that need to be checked against a type.  A nice observation is that this
duality runs through the semantics of the terms: data destructors (function
application, record projections, primitive re cursors) \emph{infer} types,
while data constructors (abstractions, record/data types data constructors)
need to be checked.  In the literature these terms are respectively known as

To introduce the concept and notation, we will revisit the STLC in a
bidirectional style.  The presentation follows \cite{Loh2010}.

% TODO do this --- is it even necessary

% The syntax of 

\subsection{Base terms and types}

Let us begin by describing the primitives available without the user
defining any data types, and without equality.  The way we handle
variables and substitution is left unspecified, and explained in section
\ref{sec:term-repr}, along with other implementation issues.  We are
also going to give an account of the implicit type hierarchy separately
in section \ref{sec:term-hierarchy}, so as not to clutter derivation
rules too much, and just treat types as impredicative for the time
being.

\mydesc{syntax}{ }{
  $
  \begin{array}{r@{\ }c@{\ }l}
    \mytmsyn & ::= & \mynamesyn \mysynsep \mytyp \\
    &  |  & \myfora{\myb{x}}{\mytmsyn}{\mytmsyn} \mysynsep
    \myabs{\myb{x}}{\mytmsyn} \mysynsep
    (\myapp{\mytmsyn}{\mytmsyn}) \mysynsep
    (\myann{\mytmsyn}{\mytmsyn}) \\
    \mynamesyn & ::= & \myb{x} \mysynsep \myfun{f}
  \end{array}
  $
}

The syntax for our calculus includes just two basic constructs:
abstractions and $\mytyp$s.  Everything else will be provided by
user-definable constructs.  Since we let the user define values, we will
need a context capable of carrying the body of variables along with
their type.  Bound names and defined names are treated separately in the
syntax, and while both can be associated to a type in the context, only
defined names can be associated with a body:

\mydesc{context validity:}{\myvalid{\myctx}}{
    \begin{tabular}{ccc}
      \AxiomC{\phantom{$\myjud{\mytya}{\mytyp_l}$}}
      \UnaryInfC{$\myvalid{\myemptyctx}$}
      \DisplayProof
      &
      \AxiomC{$\myjud{\mytya}{\mytyp}$}
      \AxiomC{$\mynamesyn \not\in \myctx$}
      \BinaryInfC{$\myvalid{\myctx ; \mynamesyn : \mytya}$}
      \DisplayProof
      &
      \AxiomC{$\myjud{\mytmt}{\mytya}$}
      \AxiomC{$\myfun{f} \not\in \myctx$}
      \BinaryInfC{$\myvalid{\myctx ; \myfun{f} \mapsto \mytmt : \mytya}$}
      \DisplayProof
    \end{tabular}
}

Now we can present the reduction rules, which are unsurprising.  We have
the usual function application ($\beta$-reduction), but also a rule to
replace names with their bodies ($\delta$-reduction), and one to discard
type annotations.  For this reason reduction is done in-context, as
opposed to what we have seen in the past:

\mydesc{reduction:}{\myctx \vdash \mytmsyn \myred \mytmsyn}{
    \begin{tabular}{ccc}
      \AxiomC{\phantom{$\myb{x} \mapsto \mytmt : \mytya \in \myctx$}}
      \UnaryInfC{$\myctx \vdash \myapp{(\myabs{\myb{x}}{\mytmm})}{\mytmn}
                  \myred \mysub{\mytmm}{\myb{x}}{\mytmn}$}
      \DisplayProof
      &
      \AxiomC{$\myfun{f} \mapsto \mytmt : \mytya \in \myctx$}
      \UnaryInfC{$\myctx \vdash \myfun{f} \myred \mytmt$}
      \DisplayProof
      &
      \AxiomC{\phantom{$\myb{x} \mapsto \mytmt : \mytya \in \myctx$}}
      \UnaryInfC{$\myctx \vdash \myann{\mytmm}{\mytya} \myred \mytmm$}
      \DisplayProof
    \end{tabular}
}

We can now give types to our terms.  The type of names, both defined and
abstract, is inferred.  The type of applications is inferred too,
propagating types down the applied term.  Abstractions are checked.
Finally, we have a rule to check the type of an inferrable term.  We
defer the question of term equality (which is needed for type checking)
to section \label{sec:kant-irr}.

\mydesc{typing:}{\myctx \vdash \mytmsyn \Leftrightarrow \mytmsyn}{   
    \begin{tabular}{ccc}
      \AxiomC{$\myse{name} : A \in \myctx$}
      \UnaryInfC{$\myinf{\myse{name}}{A}$}
      \DisplayProof
      &
      \AxiomC{$\myfun{f} \mapsto \mytmt : A \in \myctx$}
      \UnaryInfC{$\myinf{\myfun{f}}{A}$}
      \DisplayProof
      &
      \AxiomC{$\myinf{\mytmt}{\mytya}$}
      \UnaryInfC{$\mychk{\myann{\mytmt}{\mytya}}{\mytya}$}
      \DisplayProof
    \end{tabular}
    \myderivsp

    \begin{tabular}{ccc}
      \AxiomC{$\myinf{\mytmm}{\myfora{\myb{x}}{\mytya}{\mytyb}}$}
      \AxiomC{$\mychk{\mytmn}{\mytya}$}
      \BinaryInfC{$\myinf{\myapp{\mytmm}{\mytmn}}{\mysub{\mytyb}{\myb{x}}{\mytmn}}$}
      \DisplayProof

      &

      \AxiomC{$\mychkk{\myctx; \myb{x}: \mytya}{\mytmt}{\mytyb}$}
      \UnaryInfC{$\mychk{\myabs{\myb{x}}{\mytmt}}{\myfora{\myb{x}}{\mytyb}{\mytyb}}$}
      \DisplayProof
    \end{tabular}
}

\subsection{Elaboration}

As we mentioned, $\mykant$\ allows the user to define not only values
but also custom data types and records.  \emph{Elaboration} consists of
turning these declarations into workable syntax, types, and reduction
rules.  The treatment of custom types in $\mykant$\ is heavily inspired
by McBride and McKinna early work on Epigram \citep{McBride2004},
although with some differences.

\subsubsection{Term vectors, telescopes, and assorted notation}

We use a vector notation to refer to a series of term applied to
another, for example $\mytyc{D} \myappsp \vec{A}$ is a shorthand for
$\mytyc{D} \myappsp \mytya_1 \cdots \mytya_n$, for some $n$.  $n$ is
consistently used to refer to the length of such vectors, and $i$ to
refer to an index in such vectors.  We also often need to `build up'
terms vectors, in which case we use $\myemptyctx$ for an empty vector
and add elements to an existing vector with $\myarg ; \myarg$, similarly
to what we do for context.

To present the elaboration and operations on user defined data types, we
frequently make use what de Bruijn called \emph{telescopes}
\citep{Bruijn91}, a construct that will prove useful when dealing with
the types of type and data constructors.  A telescope is a series of
nested typed bindings, such as $(\myb{x} {:} \mynat); (\myb{p} :
\myapp{\myfun{even}}{\myb{x}})$.  Consistently with the notation for
contexts and term vectors, we use $\myemptyctx$ to denote an empty
telescope and $\myarg ; \myarg$ to add a new binding to an existing
telescope.

We refer to telescopes with $\mytele$, $\mytele'$, $\mytele_i$, etc.  If
$\mytele$ refers to a telescope, $\mytelee$ refers to the term vector
made up of all the variables bound by $\mytele$.  $\mytele \myarr
\mytya$ refers to the type made by turning the telescope into a series
of $\myarr$.  Returning to the examples above, we have that
{\small\[
   (\myb{x} {:} \mynat); (\myb{p} : \myapp{\myfun{even}}{\myb{x}}) \myarr \mynat =
   (\myb{x} {:} \mynat) \myarr (\myb{p} : \myapp{\myfun{even}}{\myb{x}}) \myarr \mynat
\]}

We make use of various operations to manipulate telescopes:
\begin{itemize}
\item $\myhead(\mytele)$ refers to the first type appearing in
  $\mytele$: $\myhead((\myb{x} {:} \mynat); (\myb{p} :
  \myapp{\myfun{even}}{\myb{x}})) = \mynat$.  Similarly,
  $\myix_i(\mytele)$ refers to the $i^{th}$ type in a telescope
  (1-indexed).
\item $\mytake_i(\mytele)$ refers to the telescope created by taking the
  first $i$ elements of $\mytele$:  $\mytake_1((\myb{x} {:} \mynat); (\myb{p} :
  \myapp{\myfun{even}}{\myb{x}})) = (\myb{x} {:} \mynat)$
\item $\mytele \vec{A}$ refers to the telescope made by `applying' the
  terms in $\vec{A}$ on $\mytele$: $((\myb{x} {:} \mynat); (\myb{p} :
  \myapp{\myfun{even}}{\myb{x}}))42 = (\myb{p} :
  \myapp{\myfun{even}}{42})$.
\end{itemize}

\subsubsection{Declarations syntax}

\mydesc{syntax}{ }{
  $
  \begin{array}{r@{\ }c@{\ }l}
      \mydeclsyn & ::= & \myval{\myb{x}}{\mytmsyn}{\mytmsyn} \\
                 &  |  & \mypost{\myb{x}}{\mytmsyn} \\
                 &  |  & \myadt{\mytyc{D}}{\mytelesyn}{}{\mydc{c} : \mytelesyn\ |\ \cdots } \\
                 &  |  & \myreco{\mytyc{D}}{\mytelesyn}{}{\myfun{f} : \mytmsyn,\ \cdots } \\

      \mytelesyn & ::= & \myemptytele \mysynsep \mytelesyn \mycc (\myb{x} {:} \mytmsyn) \\
      \mynamesyn & ::= & \cdots \mysynsep \mytyc{D} \mysynsep \mytyc{D}.\mydc{c} \mysynsep \mytyc{D}.\myfun{f}
  \end{array}
  $
}

In \mykant\ we have four kind of declarations:

\begin{description}
\item[Defined value] A variable, together with a type and a body.
\item[Abstract variable] An abstract variable, with a type but no body.
\item[Inductive data] A datatype, with a type constructor and various data
  constructors---somewhat similar to what we find in Haskell.  A primitive
  recursor (or `destructor') will be generated automatically.
\item[Record] A record, which consists of one data constructor and various
  fields, with no recursive occurrences.
\end{description}

Elaborating defined variables consists of type checking body against the
given type, and updating the context to contain the new binding.
Elaborating abstract variables and abstract variables consists of type
checking the type, and updating the context with a new typed variable:

\mydesc{context elaboration:}{\myelab{\mydeclsyn}{\myctx}}{
    \begin{tabular}{cc}
      \AxiomC{$\myjud{\mytmt}{\mytya}$}
      \AxiomC{$\myfun{f} \not\in \myctx$}
      \BinaryInfC{
        $\myctx \myelabt \myval{\myfun{f}}{\mytya}{\mytmt} \ \ \myelabf\ \  \myctx; \myfun{f} \mapsto \mytmt : \mytya$
      }
      \DisplayProof
      &
      \AxiomC{$\myjud{\mytya}{\mytyp}$}
      \AxiomC{$\myfun{f} \not\in \myctx$}
      \BinaryInfC{
        $
          \myctx \myelabt \mypost{\myfun{f}}{\mytya}
          \ \ \myelabf\ \  \myctx; \myfun{f} : \mytya
        $
      }
      \DisplayProof
    \end{tabular}
}

\subsubsection{User defined types}

\begin{figure}[p]
  \begin{subfigure}[b]{\textwidth}
    \vspace{-1cm}
    \mydesc{syntax}{ }{
      \footnotesize
      $
      \begin{array}{l}
        \mynamesyn ::= \cdots \mysynsep \mytyc{D} \mysynsep \mytyc{D}.\mydc{c} \mysynsep \mytyc{D}.\myfun{f}
      \end{array}
      $
    }

  \mydesc{syntax elaboration:}{\mydeclsyn \myelabf \mytmsyn ::= \cdots}{
    \footnotesize
      $
      \begin{array}{r@{\ }l}
         & \myadt{\mytyc{D}}{\mytele}{}{\cdots\ |\ \mydc{c}_n : \mytele_n } \\
        \myelabf &
        
        \begin{array}{r@{\ }c@{\ }l}
          \mytmsyn & ::= & \cdots \mysynsep \myapp{\mytyc{D}}{\mytmsyn^{\mytele}} \mysynsep \cdots \mysynsep
          \mytyc{D}.\mydc{c}_n \myappsp \mytmsyn^{\mytele_n} \mysynsep \mytyc{D}.\myfun{elim} \myappsp \mytmsyn \\
        \end{array}
      \end{array}
      $
  }

  \mydesc{context elaboration:}{\myelab{\mydeclsyn}{\myctx}}{
        \footnotesize

      \AxiomC{$
        \begin{array}{c}
          \myinf{\mytele \myarr \mytyp}{\mytyp}\hspace{0.8cm}
          \mytyc{D} \not\in \myctx \\
          \myinff{\myctx;\ \mytyc{D} : \mytele \myarr \mytyp}{\mytele \mycc \mytele_i \myarr \myapp{\mytyc{D}}{\mytelee}}{\mytyp}\ \ \ (1 \leq i \leq n) \\
          \text{For each $(\myb{x} {:} \mytya)$ in each $\mytele_i$, if $\mytyc{D} \in \mytya$, then $\mytya = \myapp{\mytyc{D}}{\vec{\mytmt}}$.}
        \end{array}
          $}
      \UnaryInfC{$
        \begin{array}{r@{\ }c@{\ }l}
          \myctx & \myelabt & \myadt{\mytyc{D}}{\mytele}{}{ \cdots \ |\ \mydc{c}_n : \mytele_n } \\
          & & \vspace{-0.2cm} \\
          & \myelabf & \myctx;\ \mytyc{D} : \mytele \myarr \mytyp;\ \cdots;\ \mytyc{D}.\mydc{c}_n : \mytele \mycc \mytele_n \myarr \myapp{\mytyc{D}}{\mytelee}; \\
          &          &
          \begin{array}{@{}r@{\ }l l}
            \mytyc{D}.\myfun{elim} : & \mytele \myarr (\myb{x} {:} \myapp{\mytyc{D}}{\mytelee}) \myarr & \textbf{target} \\
            & (\myb{P} {:} \myapp{\mytyc{D}}{\mytelee} \myarr \mytyp) \myarr & \textbf{motive} \\
            & \left.
              \begin{array}{@{}l}
                \myind{3} \vdots \\
                (\mytele_n \mycc \myhyps(\myb{P}, \mytele_n) \myarr \myapp{\myb{P}}{(\myapp{\mytyc{D}.\mydc{c}_n}{\mytelee_n})}) \myarr
              \end{array} \right \}
            & \textbf{methods}  \\
            & \myapp{\myb{P}}{\myb{x}} &
          \end{array}
        \end{array}
        $}
      \DisplayProof \\ \vspace{0.2cm}\ \\
      $
        \begin{array}{@{}l l@{\ } l@{} r c l}
          \textbf{where} & \myhyps(\myb{P}, & \myemptytele &) & \mymetagoes & \myemptytele \\
          & \myhyps(\myb{P}, & (\myb{r} {:} \myapp{\mytyc{D}}{\vec{\mytmt}}) \mycc \mytele &) & \mymetagoes & (\myb{r'} {:} \myapp{\myb{P}}{\myb{r}}) \mycc \myhyps(\myb{P}, \mytele) \\
          & \myhyps(\myb{P}, & (\myb{x} {:} \mytya) \mycc \mytele & ) & \mymetagoes & \myhyps(\myb{P}, \mytele)
        \end{array}
        $

  }

  \mydesc{reduction elaboration:}{\mydeclsyn \myelabf \myctx \vdash \mytmsyn \myred \mytmsyn}{  
        \footnotesize
        $\myadt{\mytyc{D}}{\mytele}{}{ \cdots \ |\ \mydc{c}_n : \mytele_n } \ \ \myelabf$
      \AxiomC{$\mytyc{D} : \mytele \myarr \mytyp \in \myctx$}
      \AxiomC{$\mytyc{D}.\mydc{c}_i : \mytele;\mytele_i \myarr \myapp{\mytyc{D}}{\mytelee} \in \myctx$}
      \BinaryInfC{$
          \myctx \vdash \myapp{\myapp{\myapp{\mytyc{D}.\myfun{elim}}{(\myapp{\mytyc{D}.\mydc{c}_i}{\vec{\myse{t}}})}}{\myse{P}}}{\vec{\myse{m}}} \myred \myapp{\myapp{\myse{m}_i}{\vec{\mytmt}}}{\myrecs(\myse{P}, \vec{m}, \mytele_i)}
        $}
      \DisplayProof \\ \vspace{0.2cm}\ \\
      $
        \begin{array}{@{}l l@{\ } l@{} r c l}
          \textbf{where} & \myrecs(\myse{P}, \vec{m}, & \myemptytele &) & \mymetagoes & \myemptytele \\
                         & \myrecs(\myse{P}, \vec{m}, & (\myb{r} {:} \myapp{\mytyc{D}}{\vec{A}}); \mytele & ) & \mymetagoes &  (\mytyc{D}.\myfun{elim} \myappsp \myb{r} \myappsp \myse{P} \myappsp \vec{m}); \myrecs(\myse{P}, \vec{m}, \mytele) \\
                         & \myrecs(\myse{P}, \vec{m}, & (\myb{x} {:} \mytya); \mytele &) & \mymetagoes & \myrecs(\myse{P}, \vec{m}, \mytele)
        \end{array}
        $
  }
  \end{subfigure}

  \begin{subfigure}[b]{\textwidth}
    \mydesc{syntax elaboration:}{\myelab{\mydeclsyn}{\mytmsyn ::= \cdots}}{
          \footnotesize
    $
    \begin{array}{r@{\ }c@{\ }l}
      \myctx & \myelabt & \myreco{\mytyc{D}}{\mytele}{}{ \cdots, \myfun{f}_n : \myse{F}_n } \\
             & \myelabf &

             \begin{array}{r@{\ }c@{\ }l}
               \mytmsyn & ::= & \cdots \mysynsep \myapp{\mytyc{D}}{\mytmsyn^{\mytele}} \mysynsep \mytyc{D}.\mydc{constr} \myappsp \mytmsyn^{n} \mysynsep \cdots  \mysynsep \mytyc{D}.\myfun{f}_n \myappsp \mytmsyn \\
             \end{array}
    \end{array}
    $
}


\mydesc{context elaboration:}{\myelab{\mydeclsyn}{\myctx}}{
      \footnotesize
    \AxiomC{$
      \begin{array}{c}
        \myinf{\mytele \myarr \mytyp}{\mytyp}\hspace{0.8cm}
        \mytyc{D} \not\in \myctx \\
        \myinff{\myctx; \mytele; (\myb{f}_j : \myse{F}_j)_{j=1}^{i - 1}}{F_i}{\mytyp} \myind{3} (1 \le i \le n)
      \end{array}
        $}
    \UnaryInfC{$
      \begin{array}{r@{\ }c@{\ }l}
        \myctx & \myelabt & \myreco{\mytyc{D}}{\mytele}{}{ \cdots, \myfun{f}_n : \myse{F}_n } \\
        & & \vspace{-0.2cm} \\
        & \myelabf & \myctx;\ \mytyc{D} : \mytele \myarr \mytyp;\ \cdots;\ \mytyc{D}.\myfun{f}_n : \mytele \myarr (\myb{x} {:} \myapp{\mytyc{D}}{\mytelee}) \myarr \mysub{\myse{F}_n}{\myb{f}_i}{\myapp{\myfun{f}_i}{\myb{x}}}_{i = 1}^{n-1}; \\
        & & \mytyc{D}.\mydc{constr} : \mytele \myarr \myse{F}_1 \myarr \cdots \myarr \myse{F}_n \myarr \myapp{\mytyc{D}}{\mytelee};
      \end{array}
      $}
    \DisplayProof
}

  \mydesc{reduction elaboration:}{\mydeclsyn \myelabf \myctx \vdash \mytmsyn \myred \mytmsyn}{
        \footnotesize
          $\myreco{\mytyc{D}}{\mytele}{}{ \cdots, \myfun{f}_n : \myse{F}_n } \ \ \myelabf$
          \AxiomC{$\mytyc{D} \in \myctx$}
          \UnaryInfC{$\myctx \vdash \myapp{\mytyc{D}.\myfun{f}_i}{(\mytyc{D}.\mydc{constr} \myappsp \vec{t})} \myred t_i$}
          \DisplayProof
  }

  \end{subfigure}
  \caption{Elaboration for data types and records.}
  \label{fig:elab}
\end{figure}

Elaborating user defined types is the real effort.  First, let's explain
what we can defined, with some examples.

\begin{description}
\item[Natural numbers] To define natural numbers, we create a data type
  with two constructors: one with zero arguments ($\mydc{zero}$) and one
  with one recursive argument ($\mydc{suc}$):
  {\small\[
  \begin{array}{@{}l}
    \myadt{\mynat}{ }{ }{
      \mydc{zero} \mydcsep \mydc{suc} \myappsp \mynat
    }
  \end{array}
  \]}
  This is very similar to what we would write in Haskell:
  {\small\[\text{\texttt{data Nat = Zero | Suc Nat}}\]}
  Once the data type is defined, $\mykant$\ will generate syntactic
  constructs for the type and data constructors, so that we will have
  \begin{center}
    \small
    \begin{tabular}{ccc}
      \AxiomC{\phantom{$\mychk{\mytmt}{\mynat}$}}
      \UnaryInfC{$\myinf{\mynat}{\mytyp}$}
      \DisplayProof
    &
      \AxiomC{\phantom{$\mychk{\mytmt}{\mynat}$}}
      \UnaryInfC{$\myinf{\mytyc{\mynat}.\mydc{zero}}{\mynat}$}
      \DisplayProof
    &
      \AxiomC{$\mychk{\mytmt}{\mynat}$}
      \UnaryInfC{$\myinf{\mytyc{\mynat}.\mydc{suc} \myappsp \mytmt}{\mynat}$}
      \DisplayProof
    \end{tabular}
  \end{center}
  While in Haskell (or indeed in Agda or Coq) data constructors are
  treated the same way as functions, in $\mykant$\ they are syntax, so
  for example using $\mytyc{\mynat}.\mydc{suc}$ on its own will be a
  syntax error.  This is necessary so that we can easily infer the type
  of polymorphic data constructors, as we will see later.

  Moreover, each data constructor is prefixed by the type constructor
  name, since we need to retrieve the type constructor of a data
  constructor when type checking.  This measure aids in the presentation
  of various features but it is not needed in the implementation, where
  we can have a dictionary to lookup the type constructor corresponding
  to each data constructor.  When using data constructors in examples I
  will omit the type constructor prefix for brevity.

  Along with user defined constructors, $\mykant$\ automatically
  generates an \emph{eliminator}, or \emph{destructor}, to compute with
  natural numbers: If we have $\mytmt : \mynat$, we can destruct
  $\mytmt$ using the generated eliminator `$\mynat.\myfun{elim}$':
  \begin{prooftree}
    \small
    \AxiomC{$\mychk{\mytmt}{\mynat}$}
    \UnaryInfC{$
      \myinf{\mytyc{\mynat}.\myfun{elim} \myappsp \mytmt}{
        \begin{array}{@{}l}
          \myfora{\myb{P}}{\mynat \myarr \mytyp}{ \\ \myapp{\myb{P}}{\mydc{zero}} \myarr (\myfora{\myb{x}}{\mynat}{\myapp{\myb{P}}{\myb{x}} \myarr \myapp{\myb{P}}{(\myapp{\mydc{suc}}{\myb{x}})}}) \myarr \\ \myapp{\myb{P}}{\mytmt}}
          \end{array}
        }$}
  \end{prooftree}
  $\mynat.\myfun{elim}$ corresponds to the induction principle for
  natural numbers: if we have a predicate on numbers ($\myb{P}$), and we
  know that predicate holds for the base case
  ($\myapp{\myb{P}}{\mydc{zero}}$) and for each inductive step
  ($\myfora{\myb{x}}{\mynat}{\myapp{\myb{P}}{\myb{x}} \myarr
    \myapp{\myb{P}}{(\myapp{\mydc{suc}}{\myb{x}})}}$), then $\myb{P}$
  holds for any number.  As with the data constructors, we require the
  eliminator to be applied to the `destructed' element.

  While the induction principle is usually seen as a mean to prove
  properties about numbers, in the intuitionistic setting it is also a
  mean to compute.  In this specific case we will $\mynat.\myfun{elim}$
  will return the base case if the provided number is $\mydc{zero}$, and
  recursively apply the inductive step if the number is a
  $\mydc{suc}$cessor:
  {\small\[
  \begin{array}{@{}l@{}l}
    \mytyc{\mynat}.\myfun{elim} \myappsp \mydc{zero} & \myappsp \myse{P} \myappsp \myse{pz} \myappsp \myse{ps} \myred \myse{pz} \\
    \mytyc{\mynat}.\myfun{elim} \myappsp (\mydc{suc} \myappsp \mytmt) & \myappsp \myse{P} \myappsp \myse{pz} \myappsp \myse{ps} \myred \myse{ps} \myappsp \mytmt \myappsp (\mynat.\myfun{elim} \myappsp \mytmt \myappsp \myse{P} \myappsp \myse{pz} \myappsp \myse{ps})
  \end{array}
  \]}
  The Haskell equivalent would be
  {\small\[
    \begin{array}{@{}l}
      \text{\texttt{elim :: Nat -> a -> (Nat -> a -> a) -> a}}\\
      \text{\texttt{elim Zero    pz ps = pz}}\\
      \text{\texttt{elim (Suc n) pz ps = ps n (elim n pz ps)}}
    \end{array}
    \]}
  Which buys us the computational behaviour, but not the reasoning power.
  % TODO maybe more examples, e.g. Haskell eliminator and fibonacci

\item[Binary trees] Now for a polymorphic data type: binary trees, since
  lists are too similar to natural numbers to be interesting.
  {\small\[
  \begin{array}{@{}l}
    \myadt{\mytree}{\myappsp (\myb{A} {:} \mytyp)}{ }{
      \mydc{leaf} \mydcsep \mydc{node} \myappsp (\myapp{\mytree}{\myb{A}}) \myappsp \myb{A} \myappsp (\myapp{\mytree}{\myb{A}})
    }
  \end{array}
  \]}
  Now the purpose of constructors as syntax can be explained: what would
  the type of $\mydc{leaf}$ be?  If we were to treat it as a `normal'
  term, we would have to specify the type parameter of the tree each
  time the constructor is applied:
  {\small\[
  \begin{array}{@{}l@{\ }l}
    \mydc{leaf} & : \myfora{\myb{A}}{\mytyp}{\myapp{\mytree}{\myb{A}}} \\
    \mydc{node} & : \myfora{\myb{A}}{\mytyp}{\myapp{\mytree}{\myb{A}} \myarr \myb{A} \myarr \myapp{\mytree}{\myb{A}} \myarr \myapp{\mytree}{\myb{A}}}
  \end{array}
  \]}
  The problem with this approach is that creating terms is incredibly
  verbose and dull, since we would need to specify the type parameters
  each time.  For example if we wished to create a $\mytree \myappsp
  \mynat$ with two nodes and three leaves, we would have to write
  {\small\[
  \mydc{node} \myappsp \mynat \myappsp (\mydc{node} \myappsp \mynat \myappsp (\mydc{leaf} \myappsp \mynat) \myappsp (\myapp{\mydc{suc}}{\mydc{zero}}) \myappsp (\mydc{leaf} \myappsp \mynat)) \myappsp \mydc{zero} \myappsp (\mydc{leaf} \myappsp \mynat)
  \]}
  The redundancy of $\mynat$s is quite irritating.  Instead, if we treat
  constructors as syntactic elements, we can `extract' the type of the
  parameter from the type that the term gets checked against, much like
  we get the type of abstraction arguments:
  \begin{center}
    \small
    \begin{tabular}{cc}
      \AxiomC{$\mychk{\mytya}{\mytyp}$}
      \UnaryInfC{$\mychk{\mydc{leaf}}{\myapp{\mytree}{\mytya}}$}
      \DisplayProof
      &
      \AxiomC{$\mychk{\mytmm}{\mytree \myappsp \mytya}$}
      \AxiomC{$\mychk{\mytmt}{\mytya}$}
      \AxiomC{$\mychk{\mytmm}{\mytree \myappsp \mytya}$}
      \TrinaryInfC{$\mychk{\mydc{node} \myappsp \mytmm \myappsp \mytmt \myappsp \mytmn}{\mytree \myappsp \mytya}$}
      \DisplayProof
    \end{tabular}
  \end{center}
  Which enables us to write, much more concisely
  {\small\[
  \mydc{node} \myappsp (\mydc{node} \myappsp \mydc{leaf} \myappsp (\myapp{\mydc{suc}}{\mydc{zero}}) \myappsp \mydc{leaf}) \myappsp \mydc{zero} \myappsp \mydc{leaf} : \myapp{\mytree}{\mynat}
  \]}
  We gain an annotation, but we lose the myriad of types applied to the
  constructors.  Conversely, with the eliminator for $\mytree$, we can
  infer the type of the arguments given the type of the destructed:
  \begin{prooftree}
    \footnotesize
    \AxiomC{$\myinf{\mytmt}{\myapp{\mytree}{\mytya}}$}
    \UnaryInfC{$
      \myinf{\mytree.\myfun{elim} \myappsp \mytmt}{
        \begin{array}{@{}l}
          (\myb{P} {:} \myapp{\mytree}{\mytya} \myarr \mytyp) \myarr \\
          \myapp{\myb{P}}{\mydc{leaf}} \myarr \\
          ((\myb{l} {:} \myapp{\mytree}{\mytya}) (\myb{x} {:} \mytya) (\myb{r} {:} \myapp{\mytree}{\mytya}) \myarr \myapp{\myb{P}}{\myb{l}} \myarr
          \myapp{\myb{P}}{\myb{r}} \myarr \myb{P} \myappsp (\mydc{node} \myappsp \myb{l} \myappsp \myb{x} \myappsp \myb{r})) \myarr \\
          \myapp{\myb{P}}{\mytmt}
        \end{array}
      }
      $}
  \end{prooftree}
  As expected, the eliminator embodies structural induction on trees.

\item[Empty type] We have presented types that have at least one
  constructors, but nothing prevents us from defining types with
  \emph{no} constructors:
  {\small\[
  \myadt{\mytyc{Empty}}{ }{ }{ }
  \]}
  What shall the `induction principle' on $\mytyc{Empty}$ be?  Does it
  even make sense to talk about induction on $\mytyc{Empty}$?
  $\mykant$\ does not care, and generates an eliminator with no `cases',
  and thus corresponding to the $\myfun{absurd}$ that we know and love:
  \begin{prooftree}
    \small
    \AxiomC{$\myinf{\mytmt}{\mytyc{Empty}}$}
    \UnaryInfC{$\myinf{\myempty.\myfun{elim} \myappsp \mytmt}{(\myb{P} {:} \mytmt \myarr \mytyp) \myarr \myapp{\myb{P}}{\mytmt}}$}
  \end{prooftree}

\item[Ordered lists] Up to this point, the examples shown are nothing
  new to the \{Haskell, SML, OCaml, functional\} programmer.  However
  dependent types let us express much more than 
  % TODO

\item[Dependent products] Apart from $\mysyn{data}$, $\mykant$\ offers
  us another way to define types: $\mysyn{record}$.  A record is a
  datatype with one constructor and `projections' to extract specific
  fields of the said constructor.

  For example, we can recover dependent products:
  {\small\[
  \begin{array}{@{}l}
    \myreco{\mytyc{Prod}}{\myappsp (\myb{A} {:} \mytyp) \myappsp (\myb{B} {:} \myb{A} \myarr \mytyp)}{\\ \myind{2}}{\myfst : \myb{A}, \mysnd : \myapp{\myb{B}}{\myb{fst}}}
  \end{array}
  \]}
  Here $\myfst$ and $\mysnd$ are the projections, with their respective
  types.  Note that each field can refer to the preceding fields.  A
  constructor will be automatically generated, under the name of
  $\mytyc{Prod}.\mydc{constr}$.  Dually to data types, we will omit the
  type constructor prefix for record projections.

  Following the bidirectionality of the system, we have that projections
  (the destructors of the record) infer the type, while the constructor
  gets checked:
  \begin{center}
    \small
    \begin{tabular}{cc}
      \AxiomC{$\mychk{\mytmm}{\mytya}$}
      \AxiomC{$\mychk{\mytmn}{\myapp{\mytyb}{\mytmm}}$}
      \BinaryInfC{$\mychk{\mytyc{Prod}.\mydc{constr} \myappsp \mytmm \myappsp \mytmn}{\mytyc{Prod} \myappsp \mytya \myappsp \mytyb}$}
      \noLine
      \UnaryInfC{\phantom{$\myinf{\myfun{snd} \myappsp \mytmt}{\mytyb \myappsp (\myfst \myappsp \mytmt)}$}}
      \DisplayProof
      &
      \AxiomC{$\myinf{\mytmt}{\mytyc{Prod} \myappsp \mytya \myappsp \mytyb}$}
      \UnaryInfC{$\myinf{\myfun{fst} \myappsp \mytmt}{\mytya}$}
      \noLine
      \UnaryInfC{$\myinf{\myfun{snd} \myappsp \mytmt}{\mytyb \myappsp (\myfst \myappsp \mytmt)}$}
      \DisplayProof
    \end{tabular}
  \end{center}
  What we have is equivalent to ITT's dependent products.
\end{description}

Following the intuition given by the examples, the mechanised
elaboration is presented in figure \ref{fig:elab}, which is essentially
a modification of figure 9 of \citep{McBride2004}\footnote{However, our
  datatypes do not have indices, we do bidirectional typechecking by
  treating constructors/destructors as syntactic constructs, and we have
  records.}.

In data types declarations we allow recursive occurrences as long as
they are \emph{strictly positive}, employing a syntactic check to make
sure that this is the case.  See \cite{Dybjer1991} for a more formal
treatment of inductive definitions in ITT.

For what concerns records, recursive occurrences are disallowed.  The
reason for this choice is answered by the reason for the choice of
having records at all: we need records to give the user types with
$\eta$-laws for equality, as we saw in section % TODO add section
and in the treatment of OTT in section \ref{sec:ott}.  If we tried to
$\eta$-expand recursive data types, we would expand forever.

To implement bidirectional type checking for constructors and
destructors, we store their types in full in the context, and then
instantiate when due:

\mydesc{typing:}{ }{
    \AxiomC{$
      \begin{array}{c}
        \mytyc{D} : \mytele \myarr \mytyp \in \myctx \hspace{1cm}
        \mytyc{D}.\mydc{c} : \mytele \mycc \mytele' \myarr
        \myapp{\mytyc{D}}{\mytelee} \in \myctx \\
        \mytele'' = (\mytele;\mytele')\vec{A} \hspace{1cm}
        \mychkk{\myctx; \mytake_{i-1}(\mytele'')}{t_i}{\myix_i( \mytele'')}\ \ 
          (1 \le i \le \mytele'')
      \end{array}
      $}
    \UnaryInfC{$\mychk{\myapp{\mytyc{D}.\mydc{c}}{\vec{t}}}{\myapp{\mytyc{D}}{\vec{A}}}$}
    \DisplayProof

    \myderivsp

    \AxiomC{$\mytyc{D} : \mytele \myarr \mytyp \in \myctx$}
    \AxiomC{$\mytyc{D}.\myfun{f} : \mytele \mycc (\myb{x} {:}
      \myapp{\mytyc{D}}{\mytelee}) \myarr \myse{F}$}
    \AxiomC{$\myjud{\mytmt}{\myapp{\mytyc{D}}{\vec{A}}}$}
    \TrinaryInfC{$\myinf{\myapp{\mytyc{D}.\myfun{f}}{\mytmt}}{(\mytele
        \mycc (\myb{x} {:} \myapp{\mytyc{D}}{\mytelee}) \myarr
        \myse{F})(\vec{A};\mytmt)}$}
    \DisplayProof
  }

\subsubsection{Why user defined types?}

% TODO reference levitated theories, indexed containers

foobar

\subsection{Cumulative hierarchy and typical ambiguity}
\label{sec:term-hierarchy}

A type hierarchy as presented in section \label{sec:itt} is a
considerable burden on the user, on various levels.  Consider for
example how we recovered disjunctions in section \ref{sec:disju}: we
have a function that takes two $\mytyp_0$ and forms a new $\mytyp_0$.
What if we wanted to form a disjunction containing two $\mytyp_0$, or
$\mytyp_{42}$?  Our definition would fail us, since $\mytyp_0 :
\mytyp_1$.

One way to solve this issue is a \emph{cumulative} hierarchy, where
$\mytyp_{l_1} : \mytyp_{l_2}$ iff $l_1 < l_2$.  This way we retain
consistency, while allowing for `large' definitions that work on small
types too.  For example we might define our disjunction to be
{\small\[
  \myarg\myfun{$\vee$}\myarg : \mytyp_{100} \myarr \mytyp_{100} \myarr \mytyp_{100}
\]}
And hope that $\mytyp_{100}$ will be large enough to fit all the types
that we want to use with our disjunction.  However, there are two
problems with this.  First, there is the obvious clumsyness of having to
manually specify the size of types.  More importantly, if we want to use
$\myfun{$\vee$}$ itself as an argument to other type-formers, we need to
make sure that those allow for types at least as large as
$\mytyp_{100}$.

A better option is to employ a mechanised version of what Russell called
\emph{typical ambiguity}: we let the user live under the illusion that
$\mytyp : \mytyp$, but check that the statements about types are
consistent behind the hood.  $\mykant$\ implements this following the
lines of \cite{Huet1988}.  See also \citep{Harper1991} for a published
reference, although describing a more complex system allowing for both
explicit and explicit hierarchy at the same time.

We define a partial ordering on the levels, with both weak ($\le$) and
strong ($<$) constraints---the laws governing them being the same as the
ones governing $<$ and $\le$ for the natural numbers.  Each occurrence
of $\mytyp$ is decorated with a unique reference, and we keep a set of
constraints and add new constraints as we type check, generating new
references when needed.

For example, when type checking the type $\mytyp\, r_1$, where $r_1$
denotes the unique reference assigned to that term, we will generate a
new fresh reference $\mytyp\, r_2$, and add the constraint $r_1 < r_2$
to the set.  When type checking $\myctx \vdash
\myfora{\myb{x}}{\mytya}{\mytyb}$, if $\myctx \vdash \mytya : \mytyp\,
r_1$ and $\myctx; \myb{x} : \mytyb \vdash \mytyb : \mytyp\,r_2$; we will
generate new reference $r$ and add $r_1 \le r$ and $r_2 \le r$ to the
set.

If at any point the constraint set becomes inconsistent, type checking
fails.  Moreover, when comparing two $\mytyp$ terms we equate their
respective references with two $\le$ constraints---the details are
explained in section \ref{sec:hier-impl}.

Another more flexible but also more verbose alternative is the one
chosen by Agda, where levels can be quantified so that the relationship
between arguments and result in type formers can be explicitly
expressed:
{\small\[
\myarg\myfun{$\vee$}\myarg : (l_1\, l_2 : \mytyc{Level}) \myarr \mytyp_{l_1} \myarr \mytyp_{l_2} \myarr \mytyp_{l_1 \mylub l_2}
\]}
Inference algorithms to automatically derive this kind of relationship
are currently subject of research.  We chose less flexible but more
concise way, since it is easier to implement and better understood.

\subsection{Observational equality, \mykant\ style}

There are two correlated differences between $\mykant$\ and the theory
used to present OTT.  The first is that in $\mykant$ we have a type
hierarchy, which lets us, for example, abstract over types.  The second
is that we let the user define inductive types.

Reconciling propositions for OTT and a hierarchy had already been
investigated by Conor McBride\footnote{See
  \url{http://www.e-pig.org/epilogue/index.html?p=1098.html}.}, and we
follow his footsteps.  Most of the work, as an extension of elaboration,
is to generate reduction rules and coercions.

\subsubsection{The \mykant\ prelude, and $\myprop$ositions}

Before defining $\myprop$, we define some basic types inside $\mykant$,
as the target for the $\myprop$ decoder:

\begin{framed}
\small
$
\begin{array}{l}
  \myadt{\mytyc{Empty}}{}{ }{ } \\
  \myfun{absurd} : (\myb{A} {:} \mytyp) \myarr \mytyc{Empty} \myarr \myb{A} \mapsto \\
  \myind{2} \myabs{\myb{A\ \myb{bot}}}{\mytyc{Empty}.\myfun{elim} \myappsp \myb{bot} \myappsp (\myabs{\_}{\myb{A}})} \\
  \ \\

  \myreco{\mytyc{Unit}}{}{\mydc{tt}}{ } \\ \ \\

  \myreco{\mytyc{Prod}}{\myappsp (\myb{A}\ \myb{B} {:} \mytyp)}{ }{\myfun{fst} : \myb{A}, \myfun{snd} : \myb{B} }
\end{array}
$
\end{framed}
When using $\mytyc{Prod}$, we shall use $\myprod$ to define `nested'
products, and $\myproj{n}$ to project elements from them, so that
{\small
\[
\begin{array}{@{}l}
\mytya \myprod \mytyb = \mytyc{Prod} \myappsp \mytya \myappsp (\mytyc{Prod} \myappsp \mytyb \myappsp \myunit) \\
\mytya \myprod \mytyb \myprod \myse{C} = \mytyc{Prod} \myappsp \mytya \myappsp (\mytyc{Prod} \myappsp \mytyb \myappsp (\mytyc{Prod} \myappsp \mytyc \myappsp \myunit)) \\
\myind{2} \vdots \\
\myproj{1} : \mytyc{Prod} \myappsp \mytya \myappsp \mytyb \myarr \mytya \\
\myproj{2} : \mytyc{Prod} \myappsp \mytya \myappsp (\mytyc{Prod} \myappsp \mytyb \myappsp \myse{C}) \myarr \mytyb \\
\myind{2} \vdots
\end{array}
\]
}
And so on, so that $\myproj{n}$ will work with all products with at
least than $n$ elements.  Then we can define propositions, and decoding:

\mydesc{syntax}{ }{
  $
  \begin{array}{r@{\ }c@{\ }l}
    \mytmsyn & ::= & \cdots \mysynsep \myprdec{\myprsyn} \\
    \myprsyn & ::= & \mybot \mysynsep \mytop \mysynsep \myprsyn \myand \myprsyn \mysynsep \myprfora{\myb{x}}{\mytmsyn}{\myprsyn}
  \end{array}
  $
}

\mydesc{proposition decoding:}{\myprdec{\mytmsyn} \myred \mytmsyn}{
  \begin{tabular}{cc}
    $
    \begin{array}{l@{\ }c@{\ }l}
      \myprdec{\mybot} & \myred & \myempty \\
      \myprdec{\mytop} & \myred & \myunit
    \end{array}
    $
    &
    $
    \begin{array}{r@{ }c@{ }l@{\ }c@{\ }l}
      \myprdec{&\myse{P} \myand \myse{Q} &} & \myred & \myprdec{\myse{P}} \myprod \myprdec{\myse{Q}} \\
      \myprdec{&\myprfora{\myb{x}}{\mytya}{\myse{P}} &} & \myred &
      \myfora{\myb{x}}{\mytya}{\myprdec{\myse{P}}}
    \end{array}
    $
  \end{tabular}
}

\subsubsection{Why $\myprop$?}

It is worth to ask if $\myprop$ is needed at all.  It is perfectly
possible to have the type checker identify propositional types
automatically, and in fact that is what The author initially planned to
identify the propositional fragment iinternally \cite{Jacobs1994}.

\subsubsection{OTT constructs}

\mydesc{syntax}{ }{
  $
  \begin{array}{r@{\ }c@{\ }l}
    \mytmsyn & ::= & \cdots \mysynsep \mycoee{\mytmsyn}{\mytmsyn}{\mytmsyn}{\mytmsyn} \mysynsep
                     \mycohh{\mytmsyn}{\mytmsyn}{\mytmsyn}{\mytmsyn} \\
    \myprsyn & ::= & \cdots \mysynsep \myjm{\mytmsyn}{\mytmsyn}{\mytmsyn}{\mytmsyn} \\
  \end{array}
  $
}

\mydesc{equality reduction:}{\myctx \vdash \myprsyn \myred \myprsyn}{
  \footnotesize
  \AxiomC{}
  \UnaryInfC{$
    \begin{array}{r@{\ }l}
    \myctx \vdash &
    \myjm{\myfora{\myb{x_1}}{\mytya_1}{\mytyb_1}}{\mytyp}{\myfora{\myb{x_2}}{\mytya_2}{\mytyb_2}}{\mytyp}  \myred \\
    & \myind{2} \mytya_2 \myeq \mytya_1 \myand \\
    & \myind{2} \myprfora{\myb{x_2}}{\mytya_2}{\myprfora{\myb{x_1}}{\mytya_1}{
        \myjm{\myb{x_2}}{\mytya_2}{\myb{x_1}}{\mytya_1} \myimpl \mytyb_1 \myeq \mytyb_2
      }}
    \end{array}
    $}
  \DisplayProof

  \myderivsp

  \AxiomC{$\mytyc{D} : \mytele \myarr \mytyp \in \myctx$}
  \UnaryInfC{$
    \begin{array}{r@{\ }l}
      \myctx \vdash &
      \myjm{\mytyc{D} \myappsp \vec{A}}{\mytyp}{\mytyc{D} \myappsp \vec{B}}{\mytyp}  \myred \\
      & \myind{2} \myjm{\mytya_1}{\myhead(\mytele)}{\mytyb_1}{\myhead(\mytele)} \myand \cdots \myand \\
      & \myind{2} \myjm{\mytya_n}{\myhead(\mytele(A_1 \cdots A_{n-1}))}{\mytyb_n}{\myhead(\mytele(B_1 \cdots B_{n-1}))}
    \end{array}
    $}
  \DisplayProof

  \myderivsp

  \AxiomC{}
  \UnaryInfC{$\myctx \vdash \myjm{\mytyp}{\mytyp}{\mytyp}{\mytyp} \myred \mytop$}
  \DisplayProof

  \myderivsp

  \AxiomC{$
    \begin{array}{c}
      \mydataty(\mytyc{D}, \myctx)\hspace{0.8cm}
      \mytyc{D}.\mydc{c}_i : \mytele;\mytele' \myarr \mytyc{D} \myappsp \mytelee \in \myctx \\
      \mytele_A = (\mytele;\mytele')\vec{A}\hspace{0.8cm}
      \mytele_B = (\mytele;\mytele')\vec{B}
    \end{array}
    $}
  \UnaryInfC{$
    \begin{array}{l}
      \myctx \vdash \myjm{\mytyc{D}.\mydc{c}_i \myappsp \vec{\mytmm}}{\mytyc{D} \myappsp \vec{A}}{\mytyc{D}.\mydc{c}_i \myappsp \vec{\mytmn}}{\mytyc{D} \myappsp \vec{B}} \myred \\
      \myind{2} \myjm{\mytmm_1}{\myhead(\mytele_A)}{\mytmn_1}{\myhead(\mytele_B)} \myand \cdots \myand \\
      \myind{2} \myjm{\mytmm_n}{\mytya_n}{\mytmn_n}{\mytyb_n}
    \end{array}
    $}
  \DisplayProof

  \myderivsp

  \AxiomC{$\myisreco(\mytyc{D}, \myctx)$}
  \UnaryInfC{$\myctx \vdash \myjm{\mytmm}{\mytyc{D} \myappsp \vec{A}}{\mytmn}{\mytyc{D} \myappsp \vec{B}} \myred foo$}
  \DisplayProof
  
  \myderivsp
  \AxiomC{}
  \UnaryInfC{$\mytya  \myeq  \mytyb  \myred \mybot\ \text{if $\mytya$ and $\mytyb$ are canonical types.}$}
  \DisplayProof
}

\subsubsection{$\myprop$ and the hierarchy}

Where is $\myprop$ placed in the $\mytyp$ hierarchy?  

\subsubsection{Quotation and irrelevance}
\ref{sec:kant-irr}

foo

\section{\mykant : The practice}
\label{sec:kant-practice}

The codebase consists of around 2500 lines of Haskell, as reported by
the \texttt{cloc} utility.  The high level design is inspired by Conor
McBride's work on various incarnations of Epigram, and specifically by
the first version as described \citep{McBride2004} and the codebase for
the new version \footnote{Available intermittently as a \texttt{darcs}
  repository at \url{http://sneezy.cs.nott.ac.uk/darcs/Pig09}.}.  In
many ways \mykant\ is something in between the first and second version
of Epigram.

The interaction happens in a read-eval-print loop (REPL).  The REPL is a
available both as a commandline application and in a web interface,
which is available at \url{kant.mazzo.li} and presents itself as in
figure \ref{fig:kant-web}.

\begin{figure}
  \centering{
    \includegraphics[scale=1.0]{kant-web.png}
  }
  \caption{The \mykant\ web prompt.}
  \label{fig:kant-web}
\end{figure}

The interaction with the user takes place in a loop living in and updating a
context \mykant\ declarations.  The user inputs a new declaration that goes
through various stages starts with the user inputing a \mykant\ declaration or
another REPL command, which then goes through various stages that can end up
in a context update, or in failures of various kind.  The process is described
diagrammatically in figure \ref{fig:kant-process}:

\begin{description}
\item[Parse] In this phase the text input gets converted to a sugared
  version of the core language.

\item[Desugar] The sugared declaration is converted to a core term.

\item[Reference] Occurrences of $\mytyp$ get decorated by a unique reference,
  which is necessary to implement the type hierarchy check.

\item[Elaborate] Convert the declaration to some context item, which might be
  a value declaration (type and body) or a data type declaration (constructors
  and destructors).  This phase works in tandem with \textbf{Typechecking},
  which in turns needs to \textbf{Evaluate} terms.

\item[Distill] and report the result.  `Distilling' refers to the process of
  converting a core term back to a sugared version that the user can
  visualise.  This can be necessary both to display errors including terms or
  to display result of evaluations or type checking that the user has
  requested.

\item[Pretty print] Format the terms in a nice way, and display the result to
  the user.

\end{description}

\begin{figure}
  \centering{\small
    \tikzstyle{block} = [rectangle, draw, text width=5em, text centered, rounded
    corners, minimum height=2.5em, node distance=0.7cm]
      
      \tikzstyle{decision} = [diamond, draw, text width=4.5em, text badly
      centered, inner sep=0pt, node distance=0.7cm]
      
      \tikzstyle{line} = [draw, -latex']
      
      \tikzstyle{cloud} = [draw, ellipse, minimum height=2em, text width=5em, text
      centered, node distance=1.5cm]
      
      
      \begin{tikzpicture}[auto]
        \node [cloud] (user) {User};
        \node [block, below left=1cm and 0.1cm of user] (parse) {Parse};
        \node [block, below=of parse] (desugar) {Desugar};
        \node [block, below=of desugar] (reference) {Reference};
        \node [block, below=of reference] (elaborate) {Elaborate};
        \node [block, left=of elaborate] (tycheck) {Typecheck};
        \node [block, left=of tycheck] (evaluate) {Evaluate};
        \node [decision, right=of elaborate] (error) {Error?};
        \node [block, right=of parse] (distill) {Distill};
        \node [block, right=of desugar] (update) {Update context};
        
        \path [line] (user) -- (parse);
        \path [line] (parse) -- (desugar);
        \path [line] (desugar) -- (reference);
        \path [line] (reference) -- (elaborate);
        \path [line] (elaborate) edge[bend right] (tycheck);
        \path [line] (tycheck) edge[bend right] (elaborate);
        \path [line] (elaborate) -- (error);
        \path [line] (error) edge[out=0,in=0] node [near start] {yes} (distill);
        \path [line] (error) -- node [near start] {no} (update);
        \path [line] (update) -- (distill);
        \path [line] (distill) -- (user);
        \path [line] (tycheck) edge[bend right] (evaluate);
        \path [line] (evaluate) edge[bend right] (tycheck);
      \end{tikzpicture}
  }
  \caption{High level overview of the life of a \mykant\ prompt cycle.}
  \label{fig:kant-process}
\end{figure}

\subsection{Parsing and Sugar}

\subsection{Term representation and context}
\label{sec:term-repr}

\subsection{Type checking}

\subsection{Type hierarchy}
\label{sec:hier-impl}

\subsection{Elaboration}

\section{Evaluation}

\section{Future work}

% TODO coinduction (obscoin, gimenez), pattern unification (miller,
% gundry), partiality monad (NAD)

\appendix

\section{Notation and syntax}

Syntax, derivation rules, and reduction rules, are enclosed in frames describing
the type of relation being established and the syntactic elements appearing,
for example

\mydesc{typing:}{\myjud{\mytmsyn}{\mytysyn}}{
  Typing derivations here.
}

In the languages presented and Agda code samples I also highlight the syntax,
following a uniform color and font convention:

\begin{center}
  \begin{tabular}{c | l}
    $\mytyc{Sans}$   & Type constructors. \\
    $\mydc{sans}$    & Data constructors. \\
    % $\myfld{sans}$  & Field accessors (e.g. \myfld{fst} and \myfld{snd} for products). \\
    $\mysyn{roman}$  & Keywords of the language. \\
    $\myfun{roman}$  & Defined values and destructors. \\
    $\myb{math}$     & Bound variables.
  \end{tabular}
\end{center}

Moreover, I will from time to time give examples in the Haskell programming
language as defined in \citep{Haskell2010}, which I will typeset in
\texttt{teletype} font.  I assume that the reader is already familiar with
Haskell, plenty of good introductions are available \citep{LYAH,ProgInHask}.

When presenting grammars, I will use a word in $\mysynel{math}$ font
(e.g. $\mytmsyn$ or $\mytysyn$) to indicate indicate nonterminals. Additionally,
I will use quite flexibly a $\mysynel{math}$ font to indicate a syntactic
element.  More specifically, terms are usually indicated by lowercase letters
(often $\mytmt$, $\mytmm$, or $\mytmn$); and types by an uppercase letter (often
$\mytya$, $\mytyb$, or $\mytycc$).

When presenting type derivations, I will often abbreviate and present multiple
conclusions, each on a separate line:
\begin{prooftree}
  \AxiomC{$\myjud{\mytmt}{\mytya \myprod \mytyb}$}
  \UnaryInfC{$\myjud{\myapp{\myfst}{\mytmt}}{\mytya}$}
  \noLine
  \UnaryInfC{$\myjud{\myapp{\mysnd}{\mytmt}}{\mytyb}$}
\end{prooftree}

I will often present `definition' in the described calculi and in
$\mykant$\ itself, like so:
{\small\[
\begin{array}{@{}l}
  \myfun{name} : \mytysyn \\
  \myfun{name} \myappsp \myb{arg_1} \myappsp \myb{arg_2} \myappsp \cdots \mapsto \mytmsyn
\end{array}
\]}
To define operators, I use a mixfix notation similar
to Agda, where $\myarg$s denote arguments, for example
{\small\[
\begin{array}{@{}l}
  \myarg \mathrel{\myfun{$\wedge$}} \myarg : \mybool \myarr \mybool \myarr \mybool \\
  \myb{b_1} \mathrel{\myfun{$\wedge$}} \myb{b_2} \mapsto \cdots
\end{array}
\]}

\section{Code}

\subsection{ITT renditions}
\label{app:itt-code}

\subsubsection{Agda}
\label{app:agda-itt}

Note that in what follows rules for `base' types are
universe-polymorphic, to reflect the exposition.  Derived definitions,
on the other hand, mostly work with \mytyc{Set}, reflecting the fact
that in the theory presented we don't have universe polymorphism.

\begin{code}
module ITT where
  open import Level

  data Empty : Set where

  absurd : ∀ {a} {A : Set a} → Empty → A
  absurd ()

  ¬_ : ∀ {a} → (A : Set a) → Set a
  ¬ A = A → Empty

  record Unit : Set where
    constructor tt

  record _×_ {a b} (A : Set a) (B : A → Set b) : Set (a ⊔ b) where
    constructor _,_
    field
      fst  : A
      snd  : B fst
  open _×_ public

  data Bool : Set where
    true false : Bool

  if_/_then_else_ : ∀ {a} (x : Bool) (P : Bool → Set a) → P true → P false → P x
  if true / _ then x else _ = x
  if false / _ then _ else x = x

  if_then_else_ : ∀ {a} (x : Bool) {P : Bool → Set a} → P true → P false → P x
  if_then_else_ x {P} = if_/_then_else_ x P

  data W {s p} (S : Set s) (P : S → Set p) : Set (s ⊔ p) where
    _◁_ : (s : S) → (P s → W S P) → W S P

  rec : ∀ {a b} {S : Set a} {P : S → Set b}
    (C : W S P → Set) →       -- some conclusion we hope holds
    ((s : S) →                -- given a shape...
     (f : P s → W S P) →      -- ...and a bunch of kids...
     ((p : P s) → C (f p)) →  -- ...and C for each kid in the bunch...
     C (s ◁ f)) →             -- ...does C hold for the node?
    (x : W S P) →             -- If so, ...
    C x                       -- ...C always holds.
  rec C c (s ◁ f) = c s f (λ p → rec C c (f p))

module Examples-→ where
  open ITT

  data ℕ : Set where
    zero : ℕ
    suc : ℕ → ℕ

  -- These pragmas are needed so we can use number literals.
  {-# BUILTIN NATURAL ℕ #-}
  {-# BUILTIN ZERO zero #-}
  {-# BUILTIN SUC suc #-}

  data List (A : Set) : Set where
    [] : List A
    _∷_ : A → List A → List A

  length : ∀ {A} → List A → ℕ
  length [] = zero
  length (_ ∷ l) = suc (length l)

  _>_ : ℕ → ℕ → Set
  zero > _ = Empty
  suc _ > zero = Unit
  suc x > suc y = x > y

  head : ∀ {A} → (l : List A) → length l > 0 → A
  head [] p = absurd p
  head (x ∷ _) _ = x

module Examples-× where
  open ITT
  open Examples-→

  even : ℕ → Set
  even zero = Unit
  even (suc zero) = Empty
  even (suc (suc n)) = even n

  6-even : even 6
  6-even = tt

  5-not-even : ¬ (even 5)
  5-not-even = absurd
  
  there-is-an-even-number : ℕ × even
  there-is-an-even-number = 6 , 6-even

  _∨_ : (A B : Set) → Set
  A ∨ B = Bool × (λ b → if b then A else B)

  left : ∀ {A B} → A → A ∨ B
  left x = true , x

  right : ∀ {A B} → B → A ∨ B
  right x = false , x

  [_,_] : {A B C : Set} → (A → C) → (B → C) → A ∨ B → C
  [ f , g ] x =
    (if (fst x) / (λ b → if b then _ else _ → _) then f else g) (snd x)

module Examples-W where
  open ITT
  open Examples-×

  Tr : Bool → Set
  Tr b = if b then Unit else Empty

  ℕ : Set
  ℕ = W Bool Tr

  zero : ℕ
  zero = false ◁ absurd

  suc : ℕ → ℕ
  suc n = true ◁ (λ _ → n)

  plus : ℕ → ℕ → ℕ
  plus x y = rec
    (λ _ → ℕ)
    (λ b →
      if b / (λ b → (Tr b → ℕ) → (Tr b → ℕ) → ℕ)
      then (λ _ f → (suc (f tt))) else (λ _ _ → y))
    x

  List : (A : Set) → Set
  List A = W (A ∨ Unit) (λ s → Tr (fst s))

  [] : ∀ {A} → List A
  [] = (false , tt) ◁ absurd

  _∷_ : ∀ {A} → A → List A → List A
  x ∷ l = (true , x) ◁ (λ _ → l)

  _++_ : ∀ {A} → List A → List A → List A
  l₁ ++ l₂ = rec
    (λ _ → List _ → List _)
    (λ s f c l → {!!})
    l₁ l₂

module Equality where
  open ITT
  
  data _≡_ {a} {A : Set a} : A → A → Set a where
    refl : ∀ x → x ≡ x

  ≡-elim : ∀ {a b} {A : Set a}
    (P : (x y : A) → x ≡ y → Set b) →
    ∀ {x y} → P x x (refl x) → (x≡y : x ≡ y) → P x y x≡y
  ≡-elim P p (refl x) = p

  subst : ∀ {A : Set} (P : A → Set) → ∀ {x y} → (x≡y : x ≡ y) → P x → P y
  subst P x≡y p = ≡-elim (λ _ y _ → P y) p x≡y

  sym : ∀ {A : Set} (x y : A) → x ≡ y → y ≡ x
  sym x y p = subst (λ y′ → y′ ≡ x) p (refl x)

  trans : ∀ {A : Set} (x y z : A) → x ≡ y → y ≡ z → x ≡ z
  trans x y z p q = subst (λ z′ → x ≡ z′) q p

  cong : ∀ {A B : Set} (x y : A) → x ≡ y → (f : A → B) → f x ≡ f y 
  cong x y p f = subst (λ z → f x ≡ f z) p (refl (f x))
\end{code}

\subsubsection{\mykant}

The following things are missing: $\mytyc{W}$-types, since our
positivity check is overly strict, and equality, since we haven't
implemented that yet.

{\small
\verbatiminput{itt.ka}
}

\subsection{\mykant\ examples}

{\small
\verbatiminput{examples.ka}
}

\subsection{\mykant's hierachy}

This rendition of the Hurken's paradox does not type check with the
hierachy enabled, type checks and loops without it.  Adapted from an
Agda version, available at
\url{http://code.haskell.org/Agda/test/succeed/Hurkens.agda}.

{\small
\verbatiminput{hurkens.ka}
}

\bibliographystyle{authordate1}
\bibliography{thesis}

\end{document}