\documentclass[nonatbib]{sigplanconf}
\usepackage[authoryear,square]{natbib}

\usepackage{todonotes}
\usepackage{amsmath}
\usepackage{amsthm}
\usepackage{amssymb}
\usepackage{graphicx}
\usepackage{comment}
\usepackage{url}
\usepackage{bbm}
\usepackage[greek,english]{babel}
\usepackage{ucs}
\usepackage[utf8x]{inputenc}
\usepackage{autofe}
\usepackage{stmaryrd}
\usepackage{enumitem}

\usepackage{float}
\floatstyle{boxed}
\restylefloat{figure}

\DeclareUnicodeCharacter{8988}{\ensuremath{\ulcorner}}
\DeclareUnicodeCharacter{8989}{\ensuremath{\urcorner}}
\DeclareUnicodeCharacter{8803}{\ensuremath{\overline{\equiv}}}
\DeclareUnicodeCharacter{8759}{\ensuremath{\colon\colon}}
\DeclareUnicodeCharacter{12314}{\ensuremath{\llbracket}}
\DeclareUnicodeCharacter{12315}{\ensuremath{\rrbracket}}
\DeclareUnicodeCharacter{10214}{\ensuremath{\llbracket}}
\DeclareUnicodeCharacter{10215}{\ensuremath{\rrbracket}}
\DeclareUnicodeCharacter{8614}{\ensuremath{\mapsto}}
\DeclareUnicodeCharacter{8799}{\ensuremath{\stackrel{?}{=}}}
\DeclareUnicodeCharacter{8669}{\ensuremath{\leadsto}}

\DeclareUnicodeCharacter{7496}{\ensuremath{^{d}}}

\usepackage{fancyvrb}

\usepackage[labelfont=bf]{caption}

\newtheorem*{mythm}{Theorem}
\newtheorem*{mylem}{Lemma}

\newcommand{\refthm}[1]{Theorem \ref{thm:#1}}
\newcommand{\reflem}[1]{Lemma \ref{lem:#1}}

\newtheorem{mydef}{Definition}
\newtheorem{myparte}{Part$_E$}
\newtheorem{myparti}{Part$_I$}

\newcommand{\reffig}[1]{Figure \ref{fig:#1}}
\newcommand{\refsec}[1]{Section \ref{sec:#1}}
\newcommand{\refparte}[1]{Part$_E$ \ref{parte:#1}}
\newcommand{\refparti}[1]{Part$_I$ \ref{parti:#1}}

\begin{document}

\conferenceinfo{WGP~'14}{ August 31 2014, Gothenburg, Sweden}
\copyrightyear{2014}
\copyrightdata{978-1-4503-3042-8/14/08}
\doi{2633628.2633630}

\special{papersize=8.5in,11in}
\setlength{\pdfpageheight}{\paperheight}
\setlength{\pdfpagewidth}{\paperwidth}

\titlebanner{DRAFT}        % These are ignored unless
%% \preprintfooter{short description of paper}   % 'preprint' option specified.

\title{Generic Constructors and Eliminators from Descriptions}
\subtitle{Type Theory as a Dependently Typed Internal DSL}

\authorinfo{Larry Diehl\and Tim Sheard}
           {Portland State University}
           {\{ldiehl,sheard\}@cs.pdx.edu}

\maketitle

\begin{abstract}
Dependently typed languages with an ``open'' type theory
introduce new datatypes using an axiomatic approach.
Each new datatype introduces axioms for constructing values
of the datatype, and an elimination axiom (which we call
the {\it standard eliminator}) for consuming such values. In a ``closed''
type theory a single introduction rule primitive and a single
elimination rule primitive can be used for all datatypes, without
adding axioms to the theory.

We review a closed type theory, specified as an {\sc Agda} program, that
uses descriptions for datatype construction. Descriptions make
datatype definitions first class values, but writing programs using
such datatypes requires low-level understanding of how the datatypes
are encoded in terms of descriptions.
In this
work we derive constructors and standard eliminators, by defining
generic functions
parameterized by a description. Our generic type theory constructions
are defined as generic wrappers around the closed type theory
primitives, which are themselves generic functions in the {\sc Agda}
model. Thus, we allow users to write programs in the model without
understanding the details of the description-based encoding of
datatypes, by using open type theory constructions as an
internal domain-specific language (IDSL).

\end{abstract}

\category{D.3}{Software}{Programming Languages}.

\keywords
Generic programming; dependent types; descriptions; eliminators.

\section{Introduction}
\label{sec:intro}
Dependently typed languages such as
{\sc Coq}~\citep{coq08},
{\sc Agda}~\citep{norell2007towards}, and
{\sc Idris}~\citep{brady2011idris}
introduce datatypes axiomatically.
These systems extend an {\it open} type theory with new axioms that
describe how to legally manipulate values of a newly declared type.

%% In \citet{martin1975intuitionistic} type theory, declaring datatypes
%% results in axioms for
%% type constructors, value constructors, and eliminators (induction
%% principles as dependently typed folds).

Recently, there has been quite a bit of work on defining datatypes
within a {\it closed}
theory (without axioms) using {\it descriptions}.
Descriptions make datatype definitions first class values in a
dependent type theory. This has several desirable consequences, such as the
ability to perform generic programming~\citep{Chapman:2010:GAL:1932681.1863547,mcbride2010ornamental,dagand:phd}
over described types, as well as decreasing the number of constructs in the
metatheory via
levitation~\citep{Chapman:2010:GAL:1932681.1863547,dagand:phd}.

For example, we might declare the type of vectors, length indexed
lists, in an open dependently typed language based on
\citet{martin1975intuitionistic} type theory.
Declaring vectors ({\tt Vec})
adds two constructors ({\tt nil} and {\tt cons}) and one
eliminator ({\tt elimVec}) as axioms to the language.

\begin{verbatim}
nil : (A : Set) → Vec A zero
cons : (A : Set) (n : ℕ) (a : A)
  (xs : Vec A n) → Vec A (suc n)

elimVec : (A : Set) (P : (n : ℕ) → Vec A n → Set)
  (pnil : P zero nil)
  (pcons : (n : ℕ) (a : A) (xs : Vec A n)
    → P n xs → P (suc n) (cons n a xs))
  (n : ℕ) (xs : Vec A n) → P n xs
\end{verbatim}

In contrast, declaring a datatype like {\tt Vec} in a closed type
theory using descriptions does {\it not} add constructors and an
eliminator as specialized axioms to the language. Instead, values of
datatypes built from descriptions can be introduced with a single
primitive, the initial algebra ({\tt init}), and can be eliminated with
a single primitive, a dependently typed version of catamorphism
({\tt ind}), which takes an algebra ({\tt α}) as its argument.

\begin{verbatim}
init : {I : Set} {D : Desc I} {i : I}
  → El D (μ D) i → μ D i

ind : {I : Set} (D : Desc I)
  (P : (i : I) → μ D i → Set)
  (α : (i : I) (xs : El D (μ D) i)
    (ihs : Hyps D (μ D) P i xs) → P i (init xs))
  (i : I) (x : μ D i) → P i x
\end{verbatim}

Without trying to understand these type signatures at the moment,
recognize that:

\begin{itemize}
\item{}
Both types are parameterized by a description, allowing them to be used with any
datatype defined using a description.
\item{}
Both types refer to the type {\tt El D}, which interprets a
description as a pattern functor and is used to define the datatypes with an
initial algebra-style semantics.
\end{itemize}

Two unfortunate side effects of introducing and eliminating described
datatypes using algebras based on pattern functors are:

\begin{enumerate}
\item{}
Users need to understand how {\tt El D} gets interpreted as a type in
the language in order to program with values of said types, exposing
the low-level encoding.
\item{}
Function definitions defined with {\tt ind} are particularly verbose,
due to the low-level encoding, but the functions follow a common
pattern.
\end{enumerate}

Rather than making users of the {\sc Agda} model learn the details of
description-based encodings when writing programs using described
datatypes,
the {\bf major contribution} of
this paper is a generic constructor ({\tt inj}) and a generic
eliminator ({\tt elim}), which both have an interface that hides the
details of the description-based encoding.
The type of {\tt inj} applied to a
description of a datatype, and a tag specifying constructor, is exactly the
expected type signature of a constructor defined axiomatically in an
{\it open} language. Similarly, the type signature of {\tt elim} applied to
a description of a type is exactly the expected type signature
of an eliminator defined axiomatically in an {\it open} language.
Moreover, {\tt inj} and {\tt elim} are examples of generic
programming, defined as generic wrapper functions around the
{\it closed} type theory primitives {\tt init}
and {\tt ind}, which are themselves generic functions in the
{\sc Agda} model.

In a sense we derive the standard constructors and
eliminators of type theory within a simple and sound system.
We retain the generic programming ability afforded by description based languages,
but also hide implementation details when defining functions over
particular types by supplying the user with standard constructors and
eliminators. Essentially, we use generic programming to define type
theory constructions as an
{\it internal domain-specific language}~\citep{landin1966next} within the
{\sc Agda} model of closed type theory.

\paragraph{}
The remainder of this paper proceeds as follows:

\begin{itemize}
\item{\bf{\refsec{background}}}
{\it Reviews} how to define datatypes using descriptions.

\item{\bf{\refsec{init}}}
{\it Reviews} how to introduce values of described types using the
primitive initial algebra {\tt init}.

\item{\bf{\refsec{inj}}}
{\it Contributes} the novel generic constructor {\tt inj}. To this
end, we highlight each {\bf Part$_I$} involved in defining a specialized
constructor in terms of {\tt init}.

\item{\bf{\refsec{ind}}}
{\it Reviews} how to eliminate values of described types using the
primitive dependent catamorphism {\tt ind}. We also demonstrate
the verbosity of {\tt ind}-based definitions.

\item{\bf{\refsec{elim}}}
{\it Contributes} the novel generic eliminator {\tt elim}. To this
end, we highlight each {\bf Part$_E$} involved in defining a specialized
eliminator in terms of {\tt ind}.

\item{\bf{\refsec{correctness}}}
{\it Proves} the correctness property that {\tt ind} and {\tt elim}
are extensionally equivalent functions. For technical reasons, we actually prove that
{\tt ind} is equivalent to the helper function {\tt elimUncurried} instead.

\item{\bf{\refsec{related-work}}}
{\it Discusses} related work.

\end{itemize}

\paragraph{}
All code presented in this paper has been checked with {\sc Agda}.
\footnote{\raggedright{The accompanying source code can be found at
{\tt https://github.com/larrytheliquid/generic-elim}}}
To avoid clutter, in this paper we omit universe levels and assume
{\tt Set : Set}. However, the accompanying source code contains a
version of the code stratified by universe levels.

\section{Declaring Datatypes}
\label{sec:background}

The goal of this section is to {\it review} how to define the following type
declaration as a first-class value of our type theory.

\begin{verbatim}
data Vec (A : Set) : ℕ → Set where
  nil : Vec A zero
  cons : (n : ℕ) (a : A) (xs : Vec A n)
    → Vec A (suc n)
\end{verbatim}

Whereas such a declaration typically involves axiomatically extending
the type theory, the technology of
descriptions~\citep{Chapman:2010:GAL:1932681.1863547,mcbride2010ornamental,dagand:phd}
lets us define datatypes within a closed type theory.
There are
several ways to define the datatype of descriptions {\tt Desc}.
For simplicity, in this paper we use the encoding by
\citet{mcbride2010ornamental}.

\subsection{Description Type}

The datatype {\tt Desc} of descriptions is used to represent
user-defined definitions of strictly-positive indexed
families of inductively defined types.
{\tt Desc} is parameterized by
a type {\tt I}, the index of the encoded type family.

Throughout this paper it will be easier to first pretend like we
defined {\tt Vec} with a single constructor, either
{\tt nil} or {\tt cons}. This makes it easier to understand
later definitions where {\tt Vec} contains both constructors.

Imagine declaring a datatype with a single constructor.
A constructor is a sequence of
arguments that subsequent arguments may depend on (i.e., a {\it telescope}), along with
recursive arguments at some type indices, and it ends with some type index.
Respectively, {\tt Arg}, {\tt Rec}, and {\tt End} allow you to encode
a dependent argument, a recursive argument at some index, and ending the
constructor definition at some index.

\begin{verbatim}
data Desc (I : Set) : Set₁ where
  End : (i : I) → Desc I
  Rec : (i : I) (D : Desc I) → Desc I
  Arg : (A : Set) (B : A → Desc I) → Desc I
\end{verbatim}

\paragraph{Description of a Single Constructor}

For example, first recall the type of the
constructor {\tt nil} of vectors.

\begin{verbatim}
nil : (A : Set) → Vec A zero
\end{verbatim}

The constructor {\tt nil} takes no arguments, so its description
ends immediately at index {\tt zero}. The type of the description
returned is {\tt Desc ℕ} because the type we are encoding {\tt Vec}
is indexed by natural numbers.

\begin{verbatim}
nilD : (A : Set) → Desc ℕ
nilD A = End zero
\end{verbatim}

Next recall the type of the
constructor {\tt cons} of vectors.

\begin{verbatim}
cons : (A : Set) (n : ℕ) → A → Vec A n
  → Vec A (suc n)
\end{verbatim}

The description of {\tt cons} requires a dependent argument
{\tt n : ℕ} for the index, a non-dependent argument {\tt A} for the value
being added to the vector, a recursive argument indexed by the
natural number {\tt n}, and finally ends at index {\tt suc n}.

\begin{verbatim}
consD : (A : Set) → Desc ℕ
consD A =
  Arg ℕ (λ n → Arg A (λ _ → Rec n (End (suc n))))
\end{verbatim}

\paragraph{Description of Multiple Constructors}
\label{sec:background:multiple}

The datatype {\tt Desc} can also be used to describe an entire
datatype, consisting of descriptions of multiple constructors.
This is achieved by making use of the isomorphism between disjoint
sums and dependent pairs whose domain is some finite enumeration.

\begin{verbatim}
A ⊎ B ≅ Σ Bool (λ b → if b then A else B)
\end{verbatim}

This works fine for a datatype with two constructors (because {\tt Bool} is a two point domain),
in general we will define an $n$-point domain for a datatype with $n$ constructors. By
convention we name such types and their constructors ending in the suffix {\tt T}, for tag.

\begin{verbatim}
data VecT : Set where
  nilT consT : VecT
\end{verbatim}

A datatype with multiple constructors is represented by an
{\tt Arg} description whose first argument (e.g. {\tt VecT}) is a datatype of tags
-- one for each constructor -- and whose second argument (e.g. {\tt VecC}) is
a function that returns a description for each constructor tag. Note
that whereas we used {\tt Arg} for arguments of constructors before,
now we are using {\tt Arg} to represent the sum of all constructors.
By convention we use the suffix {\tt C} for the sum of constructors of
a description, and the suffix {\tt D} for descriptions.

\begin{verbatim}
VecC : (A : Set) → VecT → Desc ℕ
VecC A nilT  = nilD A
VecC A consT = consD A

VecD : (A : Set) → Desc ℕ
VecD A = Arg VecT (VecC A)
\end{verbatim}

\subsection{First-class Enumerations \& Tags}
\label{sec:background:case}

When defining the description of vectors, we previously used a custom
tag type {\tt VecT} to name each constructor. Descriptions are
primarily meant as a construction for representing user-defined
datatypes in a dependent type theory with a closed universe of types.
To prevent the need to extend the type theory with new tag types
constantly, we can instead define first-class enumerations and tags.
Enumerations are just a list of labels. A tag is an index into an
enumeration, pointing at a specific label.

\begin{verbatim}
Label : Set
Label = String

Enum : Set
Enum = List Label

data Tag : Enum → Set where
  here : ∀{l E} → Tag (l ∷ E)
  there : ∀{l E} → Tag E → Tag (l ∷ E)
\end{verbatim}

Thus, the type of vector tags {\tt VecT} can be defined as
{\tt Tag} applied to the enumeration {\tt "nil" ∷ "cons" ∷ []}.
We can also define the {\tt VecT} constructors
{\tt nilT} and {\tt consT} by using
{\tt Tag} constructors to index into the enumeration of labels. The
constructors {\tt here} and {\tt there} are analogous to {\tt zero}
and {\tt suc}.

\begin{verbatim}
VecE : Enum
VecE = "nil" ∷ "cons" ∷ []

VecT : Set
VecT = Tag VecE

nilT : VecT
nilT = here

consT : VecT
consT = there here
\end{verbatim}

\paragraph{Elimination of Tags}

A tag can be eliminated with a {\tt case} construct (this is referred to
as {\tt switch} by \citet{Chapman:2010:GAL:1932681.1863547,dagand:phd}),
producing a value of the motive~\citep{McBride:2000:EM:646540.759262}
type {\tt P} indexed by the tag.
In addition to the tag being eliminated, the case construct is given a
list of branches, one of which the tag will select.

\begin{verbatim}
case : {E : Enum} (P : Tag E → Set)
  (cs : Branches E P) (t : Tag E) → P t
case P (c , cs) here = c
case P (c , cs) (there t) =
  case (λ t → P (there t)) cs t
\end{verbatim}

Think of the cases being a right-nested tuple. The type of this tuple
is computed by the {\tt Set} returning function {\tt Branches}
(\citet{Chapman:2010:GAL:1932681.1863547,dagand:phd} refer to
{\tt Branches} as {\tt π}).
There is a branch for each label in the enumeration, and the type of
each branch depends on the tag representing the position of the label
in the enumeration.

\begin{verbatim}
Branches : (E : Enum) (P : Tag E → Set) → Set
Branches [] P = ⊤
Branches (l ∷ E) P =
  P here × Branches E (λ t → P (there t))
\end{verbatim}

Now we can redefine {\tt VecC} with the {\tt case} eliminator instead
of by pattern matching. Note that a right-nested product of
{\tt Branches} always ends with the unit type {\tt ⊤}.

\begin{verbatim}
VecC : (A : Set) → VecT → Desc ℕ
VecC A = case (λ _ → Desc ℕ)
  ( End zero
  , Arg ℕ (λ n → Arg A (λ _ → Rec n (End (suc n))))
  , tt )
\end{verbatim}

\section{Introduction with Algebras}
\label{sec:init}

The goal of this section is to {\it review} how to use the primitive
introduction rule for datatypes built using descriptions to define the
constructors of {\tt Vec}.

\begin{verbatim}
nil : (A : Set) → Vec A zero
cons : (A : Set) (n : ℕ) → A → Vec A n
  → Vec A (suc n)
\end{verbatim}

In a system where the datatype declaration {\tt Vec} is an axiomatic
extension, the constructors {\tt cons} and {\tt nil} are defined for
us. When using descriptions to define {\tt Vec}, we can instead
introduce values of type {\tt Vec} using its initial algebra.

\subsection{Fixpoint Type}

A description is a first-class datatype declaration. To get back the
type encoded by the description, you apply the fixpoint type
constructor {\tt μ} to it. For example, below we define {\tt Vec} by
applying {\tt μ} to its description {\tt VecD}.

\begin{verbatim}
data μ {I : Set} (D : Desc I) (i : I) : Set where
  init : El D (μ D) i → μ D i

Vec : (A : Set) (n : ℕ) → Set
Vec A n = μ (VecD A) n
\end{verbatim}

\subsection{Interpretation of Descriptions Type}
\label{sec:init:el}

To introduce values of type {\tt Vec}, we use the
{\tt init} constructor of {\tt μ}. The argument to {\tt init} is
{\tt El D (μ D) i}. Let's understand {\tt El} by first considering a
description of {\tt Vec} that only has the single constructor
{\tt nil} or {\tt cons}. If {\tt init} introduces
a value of a single constructor datatype, then its arguments must be
the constructor's arguments. Thus, think of
{\tt El} as a function that computes the type of the arguments of our
constructor. {\tt El} computes the arguments as a right-nested tuple,
where {\tt Arg} gets interpreted as a dependent pair argument,
{\tt Rec} becomes a non-dependent recursive type argument, and
{\tt End} ends the tuple by requiring a proof that the constructor has
the correct index.

\begin{verbatim}
ISet : Set → Set₁
ISet I = I → Set

El : {I : Set} (D : Desc I) → ISet I → ISet I
El (End j) X i = j ≡ i
El (Rec j D) X i = X j × El D X i
El (Arg A B) X i = Σ A (λ a → El (B a) X i)
\end{verbatim}

\paragraph{Interpretation of a Single Constructor}

The {\tt nil} constructor of vectors has no arguments. Thus,
{\tt El} for {\tt nilD} will only require a proof that the index in
the type is equal to the vector length zero.

For the remainder of the
paper, we use a curved arrow ({\tt ⇝}) to denote that the
expression to the left of the arrow definitionally reduces to the term
on the right.

\begin{verbatim}
NilEl : (A : Set) (n : ℕ) → Set
NilEl A n = El (nilD A) (Vec A) n

NilEl A n ⇝ zero ≡ n
\end{verbatim}

The {\tt cons} constructor of vectors has an index argument, an
argument for the value being added to the vector, a recursive
argument, and finally requires a proof that the index in the type is
equal to the successor of the index argument.

\begin{verbatim}
ConsEl : (A : Set) (n : ℕ) → Set
ConsEl A n = El (consD A) (Vec A) n

ConsEl A n ⇝
  Σ ℕ (λ m → A × Vec A m × (suc m ≡ n))
\end{verbatim}

\paragraph{Interpretation of Multiple Constructors}

Recall that multiple constructors are represented as a tagged sum
using a dependent pair (\refsec{background:multiple}). Thus,
{\tt El} for {\tt VecD} will be the tagged sum requiring
{\it either} {\tt NilEl} or {\tt ConsEl}.

\begin{verbatim}
VecEl : (A : Set) (n : ℕ) → Set
VecEl A n = El (VecD A) (Vec A) n

VecEl A n ⇝ Σ VecT (case (λ _ → Set)
  (NilEl A n , ConsEl A n , tt))
\end{verbatim}

\subsection{Definition of Constructors via the Initial Algebra}
\label{sec:init:cons}

We are now ready to define the constructors {\tt nil} and
{\tt cons} using the initial algebra {\tt init}, which is the goal of
this section.
We have already seen
{\tt VecEl}, the type of the argument to {\tt init} for vectors.
Thus a constructor is defined by applying {\tt init} to a tuple. The
first argument is the tag choosing a particular constructor. Next comes
the tuple of proper arguments for the constructor. The tuple
ends with a proof that the index has the correct value.

\begin{verbatim}
nil : (A : Set) → Vec A zero
nil A = init (nilT , refl)

cons : (A : Set) (n : ℕ) (x : A) (xs : Vec A n)
  → Vec A (suc n)
cons A n x xs = init (consT , n , x , xs , refl)
\end{verbatim}

\section{Generic Constructors}
\label{sec:inj}

The goal of this section is to {\it contribute} a novel generic
constructor for datatypes built from descriptions.
The constructors {\tt nil} and {\tt cons} are manually
defined in \refsec{init} using the initial algebra
{\tt init} as a primitive. Now we will define a generic constructor
{\tt inj} that once and for all captures the pattern inherent in
definitions of constructors.  This constructor
may be used to define {\tt nil} and {\tt cons} as follows.

\begin{verbatim}
nil : (A : Set) → Vec A zero
nil A = inj (VecD A) nilT

cons : (A : Set) (n : ℕ) (x : A) (xs : Vec A n)
  → Vec A (suc n)
cons A = inj (VecD A) consT
\end{verbatim}

Importantly, our generic constructor is
defined in terms of the existing primitives and does not extend the
metatheory.
This amounts to:

\begin{myparti}
\label{parti:one}
Currying constructor arguments.
\end{myparti}

\begin{myparti}
\label{parti:two}
Inserting an implicit proof that the constructor has the correct index.
\end{myparti}

Defining {\tt inj} may not seem impressive by itself, but it acts as
nice pedagogical step towards understanding how to define the generic
eliminator {\tt elim} in \refsec{elim}.

\subsection{Uncurried Interpretation Algebra Type}

In order to implement \refparti{one}, we must first recognize the
initial algebra as an uncurried function. Recall the type of the
initial algebra {\tt init : El D (μ D) i → μ D i}. Rather than
focusing on the initial algebra, we can generalize the uncurried view
of this constructor by replacing {\tt μ D} with an arbitrary
type family {\tt X : I → Set}.

\begin{verbatim}
UncurriedEl : {I : Set}
  (D : Desc I) (X : ISet I) → Set
UncurriedEl D X = ∀ {i} → El D X i → X i
\end{verbatim}

Recognize {\tt UncurriedEl} as an uncurried function by thinking of
{\tt El D X i} as a product of $n$ arguments $A_1 × ... × A_n$, an
argument requiring a proof of correct indexing $(j≡i)$, and
{\tt X i} as the result type $Z$.
\[
A_1 × ... × A_n × (j ≡ i) → Z
\]

\paragraph{Uncurried Algebra of a Single Constructor}

For example, applying {\tt UncurriedEl} to the description of the
{\tt cons} constructor results in the following type.

\begin{verbatim}
UncurriedEl (consD A) (Vec A) ⇝
  ∀{n} → ConsEl A n → Vec A n
\end{verbatim}

\subsection{Curried Interpretation Algebra Type}

Now let's define the curried version of the function. Recall that the
type {\tt El} is a product of arguments, and {\tt UncurriedEl} is a
function from that product to some other type family. In contrast,
{\tt CurriedEl} is one large right-nested definition of function
arguments.

\begin{verbatim}
CurriedEl : {I : Set}
  (D : Desc I) (X : ISet I) → Set
CurriedEl (End i) X = X i
CurriedEl (Rec i D) X = (x : X i) → CurriedEl D X
CurriedEl (Arg A B) X = (a : A) → CurriedEl (B a) X
\end{verbatim}

Recognize {\tt CurriedEl} as a curried function that demands
$n$ constructor arguments as function arguments
$A_1 → ... → A_n$, and has the result type $Z$.
\[
A_1 → ... → A_n → Z
\]

Significantly, {\tt CurriedEl} does not require a proof of correct
indexing $(j≡i)$. Thus, in addition to solving \refparti{one} by
currying arguments, {\tt CurriedEl} also solves \refparti{two} by
implicitly supplying the correctness proof. Compare this to the
alternative definition {\tt CurriedEl'} that explicitly requires the
correctness proof below. The extra proof can be seen in the
{\tt End} constructor case.

\begin{verbatim}
CurriedEl' : {I : Set}
  (D : Desc I) (X : ISet I) (i : I) → Set
CurriedEl' (End j) X i =
  j ≡ i → X i
CurriedEl' (Rec j D) X i =
  (x : X j) → CurriedEl' D X i
CurriedEl' (Arg A B) X i =
  (a : A) → CurriedEl' (B a) X i
\end{verbatim}

\paragraph{Curried Algebra of a Single Constructor}

Below is an example of applying {\tt CurriedEl} to the
description of the {\tt cons} constructor. Notice that all arguments
are curried, and a proof of index correctness is not demanded.

\begin{verbatim}
CurriedEl (consD A) (Vec A) ⇝
  (m : ℕ) → A → Vec A m → Vec A (suc m)
\end{verbatim}

\subsection{Curry Interpretation Algebra Function}

All we need now is a curry function that takes an
{\tt UncurriedEl} and returns a {\tt CurriedEl}. The definition of
this function is unremarkable, but its type clearly explains its
intentions.

\begin{verbatim}
curryEl : {I : Set} (D : Desc I) (X : ISet I)
  → UncurriedEl D X → CurriedEl D X
curryEl (End i) X cn =
  cn refl
curryEl (Rec i D) X cn =
  λ x → curryEl D X (λ xs → cn (x , xs))
curryEl (Arg A B) X cn =
  λ a → curryEl (B a) X (λ xs → cn (a , xs))
\end{verbatim}

\subsection{Generic Constructor}

The moment has arrived, with the help of our {\tt curryEl} function we
can easily define the generic constructor {\tt inj}.

\begin{verbatim}
inj : {I : Set} (D : Desc I) → CurriedEl D (μ D)
inj D = curryEl D (μ D) init
\end{verbatim}

Unlike previous functions, this one is specialized to datatypes
defined with {\tt μ} rather than arbitrary type families {\tt X}. This
is the function we set out to define at the beginning of this section.
Compared to values of some type introduced with {\tt init} (\refsec{init:cons}),
values introduced with {\tt inj} have curried arguments and do not
need to supply a proof {\tt refl} of correct indexing.

\section{Elimination with Algebras}
\label{sec:ind}

The goal of this section is to {\it review} how to use the primitive
elimination rule for datatypes built using descriptions. We use
the vector concatenation function (which flattens a vector of
homogenously-sized vectors) as our example, defined below using the
specialized eliminator {\tt elimVec}.

\begin{verbatim}
concat : (A : Set) (m n : ℕ)
  (xss : Vec (Vec A m) n) → Vec A (mult n m)
concat A m = elimVec (Vec A m)
  (λ n xss → Vec A (mult n m))
  (nil A)
  (λ n xs xss ih → append A m xs (mult n m) ih)
\end{verbatim}

This section develops the definitions necessary to understand how to
write {\tt concat} by applying the primitive elimination rule for
described types to a suitable algebra.

\subsection{Primitive Induction Principle}

The type of the primitive elimination rule, {\tt ind}, for datatypes built from
descriptions is given below.
The algebra {\tt α} is the important argument, as it is the proof that
that some property {\tt P} holds for any value of a
described type.
Whereas an eliminator
has separate branches for proofs about each constructor, {\tt ind}
requires a single algebra argument that proves {\tt P} for any
constructor.

\begin{verbatim}
ind : {I : Set} (D : Desc I)
  (P : (i : I) → μ D i → Set)
  (α : (i : I) (xs : El D (μ D) i)
    (ihs : Hyps D (μ D) P i xs) → P i (init xs))
  (i : I) (x : μ D i) → P i x
\end{verbatim}

In order to prove {\tt P i (init xs)} you get the following
arguments of \verb+α+:

\begin{enumerate}
\item{{\tt (i : I)}} - The index of the type being eliminated.
\item{{\tt (xs : El D (μ D) i)}} - The constructors (and their arguments) of the type
  being eliminated.
\item{{\tt (ihs : Hyps D (μ D) P i xs) → P i (init xs))}} - The inductive
  hypotheses for all constructors.
\end{enumerate}

\citet{mcbride2010ornamental} gives the definition of {\tt ind}, but
our work can be understood without knowing the definition.

\subsection{Inductive Hypothesis Type}

{\tt Hyps} computes the type of inductive hypotheses for a described
datatype. Its definition closely follows the definition of
the interpretation function of descriptions {\tt El}
(\refsec{init:el}). They both compute over a description, {\tt D}, and in
fact {\tt Hyps} expects one of its arguments, {\tt xs}, to have the type
computed by {\tt El}.

\begin{verbatim}
Hyps : {I : Set} (D : Desc I) (X : ISet I)
  (P : (i : I) → X i → Set)
  (i : I) (xs : El D X i) → Set
Hyps (End j) X P i q = ⊤
Hyps (Rec j D) X P i (x , xs) =
  P j x × Hyps D X P i xs
Hyps (Arg A B) X P i (a , b) = Hyps (B a) X P i b
\end{verbatim}

First, let's understand {\tt Hyps} by what it computes for the
description of a single constructor like {\tt nil} or {\tt cons}.
{\tt Hyps} ignores dependent arguments {\tt Arg} and moves on, looking
for recursive arguments. When finding a recursive argument {\tt Rec}, it
asks for the motive {\tt P} instantiated at the recursive argument index, {\tt j}, and value, {\tt x}.
Finally, the tree of inductive hypotheses is terminated by the unit
type {\tt ⊤} once the description ends in {\tt End}.

\paragraph{Inductive Hypotheses of a Single Constructor}

The {\tt nil} constructor of vectors has neither dependent nor
recursive arguments. Thus, {\tt Hyps} for {\tt nilD} is simply
the unit type. Recall that {\tt NilEl} is the type that
{\tt nil}'s description gets interpreted as. The definition of
{\tt nilE} and related types can be found in \refsec{init:el}.

\begin{verbatim}
NilHyps : (A : Set)
  (P : (n : ℕ) → Vec A n → Set)
  (n : ℕ) (xs : NilEl A n) → Set
NilHyps A P n xs = Hyps (nilD A) (Vec A) P n xs

NilHyps A P zero refl ⇝ ⊤
\end{verbatim}

On the other hand, the {\tt cons} constructor of vectors requires an
inductive hypothesis for its recursive argument.

\begin{verbatim}
ConsHyps : (A : Set)
  (P : (n : ℕ) → Vec A n → Set)
  (n : ℕ) (xs : ConsEl A n) → Set
ConsHyps A P n xs = Hyps (consD A) (Vec A) P n xs

ConsHyps A P (suc m) (m , x , xs , refl) ⇝
  P m x × ⊤
\end{verbatim}

\paragraph{Inductive Hypotheses of Multiple Constructors}

Once again, multiple constructors are represented by a tagged
sum (\refsec{background:multiple}). {\tt Hyps} for
{\tt VecD} requires {\it either} the inductive hypotheses of
{\tt nil} or the inductive hypotheses of {\tt cons}, depending on
which constructor {\tt Hyps} is applied to.

\begin{verbatim}
VecHyps : (A : Set)
  (P : (n : ℕ) → Vec A n → Set)
  (n : ℕ) (xs : VecEl A n) → Set
VecHyps A P n xs = Hyps (VecD A) (Vec A) P n xs

VecHyps A P n (nilT  , xs) ⇝ NilHyps  A P n xs
VecHyps A P n (consT , xs) ⇝ ConsHyps A P n xs
\end{verbatim}

\subsection{Definition of Vector Concatenation via an Algebra}

Now we shall define the vector concatenation by applying the primitive
elimination rule for described types to an algebra. Below
{\tt concat} is defined as {\tt ind} applied to the description of
vectors, then the goal type as the motive, and finally the algebra
{\tt concatα}.
Note that we define the return type of
{\tt concat} to be {\tt Concat}, allowing us to reuse the return type
in later definitions.

\begin{verbatim}
Concat : (A : Set) (m n : ℕ)
  (xss : Vec (Vec A m) n) → Set
Concat A m n xss = Vec A (mult n m)

concat : (A : Set) (m n : ℕ)
  (xss : Vec (Vec A m) n) → Concat A m n xss
concat A m = ind
  (VecD (Vec A m))
  (Concat A m)
  (concatα A m)
\end{verbatim}

\paragraph{Algebra Argument}

The algebra that defines {\tt concat} takes as arguments the index
{\tt n}, the constructors {\tt xss}, and the inductive hypotheses
{\tt ihs}. Recall that the type of vector constructors
{\tt xss : VecEl (Vec A m) n} is a dependent pair. The domain of the
pair is a vector tag {\tt VecT}, and the codomain is the type of
arguments corresponding to the constructor represented by the tag. We
eliminate the tag using {\tt case} (\refsec{background:case}), and
then provide a branches for the {\tt nil} and {\tt cons} constructors.

\begin{verbatim}
concatα : (A : Set) (m n : ℕ)
  (xss : VecEl (Vec A m) n)
  (ihs : VecHyps (Vec A m) (Concat A m) n xss)
  → Vec A (mult n m)
concatα A m n xss = case (ConcatConvoy A m n)
  (nilBranch A m n , consBranch A m n , tt)
  (proj₁ xss)
  (proj₂ xss)
\end{verbatim}

All definitions in this subsection are defined {\it without} dependent
pattern matching to illustrate the exclusive use of our type theory's
primitives ({\tt ind}, {\tt proj₁}, {\tt case}, etc). After we case
analyze the constructor tag in the first projection of {\tt xss}, we
need the {\it dependent} second projection to reduce to the arguments
of the constructor. This can be done by employing the
{\it convoy pattern}~\citep{chlipala2011certified}, in which the special motive
{\tt ConcatConvoy} is passed to {\tt case}.

\paragraph{Convoy Motive}

Again, rather than eliminating the pair {\tt xss}, we eliminate the
tag in the first projection using {\tt case}. The motive supplied to
case thus takes the first projection as an argument. The motive then
asks for the type of the second projection (dependent on the argument
supplied to the motive) as the argument {\tt xss}, in addition to the
remaining argument {\tt ihs}, and then the motive ends with the goal type
{\tt Vec A (mult n m)}.

\begin{verbatim}
ConcatConvoy : (A : Set) (m n : ℕ)
  → VecT → Set
ConcatConvoy A m n t =
  (xss : El (VecC (Vec A m) t) (Vec (Vec A m)) n)
  (ihs : VecHyps (Vec A m) (Concat A m) n (t , xss))
  → Vec A (mult n m)
\end{verbatim}

\paragraph{Nil Branch}

The {\tt nil} branch within the algebra's case analysis receives as
arguments the index {\tt n}, the single argument {\tt q}, and a value
{\tt u} of type unit as the inductive hypothesis. The argument
{\tt q} is not a proper argument of the constructor, but instead the
proof {\tt n ≡ zero}, stating that the index {\tt n} is equal to
{\tt zero} for the {\tt nil} constructor. One might expect to simply
define the {\tt nil} branch of {\tt concat} to return {\tt nil A}.
However, the type of the goal is {\tt Vec A (mult n m)} while the type
of {\tt nil A} is {\tt Vec A zero}. We can get the type of the goal to
reduce to {\tt Vec A (mult zero m)}, and then to {\tt Vec A zero}, by
applying our proof that {\tt n ≡ zero} to the equality coercion
function {\tt subst}.

\begin{verbatim}
nilBranch : (A : Set) (m n : ℕ)
  (xss : NilEl (Vec A m) n)
  (ihs : NilHyps (Vec A m) (Concat A m) n xss)
  → Vec A (mult n m)
nilBranch A m n q u = subst
  (λ n → Vec A (mult n m))
  q (nil A)
\end{verbatim}

\paragraph{Cons Branch}

The {\tt cons} branch is defined in much the same way. Note
that in {\sc Agda} an identifier is treated as single name unless it
contains a space. Thus, the argument {\tt n2-xs-xss-q} below is a
single variable whose name reminds us of the tuple of constructor
arguments that it contains. Because we do not have access to pattern
matching, we need to project out each argument. For legibility, we
bind the names of the arguments below using a {\tt let} statement.
Unlike {\tt nil}, {\tt cons} has proper arguments but its tuple also
ends with a proof -- the proof that {\tt n ≡ suc n2}. The inductive
hypothesis of {\tt concat} is contained in the first projection of the
{\tt ih-u} argument, and the second projection is again a value of
type unit.

\begin{verbatim}
consBranch : (A : Set) (m n : ℕ)
  (xss : ConsEl (Vec A m) n)
  (ihs : ConsHyps (Vec A m) (Concat A m) n xss)
  → Vec A (mult n m)
consBranch A m n n2-xs-xss-q ih-u =
  let n2 = proj₁ n2-xs-xss-q
      xs = proj₁ (proj₂ n2-xs-xss-q)
      q = proj₂ (proj₂ (proj₂ n2-xs-xss-q))
      ih = proj₁ ih-u
  in subst
    (λ n → Vec A (mult n m))
    q (append A m xs (mult n2 m) ih)
\end{verbatim}

\subsection{You Made It!}

Congratulations on making it through this section, you now know how to define dependently typed
functions using the primitive elimination rule {\tt ind}!
Getting such function definitions right was a grueling experience for
the authors, and interactive theorem proving doesn't help much when
dealing with types that are so heavily encoded. You can relax knowing
that the next section defines a generic standard eliminator that supports
programming with described datatypes, instead of using this
algebra-based approach.

\section{Generic Eliminators}
\label{sec:elim}

The goal of this section is to {\it contribute} a novel generic
eliminator, {\tt elim}, for datatypes built from descriptions.
After partially applying {\tt elim} to an enumeration of constructor
names, and a function from tags (indexing into each constructor name)
to descriptions for each constructor, the resulting type is precisely
the interface of standard eliminators in type theory!  This eliminator can
be used to define {\tt concat} as follows.

\begin{verbatim}
concat : (A : Set) (m n : ℕ)
  (xss : Vec (Vec A m) n) → Vec A (mult n m)
concat A m = elim VecE (VecC (Vec A m))
  (λ n xss → Vec A (mult n m))
  (nil A)
  (λ n xs xss ih → append A m xs (mult n m) ih)
\end{verbatim}

The function {\tt concat} is defined in \refsec{ind} by applying the
primitive elimination rule {\tt ind} to an algebra. However,
functions defined in such a manner are verbose. Instead, now we
can define functions using our generic eliminator that once again can
be defined in terms of existing primitives without extending the
metatheory. This amounts to:

\begin{myparte}
\label{parte:one}
Currying constructor arguments in branches.
\end{myparte}

\begin{myparte}
\label{parte:two}
Inserting an implicit proof in each branch that the constructor has the correct index.
\end{myparte}

\begin{myparte}
\label{parte:three}
Performing case analysis to break up constructors into branches.
\end{myparte}

\begin{myparte}
\label{parte:four}
Currying the outer function taking a product of branches.
\end{myparte}

In this section we will first focus on single-constructor
datatype descriptions, implementing \refparte{one} and \refparte{two}.
Multi-constructor descriptions represented as sum types are
discussed in \refsec{elim:sum}, and from that point on we focus on
implementing \refparte{three} and \refparte{four}.

\subsection{Uncurried Inductive Hypothesis Algebra Type}

In order to implement
\refparte{one} and \refparte{two} we must recognize the algebra
argument to {\tt ind} as an uncurried function.
Below we define {\tt UncurriedHyps} to be a generalized type synonym
for the type of the algebra argument {\tt α} to {\tt ind}, where we
replace the fixpoint
{\tt μ D} with an arbitary type family {\tt X : I → Set}. This is
analogous to the generalization {\tt UncurriedEl} of the initial
algebra type in \refsec{inj}. In fact, because we generalize
{\tt UncurriedHyps} to be defined over arbitrary {\tt X} rather than
fixpoint {\tt μ D}, we require the extra argument
{\tt cn : UncurriedEl D X}, which you can think of as a
constructor of {\tt X}.

\begin{verbatim}
UncurriedHyps : {I : Set}
  (D : Desc I) (X : ISet I)
  (P : (i : I) → X i → Set)
  (cn : UncurriedEl D X)
  → Set
UncurriedHyps D X P cn = ∀ i →
  (xs : El D X i)
  (ihs : Hyps D X P i xs)
  → P i (cn xs)
\end{verbatim}

Recognize {\tt UncurriedHyps} as a kind of uncurried function
consisting of one regular argument (the index type) and two product
arguments (the constructors and inductive hypotheses).
Think of
{\tt El D X i} as a product of $n$ arguments plus the proof of correct
indexing $A_1 × ... × A_n × (j≡i)$, {\tt Hyps D X P i xs} as a
product of $m$ inductive hypotheses plus unit $B_1 × ... × B_n × ⊤$,
and {\tt X i} as the result type $Z$.
\[
I → A_1 × ... × A_n × (j ≡ i) → B_1 × ... × B_m × ⊤ → Z
\]

\paragraph{Uncurried Algebra of a Single Constructor}

For example, we can use {\tt UncurriedHyps} to define the type of
{\tt consBranch} from \refsec{ind}.

\begin{verbatim}
ConsBranch : (A : Set) (m : ℕ) → Set
ConsBranch A m = UncurriedHyps
  (consD (Vec A m))
  (Vec (Vec A m))
  (Concat A m)
  (λ xs → init (consT , xs))

ConsBranch A m ⇝
  (n : ℕ)
  (xss : ConsEl (Vec A m) n)
  (ihs : ConsHyps (Vec A m) (Concat A m) n xss)
  → Vec A (mult n m)
\end{verbatim}

\subsection{Curried Inductive Hypothesis Algebra Type}

Just like in \refsec{inj}, now we define the curried version of
the inductive hypothesis algebra. Instead of having an index function
argument {\tt I : Set}, followed by the two tuple arguments
{\tt xs : El D X i} and {\tt ihs : Hyps D X P i xs}, we uncurry
both tuple arguments.

\begin{verbatim}
CurriedHyps : {I : Set} (D : Desc I) (X : ISet I)
  (P : (i : I) → X i → Set)
  (cn : UncurriedEl D X)
  → Set
CurriedHyps (End i) X P cn =
  P i (cn refl)
CurriedHyps (Rec i D) X P cn =
  (x : X i) → P i x
  → CurriedHyps D X P (λ xs → cn (x , xs))
CurriedHyps (Arg A B) X P cn =
  (a : A)
  → CurriedHyps (B a) X P (λ xs → cn (a , xs))
\end{verbatim}

Notice that {\tt CurriedHyps} combines the
definitions of {\tt El} and {\tt Hyps}. This can be seen in the
{\tt Rec} branch, which asks for the {\tt (x : X i)} argument
from {\tt El} and the {\tt P i x} argument from {\tt Hyps}. You can
recognize {\tt CurriedHyps} as a curried function that demands
index argument $I$, $n$ constructor arguments as function arguments
$A_1 → ... → A_n$, $m$ inductive hypotheses as function arguments
$B_1 → ... → B_m$, and has the result type $Z$.

\[
I → A_1 → ... → A_n → B_1 → ... → B_m → Z
\]

This definition obviously curries arguments, implementing
\refparte{one}, but it also inserts an implicit proof of index
correctness, implementing \refparte{two}. In \refsec{inj}, we used
the same kind of trick to define {\tt CurriedEl} to have an implicit
proof instead of asking for it explicitly as demonstrated
by {\tt CurriedEl'}. By analogy, we could have defined a version of
eliminators that required the user to receive and use an explicit
index correctness proof argument as follows.

\begin{verbatim}
CurriedHyps' : {I : Set} (D : Desc I) (X : ISet I)
  (P : (i : I) → X i → Set)
  (i : I)
  (cn : El D X i → X i)
  → Set
CurriedHyps' (End j) X P i cn =
  (q : j ≡ i) → P i (cn q)
CurriedHyps' (Rec j D) X P i cn =
  (x : X j) → P j x
  → CurriedHyps' D X P i (λ xs → cn (x , xs))
CurriedHyps' (Arg A B) X P i cn =
  (a : A)
  → CurriedHyps' (B a) X P i (λ xs → cn (a , xs))
\end{verbatim}

Notice that in
{\tt Rec} case of {\tt CurriedHyps} the motive is applied to a proof
of {\tt refl} implicitly, whereas in {\tt CurriedHyps} such a proof
must be supplied as the explicit parameter {\tt q}.

\paragraph{Curried Algebra of a Single Constructor}

Below we apply \\
{\tt CurriedHyps} to the description of the
{\tt cons} constructor. This returns the type of the {\tt cons} branch
in our eliminator-based definiton of {\tt concat} at the
beginning of this section.

\begin{verbatim}
ConsElimBranch : (A : Set) (m : ℕ) → Set
ConsElimBranch A m = CurriedHyps
  (consD (Vec A m))
  (Vec (Vec A m)) (Concat A m)
  (λ xs → init (consT , xs))

ConsElimBranch A m ⇝
  (n : ℕ)
  (xs : Vec A m)
  (xss : Vec (Vec A m) n)
  (ih : Vec A (mult n m))
  → Vec A (add m (mult n m))
\end{verbatim}

This is precisely the expected type of the {\tt cons} branch of
an {\tt elimVec}-based definition of {\tt concat}. Because the index
proof is implicitly applied, the return type can definitionally
reduce from {\tt Vec A (mult (suc n) m)}
to {\tt Vec A (add m (mult n m))}.

\subsection{Uncurry Inductive Hypothesis Algebra Function}

Shortly, we will be need a function that {\it uncurries} the inductive
hypothesis algebra. Once again, the definition is unremarkable and the
type explains it all.

\begin{verbatim}
uncurryHyps : {I : Set} (D : Desc I) (X : ISet I)
  (P : (i : I) → X i → Set)
  (cn : UncurriedEl D X)
  → CurriedHyps D X P cn → UncurriedHyps D X P cn
uncurryHyps (End .i) X P cn pf i refl tt =
  pf
uncurryHyps (Rec j D) X P cn pf i (x , xs) (ih , ihs) =
  uncurryHyps D X P
    (λ ys → cn (x , ys)) (pf x ih) i xs ihs
uncurryHyps (Arg A B) X P cn pf i (a , xs) ihs =
  uncurryHyps (B a) X P
    (λ ys → cn (a , ys)) (pf a) i xs ihs
\end{verbatim}

\subsection{Curried Induction Principle}

Below we define
the function {\tt indCurried}. It is like the primitive {\tt ind},
except it takes a curried inductive hypothesis algebra instead of an
uncurried one.

\begin{verbatim}
indCurried : {I : Set} (D : Desc I)
  (P : (i : I) → μ D i → Set)
  (f : CurriedHyps D (μ D) P init)
  (i : I)
  (x : μ D i)
  → P i x
indCurried D P f i x =
  ind D P (uncurryHyps D (μ D) P init f) i x
\end{verbatim}

In \refsec{inj} we wrote a currying function
{\tt curryEl}. When introducing values, we have the uncurried initial
algebra {\tt init} and need to curry it to get generic constructors.
When eliminating using {\tt indCurried},
the user supplies a curried algebra that we uncurry
and pass to the primitive elimination rule {\tt ind}.

Because
{\tt indCurried} takes {\tt CurriedHyps} as an algebra, it implements
\refparte{one} and \refparte{two}.
Thus, we would have the expected eliminator interface when writing
functions with {\tt indCurried} over singleton datatypes built from
descriptions -- those that do not start with a sum of constructors and
instead only have ``single constructor'' with arguments.

\subsection{Sum of Curried Inductive Hypotheses Type}
\label{sec:elim:sum}

Soon we will implement \refparte{three} by defining a generic eliminator
that performs case analysis over datatypes described as a
sum (constructors) of products (arguments). We can demand such a
datatype in sum-of-products form by parameterizing not by a description,
but by an {\tt E : Enum} and a function {\tt C} from tags of that enumeration to
descriptions representing the constructor choices. Below is a function
that computes the type of the curried inductive hypothesis algebra for
some particular constructor of a datatype, where the particular
constructor is specified by a tag.

\begin{verbatim}
SumCurriedHyps : {I : Set}
  (E : Enum) (C : Tag E → Desc I)
  → let D = Arg (Tag E) C in
  (P : (i : I) → μ D i → Set)
  → Tag E → Set
SumCurriedHyps E C P t =
  let D = Arg (Tag E) C in
  CurriedHyps (C t) (μ D) P (λ xs → init (t , xs))
\end{verbatim}

Recall from
\refsec{background} that we defined datatypes like {\tt Vec} in such
pieces anyway, namely {\tt VecE} for the enumeration and {\tt VecC}
for the function from tags to constructor descriptions.
We can use these two
pieces to build a description starting with {\tt Arg}, as seen in the
{\tt let} bindings above.

\paragraph{Sum of Curried Algebras}

For example, we can use
\linebreak {\tt SumCurriedHyps}
to define a version of
{\tt ConsElimBranch} that works for any constructor of {\tt Vec} as
specified by a tag.

\begin{verbatim}
ElimBranch : (t : VecT)
  (A : Set) (m : ℕ) → Set
ElimBranch t A m = SumCurriedHyps VecE
  (VecC (Vec A m)) (Concat A m) t

ElimBranch consT A m ⇝ ConsElimBranch A m
\end{verbatim}

\subsection{Uncurried Eliminator}

Now we can implement \refparte{three} by specializing an elimination
principle to sums-of-products style datatypes, again by parameterizing
our function by an enumeration and function from enumeration tags to
descriptions for each constructor.

\begin{verbatim}
elimUncurried : {I : Set}
  (E : Enum) (C : Tag E → Desc I)
  → let D = Arg (Tag E) C in
  (P : (i : I) → μ D i → Set)
  → Branches E (SumCurriedHyps E C P)
  → (i : I) (x : μ D i) → P i x
elimUncurried E C P cs i x =
  let D = Arg (Tag E) C in
  indCurried D P
    (case (SumCurriedHyps E C P) cs)
    i x
\end{verbatim}

While {\tt indCurried} takes a single curried algebra function
({\tt CurriedHyps D (μ D) P init}), {\tt elimUncurried} takes a
product ({\tt Branches E (SumCurriedHyps E C P)})
of curried algebra functions, one for each constructor. The
implementation of {\tt elimUncurried} uses {\tt indCurried} to perform
induction, then in the body of the induction uses {\tt case} to
eliminate the branches. Recall that when we defined {\tt concat} in
\refsec{ind} with the primitive {\tt ind}, we first performed the
induction using {\tt ind} and then performed case analysis on the sum
of constructors. Our new function {\tt elimUncurried} internalizes
exactly this pattern.

\subsection{Uncurried Branches Type}

The {\tt elimUncurried} function is nearly what we expect from a
standard eliminator. However, it still takes all branches of the
eliminator as a product of arguments. We would like to curry this
product, thus implementing \refparte{four}.
To do this we need a curried and uncurried
version of a function whose domain is {\tt Branches}
from \refsec{background}. Recall that {\tt Branches} is merely a
dependent product of arguments, one for each element in an
enumeration. Below is a type synonym for a non-dependent function from
{\tt Branches} to some result type.

\begin{verbatim}
UncurriedBranches : (E : Enum)
  (P : Tag E → Set) (X : Set) → Set
UncurriedBranches E P X = Branches E P → X
\end{verbatim}

It is easy to recognize {\tt UncurriedBranches} as a standard
uncurried function. Think of {\tt Branches E P} as a product of
$n$ arguments $A_1 × ... × A_n$,
and {\tt X} as the result type $Z$.
\[
A_1 × ... × A_n → Z
\]

\subsection{Curried Branches Type}

Defining a curried version of a function taking branches is
straightforward. Unlike {\tt CurriedEl} and {\tt CurriedHyps},
{\tt CurriedBranches} does not insert an implicit proof of index
correctness anywhere, so it really is just a standard curried
function.

\begin{verbatim}
CurriedBranches : (E : Enum)
  (P : Tag E → Set) (X : Set) → Set
CurriedBranches [] P X =
  X
CurriedBranches (l ∷ E) P X =
  P here → CurriedBranches E (λ t → P (there t)) X
\end{verbatim}

The only thing of interest in this definition is incrementing the tag
in the motive with {\tt there} in recursive calls, because the motive
is dependent on the smaller enumeration {\tt E} in the recursive call.

It is also easy to recognize {\tt CurriedBranches} as a standard
curried function, dependent $n$ curried argument $A_1 × ... × A_n$ and
returning $Z$.
\[
A_1 → ... → A_n → Z
\]

\subsection{Curry Branches Function}

Shortly, we will need a function that {\it curries} a function that
takes branches. Again, this function is not surprising and can be
understood from its type.

\begin{verbatim}
curryBranches :
  {E : Enum} {P : Tag E → Set} {X : Set}
  → UncurriedBranches E P X → CurriedBranches E P X
curryBranches {[]} f =
  f tt
curryBranches {l ∷ E} f =
  λ c → curryBranches (λ cs → f (c , cs))
\end{verbatim}

\subsection{Generic Eliminator}

At long last, we have come to the grand moment, the definition of the
generic eliminator {\tt elim}! With a final flick of the wrist, we
apply {\tt curryBranches} to the result of {\tt elimUncurried}.

\begin{verbatim}
elim : {I : Set} (E : Enum) (C : Tag E → Desc I)
  → let D = Arg (Tag E) C in
  (P : (i : I) → μ D i → Set)
  → CurriedBranches E
      (SumCurriedHyps E C P)
      ((i : I) (x : μ D i) → P i x)
elim E C P = curryBranches (elimUncurried E C P)
\end{verbatim}

Note that the return type of {\tt elim} is specified with
\linebreak
{\tt CurriedBranches}. To see the curry/uncurry resemblence with
{\tt elimUncurried}, recognize that the return type of
{\tt elimUncurried} can equivalently be written with
{\tt UncurriedBranches}.

\begin{verbatim}
  ...
  → UncurriedBranches E
      (SumCurriedHyps E C P)
      ((i : I) (x : μ D i) → P i x)
⇝
  ...
  → Branches E (SumCurriedHyps E C P)
  → (i : I) (x : μ D i) → P i x
\end{verbatim}

In \refsec{ind} we had to do a lot of work to define simple dependently
typed functions like {\tt concat} using the algebra-based primitive
elimination rule {\tt ind}. In this section we did just as much work,
if not more, to define the generic eliminator {\tt elim}. However,
this need only be done once and now defining any concrete function
like {\tt concat} can be done very tersely using {\tt elim}, just as
the example at the beginning of this section demonstrates.

For pedagogical reasons, we presented the definiton of {\tt concat} in
terms of {\tt ind} by combining several smaller definitions. This
somewhat hides the verbosity of an {\tt ind}-based definition, so we
have provided an additional example that illustrates the difference
between definitions using {\tt ind} versus {\tt elim}. You can
find a definition of vector {\tt append} (adding two vectors) using
{\tt elim} in \reffig{append-elim}. Now you can appreciate {\tt elim}
by comparing \reffig{append-elim} with the
much more verbose definition of
{\tt append} using {\tt ind} in \reffig{append-ind}.

\section{Correctness}
\label{sec:correctness}

The goal of this section is to {\it prove} that the primitive
elimination rule {\tt ind} is extensionally equivalent to our
generic eliminator {\tt elim}. This amounts to proving:

\paragraph{Soundness}

\begin{align*}
&\forall a_1 ... a_n. ~ \exists \alpha. \\
&\textrm{ind} ~ (\textrm{Arg} ~ (\textrm{Tag} ~ E) ~ C) ~ P ~ \alpha ~ i ~ x =
\textrm{elim} ~ E ~ C ~ P ~ a_1 ~ ... ~ a_n ~ i ~ x
\end{align*}

\paragraph{Completeness}

\begin{align*}
&\forall \alpha. ~ \exists a_1 ... a_n. \\
&\textrm{ind} ~ (\textrm{Arg} ~ (\textrm{Tag} ~ E) ~ C) ~ P ~ \alpha ~ i ~ x =
\textrm{elim} ~ E ~ C ~ P ~ a_1 ~ ... ~ a_n ~ i ~ x
\end{align*}

However, the return type of {\tt elim} is a {\tt CurriedBranches} type,
which computes to a type taking $n$ function arguments,
one for each constructor branch,
and ending with the motive.

\[
A_1 → ... → A_n → (i : I) ~ (x : \mu ~ D ~ i) → P ~ i ~ x
\]
\linebreak
We only get this expanded type if {\tt elim} is applied to a concrete
description, otherwise {\tt CurriedBranches} will not unfold. Because
of this techninal annoyance, we will prove the equivalence between
{\tt ind} and the helper function {\tt elimUncurried} instead, which
takes all branches of the eliminator as a single tuple argument.

\subsection{Soundness}

Formally, the type of soundness of {\tt elimUncurried} with respect to
{\tt ind} is defined below.
Note that the existential type ({\tt ∃}) is
shorthand for a dependent pair type ({\tt Σ}) whose domain type is
inferred.

\begin{verbatim}
Soundness : Set
Soundness = {I : Set}
  (E : Enum) (C : Tag E → Desc I)
  → let D = Arg (Tag E) C in
  (P : (i : I) → μ D i → Set)
  (β : Branches E (SumCurriedHyps E C P))
  (i : I) (x : μ D i)
  → ∃ λ α
  → ind D P α i x ≡ elimUncurried E C P β i x
\end{verbatim}

{\tt Soundness} states that any function defined by
{\tt elimUncurried} applied to a tuple of constructor branches
({\tt β}) --
each containing curried arguments and implicit proofs of index
correctness -- can equivalently expressed by {\tt ind} applied to a
suitable algebra ({\tt α}).
In \reffig{soundness} we state and prove soundness informally
as a theorem, omitting all but the key function arguments for legibility.

\begin{figure*}
\caption{Soundness of {\tt elim}}
\label{fig:soundness}
\begin{mythm}
\begin{align*}
\forall \beta. ~ \exists \alpha.
~ \textrm{ind} ~ \alpha = \textrm{elimUncurried} ~ \beta
\end{align*}
\end{mythm}

\begin{proof}
\begin{align*}
\textrm{ind} ~ \alpha &= \textrm{elimUncurried} ~ \beta& && \\
\textrm{ind} ~ \alpha &=\textrm{indCurried} ~ ( \textrm{case} ~ \beta ) && \text{(by def {\tt elimUncurried})} \\
\textrm{ind} ~ \alpha &= \textrm{ind} ~ ( \textrm{uncurryHyps} ~ ( \textrm{case} ~ \beta ) ) && \text{(by def {\tt indCurried})} \\
\textrm{ind} ~ ( \textrm{uncurryHyps} ~ ( \textrm{case} ~ \beta ) ) &= \textrm{ind} ~ ( \textrm{uncurryHyps} ~ ( \textrm{case} ~ \beta ) ) && (\text{solve} ~ \alpha := \textrm{uncurryHyps} ~ ( \textrm{case} ~ \beta ))
\end{align*}
\end{proof}
\end{figure*}

\begin{figure*}
\caption{Completeness of {\tt elim}}
\label{fig:completeness}
\begin{mythm}
\begin{align*}
\forall \alpha. ~ \exists \beta.
~ \textrm{ind} ~ \alpha = \textrm{elimUncurried} ~ \beta
\end{align*}
\end{mythm}

\begin{proof}
\begin{align*}
\textrm{ind} ~ \alpha &= \textrm{elimUncurried} ~ \beta& && \\
\textrm{ind} ~ \alpha &=\textrm{indCurried} ~ ( \textrm{case} ~ \beta ) && \text{(by def {\tt elimUncurried})} \notag\\
\textrm{ind} ~ \alpha &= \textrm{ind} ~ ( \textrm{uncurryHyps} ~ ( \textrm{case} ~ \beta ) ) && \text{(by def {\tt indCurried})} \notag\\
\textrm{ind} ~ \alpha &= \textrm{ind} ~ ( \textrm{uncurryHyps} ~ ( \textrm{case} ~ ( \textrm{toBranches} ~ \alpha ) ) ) && (\text{solve} ~ \beta := \textrm{toBranches} ~ \alpha) \\
\textrm{ind} ~ \alpha &= \textrm{ind} ~ ( \textrm{uncurryHyps} ~ ( \textrm{curryHyps} ~ \alpha ) ) && \text{(by lemma {\it ToBranches})} \\
\textrm{ind} ~ \alpha &= \textrm{ind} ~ \alpha && \text{(by lemma {\it CurryHypsIdent})}
\end{align*}
\end{proof}
\end{figure*}

\subsection{Completeness}

Formally, the type of completeness of {\tt elimUncurried} with respect to
{\tt ind} is defined below.

\begin{verbatim}
Completeness : Set
Completeness = {I : Set}
  (E : Enum) (C : Tag E → Desc I)
  → let D = Arg (Tag E) C in
  (P : (i : I) → μ D i → Set)
  (α : UncurriedHyps D (μ D) P init)
  (i : I) (x : μ D i)
  → ∃ λ β
  → ind D P α i x ≡ elimUncurried E C P β i x
\end{verbatim}

{\tt Completeness} is the converse of {\tt Soundess}.
It states that any function defined by
{\tt ind} applied to a suitable algebra ({\tt α}), can equivalently be
expressed by {\tt elimUncurried} applied to a tuple of constructor branches
({\tt β}). In \reffig{completeness} we
state and prove completeness informally
as a theorem, once again omitting all but the key function arguments.

The proof of completeness in \reffig{completeness} uses the following
two lemmas. It also uses the definition of the function
{\tt toBranches}, which can be found in the accompanying source
code. The {\tt toBranches} function just translates an
{\tt UncurriedHyps} algebra to {\tt Branches E (SumCurriedHyps E C P)}.

\begin{mylem}[ToBranches]
\begin{align*}
\textrm{case} \circ \textrm{toBranches} = \textrm{curryHyps}
\end{align*}
\end{mylem}

\begin{proof}
By induction on the tag indexing into the enumeration of constructors argument.
\end{proof}

\begin{mylem}[CurryHypsIdent]
\begin{align*}
\textrm{uncurryHyps} \circ \textrm{curryHyps} = \textrm{id}
\end{align*}
\end{mylem}

\begin{proof}
By induction on the description argument.
\end{proof}

\section{Related Work}
\label{sec:related-work}

Our work focuses on internalizing the definition of constructors and
eliminators in terms of existing primitives that use algebras.

\subsection{Generic Programming using Descriptions}

There has been a lot of work on performing generic programming over
datatypes defined using descriptions. In some sense, this was the original
purpose of the description technology. For example,
\citet{Chapman:2010:GAL:1932681.1863547} define a generic catamorphism
(a non-dependent {\tt ind}), and a generic free monad construction.
Ornaments \citep{mcbride2010ornamental} support the definition of new
description-based datatypes in terms of their relationship with
existing datatypes, and support the conversion between the two. Free
conversion between data means that one can reuse functions defined
over old types when defining new, more specifically indexed, dependent
types, solving a major reuse issue with dependently typed programming.
\citet{dagand:phd} implements a generic ``deriving'' mechanism,
similar in purpose to {\tt deriving} in
{\sc Haskell}~\citep{jones2003haskell}, that derives
functions such as decidable equality over a class of datatypes that
support such functions. \citet{dagand:phd} also generically defines
constructions~\citep{mcbride2006few}, such as case
analysis and injectivity of constructors, that are used when
elaborating dependent pattern matching to eliminators.

\citet{Chapman:2010:GAL:1932681.1863547} introduced descriptions in a
paper that also introduced the technique of {\it levitation}.
Levitation is a technique to reduce the number of type theory
primitives, hence the size of a core type theory, by defining certain
datatypes that would normally be primitive in terms of descriptions
(including descriptions themselves, hence the name ``levitation'').
While both levitation and a closed type theory based on descriptions
were introduced at the same time, the closed type theory can also be
defined without levitation. Hence, our present work of generic type
theory constructions is orthogonal to whether or not the closed type
theory primitives have been levitated.

\citet{dagand2012transporting} describe using ornaments
to define new functions from old ones, such that the
relationship between the two is freely captured.
This work uses an alternative, more expressive, description
type that makes it possible to define datatypes as computations over
their index rather than using the equality type to constrain what the
indices must be. We have not extended the present work to
computational descriptions, but this should be possible in the same
way that \citet{dagand:phd} defines generic operations over
computational descriptions that are restricted to a universe of
``tagged descriptions'' representing sum-of-products style datatypes.

An alternative way to encode datatypes is to
support sum types directly in descriptions and use those rather than
their isomorphic dependent pair equivalents. Foveran~\citep{foveran} is
an example of a language that encoded sum types directly. Our work
could be extended to use descriptions that support primitive sum
types. A function like {\tt elim} would still need to be parameterized
by an {\tt Enum}-like collection of all constructors, such that the
primitive sum description could be computed from the {\tt Enum} in the
same way that we use the enumeration to build an {\tt Arg}
description.

\subsection{Metatheory of Descriptions}

\citet{dagand:phd} defines an elaboration procedure to translate
{\tt data} declaration syntax to descriptions. As part of the
metatheory of this work, Dagand defines and proves a soundness theorem
that any high level datatype declaration elaborates to a well-typed
term in the kernel type theory. Dagand defines and proves completeness as the
extensional equivalence between {\sc Coq}'s {\tt Fix}-based
definitions and {\tt ind}-based definitions. This is done at the level
of the metatheory of {\sc Coq}'s {\tt Fix}-based definitions, which
\citet{gimenez1995codifying} defines in terms of underlying
eliminators. Although Dagand does not describe the proof in all of its
low-level ``symbol-pushing'' detail, converting from
eliminator-based definitions, to {\tt ind}-based definitions is very similar
to what we have described. The difference is that, in our work, this
conversion is {\it internalized}, as we define eliminators in terms of
{\tt ind} within the existing type theory, rather than prove an
equivalence to eliminators defined at the level of the metatheory.

Besides defining {\tt elim} in terms of {\tt ind}, we also prove the
extensional equivalence of both functions as a soundness and
completeness theorem. We also expect these theorems to be similar in
nature to the proof by \citet{dagand:phd} in terms of the work by
\citet{gimenez1995codifying}.

\subsection{Algebras Defined with Curry}

Throughout this paper we have emphasized the verbosity of functions
defined in terms of the primitive elimination rule {\tt ind}.
\citet{mcbride2010ornamental} gives examples of functions defined more
tersely in terms of {\tt ind} by sprinkling in uses of the {\tt curry}
function. We believe that while this makes functions easier to
read, they are still difficult to write, even when defining them
interactively due to pervasive definitional expansion of encoded
constructions.

\section{Conclusion \& Future Work}
\label{sec:conclusion}

Closed dependently typed languages that define datatypes from
descriptions offer tremendous generic programming capabilities.
However, when programming over particular datatypes within the model
of a closed language, it can be useful
to not worry about the details of the encodings of description-based
datatypes. Thanks to our our generic
constructor ({\tt inj}) and generic eliminator ({\tt elim}), users can
now optionally program in the IDSL of type theory, without needing to
be aware of description-based encodings.

Besides the generic constructors and eliminators we presented here, we
have used the same techniques to generically implement type
formers. This is made possible by representing datatype parameters and
indices explicitly as telescopes. We have also modified the generic
constructor and eliminator to be parameter and index aware. Additionally, we have added a
distinct {\it implicit} argument constructor for telescopes and
descriptions, allowing users of our IDSL to specify which type
parameters, type indices, and constructor arguments should be rendered
as implicit arguments. These extensions can be found in the
accompanying source code, linked in the introduction.

\appendix

\begin{figure*}
\caption{Definition of vector {\tt append} using our generic {\tt elim}}
\label{fig:append-elim}
\begin{verbatim}
  append : (A : Set) (m : ℕ) (xs : Vec A m) (n : ℕ) (ys : Vec A n) → Vec A (add m n)
  append A = elim VecE (VecC A) (λ m xs → (n : ℕ) (ys : Vec A n) → Vec A (add m n))
    (λ n ys → ys)
    (λ m x xs ih n ys → cons A (add m n) x (ih n ys))
\end{verbatim}
\end{figure*}

\begin{figure*}
\caption{Definition of vector {\tt append} using the primitive {\tt ind}}
\label{fig:append-ind}
\begin{verbatim}
  append : (A : Set) (m : ℕ) (xs : Vec A m) (n : ℕ) (ys : Vec A n) → Vec A (add m n)
  append A = ind (VecD A) (λ m xs → (n : ℕ) (ys : Vec A n) → Vec A (add m n))
    (λ m t-c → case
      (λ t → (c : El (VecC A t) (Vec A) m)
             (ih : Hyps (VecD A) (Vec A) (λ m xs → (n : ℕ) (ys : Vec A n) → Vec A (add m n)) m (t , c))
             (n : ℕ) (ys : Vec A n) → Vec A (add m n)
      )
      ( (λ q ih n ys → subst (λ m → Vec A (add m n)) q ys)
      , (λ m2-x-xs-q ih-u n ys →
          let m2 = proj₁ m2-x-xs-q
              x = proj₁ (proj₂ m2-x-xs-q)
              q = proj₂ (proj₂ (proj₂ m2-x-xs-q))
              ih = proj₁ ih-u
          in
          subst (λ m → Vec A (add m n)) q (cons A (add m2 n) x (ih n ys))
        )
      , tt
      )
      (proj₁ t-c)
      (proj₂ t-c)
    )
\end{verbatim}
\end{figure*}

\acks

We are indebted to everyone involved with the
{\sc Epigram}~\citep{mcbride2005epigram} language project, from which
descriptions sprung, and more broadly everyone involved with defining
descriptions.
We would also like to thank Nathan Collins for discussing some of this
development with us and helping us settle on some terminology.
Finally, we are grateful for feedback from anonymous reviewers.
This
work was supported by NSF/CISE/CCF grant \#1320934.

\bibliographystyle{abbrvnat}
\bibliography{generic-elim}

\end{document}


\documentclass{article}

\usepackage{fancyhdr}
\usepackage{extramarks}
\usepackage{amsfonts}
\usepackage{syntax}
\usepackage{stmaryrd}
\usepackage{mathpartir}
\usepackage{tipa}

%
% Basic Document Settings
%

\topmargin=-0.45in
\evensidemargin=0in
\oddsidemargin=0in
\textwidth=6.5in
\textheight=9.0in
\headsep=0.25in

\linespread{1.1}

\pagestyle{fancy}
\chead{Globally Ordered Type System}
\lfoot{\lastxmark}
\cfoot{\thepage}

\renewcommand\headrulewidth{0.4pt}
\renewcommand\footrulewidth{0.4pt}

\setlength\parindent{30pt}

\newcommand{\Z}{\mathbb{Z}}
\newcommand{\Zt}{$\Z$}

% Create a relational rule
% [#1] - Additional mathpartir arguments
% {#2} - Name of the rule
% {#3} - Premises for the rule
% {#4} - Conclusions for the rule
\newcommand{\relationRule}[4][]{\inferrule*[lab={\sc #2},#1]{#3}{#4}}

\newcommand{\rel}[1]{\ensuremath{\llbracket {#1} \rrbracket}}
\newcommand{\ttt}{\texttt}
\newcommand{\transform}{\rightsquigarrow}
\newcommand{\proj}{\pi}
\newcommand{\ttuple}{(\tau_1, \ldots, \tau_n)}
\newcommand{\etuple}{(e_1,\ldots,e_n)}
\newcommand{\bool}{\mathrm{bool}}
\newcommand{\integer}{\mathrm{int}}
\newcommand{\option}{\mathrm{option}}
\newcommand{\uoption}[1]{(\bool,#1)}
\newcommand{\opt}[1]{\texttt{opt-#1}}
\newcommand{\varOf}[1]{\texttt{varOf}(#1)}

\begin{document}
\section*{The System}
Everything in this document is defined with respect to an ordered set $\mathbb{G} = \{g_1, \dots, g_n\}$ of \emph{global variables}. Our goal is to enforce that $g_1$ is always used before $g_2$, $g_2$ before $g_3$, and so on. For simplicity, we require that each global variable be used; however, it is simple to relax this restriction by adding subtyping.

The \emph{effects} in this system specify which global variables have been used so far. Effects are represented as an integer from $1$ to $n+1$, where effect $i$ means that all global variables up to but not including $g_i$ have been used so far (that is, we expect to use $g_i$ next).

Unlike a regular ordered type system, we have a looser definition of when a variable is used. Our model is one in which the global variables are not considered \emph{used} until they are actually accessed. We can think of global variables as something like ref cells, and we wish to track their dereferences/assignments. This will be the syntax we use in this presentation; however, in actual dpt, the user views global variables as simple values. The dpt language will not have the dereference/assign operators that we will present below, but instead will have several builtin functions which perform similar tasks.

This system sits atop a regular type system for the language, and modifies it slightly. Specifically, we modify function types to include an effect. Instead of being represented as $\tau \rightarrow \tau$, they now have the form $(\tau, \epsilon) \rightarrow (\tau, \epsilon)$. We expect function arguments to be annotated with both, although in practice we intend to perform type inference.

We also allow users to define polymorphic (in effect) functions by annotating with an "effect" variable such as $\alpha$, analogously to regular polymorphic functions. As a result, we might wish to write a function with type $(\texttt{int}, \alpha) \rightarrow (\texttt{bool}, \alpha+1)$. Hence we shall bolster our effect grammar with effect variables and the + construct.

All in all, we have the following grammar of types and effects. For concreteness, we assume the base type Int and Bool, as well as function and pair types. We also need unit for ref cell updates.

$\forall \alpha. (\texttt{ref } (Int, \alpha), \alpha) \rightarrow (Int, \alpha+1)$

\begin{grammar}
	<$\epsilon$ (effects)> ::= 1 | 2 | \dots | n + 1 | $\alpha$ | $\epsilon + \epsilon$

	<$\tau$ (types)> ::= Unit | Int | Bool | ref ($\tau, \epsilon$) | $\tau * \tau$ | $\forall \alpha.(\tau, \epsilon) \rightarrow (\tau, \epsilon)$
\end{grammar}

Next, we define a simple functional language to use this system on:

\begin{grammar}
	<$x$ (variables)> ::= alphanumeric

	<$v$ (values)> ::= () | $\Z$ | True | False | $(v, v)$ | <closures> | $g_1$ | \dots | $g_n$

	<$e$ (expressions)> ::= $v$ | $x$ | $(e,e)$ | let $x$ = $e$ in $e$ | !$e$ | $e := e$
	\alt $\texttt{fun}\ [\alpha]\ (x:\tau, \epsilon) \rightarrow e$ | $e[\epsilon]$ $e$
\end{grammar}

Note that we treat the global variables as values in their own right in this system.

The $\texttt{fun}\ [\alpha]$ syntax defines an effect-polymorphic function whose effects may use the universally quantified effect variable $\alpha$. The $e[\epsilon]$ $e$ syntax applies an effect-polymorphic function, instantiating $\alpha$ with $\epsilon$.

One might notice that updating a global variable is pointless, since it will thereafter count as used. In practice, we expect this system to be used on a series of programs, all of which share the global variables, and each of which uses the global variables in order. So a program might update a global variable for use in a later program.

\section*{The Typing Relation}

Type inference in this system simultaneously reasons about effects and regular types. As a result, the typing relation has an extra input and output, representing the state of the global variables before and after the expression, respectively.

Our typing relation will thus have the form $\Gamma, \epsilon \vdash e\ \colon \tau, \epsilon$. As usual, $\Gamma$ represents our current collection of bound variables; we treat it as a set. Our goal is that our program $p$ satisfies $\emptyset, 1 \vdash p\ \colon \tau, n+1$ for some $\tau$.

When writing rules, we use the convention that the metavariable $x$ matches all \emph{non-global} variables. We will always denote global variables using symbols of the form $g_i$.

Without further ado, let's start at the bottom. We write $\tau_i$ for the type of the value stored in $g_i$. We also assume an equivalence relation on effects such that addition is commutative and associative, and if $e_1, e_2$ are integers then the effect $e_1 + e_2$ is equivalent to the effect given by the integer sum of $e_1$ and $e_2$. We treat equivalent effects as equal for the purposes of applying the rules.

\begin{mathpar}
	\relationRule{int}{
		n \in \Z
	}{
		\Gamma, \epsilon \vdash n\ \colon \texttt{Int}, \epsilon
	}

	\relationRule{true}{
		\
	}{
		\Gamma, \epsilon \vdash \texttt{True}\ \colon \texttt{Bool}, \epsilon
	}

	\relationRule{false}{
		\
	}{
		\Gamma, \epsilon \vdash \texttt{False}\ \colon \texttt{Bool}, \epsilon
	}

	\relationRule{local variable}{
		\Gamma[x] = \tau
	}{
		\Gamma, \epsilon \vdash x\ \colon \tau, \epsilon
	}

	\relationRule{global variable}{
		\
	}{
		\Gamma, \epsilon \vdash g_i\ \colon \texttt{ref}(\tau_i, i), \epsilon
	}
\end{mathpar}

Notice how none of these rules increment $\epsilon$. We can now write some of the simpler recursive rules:

\begin{mathpar}
	\relationRule{pair}{
		\Gamma, \epsilon \vdash e_1\ \colon \tau_1, \epsilon_1\\
		\Gamma, \epsilon_1 \vdash e_2\ \colon \tau_2, \epsilon_2
	}{
		\Gamma, \epsilon \vdash (e_1, e_2)\ \colon \tau_1 * \tau_2, \epsilon_2
	}

	\relationRule{let}{
		\Gamma, \epsilon \vdash e_1\ \colon \tau_1, \epsilon_1\\
		\Gamma[x := \tau_1], \epsilon_1 \vdash e_2\ \colon \tau_2, \epsilon_2
	}{
		\Gamma, \epsilon \vdash \texttt{let } x = e_1 \texttt{ in } e_2\ \colon \tau_2, \epsilon_2
	}
\end{mathpar}

Now let's finally write some rules that actually change $\epsilon$

\begin{mathpar}
	\relationRule{deref}{
		\Gamma, \epsilon \vdash e\ \colon \texttt{ref}(\tau, \epsilon_1), \epsilon_1
	}{
		\Gamma, \epsilon \vdash !e\ \colon \tau, \epsilon_1+1
	}

\relationRule{ref-assign}{
	\Gamma, \epsilon \vdash e_1\ \colon \tau, \epsilon_1\\
	\Gamma, \epsilon_1 \vdash e_2\ \colon \texttt{ref}(\tau, \epsilon_2), \epsilon_2
}{
	\Gamma, \epsilon \vdash e_2 := e_1\ \colon \texttt{Unit}, \epsilon_2+1
}
\end{mathpar}

Whoof. Notice how, when we evaluate the ref expression, its carried $\epsilon$ is expected to be equivalent to the output of the typing relation. Since we're about to use it, this ensures we're actually ready and able to access it. Also note how $e_2$ and $e_1$ appear "backwards" in the ref-assign rule, to reflect the order in which they are evaluated.

Now, finally, let's have some \texttt{fun}.
\begin{mathpar}
	\relationRule{abs}{
		\Gamma[x := \tau], \epsilon_f \vdash e\ \colon \tau_1, \epsilon_1
	}{
		\Gamma, \epsilon \vdash \texttt{poly } \alpha (x : \tau, \epsilon_f) \rightarrow e\ \colon \forall \alpha.(\tau, \epsilon_f) \rightarrow (\tau_1, \epsilon_1), \epsilon
	}

	\relationRule{app}{
		\Gamma, \epsilon \vdash e_1\ \colon \forall \alpha.\tau_1, \epsilon_1\\
		\Gamma, \epsilon_1 \vdash e_2\ \colon \tau_2, \epsilon_2\\
		\tau_1[\epsilon_\alpha/\alpha] = (\tau_2, \epsilon_2) \rightarrow (\tau', \epsilon')
	}{
		\Gamma, \epsilon \vdash e_1[\epsilon_\alpha]\ e_2\ \colon \tau', \epsilon'
	}
\end{mathpar}

Where we assume the substitution relation on effects works as expected.

\section*{Weak Globally Ordered Type System}
It's pretty easy to see how we could convert this to a weakly-ordered effect system (in which each ordered variable may be used at most once, instead of exactly once) just by inserting some inequalities into the rules. More interesting, though, is the observation that this corresponds to adding subtyping to the effects. The effect rules are:

\begin{mathpar}
	\relationRule{refl-effect}{
		\
	}{
		\epsilon <: \epsilon
	}

	\relationRule{trans-effect}{
		\epsilon_1 <: \epsilon_2\\
		\epsilon_2 <: \epsilon_3
	}{
		\epsilon_1 <: \epsilon_3
	}

	\relationRule{sub-effect}{
		i < j
	}{
      	i <: j
	}

	\relationRule{plus-effect}{
		i <: j\\ k <: l
	}{
		i+k <: j+l
	}
\end{mathpar}

While the type rules are:

\begin{mathpar}
	\relationRule{refl-type}{
		\
	}{
		\tau <: \tau
	}

	\relationRule{trans-type}{
		\tau_1 <: \tau\
		\tau_2 <: \tau_3
	}{
		\tau_1 <: \tau_3
	}

	\relationRule{function}{
		\tau_1' <: \tau_1\\
		\tau_2 <: \tau_2'\\
		\epsilon_1' <: \epsilon_1\\
		\epsilon_2 <: \epsilon_2'
	}{
		(\tau_1, \epsilon_1) \rightarrow (\tau_2, \epsilon_2) <: (\tau_1', \epsilon_1') \rightarrow (\tau_2', \epsilon_2')
	}

	\relationRule{ref}{
		\epsilon_1 <: \epsilon_2
	}{
		ref (\tau, \epsilon_1) <: ref (\tau, \epsilon_2)
	}
\end{mathpar}

Finally, we augment our typing relation with the single rule
\begin{mathpar}
	\relationRule{subtyping}{
		\tau_1 <: \tau_2\\
		\epsilon_1 <: \epsilon_2\\
		\Gamma, \epsilon \vdash e\ \colon\ \tau_1, \epsilon_1
	}{
		\Gamma, \epsilon \vdash e\ \colon\ \tau_2, \epsilon_2
	}
\end{mathpar}

and all other standard subtyping rules (refl, trans, function subtyping.)

\section*{Operational Semantics}

\end{document}
%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:


\chapter{The "Aime" methods for Tie Points computation}

% Conclusion, on peut sans doute limiter le nombre de point avec ScaleStab
% pour filtrage a priori => genre les 500 les plus stable

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

\section{Fast recognitation}

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

\subsection{Motivation}
For each image, we have computed tie points. A tie points is made
of a vector $V \in \RR^n)$ . Typically $V$ is invariant
to the main geometric deformation .  Le  $V_1$ and $V_2$
be two tie points, we note :

\begin{itemize}
   \item  $H_{om}(V_1,V_2) $ the fact that two tie points are homologous;
\end{itemize}

Given $V_1,V_2$, there is of course no no oracle that can indicate if  $H_{om}(V_1,V_2)$,
and classically we want to compute  a fast mathematicall function $\Psi $ that indicate if two vector $V_1$ and $V_2$
correspond to the same tie points .  The ideal function would be such :

\begin{itemize}
   \item  $\Psi(V_1,V_2)  \iff H_{om}(V_1,V_2)$
\end{itemize}

Of course this impossible, and we introduce the miss rate  and fall out:

\begin{itemize}
   \item   miss rate , probability of $\Psi=0$ knowing $H_{om}=1$ , we note $p_m$;
   \item   fall out , probability of $\Psi=1$ knowing $H_{om}=0$, we note $p_f$;
\end{itemize}

As we cannot have the ideal function $\Psi $ such as $p_m=0$ and $p_f=0$,
we have to compromise, and depending on the circunstances, the price of the
two error, will not be the same. Typically, in indexation step,  we are especially
interested to have a low $p_f$; converselly in recognition step we are
especially interested to have a low  $p_m$.

\subsection{Bits vector}

%----------------------------------------
%  A conserver : equations TIPE Lolo
%-----------------------------------------
\COM{
\begin{equation}
   \delta R = \frac{1}{\sigma} \frac{L}{S} = \frac{1}{\sigma}  \frac{2 \pi a }{ e \; dz}
\end{equation}

\begin{equation}
   \phi  = \iint \overrightarrow{B} \overrightarrow{dS}
         = B_M \cos(\omega t) \pi a^2
\end{equation}

\begin{equation}
   e = -\frac{d\phi}{dt}= B_M \omega  \sin(\omega t)  \pi a^2
\end{equation}

\begin{equation}
   d P_J = \frac{e^2}{\delta R}
         = \frac{ (B_M \omega \pi a^2  \sin(\omega t))^2 \sigma_e dz }{2 \pi a}
\end{equation}

\begin{equation}
   <d P_J> = \frac{B_M^2 \; \omega ^2 \; \pi \; a^3 \; e \; \sigma \; dz}{4}
\end{equation}

\begin{equation}
  <P_J> =  \int_{z=0}^H <d P_J> = \frac{B_M^2 \; \omega ^2  \; \pi \;  a^3  \; e  \; \sigma  \; H}{4}
\end{equation}

\begin{equation}
  dU = \delta ^2 Q_{creee} +  \delta ^2 Q_{recue de l'air}
\end{equation}

\begin{equation}
  C dT = <P_J> dt - g 2\pi aH(T-T_a)
\end{equation}

\begin{equation}
  C = \mu c 2 \pi a e H
\end{equation}

\begin{equation}
  \mu c 2 \pi a e H \frac{dT}{dt} = \frac{B_M \omega^2 \pi a^3 e \sigma H}{4} - g 2 \pi a H (T-T_a)
\end{equation}

\begin{equation}
  \tau  \frac{dT}{dt} + T = T_{\infty}
\end{equation}

\begin{equation}
  \tau  = \frac{\mu  c e}{g}
\end{equation}

\begin{equation}
  T_{\infty} - T_a = \frac{(B_M \omega a)^2 e \sigma}{8g}
\end{equation}
}


Large LMs files can be pruned in a smart way by means of the command
{\tt prune-lm} that removes $n$-grams for which resorting to the back-off
results in a small loss. {\IRSTLM} implements a method similar to the
Weighted Difference Method described in the paper {\em Scalable Backoff
Language Models} by Seymore and Rosenfeld.

\noindent
The syntax is as follows:
\begin{verbatim}
$> prune-lm --threshold=1e-6,1e-6  train.lm.gz  train.plm
\end{verbatim}
Thresholds for each n-gram level, up from 2-grams, are based on empirical
evidence. Threshold zero results in no pruning. If less thresholds are specified,
the right most is applied to the higher levels. Hence, in the above example we
could have just specified one threshold, namely {\tt --threshold=1e-6}.
The effect of pruning is shown in the following messages of {\tt prune-lm}:

\begin{verbatim}1-grams: reading 15059 entries
2-grams: reading 142684 entries
3-grams: reading 293685 entries
done
OOV code is 15058
OOV code is 15058
pruning LM with thresholds:
 1e-06 1e-06
savetxt: train.plm
save: 15059 1-grams
save: 138252 2-grams
save: 194194 3-grams
\end{verbatim}

\noindent
The saved LM table {\tt train.plm}  contains about 3\% less bigrams, and 34\%
less trigrams.
Notice that the output of prune-lm is an ARPA LM file, while the input can be
either an ARPA or binary LM.
In order to measure the loss in accuracy introduced
by pruning, perplexity of the resulting LM can be computed (see below).

\paragraph{Warning:} the possible quantization should be performed after pruning.

\paragraph{Warning:}
{\IRSTLM} does not provide a reliable probability for the special
1-gram composed by the ``sentence start symbol'' ({\tt <s>}) , because none
should ever ask for it.  However, this pruning method requires the
computation of the probability of this 1-gram.  Hence, (only) in this case
the probability of this special 1-gram is arbitrarily set to 1.