Type-indexed data types

Ralf Hinze a Johan Jeuring b,c Andres Löh b

a Institut
für Informatik III, Universität Bonn
Römerstraße 164, 53117 Bonn, Germany
[email protected]
http://www.informatik.uni-bonn.de/~ralf/
b Instituteof Information and Computing Sciences, Utrecht University
P.O.Box 80.089, 3508 TB Utrecht, The Netherlands
{johanj,andres}@cs.uu.nl
http://www.cs.uu.nl/~{johanj,andres}/
c Open University, Heerlen, The Netherlands

Abstract

A polytypic function is a function that can be instantiated on many data types

to obtain data type specific functionality. Examples of polytypic functions are the
functions that can be derived in Haskell, such as show , read , and ‘ ’. More ad-
vanced examples are functions for digital searching, pattern matching, unification,
rewriting, and structure editing. For each of these problems, we not only have to
define polytypic functionality, but also a type-indexed data type: a data type that
is constructed in a generic way from an argument data type. For example, in the
case of digital searching we have to define a search tree type by induction on the
structure of the type of search keys. This paper shows how to define type-indexed
data types, discusses several examples of type-indexed data types, and shows how to
specialize type-indexed data types. The approach has been implemented in Generic
Haskell, a generic programming extension of the functional language Haskell.

1 Introduction

A polytypic (or generic, or type-indexed) function is a function that can be

instantiated on many data types to obtain data type specific functionality.
Examples of polytypic functions are the functions that can be derived in
Haskell [1], such as show , read , and ‘ ’. See Backhouse et al [2] for an in-
troduction to polytypic programming.

More advanced examples of polytypic functions are functions for digital search-
ing [3], pattern matching [4], unification [5,6], rewriting [7], and structure edit-

Preprint submitted to Elsevier Science 23 July 2003

ing [8]. For each of these problems, we not only have to define polytypic func-
tionality, but also a type-indexed data type: a data type that is constructed in
a generic way from an argument data type. For instance, in the case of digital
searching we have to define a search tree type by induction on the structure of
the type of search keys. Since current strongly typed programming languages
do not support type-indexed data types, the examples that appear in the lit-
erature are either implemented in an ad-hoc fashion [5], or not implemented
at all [3].

This paper shows how to define a type-indexed data type, discusses several
examples of type-indexed data types, and shows how to specialize a type-
indexed data type. The specialization is illustrated with example translations
to Haskell. The approach has been implemented in Generic Haskell, a generic
programming extension of the functional language Haskell. Generic Haskell
can be obtained from http://www.generic-haskell.org/. This paper is a
revised version of [9].

Example 1: Digital searching. A digital search tree or trie is a search

tree scheme that employs the structure of search keys to organize information.
Searching is useful for various data types, so we would like to allow for keys
and information of any data type. This means that we have to construct a
new kind of trie for each key type. For example, consider the data type String
defined by 1

data String = Nil | Cons Char String.

We can represent string-indexed tries with associated values of type v as fol-

lows:

data FMap String v = Trie String (Maybe v)

(FMapChar (FMap String v)),

where FMap stands for ‘finite map’. Such a trie for strings would typically be
used for an index on texts. The first component of the constructor Trie String
contains the value associated with Nil . The second component of Trie String
is derived from the constructor Cons :: Char → String → String. We assume
that a suitable data structure, FMapChar, and an associated look-up function
lookupChar ::∀v . Char → FMapChar v → Maybe v for characters are predefined.
We use the following naming convention: names such as FMap String where
an underscore separates the name of two types are used for instances of type-
indexed entities. The goal of the paper is to describe how to generate such types
automatically from a generic definition. Compound names (such as FMapChar)
1 The examples are given in Haskell [1]. Deviating from Haskell, universal quantifi-
cation of types is always made explicit by means of ∀·’s in the type.

2
are used when we assume that a type or function is predefined or defined by
the user.

Given the definitions of String and FMap String, we can define a look-up func-
tion for strings as follows:

lookup String :: ∀v . String → FMap String v → Maybe v

lookup String Nil (Trie String tn tc) = tn
lookup String (Cons c s) (Trie String tn tc)
= (lookupChar c 3 lookup String s) tc.

To look up a non-empty string, Cons c s, we look up c in the FMapChar

obtaining a trie, which is then recursively searched for s. Since the look-up
functions have result type Maybe v, we use the reverse monadic composition
of the Maybe monad, called ‘3’, to compose lookup String and lookup Char .

(3) :: ∀a b c . (a → Maybe b) → (b → Maybe c) → a → Maybe c

(f 3 g) a = case f a of {Nothing → Nothing; Just b → g b }

Consider now the data type Bush of binary trees with characters in the leaves:

data Bush = Leaf Char | Fork Bush Bush.

Bush-indexed tries can be represented by the following data type:

data FMap Bush v = Trie Bush (FMapChar v)

(FMap Bush (FMap Bush v)).

Again, we have two components, one to store values constructed by Leaf , and
one for values constructed by Fork . The corresponding look-up function is
given by

lookup Bush :: ∀v . Bush → FMap Bush v → Maybe v

lookup Bush (Leaf c) (Trie Bush tl tf ) = lookupChar c tl
lookup Bush (Fork bl br ) (Trie Bush tl tf )
= (lookup Bush bl 3 lookup Bush br ) tf .

One can easily recognize that not only the look-up functions, but also the
data types for the tries are instances of an underlying generic pattern. In the
following section we will show how to define a trie and associated functions
generically for arbitrary data types. The material is taken from Hinze [3],
and it is repeated here because it serves as a nice and simple example of a
type-indexed data type.

3
Example 2: Pattern matching. The polytypic functions for the maximum
segment sum problem [10] and pattern matching [4] use labelled data types.
These labelled data types, introduced in [10], can be used to store at each node
the subtree rooted at that node, or a set of patterns (trees with variables)
matching at a subtree, etc. For example, the data type of labelled bushes is
defined by

data Lab Bush m = Label Leaf Char m

| Label Fork (Lab Bush m) (Lab Bush m) m.

It can be constructed from the Bush data type by extending each constructor
with an additional field to store the label. In the following section we show
how to define such a labelled data type generically, and how this data type is
used in a (specification of a) generic pattern matching program.

Example 3: Zipper. The zipper [11,12] is a data structure that is used to

represent a tree together with a subtree that is the focus of attention, where
that focus may move left, right, up, or down the tree. For example, the zipper
corresponding to the data type Bush, called Loc Bush, is defined by

type Loc Bush = (Bush, Context Bush)

data Context Bush = Top
| ForkL Context Bush Bush
| ForkR Bush Context Bush.

Using the type of locations we can efficiently navigate through a tree. For
example:

down Bush :: Loc Bush → Loc Bush

down Bush (Leaf a, c) = (Leaf a, c)
down Bush (Fork tl tr , c) = (tl , ForkL c tr )
right Bush :: Loc Bush → Loc Bush
right Bush (tl , ForkL c tr ) = (tr , ForkR tl c)
right Bush m = m.

The navigation function down Bush moves the focus of attention to the left-
most subtree of the current node; right Bush moves the focus to its right
sibling.

Huet [11] defines the zipper data structure for rose trees and for the data type
Bush, and gives the generic construction in words. In Section 5 we describe
the zipper in more detail and show how to define a zipper for an arbitrary
data type.

4
Other examples. Besides these three examples, a number of other exam-
ples of type-indexed data types have appeared in the literature [13–16]. We
expect that type-indexed data types will also be useful for generic DTD trans-
formations [17]. Generally, we believe that type-indexed data types are almost
as important as type-indexed functions.

Background and related work. There is little related work on type-

indexed data types. Type-indexed functions [18,10,19–21] were introduced
more than a decade ago. There are several other approaches to type-indexed
functions, see Dubois et al [22], Jay et al [23] and Yang [24], but none of them
mentions user-defined type-indexed data types (Yang does mention value-
indexed types, usually called dependent types).

Type-indexed data types, however, appear in the work on intensional type

analysis [14,25–28]. Intensional type analysis is used in typed intermediate
languages in compilers for polymorphic languages, among others to be able to
optimize code for polymorphic functions. This work differs from our work in
several aspects:

• typed intermediate languages are expressive, but rather complex languages

not intended for programmers but for compiler writers;
• since Generic Haskell is built on top of Haskell, there is the problem of how
to combine user-defined functions and data types with type-indexed func-
tions and data types. This problem does not appear in typed intermediate
languages;
• typed intermediate languages interpret (a representation of a) type argu-
ment at run-time, whereas the specialization technique described in this
paper does not require passing around (representations of) type arguments;
• originally, typed intermediate languages were restricted to data types of kind
?. Building upon Hinze’s work, Weirich recently generalized intensional type
analysis to higher-order kinded types [29]. However, higher-order intensional
type analysis does not support type-indexed data types.

Organization. The rest of this paper is organized as follows. We will show

how to define type-indexed data types in Section 2 using Hinze’s approach
to polytypic programming [30,31]. Section 3 illustrates the process of special-
ization by means of example. Section 4 shows that type-indexed data types
possess kind-indexed kinds, and provides theoretical background for the spe-
cialization of type-indexed data types and functions with arguments of type-
indexed data types. Section 5 provides the details of the zipper example. Fi-
nally, Section 6 summarizes the main points and concludes.

5
2 Defining type-indexed data types

This section shows how to define type-indexed data types. Section 2.1 briefly
reviews the concepts of polytypic programming necessary for defining type-
indexed data types. The subsequent sections define type-indexed data types
for the problems described in the introduction. We assume a basic familiarity
with Haskell’s type system and in particular with the concept of kinds [32].
For a more thorough treatment the reader is referred to Hinze’s work [31,30].

2.1 Type-indexed definitions

The central idea of polytypic programming (also called type-indexed or generic

programming) is to provide the programmer with the ability to define a func-
tion by induction on the structure of types. Since Haskell’s type language
is rather involved—we have mutually recursive types, parameterized types,
nested types, and type constructors of higher-order kinds—this sounds like
a hard nut to crack. Fortunately, one can show that a polytypic function is
uniquely defined by giving cases for a very limited set of types and type con-
structors. For instance, to define a generic function on types of kind ?, we need
cases for the unit type 1, the sum type constructor +, and the product type
constructor ×. These three types are required for modelling Haskell’s data
construct that introduces a sum of products. We treat 1, +, and × as if they
were given by the following data declarations:

data 1 = ()
data a + b = Inl a | Inr b
data a × b = (a, b).

Additionally, if we want our generic functions to work on primitive types such

as Char and Float, which are not defined by means of a Haskell data statement,
we need to include additional cases for such types. For the purposes of the
paper, we will assume Char to be the only primitive type.

Now, a polytypic function is given by a definition that is inductive on 1,

Char, +, and ×. As an example, here is the polytypic equality function. For
emphasis, the type index is enclosed in angle brackets.

equal ht :: ?i :: t → t → Bool
equal h1i () () = True
equal hChari c1 c2 = equalChar c1 c2
equal ht1 + t2 i (Inl a1 ) (Inl a2 ) = equal ht1 i a1 a2
equal ht1 + t2 i (Inl a1 ) (Inr b2 ) = False

6
 equal ht1 + t2 i (Inr b1 ) (Inl a2 ) = False
equal ht1 + t2 i (Inr b1 ) (Inr b2 ) = equal ht2 i b1 b2
equal ht1 × t2 i (a1 , b1 ) (a2 , b2 ) = equal ht1 i a1 a2 ∧ equal ht2 i b1 b2

This simple definition contains all ingredients needed to specialize equal for
arbitrary data types. Note that the definition does not mention type abstrac-
tion, type application, and fixed points. Instances of polytypic functions on
types with these constructions can be generated automatically from just the
cases given above. For example, if we used equal at the data type Bush, the
generated specialization would behave exactly as the following hand-written
code.

equal Bush :: Bush → Bush → Bool

equal Bush (Leaf c1 ) (Leaf c2 ) = equalChar c1 c2
equal Bush (Fork m1 r1 ) (Fork m2 r2 ) =
equal Bush m1 m2 ∧ equal Bush r1 r2
equal Bush = False

We will discuss the generation of specializations for generic functions in detail

in Section 4.

Sometimes we want to be able to refer to the name of a constructor. To this

end, we add one more special type constructor for which a case can be defined
in a generic function: c of t, where c is a value, and t is a type of kind ?. The
value c represents the name of a constructor. If the ‘c of t’ case is omitted
in the definition of a polytypic function poly, as in function equal , we assume
that polyhc of ti = polyhti. For the purposes of this paper, we assume that c
is of type String.

As an example for the use of constructor names in a generic function, we give

a very simple variant of the polytypic show function, that computes a textual
representation of any value:

show ht :: ?i :: t → String
show h1i () = ""
show hChari c = showChar c
show ht1 + t2 i (Inl a) = show ht1 i a
show ht1 + t2 i (Inr b) = show ht2 i b
show ht1 × t2 i (a, b) = show ht1 i a ++" "++ show ht2 i b
show hc of ti t = "(" ++c+ +" "++ show hti t +
+ ")".

Here, (++) :: String → String → String stands for string concatenation.

Whenever we make use of a polytypic function for a specific data type, we

implicitly view this data type as if it were constructed by the unit type, sum,
product, and the marker for constructors. For example, the Haskell data type

7
of natural numbers

data Nat = Zero | Succ Nat

is represented by

Nat = "Zero" of 1 + "Succ" of Nat,

and the data type of bushes

data Bush = Leaf Char | Fork Bush Bush

is viewed as

Bush = "Leaf" of Char + "Fork" of Bush × Bush.

The details of the type representation are given in Section 3.

The functions equal and show are indexed by a type of kind ?. A polytypic
function may also be indexed by type constructors of kind ? → ? (and, of
course, by type constructors of other kinds, but these are not needed in the
sequel). We need slightly different base cases for generic functions operating
on types of kind ? → ?:

Id = Λa . a
Kt = Λa . t
f1 + f2 = Λa . f1 a + f2 a
f1 × f2 = Λa . f1 a × f2 a
c of f = Λa . c of f a.

Here, Λa . t denotes abstraction on the type level. We have the constant functor
K, which lifts a type of kind ? to kind ? → ?. We will need K 1 as well as
K Char (or more general, K t for all primitive types). We overload +, ×, and
c of to be the lifted versions of their previously defined counterparts. The
only new type index in this set of indices of kind ? → ? is the identity functor
Id. Hinze [30] shows that these types are the normal forms of types of kind
? → ?.

A well-known example of a (? → ?)-indexed function is the mapping function,

which applies a given function to each element of type a in a given structure
of type f a.

maphf :: ? → ?i :: ∀a b . (a → b) → (f a → f b)
maphIdi ma =ma
maphK 1i mc =c
maphK Chari m c =c

8
 maphf1 + f2 i m (Inl f ) = Inl (maphf1 i m f )
maphf1 + f2 i m (Inr g) = Inr (maphf2 i m g)
maphf1 × f2 i m (f , g) = (maphf1 i m f , maphf2 i m g)

Using map we can, for instance, define generic versions of cata- and anamor-
phisms [33]. To this end we assume that data types are given as fixed points
of so-called pattern functors. In Haskell the fixed point combinator can be
defined as follows:

newtype Fix f = In{out :: f (Fix f)}.

It follows that the constructor In and the ‘destructor’ out have the following
types:

In :: ∀f . f (Fix f) → Fix f
out :: ∀f . Fix f → f (Fix f)

For example, we could have defined the type of bushes by Bush = Fix BushF,
where

data BushF r = LeafF Char | ForkF r r.

It is easy to convert between this data type defined as a fixed point and the
original type definition of bushes.

Cata- and anamorphisms are now given by

catahf :: ? → ?i :: ∀a . (f a → a) → (Fix f → a)
catahfi ϕ = ϕ · maphfi (catahfi ϕ) · out
anahf :: ? → ?i :: ∀a . (a → f a) → (a → Fix f)
anahfi ψ = In · maphfi (anahfi ψ) · ψ.

Note that both functions are parameterized by the pattern functor f rather
than by the fixed point Fix f. For example, the catamorphism on the functor
of bushes, BushF, would be defined by

catahBushFi :: ∀a . (BushF a → a) → (Fix BushF → a)

catahBushFi ϕ = ϕ · maphBushFi (catahBushFi ϕ) · out,

where maphBushFi is an instance of the generic function map, defined above,

that is equivalent to

map BushF :: ∀a b . (a → b) → (BushF a → BushF b)

map BushF m (LeafF c) = LeafF c
map BushF m (ForkF bl br ) = ForkF (m bl ) (m br ).

9
Both cata and ana are so-called generic abstractions, i.e. generic functions
that are not defined by induction on base types, but in terms of other generic
functions. Generic Haskell supports generic abstractions [34].

2.2 Tries

Tries are based on the following isomorphisms, also known as the laws of
exponentials.

1 →fin v ∼
= v
(t1 + t2 ) →fin v ∼
= (t1 →fin v) × (t2 →fin v)
(t1 × t2 ) →fin v ∼
= t1 →fin (t2 →fin v)

There are more laws for exponentials, but these are the ones we need in our
definition of tries. Here, t →fin v denotes the type of finite maps from t to v. Us-
ing the isomorphisms above as defining equations, we can give a type-indexed
definition for the data type FMaphti v of finite maps from t to v, which gener-
alizes FMap String from the introduction to arbitrary data types. This is our
first example of a type-indexed data type.

FMapht :: ?i :: ? → ?
FMaph1i v = Maybe v
FMaphChari v = FMapChar v
FMapht1 + t2 i v = FMapht1 i v × FMapht2 i v
FMapht1 × t2 i v = FMapht1 i (FMapht2 i v)

The definition of a type-indexed data type is very similar to the definition of a

type-indexed function as seen in the previous subsection. Note that a name of
a type-indexed data type starts with a capital letter. We give cases for 1, Char,
+, and ×, and with these cases we have sufficient information to subsequently
use FMap at any data type of kind ?. Note that FMaph1i is Maybe rather
than Id since we use the Maybe monad for exception handling in the case of a
partially defined finite map.

We assume that a suitable data structure, FMapChar, and an associated look-

up function lookupChar :: ∀v . Char → FMapChar v → Maybe v for characters
are predefined. The generic look-up function is then given by the following
definition.

lookupht :: ?i :: ∀v . t → FMaphti v → Maybe v

lookuph1i () t =t
lookuphChari c t = lookupChar c t
lookupht1 + t2 i (Inl k1 ) (t1 , t2 ) = lookupht1 i k1 t1
lookupht1 + t2 i (Inr k2 ) (t1 , t2 ) = lookupht2 i k2 t2
lookupht1 × t2 i (k1 , k2 ) t = (lookupht1 i k1 3 lookupht2 i k2 ) t

10
On sums the look-up function selects the appropriate map; on products it
‘composes’ the look-up functions for the component keys. The second argu-
ment to the look-up function is an element of the type-indexed type that we
have defined before. Note how the definition of lookup relies on the fact that
the second argument is a pair in the +-case and a nested finite map in the
×-case. This generic look-up function is a generalization of the type-specific
look-up functions on strings and bushes that we have seen in the introduction.

Another generic function can be used to produce the empty trie for any data
type:

emptyht :: ?i :: ∀v . FMaphti v
emptyh1i = Nothing
emptyhChari = emptyChar
emptyht1 + t2 i = (emptyht1 i, emptyht2 i)
emptyht1 × t2 i = emptyht1 i,

where emptyChar is the empty value of type FMapChar. The empty function
serves as a simple example for a function that constructs values in a generic
way.

2.3 Generic pattern matching

The pattern matching problem (for exact patterns) can be informally specified
as follows: given a pattern and a text, find all occurrences of the pattern in
the text. The pattern and the text may both be lists, or they may both be
trees, etc. This section specifies a generic pattern-matching program for data
types specified as fixed points of pattern functors. The specification is a rather
inefficient program, but it can be transformed into an efficient program [4].
The efficient program is a generalization of the Knuth, Morris, and Pratt
algorithm on lists [35] to arbitrary data types.

A pattern is a value of a type extended with variables. For example, the data
type Bush is extended with a constructor for variables as follows:

data Var Bush = Var Int

| Var Leaf Char
| Var Fork Var Bush Var Bush.

In general, we want to extend a data type given as the fixed point of a functor
Fix f with a case for variables. We can perform the extension on the functor
directly, and we can parametrize over the functor f in question:

11
 data VarF f r = Var Int
| Val (f r).

With this definition, Fix (VarF f) is the extension of Fix f with variable case
that we are interested in. In particular, one can easily define isomorphisms
to confirm that Fix (VarF BushF) is equivalent to the previously defined type
Var Bush.

To establish that we want to store patterns in the extended data types, we

define the abbreviation

type Pattern f = Fix (VarF f).

We construct a specification for pattern matching in three steps: firstly, we de-

fine a generic function match that matches a pattern against a complete value.
In particular, it does not look for occurrences of the pattern in substructures
of the value; secondly, we can systematically compute substructures of a value
using a generic function suffixes. Finally, both match and suffixes are the
combined into the function pattern match, that looks for a pattern all over a
value. It turns out that we need a type-indexed type to store the results of
suffixes and pattern match.

We start with function match that matches a pattern against a value. A pat-
tern matches a value if it is a variable, or if it has the same top-level constructor
as the value, and all children match pairwise. On Bush, for example:

match Bush :: Bush → Var Bush → Bool

match Bush t (Var i) = True
match Bush (Leaf c) (Var Leaf c 0 ) = equalChar c c 0
match Bush (Fork l r ) (Var Fork l 0 r 0 ) =
match Bush l l 0 ∧ match Bush r r 0
match Bush = False.

For the general case we use the function zipWith to match all children of a
constructor pairwise:

matchhf :: ? → ?i :: Fix f → Pattern f → Bool

matchhfi t (In (Var x )) = True
matchhfi (In x ) (In (Val y)) = case gzipWith (f) (matchhfi) x y of
{Nothing → False;
Just t → and hfi t },

where zipWith and and are the generalizations of the list-processing func-
tions defined in the Haskell prelude. On BushF, function zipWith is defined as
follows:

12
 zipWith BushF :: ∀a b c . (a → b → c)
→ BushF a → BushF b → Maybe (BushF c)
zipWith BushF f (LeafF c1 ) (LeafF c2 ) =
if equalChar c1 c2 then Just (LeafF c1 ) else Nothing
zipWith BushF f (ForkF a1 b1 ) (ForkF a2 b2 ) =
Just (ForkF (f a1 a2 ) (f b1 b2 ))
zipWith BushF f = Nothing.

Of course, zipWith can also be defined generically for types of kind ? → ?:

zipWithhf :: ? → ?i :: ∀a b c . (a → b → c)
→ f a → f b → Maybe (f c)
zipWithhIdi f a b = Just (f a b)
zipWithhK 1i f u u = Just u
zipWithhK Chari f c1 c2 = if equalChar c1 c2
then Just c1
else Nothing
zipWithhf1 + f2 i f (Inl a1 ) (Inl a2 ) = do {x ← zipWithhf1 i f a1 a2 ;
return (Inl x )}
zipWithhf1 + f2 i f (Inl a1 ) (Inr b2 ) = Nothing
zipWithhf1 + f2 i f (Inr b1 ) (Inl a2 ) = Nothing
zipWithhf1 + f2 i f (Inr b1 ) (Inr b2 ) = do {y ← zipWithhf2 i f b1 b2 ;
return (Inr y)}
zipWithhf1 × f2 i f (a1 , b1 ) (a2 , b2 ) = do {x ← zipWithhf1 i f a1 a2 ;
y ← zipWithhf2 i f b1 b2 ;
return (x , y)}.

On BushF, function and is defined as follows:

and BushF :: BushF Bool → Bool

and BushF (LeafF c) = True
and BushF (ForkF a b) = a ∧ b.

The generic definition of and is:

and hf :: ? → ?i :: f Bool → Bool

and hIdi b =b
and hK 1i u = True
and hK Chari c = True
and hf1 + f2 i (Inl a) = and hf1 i a
and hf1 + f2 i (Inr b) = and hf2 i b
and hf1 × f2 i (a, b) = and hf1 i a ∧ and hf2 i b.

Having defined match, we need to define suffixes that computes the suffixes of
a data structure generically. For lists, a suffix is a tail of the list. For example,
the string per is a suffix of the string paper . We will now generalize the concept

13
of suffixes in the following way: given a set of patterns, the generic pattern-
matching problem will require finding for each suffix the subset of patterns
matching (in the sense of match) the suffix. How do we compute all suffixes
of a value of a data type? On lists, the suffixes of a list can be represented
as a list of tails, computed by tails, a standard Haskell function that can be
defined as follows:

tails :: ∀a . [a] → [[a]]

tails [ ] = [[ ]]
tails t@( : xs) = t : tails xs.

For a value of an arbitrary data type we construct a value of a new data type,
a labelled data type, that can be used to store all suffixes.

A labelled data type is an extension of a data type that is used to store

information at the internal nodes of a value.

The data type Labelled labels a data type given by a pattern functor:

Labelledhf :: ? → ?i :: ? → ?
Labelledhfi m = Fix (Labelhfi m).

Here we use a generic abstraction, see Section 2.1, on the type level. The idea
is the same as generic abstractions on functions. The type-indexed data type
Label adds a label type to each constructor of a data type. In its definition, we
make use of the fact that a Haskell data type is viewed as a sum of constructor
applications, where the fields of a constructor form a product. In Label, we
traverse the sum structure, and add the label type once we reach a constructor.
There are no recursive calls in the constructor case, therefore the product of
fields is never traversed, and no ×-case is needed. We want to label the whole
data type, but Label does not work recursively. Therefore, we compute a fixed
point using Label in Labelled.

Labelhf :: ? → ?i :: ? → ? → ?
Labelhf1 + f2 i m r = Labelhf1 i m r + Labelhf2 i m r
Labelhc of fi m r = f r × m

The type-indexed function suffixes, defined below, labels a value of a data type
with the subtree rooted at each node. It uses a helper function add , which adds
a label to a value of type f t, returning a value of type Labelhfi m t. As for
the type-indexed type Label, we omit the ×-case for add : the function only
inspects the sum structure and the constructors of a data type.

add hf :: ? → ?i :: ∀m t . m → f t → Labelhfi m t
add hf1 + f2 i m (Inl x ) = Inl (add hf1 i m x )
add hf1 + f2 i m (Inr y) = Inr (add hf2 i m y)
add hc of fi m x = (x , m)

14
The function suffixes is then defined as a recursive function that adds the
subtrees rooted at each level to the tree. It adds the argument tree to the top
level, and applies suffixes to the children by means of function map. It is the
generalization of function tails to arbitrary data types.

suffixeshf :: ? → ?i :: Fix f → Labelledhfi (Fix f)

suffixeshfi m@(In t) = In (add hfi m (maphfi (suffixeshfi) t)).

Finally, we can specify a generic pattern-matching program. For each suffix,

we compute the set of patterns that matches that suffix.

pattern matchhf :: ? → ?i :: [Pattern f ] → Fix f

→ Labelledhfi [Pattern f ]
pattern matchhfi pats = maphLabelledhfii
(λt → filter (matchhfi t) pats)
· suffixeshfi

The data type Labelled that has been introduced in this section has other
applications: for instance, it can also be used in the generic maximum segment
sum problem [10], which requires finding a subtree of a tree with maximum
sum.

3 Examples of translations to Haskell

The semantics of type-indexed data types will be given by means of specializa-

tion. This section gives some examples as an introduction to the formal rules
provided in the following section.

We illustrate the main ideas by translating the digital search tree example to
Haskell. This translation shows in particular how type-indexed data types are
specialized in Generic Haskell: the Haskell code given here will be automat-
ically generated by the Generic Haskell compiler. The example is structured
into three sections: a translation of data types, a translation of type-indexed
data types, and a translation of type-indexed functions that operate on type-
indexed data types.

3.1 Translating data types

In general, a type-indexed function is translated to several functions: one for

each user-defined data type on which it is used. These instances work on a
slightly different, but isomorphic data type, that makes use of the types 1,
+, and ×. We call this isomorphic type the generic representation type of

15
a data type. By applying such a transformation, concepts that are usually
built-in in the Haskell data statement, such as a data type having multiple
constructors, with a variable number of fields per constructor, are replaced by
just type abstraction, type application and some basic type constructors. This
implies, of course, that values of user-defined data types have to be translated
to generic representation types. For example, the type Nat of natural numbers
defined by

data Nat = Zero | Succ Nat,

is translated to the following type (in which Nat itself still appears), together
with two conversion functions.

type Nat0 = 1 + Nat

from Nat :: Nat → Nat0
from Nat Zero = Inl ()
from Nat (Succ x ) = Inr x
to Nat :: Nat0 → Nat
to Nat (Inl ()) = Zero
to Nat (Inr x ) = Succ x

The conversion functions from Nat and to Nat transform the top-level struc-
ture of a natural number; they are not recursive.

Furthermore, the mapping between data types and generic representation

types translates n-ary products and n-ary sums to binary products and binary
sums. This is revealed by looking at a more complex data type, for instance

data Tree a = Empty | Node (Tree a) a (Tree a),

where the constructor Node takes three arguments. The generic representation
type for Tree is

type Tree0 a = 1 + Tree a × (a × Tree a),

the conversion functions are

from Tree :: ∀a . Tree a → Tree0 a

from Tree Empty = Inl ()
from Tree (Node l v r ) = Inr (l , (v , r ))
to Tree :: ∀a . Tree0 a → Tree a
to Tree (Inl ()) = Empty
to Tree (Inr (l , (v , r ))) = Node l v r .

For convenience, we pair the two conversion functions:

16
 data Iso a b = Iso{from :: a → b, to :: b → a}
iso Nat :: Iso Nat Nat0
iso Nat = Iso from Nat to Nat
iso Tree :: Iso Tree Tree0
iso Tree = Iso from Tree to Tree.

The conversion functions only affect the top-level structure of a data type.
For recursive data types, the generic representation type still contains the
original data type. The isomorphisms will be used in the translation of type-
indexed data types and type-indexed functions to move between the structural
view and the original data type as needed. If the function is recursive and
operates on a recursive data type, then the conversion functions will be applied
recursively, as well.

3.2 Translating type-indexed data types

A type-indexed data type is translated to several newtypes in Haskell: one for

each type case in its definition. The translation proceeds in a similar fashion
as in Hinze [31], but now for types instead of values. For example, the product
case t1 × t2 takes two argument types for t1 and t2 , and returns the type for
the product. Recall the type-indexed data type FMap defined by

FMaph1i v = Maybe v
FMaphChari v = FMapChar v
FMapht1 + t2 i v = FMapht1 i v × FMapht2 i v
FMapht1 × t2 i v = FMapht1 i (FMapht2 i v).

These equations are translated to:

newtype FMap Unit v = FMap Unit (Maybe v)

newtype FMap Char v = FMap Char (FMapChar v)
newtype FMap Either fma fmb v = FMap Either (fma v, fmb v)
newtype FMap Product fma fmb v = FMap Product (fma (fmb v)).

The constructor names are generated automatically. This implies that a value
of a type-indexed data type can only be constructed by means of a generic
function. Thus, a type-indexed data type can be viewed as an abstract type.

Finally, for each data type t on which we want to use a trie we generate a
suitable instance FMap t.

type FMap Nat0 v = FMap Either FMap Unit FMap Nat v

newtype FMap Nat v = FMap Nat{unFMap Nat :: FMap Nat0 v}

17
Note that we use newtype for FMap Nat because it is not possible to define
recursive types in Haskell. The types FMap Nat and FMap Nat0 can easily be
converted into each other by means of the following pair of isomorphisms:

iso FMap Nat :: ∀v . Iso (FMap Nat v) (FMap Nat0 v)

iso FMap Nat = Iso unFMap Nat FMap Nat.

3.3 Translating type-indexed functions on type-indexed data types

The translation of a type-indexed function that takes a type-indexed data

type as an argument is a generalization of the translation of ‘ordinary’ type-
indexed functions. The translation consists of two parts: a translation of the
type-indexed function itself, and a specialization on each data type on which
the type-indexed function is used, together with a conversion function.

A type-indexed function is translated by generating a function, together with

its type signature, for each case of its definition. For the type indices of kind ?
(i.e. 1 and Char) we generate types that are instances of the type of the generic
function. The occurrences of the type index are replaced by the instance type,
and occurrences of type-indexed data types are replaced by the translation of
the type-indexed data type on the type index. As an example, for the generic
function lookup of type:

lookupht :: ?i :: ∀v . t → FMaphti v → Maybe v,

the instances are obtained by replacing t by 1 or Char, and by replacing

FMaphti by FMap Unit or FMap Char, respectively. So, for the function lookup
we have that the user-supplied equations

lookuph1i () t = t
lookuphChari c t = lookupChar c t,

are translated into

lookup Unit :: ∀v . 1 → FMap Unit v → Maybe v

lookup Unit () (FMap Unit t) = t
lookup Char :: ∀v . Char → FMap Char v → Maybe v
lookup Char c (FMap Char t) = lookupChar c t.

Note that we have to wrap the trie constructors around the second argument
of the function.

For the type indices of kind ? → ? → ? (i.e. ‘+’ and ‘×’) we generate types
that take two functions as arguments, corresponding to the instances of the

18
generic function on the arguments of ‘+’ and ‘×’, and return a function of the
combined type, see Hinze [31]. For example, the following lines

lookupht1 + t2 i (Inl k1 ) (t1 , t2 ) = lookupht1 i k1 t1

lookupht1 + t2 i (Inr k2 ) (t1 , t2 ) = lookupht2 i k2 t2
lookupht1 × t2 i (k1 , k2 ) t = (lookupht1 i k1 3 lookupht2 i k2 ) t

are translated into the following functions

lookup Either :: ∀a fma . ∀b fmb .

(∀v . a → fma v → Maybe v)
→ (∀v . b → fmb v → Maybe v)
→ (∀v . a + b → FMap Either fma fmb v → Maybe v)
lookup Either lua lub (Inl a) (FMap Either (fma, fmb)) = lua a fma
lookup Either lua lub (Inr b) (FMap Either (fma, fmb)) = lub b fmb
lookup Product :: ∀a fma . ∀b fmb .
(∀v . a → fma v → Maybe v)
→ (∀v . b → fmb v → Maybe v)
→ (∀v . a × b → FMap Product fma fmb v → Maybe v)
lookup Product lua lub (a, b) (FMap Product t) = (lua a 3 lub b) t.

The translation involves replacing the recursive invocations lookupht1 i and

lookupht2 i by the function arguments lua and lub.

Now we generate a specialization of the type-indexed function for each data

type on which it is used. For example, on Nat we have

lookup Nat :: ∀v . Nat → FMap Nat v → Maybe v

lookup Nat = conv lookup Nat (lookup Either lookup Unit lookup Nat).

The expression lookup Either lookup Unit lookup Nat is generated directly
from the type Nat0 , which is defined as 1 + Nat: each of the type constants has
been replaced by the corresponding case or specialization of the lookup func-
tion, and type application is translated into value application. Unfortunately,
this expression does not have the type we require for lookup Nat – the type
given in the type signature – but rather the type

∀v . Nat0 → FMap Nat0 v → Maybe v.

However, this type is isomorphic to the type we need, because Nat0 is iso-
morphic to Nat, and FMap Nat0 is isomorphic to FMapNatT . The conversion
function conv lookup Nat witnesses this isomorphism:

19
 conv lookup Nat :: (∀v . Nat0 → FMap Nat0 v → Maybe v)
→ (∀v . Nat → FMap Nat v → Maybe v)
conv lookup Nat lu
= λt fmt → lu (from iso Nat t) (from iso FMap Nat fmt).

Note that the functions to iso Nat and to FMap Nat are not used on the
right-hand side of the definition of conv lookup Nat. This is because no values
of type Nat or FMap Nat are built for the result of the function. If we look at
the instance of empty for Nat, we are in a different situation. Here we have

empty Nat :: ∀v . FMap Nat v

empty Nat = conv Empty Nat (empty Either empty Unit empty Nat)

where

conv empty Nat :: (∀v . FMap Nat0 v) → (∀v . FMap Nat v)

conv empty Nat e = to iso FMap Nat e.

Generally, for each specialization of a generic function a conversion function

is generated that uses the relevant isomorphism pairs at the appropriate posi-
tions, dictated by the generic representation type of the type on which we want
to obtain an instance. Section 4.5 shows that this can be done in a systematic
way.

3.4 Implementing FMap using type classes

Alternatively, we can use multi-parameter type classes and functional depen-

dencies [36] to implement a type-indexed data type such as FMap in Haskell.
An example is given in Figure 1. With type classes, the recursive invocations
of the generic functions are not passed as explicit type arguments (lua and lub
in the definition of lookup Either and lookup Product). They remain implicit
in the class context, and it is the task of the Haskell compiler to pass these
implicit contexts around and to use of them as necessary.

We will use the explicit style introduced in Section 3.3 throughout the rest of
the paper.

4 Specializing type-indexed types and values

This section gives a formal semantics of type-indexed data types by means of

specialization. Examples of this translation have been given in the previous
section. The specialization to concrete data type instances removes the type

20
 class FMap fma a | a → fma where
lookup :: ∀v . a → fma v → Maybe v
instance FMap Maybe () where
lookup () fm = fm
data FMap Either fma fmb v = FMap Either (fma v, fmb v)
instance (FMap fma a, FMap fmb b)
⇒ FMap (FMap Either fma fmb) (a + b) where
lookup (Inl a) (FMap Either fma fmb) = lookup a fma
lookup (Inr b) (FMap Either fma fmb) = lookup b fmb
data FMap Product fma fmb v = FMap Product (fma (fmb v))
instance (FMap fma a, FMap fmb b)
⇒ FMap (FMap Product fma fmb) (a × b) where
lookup (a, b) (FMap Product fma) = (lookup a 3 lookup b) fma
Fig. 1. Implementing FMap in Haskell directly.

arguments of type-indexed data types and functions. In other words, type-

indexed data types and functions can be used at no run-time cost, since all
type arguments are removed at compile-time. The specialization can be seen as
partial evaluation of type-indexed functions where the type index is the static
argument. The specialization is obtained by lifting the semantic description
of type-indexed functions given in Hinze [37] to the level of data types.

Type-indexed data types and type-indexed functions take types as arguments,

and return types and functions, respectively. For the formal description of
type-indexed data types and functions and for their semantics we use an ex-
tension of the polymorphic lambda calculus, described in Section 4.1. Section
4.2 briefly discusses the form of type-indexed definitions. The description of
the specialization is divided into two parts: Section 4.3 deals with the special-
ization of type-indexed data types, and Section 4.4 deals with the specializa-
tion of type-indexed functions that involve type-indexed data types. Section
4.5 shows how the gap between the formal type language and Haskell’s data
types can be bridged, and Section 4.6 summarizes.

4.1 The polymorphic lambda calculus

This section briefly introduces kinds, types, type schemes, and terms.

Kind terms are formed by:

T, U ∈ Kind ::= ? kind of types

| (T → U) function kind.

21
We distinguish between type terms and type schemes: the language of type
terms comprises the types that may appear as type indices; the language of
type schemes comprises the constructs that are required for the translation of
generic definitions (such as polymorphic types).

Type terms are built from type constants and type variables using type appli-
cation and type abstraction.

t, u ∈ Type ::= C type constant

| a type variable
| (Λa :: U . t) type abstraction
| (t u) type application

For typographic simplicity, we will often omit the kind annotation in Λa :: U . t

(especially if U = ?) and we abbreviate nested abstractions Λa1 . . . . Λam . t by
Λa1 . . . am . t.

In order to be able to model Haskell’s data types the set of type constants
should include at least the types 1, Char, ‘+’, ‘×’, and ‘c of ’ for all known
constructors in the program. Furthermore, it should include a family of fixed
point operators indexed by kind: FixT :: (T → T) → T. In the examples, we
will often omit the kind annotation T in FixT . We may additionally add the
function space constructor ‘→’ or universal quantifiers ∀U :: (U → ?) → ? to
the set of type constants (see Section 4.5 for an example).

Type schemes are formed by:

r, s ∈ Scheme ::= t type term

| (r → s) functional type
| (∀a :: U . s) polymorphic type.

Terms are formed by:

t, u ∈ Term ::= c constant

| a variable
| (λa :: s . t) abstraction
| (t u) application
| (λa :: U . t) universal abstraction
| (t r) universal application.

Here, λa :: U . t denotes universal abstraction (forming a polymorphic value)

and t r denotes universal application (instantiating a polymorphic value). We
use the same syntax for value abstraction λa :: s . t (here a is a value variable)

22
and universal abstraction λa :: U . t (here a is a type variable). We assume
that the set of value constants includes at least the polymorphic fixed point
operator

fix :: ∀a . (a → a) → a

and suitable functions for each of the other type constants (such as () for
‘1’, Inl , Inr , and case for ‘+’, and outl , outr , and (,) for ‘×’). To improve
readability we will usually omit the type argument of fix .

We omit the standard typing rules for the polymorphic lambda calculus.

4.2 On the form of type-indexed definitions

The type-indexed definitions given in Section 2 implicitly define a catamor-

phism on the language of types. For the specialization we have to make these
catamorphisms explicit. This section describes the different views on type-
indexed definitions.

Almost all inductive definitions of type-indexed functions and data types given
in Section 2 take the form of a catamorphism:

catah1i = cata1
catahChari = cataChar
cataht1 + t2 i = cata+ (cataht1 i) (cataht2 i)
cataht1 × t2 i = cata× (cataht1 i) (cataht2 i)
catahc of t1 i = catac of (cataht1 i).

These equations implicitly define the family of functions cata1 , cataChar , cata+ ,
cata× , and catac of . In the sequel, we will assume that type-indexed functions
and data types are explicitly defined as a catamorphism. For example, for
digital search trees we have

FMap1 = Λv . Maybe v
FMapChar = Λv . FMapChar v
FMap+ = ΛfMapa fMapb . Λv . fMapa v × fMapb v
FMap× = ΛfMapa fMapb . Λv . fMapa (fMapb v)
FMapc of = ΛfMapa . Λv . fMapa v.

Some inductive definitions, such as the definition of Label, also use the ar-
gument types themselves in their right-hand sides. Such functions are called
paramorphisms [19], and are characterized by:

23
 parah1i = para1
parahChari = paraChar
paraht1 + t2 i = para+ t1 t2 (paraht1 i) (paraht2 i)
paraht1 × t2 i = para× t1 t2 (paraht1 i) (paraht2 i)
parahc of t1 i = parac of t1 (paraht1 i).

Fortunately, every paramorphism can be transformed into a catamorphism by

tupling it with the identity. Likewise, mutually recursive definitions can be
transformed into simple catamorphisms using tupling.

Section 4.3 below describes how to specialize type-indexed data types with
type indices that appear in the set of type constants: 1, Char, ‘+’, ‘×’, and
‘c of ’. However, we have also used the type indices Id· , K 1, K Char, and
lifted versions of ‘+’ and ‘×’. How are type-indexed data types with these
type indices specialized? The specialization of type-indexed data types with
higher-order type indices proceeds in much the same fashion as in the following
section. Essentially, the process only has to be lifted to higher-order type
indices. For the details of this lifting process see Hinze [37, Section 3.2].

4.3 Specializing type-indexed data types

Rather amazingly, the process of specialization of type-indexed functions and

type-indexed data types can be phrased as an interpretation of the simply
typed lambda calculus. The interpretation of the constants (1, Char, ‘+’, ‘×’,
and ‘c of ’) is obtained from the definition of the type-indexed data type as
a catamorphism. The remaining constructs are interpreted generically: type
application is interpreted as type application (albeit in a different domain),
abstraction as abstraction, and fixed points as fixed points.

The first thing we have to do is to generalize the ‘type’ of a type-indexed data

type. In the previous sections, the type-indexed data types had a fixed kind,
for example, FMapt::? :: ? → ?. However, when type application is interpreted
as application, we have that FMapList a = FMapList FMapa . Since List is of kind
? → ?, we have to extend the domain of FMap· by giving it a kind-indexed
kind, in such a way that FMapList :: (? → ?) → (? → ?).

Generalizing the above example, we have that a type-indexed data type pos-
sesses a kind-indexed kind:

Datat::T :: DataT ,

where DataT has the following form:

24
 DataT::2 :: 2
Data? =
DataA→B = DataA → DataB .

Here, ‘2’ is the superkind: the type of kinds. Note that only the definition of
Data? , as indicated by the box, has to be given to complete the definition of
the kind-indexed kind. The definition of Data· on functional kinds is dictated
by the specialization process. Since type application is interpreted by type
application, the kind of a type with a functional kind is functional.

For example, the kind of the type-indexed data type FMapt , where t is a type
of kind ? is:

FMap? = ? → ?.

As noted above, the process of specialization is phrased as an interpretation of

the simply typed lambda calculus. The interpretation of the constants (1, Char,
‘+’, ‘×’, and ‘c of ’) is obtained from the definition of the type-indexed data
type as a catamorphism, and the interpretation of application, abstraction,
and fixed points is given via an environment model [38] for the type-indexed
data type.

An environment model is an applicative structure (M, app, const·), where M

is the domain of the structure, app is a mapping that interprets functions, and
where const· maps constants to the domain of the structure. In order to qualify
as an environment model, an applicative structure has to be extensional and
must satisfy the so-called combinatory model condition. The precise definitions
of these concepts can be found in Mitchell [38]. For an arbitrary type-indexed
data type Datat::T :: DataT we use the following applicative structure:

MT = Type DataT / E
appT,U [t] [u] = [t u]
const(C) = [DataC ].

The domain of the applicative structure for a kind T is the equivalence class
of the set of types of kind DataT , under an appropriate set of equations E
between type terms, that is, β- and η-equality and f (FixT f) = FixT f for
all kinds T and type constructors f of kind T → T. The application of two
equivalence classes of types (denoted by [t] and [u]) is the equivalence class
of the application of the types. The definition of the constants is obtained
from the definition as a catamorphism. It can be verified that the applicative
structure defined thus is an environment model.

25
It remains to specify the interpretation of the fixed point operators, which is
the same for all type-indexed data types:

const(FixT ) = [FixDataT ].

4.4 Specializing type-indexed values

A type-indexed value possesses a kind-indexed type [31],

poly t::T :: PolyT Data1t . . . Datant

in which PolyT has the following general form

PolyT::2 :: Data1T → · · · → DatanT → ?

Poly? = Λx1 :: Data1? . . . . . Λxn :: Datan? .
PolyA→B = Λx1 :: Data1A→B . . . . . Λxn :: DatanA→B .
∀a1 :: Data1A . . . . . ∀an :: DatanA .
PolyA a1 . . . an → PolyB (x1 a1 ) . . . (xn an ).

Again, note that only an equation for Poly? has to be given to complete the
definition of the kind-indexed type. The definition of Poly· on functional kinds
is dictated by the specialization process. The presence of type-indexed data
types slightly complicates the type of a type-indexed value. In Hinze [31]
PolyT takes n arguments of kind T. Here PolyT takes n possibly different type
arguments obtained from the type-indexed data type arguments. For example,
for the type of the look-up function we have:

LookupT::2 :: IdT → FMapT → ?

Lookup? = Λk . Λfmk . ∀v . k → fmk v → Maybe v,

where Id· is the identity function on kinds. From the definition of the generic
look-up function we obtain the following equations:

lookup t::T :: LookupT Idt FMapt

lookup 1 = λv k fmk . fmk
lookup Char = lookupChar
lookup + = λa fma lookup a . λb fmb lookup b .
λv k (fmkl , fmkr ) . case k of {Inl a → lookup a v a fmkl ;
Inr b → lookup b v b fmkr }
lookup × = λa fma lookup a . λb fmb lookup b .
λv (kl , kr ) fmk . case lookup a (fmb v) kl fmk of
{Nothing → Nothing;
Just fmk 0 → lookup b v kr fmk 0 }
lookup c of = λa fma lookup a . λv k fmk . lookup a v k fmk .

26
Just as with type-indexed data types, type-indexed values on type-indexed
data types are specialized by means of an interpretation of the simply typed
lambda calculus. The environment model used for the specialization is some-
what more involved than the one given in Section 4.3. The domain of the
environment model is now a dependent product: the type of the last compo-
nent (the equivalence class of the terms of type PolyT d1 . . . dn ) depends on
the first n components (the equivalence classes of the type schemes d1 . . . dn
of kind T). Note that the application operator applies the term component of
its first argument to both the type and the term components of the second
argument.
1 n
MT = ([d1 ] ∈ Scheme DataT / E, . . . , [dn ] ∈ Scheme DataT / E;
Term PolyT d1 ... dn / E)
appT,U ([r1 ], . . . , [rn ]; [t ]) ([s1 ], . . . , [sn ]; [u ])
= ([r1 s1 ], . . . , [rn sn ]; [t s1 . . . sn u ])
const(C) = ([Data1C ], . . . , [DatanC ]; [poly C ]).

Again, the interpretation of fixed points is the same for different type-indexed
values:

const(FixT ) = ([FixData1T ], . . . , [FixDatanT ]; [poly FixT ]),

where poly FixT is given by

poly FixT = λf1 . . . fn . λpoly f :: PolyT→T f1 . . . fn .

fix poly f (FixData1T f1 ) . . . (FixDatanT fn ).

4.5 Conversion functions

As can be seen in the example of Section 3, we do not interpret type-indexed

functions and data types on Haskell data types directly, but rather on slightly
different, yet isomorphic types. Furthermore, since Haskell does not allow re-
cursive type synonyms, we must introduce a newtype for each specialisation
of a type-indexed data type, thereby again creating a different, but isomorphic
type from the one we are interested in. As a consequence, we have to generate
conversion functions that mediate between these isomorphic types.

These conversion functions are easily generated, both for type-indexed values
and data types, and can be stored in pairs, as values of type Iso. The only
difficult task is to plug them in at the right positions. This problem is solved by
lifting the conversion functions to the type of the specialized generic function.
This again is a generic program [37, Section 6.1.3], which makes use of the
bimap · function displayed in Figure 2 (we omit the type arguments for function

27
 BimapT::2 :: IdT → IdT → ?
Bimap? = Λt1 . Λt2 . Iso t1 t2
bimap t::T :: BimapT Idt Idt
bimap 1 = Iso id id
bimap Char = Iso id id
bimap + = λa1 a2 bimap a . λb1 b2 bimap b .
Iso (λab → case ab of
{Inl a → (Inl · from a1 a2 bimap a ) a;
Inr b → (Inr · from b1 b2 bimap b ) b })
(λab → case ab of
{Inl a → (Inl · to a1 a2 bimap a ) a;
Inr b → (Inr · to b1 b2 bimap b ) b })
bimap × = λa1 a2 bimap a . λb1 b2 bimap b .
Iso (λ(a, b) → (from a1 a2 bimap a a, from b1 b2 bimap b b))
(λ(a, b) → (to a1 a2 bimap a a, to b1 b2 bimap b b))
bimap → = λa1 a2 bimap a . λb1 b2 bimap b .
Iso (λab → from b1 b2 bimap b · ab · to a1 a2 bimap a )
(λab → to b1 b2 bimap b · ab · from a1 a2 bimap a )
bimap ∀? = λf1 f2 bimap f .
Iso (λf v . from (f1 v) (f2 v)
(bimap f v v (Iso id id )) (f v))
(λf v . to (f1 v) (f2 v)
(bimap f v v (Iso id id )) (f v))
bimap c of = λa1 a2 bimap a . bimap a
Fig. 2. Lifting isomorphisms with a generic function.
composition and identity functions).

Consider the generic function

poly t::T :: PolyT Data1t . . . Datant .

Let isoDatat denote iso tT if Datat = Idt , and iso Data tT otherwise. The
conversion function can now be derived as

conv poly t = to (bimap Poly? isoData1t . . . isoDatant ).

For example, the conversion function for the specialization of lookup to Nat is
given by

conv lookup Nat = to (bimap Lookup? iso Nat iso FMap Nat),

which is extensionally the same as the function given in Section 3.

Note that the definition of bimap · must include a case for the quantifier ∀? ::
(? → ?) → ? since Lookup? is a polymorphic type. In this specific case,

28
however, polymorphic type indices can be easily handled, see Figure 2. The
further details are exactly the same as for type-indexed values [39,37], and are
omitted here.

4.6 Summary

For a Generic Haskell program including type-indexed types, the Generic

Haskell compiler does the following.

• For each data type, the corresponding generic representation type is gener-
ated, together with a pair of isomorphisms.
• Each type-indexed type is translated into a series of newtype statements,
one for each case.
• Analogously, each case of each type-indexed function is translated into one
ordinary function definition.
• Finally, each call to a generic function is replaced by a call to the appropriate
specialization.

It is sufficient to specialize generic functions to type constants only. Because

we assign semantics of generic functions via an interpretation of the simply
typed lambda calculus, the calls to generic functions where the type argument
is a more complex type term can be simplified. For instance, the expression

lookuphList Chari

can be simplified to

lookuphListi lookuphChari,

hence only the specializations of lookup to List and Char are required. If generic
functions involve type-indexed types, then specializations for those are needed
as well. The same observation holds for type-indexed types, though: special-
izations to type constants suffice.

It is thus obvious that the additional code size of the translated program is
in the order the number of generic functions times the number of data types
in the program. Careful analysis of which calls actually appear in a program
can be used to reduce the number of specializations that is generated.

29
5 An advanced example: the Zipper

This section shows how to define a so-called zipper for an arbitrary data
type. This is a more complex example demonstrating the full power of a
type-indexed data structure together with a number of type-indexed functions
working on it.

The zipper is a data structure that is used to represent a tree together with a
subtree that is the focus of attention, where that focus may move left, right,
up or down in the tree. The zipper is used in tools where a user interactively
manipulates trees, for instance, in editors for structured documents such as
proofs or programs. For the following it is important to note that the focus of
the zipper may only move to recursive components. Consider as an example
the data type Tree:

data Tree a = Empty | Node (Tree a) a (Tree a).

If the left subtree of a Node constructor is the current focus, moving right
means moving to the right tree, not to the a-label. This implies that recursive
positions in trees play an important rôle in the definition of a generic zipper
data structure. To obtain access to these recursive positions, we have to be
explicit about the fixed points in data type definitions. The zipper data struc-
ture is then defined by induction on the so-called pattern functor of a data
type.

The tools in which the zipper is used, allow the user to repeatedly apply
navigation or edit commands, and to update the focus accordingly. In this
section we define a type-indexed data type for locations, which consist of a
subtree (the focus) together with a context, and we define several navigation
functions on locations.

5.1 The basic idea

The zipper is based on pointer reversal. If we follow a pointer to a subterm,

the pointer is reversed to point from the subterm to its parent so that we
can go up again later. A location is a pair (t, c) consisting of the current
subterm t and a pointer c to its parent. The upward pointer corresponds
to the context of the subterm. It can be represented as follows. For each
constructor K that has m recursive subcomponents we introduce m context
constructors K1 , . . . , Km . Now, consider the location (K t1 t2 . . . tm , c). If
we go down to t1 , we are left with the context K • t2 . . . tm and the old
context c. To represent the combined context, we simply plug c into the hole
to obtain K1 c t2 . . . tm . Thus, the new location is (t1 , K1 c t2 . . . tm ). The

30
following picture illustrates the idea (the filled circle marks the current cursor
position).
c c c
up left
K ⇐= K1 ⇐= K2
down right
=⇒ =⇒
t1 t2 ··· tm t1 t2 ··· tm t1 t2 ··· tm

5.2 Locations

A location is a subtree, together with a context, which encodes the path from
the top of the original tree to the selected subtree. The type-indexed data type
Loc returns a type for locations given an argument pattern functor.

Lochf :: ? → ?i :: ?
Lochfi = (Fix f, Contexthfi (Fix f))
Contexthf :: ? → ?i :: ? → ?
Contexthfi r = Fix (LMaybe (Ctxhfi r))
data LMaybe f a = LNothing | LJust (f a),

where LMaybe is the lifted version of Maybe. The type Loc is defined in terms
of Context, which constructs the context parameterized by the original tree
type. The Context of a value is either empty (represented by LNothing in the
LMaybe type), or it is a path from the root down into the tree. Such a path
is constructed by means of the argument type of LMaybe: the type-indexed
data type Ctx. The type-indexed data type Ctx is defined by induction on the
pattern functor of the original data type. It can be seen as the derivative (as
in calculus) of the pattern functor f [40,41]. If the derivative of f is denoted
by f 0 , we have

const0 = Void
(f + g)0 = f 0 + g0
(f × g)0 = f 0 × g + f × g0

It follows that in the definition of Ctx we will also need access to the type
arguments themselves on the right-hand side of the definition.

Ctxhf :: ? → ?i :: ? → ? → ?
CtxhIdi rc=c
CtxhK 1i r c = Void
CtxhK Chari r c = Void

31
 Ctxhf1 + f2 i r c = Ctxhf1 i r c + Ctxhf2 i r c
Ctxhf1 × f2 i r c = (Ctxhf1 i r c × f2 r) + (f1 r × Ctxhf2 i r c)

This definition can be understood as follows. Since it is not possible to descend

into a constant, the constant cases do not contribute to the result type, which
is denoted by the ‘empty type’ Void, a type without values. The Id case denotes
a recursive component, in which it is possible to descend. Hence it may occur
in a context. Descending in a value of a sum type follows the structure of the
input value. Finally, there are two ways to descend in a product: descending
left, adding the contents to the right of the node to the context, or descending
right, adding the contents to the left of the node to the context.

For example, for natural numbers with pattern functor K 1 + Id, and for
trees of type Bush with pattern functor BushF, which can be represented by
K Char + (Id × Id) we obtain

ContexthK 1 + Idi r = Fix (LMaybe (NatC r))

ContexthK Char + Id × Idi r = Fix (LMaybe (BushC r))
data NatC r c = ZeroC Void | SuccC c
data BushC r c = LeafC Void | ForkCL (c, r) | ForkCR (r, c).

Note that the context of a natural number is isomorphic to a natural number

(the context of m in n is n − m), and the context of a Bush applied to the
data type Bush itself is isomorphic to the type Context Bush introduced in
Section 1.

McBride [40,41] also defines a type-indexed zipper data type. His zipper slightly
deviates from Huet’s and our zipper: the navigation functions on McBride’s
zipper are not constant time anymore. The observation that the Context of a
data type is its derivative (as in calculus) is due to McBride.

5.3 Navigation functions

We define type-indexed functions on the type-indexed data types Loc, Context,

and Ctx for navigating through a tree. All of these functions act on locations.
These are the basic functions for the zipper.

Function down. The function down is a type-indexed function that moves

down to the leftmost recursive child of the current node, if such a child exists.
Otherwise, if the current node is a leaf node, then down returns the location
unchanged.

downhf :: ? → ?i :: Lochfi → Lochfi

32
The instantiation of down to the data type Bush has been given in Section 1.
The function down satisfies the following property:

∀m . downhfi m 6= m =⇒ (uphfi · downhfi) m = m,

where the function up goes up in a tree. So first going down the tree and
then up again is the identity function on locations in which it is possible to
go down.

Since down moves down to the leftmost recursive child of the current node,
the inverse equality downhfi · uphfi = id does not hold in general. However,
there does exist a natural number n such that

∀m . uphfi m 6= m =⇒ (righthfin · downhfi · uphfi) m = m,

where the function right goes right in a tree. These properties do not com-
pletely specify function down. The other properties it should satisfy are that
the selected subtree of downhfi m is the leftmost tree-child of the selected
subtree of m, and the context of downhfi m is the context of m extended with
all but the leftmost tree-child of m.

The function down is defined as follows.

downhfi (t, c) = case firsthfi (out t) c of

{Just (t 0 , c 0 ) → (t 0 , In (LJust c 0 ));
Nothing → (t, c)}

To find the leftmost recursive child, we have to pattern match on the pattern
functor f, and find the first occurrence of Id. The helper function first is a
type-indexed function that possibly returns the leftmost recursive child of a
node, together with the context (a value of type Ctxhfi c t) of the selected
child. The function down then turns this context into a value of type Context
by inserting it in the right (‘non-top’) component of a sum by means of LJust,
and applying the fixed point constructor In to it.

firsthf :: ? → ?i :: ∀c t . f t → c → Maybe (t, Ctxhfi c t)

firsthIdi t c = return (t, c)
firsthK 1i t c = Nothing
firsthK Chari t c = Nothing
firsthf1 + f2 i (Inl x ) c = do {(t, cx ) ← firsthf1 i x c; return (t, Inl cx )}
firsthf1 + f2 i (Inr y) c = do {(t, cy) ← firsthf2 i y c; return (t, Inr cy)}
firsthf1 × f2 i (x , y) c = do {(t, cx ) ← firsthf1 i x c;
return (t, Inl (cx , y))}
++ do {(t, cy) ← firsthf2 i y c;
return (t, Inr (x , cy))}.

33
Here, return is obtained from the Maybe monad, and the operator (+
+) is the
standard monadic plus, called mplus in Haskell, given by

(+
+) :: ∀a . Maybe a → Maybe a → Maybe a
Nothing ++ m = m
Just a ++ m = Just a.

The function first returns the value and the context at the leftmost Id position.
So in the product case, it first tries the left component, and only if it fails, it
tries the right component.

The definitions of functions up, right and left are not as simple as the definition
of down, since they are defined by pattern matching on the context instead of
on the tree itself. We will just define functions up and right, and leave function
left as an exercise.

Function up. The function up moves up to the parent of the current node,
if the current node is not the top node.

uphf :: ? → ?i :: Lochfi → Lochfi

uphfi (t, c) = case out c of
{LNothing → (t, c);
LJust c 0 → do {ft ← inserthfi c 0 t;
c 00 ← extracthfi c 0 ;
return (In ft, c 00 )}}.

Remember that LNothing denotes the empty top context. The navigation
function up uses two helper functions: insert and extract. The latter returns
the context of the parent of the current node. Note that each element of type
Ctxhfi c t has at most one c component (by an easy inductive argument), which
marks the context of the parent of the current node. The generic function
extract extracts this context.

extracthf :: ? → ?i :: ∀c t . Ctxhfi c t → Maybe c

extracthIdi c = return c
extracthK 1i c = Nothing
extracthK Chari c = Nothing
extracthf1 + f2 i (Inl cx ) = extracthf1 i cx
extracthf1 + f2 i (Inr cy) = extracthf2 i cy
extracthf1 × f2 i (Inl (cx , y)) = extracthf1 i cx
extracthf1 × f2 i (Inr (x , cy)) = extracthf2 i cy.

Note that extract is polymorphic in c and in t.

34
Function insert takes a context and a tree, and inserts the tree in the current
focus of the context, effectively turning a context into a tree.

inserthf :: ? → ?i :: ∀c t . Ctxhfi c t → t → Maybe (f t)

inserthIdi c t = return t
inserthK 1i c t = Nothing
inserthK Chari c t = Nothing
inserthf1 + f2 i (Inl cx ) t = do {x ← inserthf1 i cx t; return (Inl x )}
inserthf1 + f2 i (Inr cy) t = do {y ← inserthf2 i cy t; return (Inr y)}
inserthf1 × f2 i (Inl (cx , y)) t = do {x ← inserthf1 i cx t; return (x , y)}
inserthf1 × f2 i (Inr (x , cy)) t = do {y ← inserthf2 i cy t; return (x , y)}.

Note that the extraction and insertion is happening in the identity case Id;
the other cases only pass on the results.

Since uphfi · downhfi = id on locations in which it is possible to go down, we

expect similar equalities for the functions first, extract, and insert. We have
that the following computation

do {(t, c 0 ) ← firsthfi ft c;
c 00 ← extracthfi c 0 ;
0
ft ← inserthfi c 0 t;
return (c c 00 ∧ ft ft 0 )}

returns True on locations in which it is possible to go down.

Function right. The function right moves the focus to the next (right) sib-
ling in a tree, if it exists. The context is moved accordingly. The instance of
right on the data type Bush has been given in Section 1. The function right
satisfies the following property:

∀m . righthfi m 6= m =⇒ (lefthfi · righthfi) m = m,

that is, first going right in the tree and then left again is the identity function
on locations in which it is possible to go to the right. Of course, the dual
equality holds on locations in which it is possible to go to the left. Furthermore,
the selected subtree of righthfi m is the sibling to the right of the selected
subtree of m, and the context of righthfi m is the context of m in which the
context is replaced by the selected subtree of m, and the first subtree to the
right of the context of m is replaced by the context of m.

Function right is defined by pattern matching on the context. It is impossible

to go to the right at the top of a tree. Otherwise, we try to find the right
sibling of the current focus.

35
 righthf :: ? → ?i :: Lochfi → Lochfi
righthfi (t, c) = case out c of
{LNothing → (t, c);
LJust c 0 → case nexthfi t c 0 of
{Just (t 0 , c 00 ) → (t 0 , In (LJust c 00 ));
Nothing → (t, c)}}

The helper function next is a type-indexed function that returns the first
location that has the recursive value to the right of the selected value as its
focus. Just as there exists a function left such that lefthfi · righthfi = id (on
locations in which it is possible to go to the right), there exists a function
previous, such that

do {(t 0 , c 0 ) ← nexthfi t c;
(t 00 , c 00 ) ← previoushfi t 0 c 0 ;
return (c c 00 ∧ t t 00 )}

returns True (on locations in which it is possible to go to the right). We will

define function next, and omit the definition of function previous.

nexthf :: ? → ?i :: ∀c t . t → Ctxhfi c t → Maybe (t, Ctxhfi c t)

nexthIdi t c = Nothing
nexthK 1i t c = Nothing
nexthK Chari t c = Nothing
nexthf1 + f2 i t (Inl cx )
= do {(t 0 , cx 0 ) ← nexthf1 i t cx ; return (t 0 , Inl cx 0 )}
nexthf1 + f2 i t (Inr cy)
= do {(t 0 , cy 0 ) ← nexthf2 i t cy; return (t 0 , Inr cy 0 )}
nexthf1 × f2 i t (Inl (cx , y))
= do {(t 0 , cx 0 ) ← nexthf1 i t cx ; return (t 0 , Inl (cx 0 , y))}
++ do {c ← extracthf1 i cx ;
x ← inserthf1 i cx t;
0
(t , cy) ← firsthf2 i y c;
return (t 0 , Inr (x , cy))}
nexthf1 × f2 i t (Inr (x , cy))
= do {(t 0 , cy 0 ) ← nexthf2 i t cy; return (t 0 , Inr (x , cy 0 ))}.

The first three lines in this definition show that it is impossible to go to the
right in an identity or constant context. If the context argument is a value of
a sum, we select the next element in the appropriate component of the sum.
The product case is the most interesting one. If the context is in the right
component of a pair, next returns the next value of that context, properly
combined with the left component of the tuple. On the other hand, if the
context is in the left component of a pair, the next value may be either in that
left component (the context), or it may be in the right component (the value).

36
If the next value is in the left component, it is returned by the first line in
the definition of the product case. If it is not, next extracts the context c (the
context of the parent) from the left context cx , it inserts the given value in the
context cx giving a ‘tree’ value x , and selects the first component in the right
component of the pair, using the extracted context c for the new context. The
new context that is thus obtained is combined with x into a context for the
selected tree.

6 Conclusion

We have shown how to define type-indexed data types, and we have given sev-
eral examples of type-indexed data types: digital search trees, generic pattern-
matching using a labelled data type, and the zipper. Furthermore, we have
shown how to specialize type-indexed data types and type-indexed functions
that take values of type-indexed data types as arguments. The treatment gen-
eralizes the specialization of type-indexed functions given in Hinze [31], and
used in the implementation of Generic Haskell, a generic programming exten-
sion of the functional language Haskell, see http://www.generic-haskell.
org/. A technical overview of the compiler can be found in De Wit’s thesis [42].
The current release of Generic Haskell contains an experimental implementa-
tion of type-indexed data types. The syntax for type-indexed types used in the
current Generic Haskell compiler differs from the syntax used in this paper in
a few places. There is a tutorial by Hinze and Jeuring [43] that explains the
syntax used in the implementation.

A type-indexed data type is defined in a similar way as a type-indexed func-

tion. The only difference is that the ‘type’ of a type-indexed data type is a
kind instead of a type. Note that a type-indexed data type may also be a type
constructor, it need not necessarily be a type of kind ?. For instance, Label is
indexed by types of kind ? → ? and yields types of kind ? → ? → ?.

The approach taken in this paper is powerful enough to be used for sets of
mutually recursive type-indexed data types. Hagg [8] uses mutually recursive
type-indexed data types to specify data types with holes, for use in a generic
editor.

Acknowledgements. Thanks are due to Dave Clarke, Ralf Lämmel, Doaitse

Swierstra, and the anonymous referees for comments on previous versions of
the paper. Jan de Wit suggested an improvement in the labelling functions.

37
References

[1] S. Peyton Jones [editor], J. Hughes [editor], L. Augustsson, D. Barton,

B. Boutel, W. Burton, S. Fraser, J. Fasel, K. Hammond, R. Hinze, P. Hudak,
T. Johnsson, M. Jones, J. Launchbury, E. Meijer, J. Peterson, A. Reid,
C. Runciman, P. Wadler, Haskell 98 — A non-strict, purely functional language,
Available from http://www.haskell.org/definition/ (Feb. 1999).

[2] R. Backhouse, P. Jansson, J. Jeuring, L. Meertens, Generic programming:

An introduction, in: S. D. Swierstra, P. R. Henriques, J. N. Oliveira (Eds.),
Advanced Functional Programming, Vol. 1608 of LNCS, Springer-Verlag, 1999,
pp. 28–115.

[3] R. Hinze, Generalizing generalized tries, Journal of Functional Programming

10 (4) (2000) 327–351.
URL citeseer.nj.nec.com/hinze99generalizing.html

[4] J. Jeuring, Polytypic pattern matching, in: Conference Record of FPCA

’95, SIGPLAN-SIGARCH-WG2.8 Conference on Functional Programming
Languages and Computer Architecture, ACM Press, 1995, pp. 238–248.

[5] P. Jansson, J. Jeuring, Functional pearl: Polytypic unification, Journal of

Functional Programming 8 (5) (1998) 527–536.

[6] K. Claessen, P. Ljunglöf, Typed logical variables in Haskell, in: Proceedings

Haskell Workshop 2000, 2000.

[7] P. Jansson, J. Jeuring, A framework for polytypic programming on terms,

with an application to rewriting, in: J. Jeuring (Ed.), Workshop on Generic
Programming 2000, Ponte de Lima, Portugal, July 2000, 2000, pp. 33–45,
utrecht Technical Report UU-CS-2000-19.

[8] P. Hagg, A framework for developing generic XML Tools, Master’s thesis,
Department of Information and Computing Sciences, Utrecht University (2002).

[9] R. Hinze, J. Jeuring, A. Löh, Type-indexed data types, in: Proceedings of the
6th Mathematics of Program Construction Conference, MPC’02, Vol. 2386 of
LNCS, 2002, pp. 148–174.

[10] R. Bird, O. de Moor, P. Hoogendijk, Generic functional programming with

types and relations, Journal of Functional Programming 6 (1) (1996) 1–28.

[11] G. Huet, The zipper, Journal of Functional Programming 7 (5) (1997) 549–554.

[12] G. Huet, Linear contexts and the sharing functor: Techniques for symbolic
computation, in: F. Kamareddine (Ed.), Thirty Five Years of Automating
Mathematics, Kluwer, 2003.

[13] M. M. T. Chakravarty, G. Keller, More types for nested data parallel

programming, in: Proceedings ICFP 2000: International Conference on
Functional Programming, ACM Press, 2000, pp. 94–105.

38
[14] R. Harper, G. Morrisett, Compiling polymorphism using intensional type
analysis, in: 22nd Symposium on Principles of Programming Languages, POPL
’95, 1995, pp. 130–141.

[15] J. Gibbons, Polytypic downwards accumulations, in: Proceedings of

Mathematics of Program Construction, Vol. 1422 of LNCS, Springer-Verlag,
1998, pp. 207–233.

[16] M. Vestin, Genetic algorithms in Haskell with polytypic programming,

Examensarbeten 1997:36, Göteborg University, Gothenburg, Sweden, available
from the Polytypic programming WWW page [44] (1997).

[17] R. Lämmel, W. Lohmann, Format Evolution, in: J. Kouloumdjian, H. Mayr,

A. Erkollar (Eds.), Proc. 7th International Conference on Reverse Engineering
for Information Systems (RETIS 2001), Vol. 155 of [email protected], OCG, 2001,
pp. 113–134.

[18] G. Malcolm, Data structures and program transformation, Science of Computer

Programming 14 (1990) 255–279.

[19] L. Meertens, Paramorphisms, Formal Aspects of Computing 4 (5) (1992) 413–

425.

[20] M. Fokkinga, Law and order in algorithmics, Ph.D. thesis, University of Twente,
Dept INF, Enschede, The Netherlands (1992).

[21] P. Jansson, J. Jeuring, PolyP — a polytypic programming language extension,

in: Conference Record of POPL ’97: The 24th ACM SIGPLAN-SIGACT
Symposium on Principles of Programming Languages, ACM Press, 1997, pp.
470–482.

[22] C. Dubois, F. Rouaix, P. Weis, Extensional polymorphism, in: 22nd Symposium

on Principles of Programming Languages, POPL ’95, 1995, pp. 118–129.

[23] C. Jay, G. Bellè, E. Moggi, Functorial ML, Journal of Functional Programming

8 (6) (1998) 573–619.

[24] Z. Yang, Encoding types in ML-like languages, in: Proceedings ICFP 1998:
International Conference on Functional Programming, ACM Press, 1998, pp.
289–300.
URL citeseer.nj.nec.com/zhe99encoding.html

[25] K. Crary, S. Weirich, J. G. Morrisett, Intensional polymorphism in type-erasure

semantics, in: Proceedings ICFP 1998: International Conference on Functional
Programming, ACM Press, 1998, pp. 301–312.

[26] K. Crary, S. Weirich, Flexible type analysis, in: Proceedings ICFP 1999:
International Conference on Functional Programming, ACM Press, 1999, pp.
233–248.
URL citeseer.nj.nec.com/crary99flexible.html

39
[27] V. Trifonov, B. Saha, Z. Shao, Fully reflexive intensional type analysis, in:
Proceedings ICFP 2000: International Conference on Functional Programming,
ACM Press, 2000, pp. 82–93.
URL citeseer.nj.nec.com/saha00fully.html

[28] S. Weirich, Encoding intensional type analysis, in: European Symposium on

Programming, Vol. 2028 of LNCS, Springer-Verlag, 2001, pp. 92–106.
URL
http://link.springer.de/link/service/series/0558/tocs/t%2028.htm

[29] S. Weirich, Higher-order intensional type analysis, in: D. Le Métayer (Ed.),

Proceedings of the 11th European Symposium on Programming, ESOP 2002,
Vol. 2305 of Lecture Notes in Computer Science, 2002, pp. 98–114.

[30] R. Hinze, A new approach to generic functional programming, in: Conference

Record of POPL ’00: The 27th ACM SIGPLAN-SIGACT Symposium on
Principles of Programming Languages, ACM Press, 2000, pp. 119–132.
URL citeseer.nj.nec.com/hinze99new.html

[31] R. Hinze, Polytypic values possess polykinded types, in: R. Backhouse, J. N.

Oliveira (Eds.), Mathematics of Program Construction, Vol. 1837 of LNCS,
Springer-Verlag, 2000, pp. 2–27.

[32] N. J. McCracken, An investigation of a programming language with a

polymorphic type structure, Ph.D. thesis, Syracuse University (June 1979).

[33] E. Meijer, M. Fokkinga, R. Paterson, Functional programming with bananas,

lenses, envelopes, and barbed wire, in: J. Hughes (Ed.), FPCA’91: Functional
Programming Languages and Computer Architecture, Vol. 523 of LNCS,
Springer-Verlag, 1991, pp. 124–144.

[34] D. Clarke, A. Löh, Generic Haskell, specifically, in: J. Gibbons, J. Jeuring (Eds.),
Generic Programming, Vol. 243 of IFIP, Kluwer Academic Publishers, 2003, pp.
21–48.

[35] D. Knuth, J. Morris, V. Pratt, Fast pattern matching in strings, SIAM Journal
on Computing 6 (1978) 323–350.

[36] M. P. Jones, Type classes with functional dependencies, in: G. Smolka (Ed.),
Proceedings of the 9th European Symposium on Programming, ESOP 2000,
Berlin, Germany, Vol. 1782 of LNCS, Springer-Verlag, 2000, pp. 230–244.

[37] R. Hinze, Generic Programs and Proofs, 2000, Habilitationsschrift, Bonn

University.

[38] J. C. Mitchell, Foundations for Programming Languages, The MIT Press, 1996.

[39] R. Hinze, S. Peyton Jones, Derivable type classes, in: G. Hutton (Ed.),
Proceedings of the 2000 ACM SIGPLAN Haskell Workshop, Vol. 41.1 of
Electronic Notes in Theoretical Computer Science, Elsevier Science, 2001, the
preliminary proceedings appeared as a University of Nottingham technical
report.

40
[40] C. McBride, The derivative of a regular type is its type of one-hole contexts,
unpublished manuscript (2001).

[41] M. Abott, T. Altenkirch, N. Ghani, C. McBride, Derivatives of containers, in:

Typed Lambda Calculi and Applications, TLCA 2003, Vol. 2701 of LNCS,
Springer-Verlag, 2003, pp. 16–30.

[42] J. de Wit, A technical overview of Generic Haskell, Master’s thesis, Department

of Information and Computing Sciences, Utrecht University (2002).

[43] R. Hinze, J. Jeuring, Generic Haskell: applications, to appear (2003).

[44] P. Jansson, The WWW home page for polytypic programming, Available from
http://www.cs.chalmers.se/~patrikj/poly/ (2001).

41