Practical type inference for arbitrary-rank types

Citation preview

c 2006 Cambridge University Press JFP 17 (1): 1–82, 2007.


1

doi:10.1017/S0956796806006034 First published online 9 June 2006 Printed in the United Kingdom

Practical type inference for arbitrary-rank types SIMON PEYTON JONES Microsoft Research

DIMITRIOS VYTINIOTIS University of Pennsylvania

STEPHANIE WEIRICH University of Pennsylvania

MARK SHIELDS Microsoft Research

Abstract Haskell’s popularity has driven the need for ever more expressive type system features, most of which threaten the decidability and practicality of Damas-Milner type inference. One such feature is the ability to write functions with higher-rank types – that is, functions that take polymorphic functions as their arguments. Complete type inference is known to be undecidable for higher-rank (impredicative) type systems, but in practice programmers are more than willing to add type annotations to guide the type inference engine, and to document their code. However, the choice of just what annotations are required, and what changes are required in the type system and its inference algorithm, has been an ongoing topic of research. We take as our starting point a λ-calculus proposed by Odersky and L¨ aufer. Their system supports arbitrary-rank polymorphism through the exploitation of type annotations on λ-bound arguments and arbitrary sub-terms. Though elegant, and more convenient than some other proposals, Odersky and L¨ aufer’s system requires many annotations. We show how to use local type inference (invented by Pierce and Turner) to greatly reduce the annotation burden, to the point where higher-rank types become eminently usable. Higher-rank types have a very modest impact on type inference. We substantiate this claim in a very concrete way, by presenting a complete type-inference engine, written in Haskell, for a traditional Damas-Milner type system, and then showing how to extend it for higher-rank types. We write the type-inference engine using a monadic framework: it turns out to be a particularly compelling example of monads in action. The paper is long, but is strongly tutorial in style. Although we use Haskell as our example source language, and our implementation language, much of our work is directly applicable to any ML-like functional language.

1 Introduction Consider the following Haskell program: foo :: ([Bool], [Char]) foo = let f x = (x [True, False], x [’a’,’b’]) in f reverse main = print foo https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

2

S. Peyton Jones et al.

In the body of f, the function x is applied both to a list of booleans and to a list of characters – but that should be fine, because the function passed to f, namely reverse, works equally well on lists of any type. If executed, therefore, one might think that the program would run without difficulty, to give the result ([False,True], [’b’,’a’]). Nevertheless, the expression is rejected by Haskell’s type checker (and would be rejected by ML as well), because Haskell implements the Damas-Milner rule that a lambda-bound argument (such as x) can only have a monomorphic type. The type checker can assign to x the type [Bool] → [Bool], or [Char] → [Char], but not ∀a.[a] → [a]. It turns out that one can do a great deal of programming in Haskell or ML without ever finding this restriction irksome. For a minority of programs, however, so-called higher-rank types turn out to be desirable, a claim we elaborate in Section 2. The following question then arises: is it possible to enhance the Damas-Milner type system to allow higher-rank types, but without making the type system, or its inference algorithm, much more complicated? We believe that the answer is an emphatic “yes”. The main contribution of this paper is to present a practical type system and inference algorithm for arbitrary-rank types; that is, types in which universal quantifiers can occur nested. For example, the Glasgow Haskell Compiler (GHC), which implements the type system of this paper, will accept the program: foo :: ([Bool], [Char]) foo = let f :: (forall a. [a] -> [a]) -> ([Bool], [Char]) f x = (x [True, False], x [’a’,’b’]) in f reverse Notice the programmer-supplied type signature for f, which expresses the polymorphic type of f’s argument. (The explicit “forall” is GHC’s concrete syntax for universal quantification “∀”.) Our work draws together and applies Odersky & L¨aufer’s type system for arbitrary-rank types (Odersky & L¨ aufer, 1996), and Pierce & Turner’s idea of local type inference (Pierce & Turner, 1998). The resulting type system, which we describe in Section 4, has the following properties: • It is a conservative extension of Damas-Milner: any program typeable with Damas-Milner remains typeable. • The system accommodates types of arbitrary finite rank; it is not, for example, restricted to rank 2. We define the rank of a type in Section 3.1. • Programmer annotations may be required to guide the type inference engine, but the type system specifies precisely which annotations are required, and which are optional. • The annotations required are quite modest, more so than in the system of Odersky and L¨ aufer.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

3

• The inference algorithm is only a little more complicated than the DamasMilner algorithm. The main claim of this paper is simplicity. In the economics of language design and compiler development, one should not invest too much to solve a rare problem. Language users only have so much time to spend on learning a language and on understanding compiler error messages. Compiler implementors have a finite time budget to spend on implementing language features, or improving type error messages. There is a real cost to complexity. We claim, however, that a suitably-designed system of higher-rank types represents an extremely modest addition to a vanilla Damas-Milner type system. First, the language is extended in a simple way: we simply permit the programmer to write explicitly-quantified types, such as the type of f above. Second, the implementation changes are also extremely modest. Contrary to our initial intuition, a type-inference engine for Damas-Milner can be modified very straightforwardly to accommodate arbitrary-rank types. This is particularly important in a full-scale compiler like GHC, because the type checker is already extremely complicated. It supports Haskell’s overloading mechanism, implicit parameters, functional dependencies, records, scoped type variables, existential types, and more besides. Anything that complicates the main type-inference fabric, on which all this is based, would be hard to justify. To make this latter claim concrete, we first present a complete implementation of Damas-Milner for a small language (Section 5), and then give all the changes needed to make it work at higher rank (Section 6). The implementation is structured using a monad to carry all the plumbing needed by the type-inference engine, so the code is remarkably concise and is given in full in the Appendix. We hope that, inter alia, this implementation of type inference may serve as a convincing example of the utility of monadic programming. As well as this pedagogical implementation, we have built what we believe is the first full-scale implementation of the Odersky/L¨aufer idea, in a compiler for Haskell, the Glasgow Haskell Compiler (GHC). Although we use Haskell as our example source language, and as our implementation language, almost all our work is directly applicable to any functional language. In a language that has side effects, extra care would be required at one or two points.

2 Motivation The introduction showed a rather artificial example in which the argument of a function needed a polymorphic type. Here is another, more realistic, example. Haskell comes with a built-in type class called Monad: class Monad m where return :: a -> m a (>>=) :: m a -> (a -> m b) -> m b

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

4

S. Peyton Jones et al.

One can easily write monad combinators; for example, mapM f applies a monadic function f to each element of its argument list1 : mapM :: Monad m => (a -> m b) -> [a] -> m [b] mapM f [] = return [] mapM f (x:xs) = f x >>= \ y -> mapM f xs >>= \ ys -> return (y:ys) Now suppose instead that one wanted to do the same thing using an explicit data structure. A value of data type Monad m would be a record of two functions, which we write using Haskell’s record notation: data Monad m = Mon { return :: a -> m a, bind :: m a -> (a -> m b) -> m b } We rename (>>=) to bind, because bind is now a selector function that extracts the function from the record. This type declaration would be illegal in Haskell 98, because the type of return, for example, mentions a type variable a that is not a parameter of the type Monad. The idea is, of course, that the data structure contains a polymorphic function of type ∀a.a → m a. The function mapM now takes an explicit argument record of type Monad m, from which it extracts the relevant fields by pattern matching2 : mapM :: Monad m -> (a -> m b) -> [a] -> m [b] mapM m@(Mon { return = ret, bind = bnd }) f xs = case xs of [] -> ret [] (x:xs) -> f x ‘bnd‘ \y -> mapM m f xs ‘bnd‘ \ys -> ret (y:ys) Notice that in this function, bnd is used at two different types within a single right-hand side, so it is crucial that it is polymorphic. In this way, we can use a data type whose constructor has a rank-2 type to simulate the effect of type classes – indeed, this is precisely the way in which type classes are implemented internally. Functions and constructors with higher-rank types now appear quite regularly in the functional programming literature. For example:

1 2

In Haskell, lambda abstractions extend as far to the right as possible; in this case, both lambdas extend to the end of the definition. In Haskell, back-quotes turn a function such as bnd into an infix operator.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

5

Data structure fusion. Short-cut deforestation (Gill et al., 1993) makes use of build with type build :: forall a. (forall b. (a -> b -> b) -> b -> b) -> [a] Encapsulation. The encapsulated state monad ST (Launchbury & Peyton Jones, 1995) requires a function runST with type: runST :: forall a. (forall s. ST s a) -> a The idea is that runST ensures that a stateful computation, of type ST s a, can be securely encapsulated to give a pure result of type a. Dynamic types. Baars and Swierstra describe the following data type data Equal a b = Equal (forall f . f a -> f b) as a key part of their approach to dynamic typing (Baars & Swierstra, 2002). Generic programming. Various approaches to generic, or polytypic, programming make essential use of higher-rank types. For example, the “scrap your boilerplate” approach to generic programming (L¨ ammel & Peyton Jones, 2003) has functions such as: gmapT :: forall a. Data a => (forall b. Data b => b -> b) -> a -> a Hinze’s work on generic programming also makes extensive use of higher-rank types (Hinze, 2000). Invariants. Several authors have explored the idea of using the type system to encode data type invariants, via so-called nested data types (Bird & Paterson, 1999; Okasaki, 1999; Hinze, 2001). For example, Paterson and Bird use the following data type to encode lambda terms, in which the nesting depth is reflected in the type: data Term v = Var v | App (Term v) (Term v) | Lam (Term (Incr v)) data Incr v = Zero | Succ v Then the fold over Term has type: foldT :: -> -> ->

(forall a. a -> n a) (forall a. n a -> n a -> n a) (forall a. n (Incr a) -> n a) Term b -> n b

All of these examples use rank-2 types, but rank-3 types are occasionally useful too. Here is an example that defines a map function over the Term type above, using a

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

6

S. Peyton Jones et al.

fixpoint function fixMT: type MapT = forall a b. (a->b) -> Term a -> Term b fixMT :: (MapT -> MapT) -> MapT fixMT f = f (fixMT f) mapT :: MapT mapT = fixMT (\mt -> \f t case t of Var x App t1 t2 Lam t

-> -> Var (f x) -> App (mt f t1) (mt f t2) -> Lam (mt (mapI f) t))

Notice that fixMT has a rank-3 type. In order to make the type readable we abbreviate the polymorphic type ∀a b.(a → b) → Term a → Term b using a type synonym MapT. Haskell 98 does not allow polymorphic types as the right hand side of a type synonym, but it is tremendously useful, as this example shows, so GHC permits it. These cases are not all that common, but there are usually no workarounds; if you need higher-rank types, you really need them! Taken together, we believe they make a compelling case that adding higher-rank types adds genuinely-useful expressive power to the language. 3 The key ideas Motivated by the previous section, we now present a brief, informal account of our approach to typing higher-ranked programs. The next section will give a formal description, while Sections 5 and 6 describe the implementation. There is a considerable amount of related work which we allude to only in passing, leaving a more thorough treatment for Section 9. 3.1 Higher-ranked types The rank of a type describes the depth at which universal quantifiers appear contravariantly (Kfoury & Tiuryn, 1992): Monotypes Polytypes

τ, σ 0 σ n+1

::= ::=

a | τ1 → τ2 σ n | σ n → σ n+1 | ∀a.σ n+1

Here are some examples: Int → Int ∀a.a → a Int → (∀a.a → a) (∀a.a → a) → Int

Rank Rank Rank Rank

0 1 1 2

Throughout this paper we will use the term “monotype”, and the symbol τ, for a rank-zero type; monotypes have no universal quantifiers whatsoever. We use the

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

7

term “polytype”, and symbol σ, for a type of rank one or greater. In the literature, the term “type” is often used to mean monotype, but we prefer to be more explicit here.

3.2 Exploiting type annotations Haskell and ML are both based on the classic Damas-Milner type system (Damas & Milner, 1982), which we review in Section 4.2. This type system has the remarkable property that a compiler can infer the principal type for a polymorphic function, without any help from the programmer. Furthermore, the type inference algorithm is not unduly complicated. But Damas-Milner stands on a delicate cusp: almost any extension of the type system either destroys this unaided-type-inference property, or greatly complicates the type-inference algorithm. The Damas-Milner type system permits ∀ quantifiers only at the outermost level of a type scheme, so the examples in Section 2 would all be ill-typed, and it turns out that type inference becomes difficult or intractable if one permits richer, higher-ranked types (Section 9). An obvious alternative is to abandon the goal of unaided type inference, at least for programs that use higher-ranked types, and instead require the programmer to supply some type annotations to guide type inference, as we did for function f in the Introduction. Odersky and L¨ aufer do precisely this, in a paper that is one of the main inspirations of our work (Odersky & L¨aufer, 1996). Our intuition is that programmers are not only willing to provide explicit type annotations; they are positively eager to do so, as a form of machine-checked documentation, especially as the types become more complicated. One problem with the Odersky/L¨ aufer approach is that the annotation burden is quite heavy, as we shall see in Section 4.5. Often, though, the context makes a type annotation redundant. For example, consider again our example: f :: (forall a. [a] -> [a]) -> ([Bool], [Char]) f x = (x [True, False], x [’a’,’b’]) The type signature for f makes the type of x clear, without explicitly annotating the latter. In this case, annotating x directly would not be too bad: f (x :: forall a. [a]->[a]) = (x [True, False], x [’a’,’b’]) But one would not want to annotate x and provide a separate type signature; and if f had multiple clauses one would tiresomely have to repeat the annotation. Similarly, in our Monad example (Section 2), the local variables ret and bnd were given polymorphic types somehow inferred from the data type declaration for Monad. The idea of propagating type information around the program, to avoid redundant type annotations, is called local type inference (Pierce & Turner, 1998). The original paper used local type inference to stretch the type system in the direction of sub-typing, but we apply the same technique to support higher-rank types, as we shall see in Section 4.7.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

8

S. Peyton Jones et al. 3.3 Subsumption

Suppose that we have variables bound with the following types: k :: ∀ab.a → b → b f1 :: (Int → Int → Int) → Int f2 :: (∀x .x → x → x ) → Int Is the application (f1 k) well typed? Yes, it is well-typed in Haskell or ML as they stand; one just instantiates a and b to Int. Now, what about the application (f2 k)? Even though k’s type is not identical to that of f2’s argument, this application too should be accepted. Why? Because k is more polymorphic than the function f2 requires. The former is independently polymorphic in a and b, while the latter is less flexible. So there is a kind of sub-typing going on: an argument is acceptable to a function if its type is more polymorphic than the function’s argument type. Odersky and L¨ aufer use the term subsumption for this “more polymorphic than” relation. When extended to arbitrary rank, the usual co/contra-variance phenomenon occurs; that is, σ1 → Int is more polymorphic than σ2 → Int if σ1 is less polymorphic than σ2 . For example, consider g :: ((∀b.[b] → [b]) → Int) → Int k1 :: (∀a.a → a) → Int k2 :: ([Int] → [Int]) → Int Since (∀a.a → a) is more polymorphic than (∀b.[b] → [b]), it follows that ((∀a.a → a) → Int) is less polymorphic than ((∀b.[b] → [b]) → Int) and hence the application (g k1) is ill-typed. In effect, k1 requires to be given an argument of type (∀a.a → a), whereas g only promises to pass it a (less polymorphic) argument of type (∀b.[b] → [b]). On the other hand, the application g k2 is well typed. 3.4 Predicativity Once one allows polytypes nested inside function types, it is natural to ask whether one can also call a polymorphic function at a polytype. For example, consider the following two functions: revapp :: a -> (a->b) -> b revapp x f = f x poly :: (forall v. v -> v) -> (Int, Bool) poly f = (f 3, f True) Would the application (revapp (\x->x) poly) be legal? The application would require us to instantiate the type variable a from revapp’s type with the polytype

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

9

∀v .v → v . The function fixMT in Section 2 is a more practical example. It is a specialised instance of an “ordinary” fix function: fix :: (a -> a) -> a fix f = f (fix f) However, using fix in place of fixMT would mean instantiating fix at the polymorphic type MapT. The same issue arises in the context of data structures. Suppose we have a data type: data Tree a = Leaf a | Branch (Tree a) (Tree a) Is it legal to have the type (Tree (∀a.a → a)); that is, a Tree whose leaves hold polymorphic functions? Doing so would require us to instantiate the Leaf constructor at a polymorphic type. A type system that allows a polymorphic function to be instantiated at a polytype is called impredicative, while a predicative system only allows a polymorphic function to be instantiated with a monotype. The Damas-Milner type system is predicative, of course, and so is the Odersky/L¨ aufer system. Type inference is much easier in a predicative type system, as we discuss in Section 5.7, so we adopt predicativity in our type system too. Remarkably, it is possible to support both type inference and impredicativity, as MLF shows (Le Botlan & Rmy, 2003), but doing so adds significant new complications to both the type system and the implementation – see Section 9.2.

3.5 Higher-kinded types Haskell allows abstraction over higher-kinded types, as we have already seen. For example, our Monad type was defined like this: data Monad m = Mon { return :: a -> m a, bind :: m a -> (a -> m b) -> m b } Here, the type variable m ranges over type constructors, such as Maybe or Tree, rather than over types. A Haskell compiler will infer that m has kind ∗ → ∗; that is, m maps types (written “∗”) to types. The question of type inference for higher kinds is an interesting one. Happily, it turns out that the solution adopted by Haskell for higher kinds extends smoothly to work in the presence of higher-rank types, as we know from our experience of implementing both in GHC. The two features are almost entirely orthogonal. We therefore do not discuss higher kinds at all in the rest of the paper.

3.6 Summary This concludes our informal summary of our language extensions, as seen by the programmer. Next, we turn our attention to a precise description of the type system.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

10

S. Peyton Jones et al.

Rank 1 ρ ::= τ

Arbitrary rank ρ ::= τ | σ → σ

Not syntax-directed Does not lead to an algorithm

Damas-Milner Section 4.2, page 12 Figure 3

Odersky-L¨ aufer Section 4.5, page 17 Figure 5

Syntax-directed Algorithm can be read off

Damas-Milner Section 4.3, page 13 Figure 4

This paper Section 4.6, page 18 Figures 6, 7 This paper Section 4.7, page 22 Figure 8

Bidirectional Algorithm can be read off

Type contexts

Γ

::=

Γ, x : σ | 

Polytypes Rho-types Monotypes Type variables

σ ρ τ a, b

::= ::= ::=

∀a.ρ See table above Int | τ1 → τ2 | a

Fig. 1. Road map.

4 Type systems for higher-rank types In this section we give a precise specification of the type system we sketched informally in Section 3. In fact, we will discuss five type systems in all, using the road-map shown in Figure 1. The first column, headed “Rank 1” deals with the conventional rank-1 MLstyle type system. There are two standard presentations of this type system, which correspond to the two cells of this column. Type systems are often specified initially in a non-syntax-directed style. This style is terse, and well-adapted for proving properties, but does not usually suggest a type inference algorithm. A standard idea is to re-cast the rules in syntax-directed form, so that the structure of the typing derivation is determined by the syntactic structure of the program. With a bit of practice, it is usually possible to “read off” an inference algorithm from a set of typing rules in syntax-directed form. We present the textbook Damas-Milner system in both forms (left-hand column of the table in Figure 1), to introduce in a familiar context our language, and to review the idea of syntax-directed rules. Then we will follow exactly the same development for the arbitrary-rank system (right-hand column of the table). The top right-hand corner is a non-syntax-directed system, developed by Odersky and L¨ aufer, on which our work is based. From this we derive a syntax-directed system, and then further develop that into a so-called bidirectional system, for reasons that will become apparent.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types Term variables Integers Terms

11

x , y, z i t, u

::= | | | | | |

i x \x .t \(x ::σ).t tu let x = u in t t::σ

Literal Variable Abstraction Typed abstraction (σ closed) Application Local binding Type annotation (σ closed)

Fig. 2. Syntax of the source language.

These systems differ in their type structure. They all share a common definition for polytypes (σ) and monotypes (τ), also given in Figure 1. In this figure, and elsewhere, we use the notation a to mean a sequence of zero or more type variables a1 , . . . , an . The systems differ in their definition of the intermediate rho-types (ρ), whose distinguishing feature is that they have no top-level quantifiers. The syntax of rho-types is given, for each system, in Figure 1. That will then leave us ready to develop an implementation in Sections 5 and 6.

4.1 Notation We will present all our type systems for a simple language, given in Figure 2. The language of terms is very simple: it is the lambda calculus augmented with nonrecursive let bindings, and type annotations on both terms and lambda abstractions. This language is carefully chosen to allow us to present the key structural aspects of type inference for higher-rank types with as few constructs as possible. For example, we omit recursive bindings because they introduce no new problems. The type annotations, written using “::” on both terms and abstractions, are the main unusual feature; indeed one of the points of this paper is to show how they can be used to direct type inference in a simple and predictable way. In this paper we will assume that the type annotations are closed – that is, they have no free type variables – which is the case in Haskell 98. There are strong reasons to want open type annotations, which require lexically-scoped type variables (Shields & Peyton Jones, 2002), but we will avoid that complication here because it opens up a whole new design space that distracts from our main theme. Figure 1 defines the syntax of types. A minor point is that in the definition of polytypes we quantify over a vector of zero or more type variables, a, rather than quantifying one variable at a time with a recursive definition. These quantifiers are not required to bind all the free type variables of ρ; that is, a polytype σ can have free type variables. Otherwise it would not be possible to write higher-rank types, such as ∀a.(∀b.(a, b) → (b, a)) → [a] → [a]. (Here, and in subsequent examples, we assume we have list and pair types, written [τ] and (τ1 , τ2 ) respectively; but we will not introduce any terms with these types.) In our syntax, a σ-type always has

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

12

S. Peyton Jones et al.

Rho-types ρ ::= τ Γt :σ Γ  i : Int

int

Γ, (x : σ)  x : σ

Γt :τ→ρ Γu:τ

Γ, (x : τ)  t : ρ Γ  (\x .t) : (τ → ρ)

abs

Γu:σ Γ, x : σ  t : ρ Γ  let x = u in t : ρ a ∈ ftv (Γ) Γt :ρ Γ  t : ∀a.ρ

var

Γt u:ρ Γt :σ

let

Γ  (t::σ) : σ

app

annot

Γ  t : ∀a.ρ gen

Γ  t : [a → τ] ρ

inst

Fig. 3. The non-syntax-directed Damas-Milner type system.

a ∀, even if there are no bound variables, but we will sometimes abbreviate the degenerate case ∀.ρ as simply ρ. The same figure also shows type contexts, Γ, which convey the typings of in-scope variables; Γ binds a term variable, x , to its type σ. We define ftv (σ) to be the free type variables of σ, and extend the function to
type contexts in the obvious way: ftv (Γ) = {ftv (σ) | (x : σ) ∈ Γ}. We use the notation [a → τ]ρ to mean the capture-avoiding substitution of type variables a by monotypes τ in the type ρ.

4.2 The non-syntax-directed Damas-Milner system Figure 3 shows the type checking rules for the well-known Damas-Milner type system (Damas & Milner, 1982). In this system, polytypes have rank 1 only, so a ρ-type is simply a monotype τ, and hence a polytype σ takes the form ∀a.τ. The main judgement takes the form: Γt :σ which means “in environment Γ the term t has type σ”. The alert reader will nevertheless notice several judgements of the form Γ  t : ρ, for example in the conclusion of rule app. As mentioned in Section 4.1, this is just shorthand for the σ-type ∀.ρ, namely a type with no quantifiers. In the Damas-Milner system we omit the type-annotated lambda (\(x ::σ).t), because a Damas-Milner lambda can only abstract over a monotype, and that is adequately dealt with by the un-annotated lambda.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

13

Rule inst quietly makes a very important point: the system is predicative (Section 3.4), so type variables may range only over monotypes. We can see this from the fact that the type variables in inst are instantiated by τ types, not σ types. Efficient type inference depends crucially on this restriction, a point that we amplify in Section 5.7.

4.3 The syntax-directed Damas-Milner system Each rule in Figure 3 has a distinct syntactic form in its conclusion, except for two: gen (generalisation) and inst (instantiation). Because these two have the same syntactic form in their premise as in their conclusion, one can apply them pretty much anywhere; for example, one could alternate gen and inst indefinitely. This flexibility makes it hard to turn the rules into a type-inference algorithm. For example, given a term, say \x.x, it is not clear which rules to use, in which order, to derive a judgement  \x.x : σ for some σ. If all the rules had a distinct syntactic form in their conclusions, the rules would be in so-called syntax-directed form, and that would, in turn, fully determine the shape of the derivation tree for any particular term t. This is a very desirable state of affairs, because it means that the steps of a type inference algorithm can be driven by the syntax of the term, rather than having to search for a valid typing derivation. Figure 4 shows an alternative form of the typing rules that is syntax-directed. The main judgement now takes the form: Γt :ρ meaning that “in context Γ term t has type ρ”. In contrast to Figure 3, the type ρ in the judgement is a monotype (recall that in the Damas-Milner system, ρ is the same as τ). The places where type generalisation and instantiation take place are now completely specified by the syntax of the term. Instantiation is handled by the inst auxiliary judgement  , where inst



σ6ρ

means that the outer quantifiers of σ can be instantiated to give ρ. Instantiation is used in rule var to instantiate the type of a polymorphic variable at its occurrence sites. poly which infers a Dually, generalisation is handled by the auxiliary judgement  polytype for a term. It is used in rule let to type the right-hand side of the let. In the spirit of moving towards an algorithm, gen also specifies that the quantified type variables a should be exactly the variables that are free in ρ but not in Γ (contrast rule gen in Figure 3). There is no point in generalising over a variable that is not free in ρ; but otherwise it is useful to generalise as much possible, subject to a ∈ Γ. In this way, we have constrained the valid derivations still further – that is, moved closer to a deterministic algorithm – without reducing the set of typeable terms. sh There is one further judgement,  , which we discuss very shortly, in Section 4.4.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

14

S. Peyton Jones et al.

Rho-types ρ ::= τ Γt :ρ inst

σ6ρ

 Γ  i : Int

int Γ, (x : σ)  x : ρ

Γt :τ→ρ Γu:τ

Γ, (x : τ)  t : ρ Γ  (\x .t) : (τ → ρ)

abs

poly

Γ

let

poly

t : ∀a.ρ

t : σ inst  σ6ρ

annot

Γ  (t::σ) : ρ

inst



t :σ

a = ftv (ρ) − ftv (Γ) Γt :ρ Γ

Γ  σ 6 σ sh

Γ  let x = u in t : ρ

app

Γt u:ρ poly

poly

u:σ Γ Γ, x : σ  t : ρ

var

gen

inst



σ6ρ

∀a.ρ 6 [a → τ] ρ

inst

 σ 6 σ sh

a ∈ ftv (σ) sh  σ6ρ sh

 σ 6 ∀a.ρ

sh

skol

 [a → τ] ρ1 6 ρ2 sh

 ∀a.ρ1 6 ρ2

spec

sh

 τ6τ

mono

Fig. 4. The syntax-directed Damas-Milner type system.

We can very nearly regard these new rules as an algorithm. Corresponding to the judgement  is an inference algorithm that, given a context Γ and a term t computes a type τ such that Γ  t : τ; and similarly for the other judgements.3 However, the rules still leave one big thing unspecified: in various rules an otherwise-unspecified τ appears out of nowhere. For example, in rule abs, where does the τ come from? Given the empty context and the term \x.x, the following judgements all hold, by choosing the τ in rule abs to be Int, [a] and a respectively:  (\x.x) : Int → Int  (\x.x) : [a] → [a]  (\x.x) : a → a 3

This is not the only possible way to regard the typing rules as an algorithm, as we discuss in Section 9.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

15

Of course, we want the last of these, because it is the most general type for \x.x, the one that is better than all the others, and in Section 5 we will see how to achieve this. A similar guess must be made in rule inst where we have to choose the types τ to use when instantiating σ. The distinction between syntax-directed and non-syntax-directed formulations of typing judgements is well known. The latter is more simple, elegant, and abstract. The former is more bulky, using auxiliary judgements to avoid duplication and, precisely because it is closer to an algorithm, is more concrete. However, although the trade-off is well known, it is not well documented; Clement et al. (1986) is one of the few papers that discuss the matter, and has the merit of giving a proof of equivalence of the two systems. 4.4 Type annotations and subsumption Rule annot does not form part of most presentations of the Damas-Milner system, because it deals with type annotations. The term (t::σ) is a term that has been annotated by the programmer with a polytype σ. For example, consider the term: (\x.x) :: (∀a.[a] → [a]) This term is well typed, because the most general type of (\x.x) is ∀a.a → a, and that is certainly more general than ∀a.[a] → [a]. The annotation is a type restriction, because the annotated term must only be used at the specified type. For example, this term is illegal: ((\x.x) :: (∀a.[a] → [a])) (True,False) because, while (\x.x) is applicable to (True,False), the type restriction makes it inapplicable. Haskell 98 includes this type annotation construct, but we introduce it here mainly as an expository device. It turns out that the typing judgements and inference algorithm for a type-annotated term involve much of the machinery that we will need later for higher-ranked types. Discussing type-annotated terms here allows us to introduce this machinery in the well-understood context of Damas-Milner inference. In the non-syntax-directed system of Figure 3, type annotations are easy to handle. Rule annot simply requires that a type-annotated term (t::σ) does indeed have type σ. Matters become more interesting in the syntax-directed system of Figure 4. There, rule annot type-checks a type-annotated term in three stages: poly

• Find t’s most general type σ , using  ; • This type might differ from the programmer-supplied annotation σ, because the latter is not necessarily the most general type of t. So the next step is to sh check that σ is at least as polymorphic as σ, using a new judgement form  , shown in Figure 4; inst • Finally, instantiate σ, using  . The new judgement form sh

 σoff 6 σreq

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

16

S. Peyton Jones et al.

means “the offered type σoff is at least as polymorphic as the required type σreq ”. In the rest of the paper we will often say “more polymorphic than” instead of the more precise but clumsier “at least as polymorphic as”. The judgement embodies a simplified form of the subsumption relationship of Section 3.3 – simplified in that it only deals with rank-1 polytypes. The superscript “sh” is used to indicate shallow subsumption; will encounter richer versions of subsupmtion shortly. inst Unlike  , the subsumption judgement compares two polytypes. For example: Int Int → Bool ∀a.a → a ∀a.a → a ∀a.a → a ∀ab.(a, b) → (b, a)

6 6 6 6 6 6

Int Int → Bool Int → Int ∀b.[b] → [b] ∀bc.(b, c) → (b, c) ∀c.(c, c) → (c, c)

The third example involves only simple instantiation, but the last three illustrate the general case. Notice that the number of quantified type variables in the left-hand type can be the same, or more, or fewer, than in the right-hand type, as the last three examples demonstrate. sh It is worth studying carefully the rules for  , in Figure 4, because they play a central role in this paper. We reproduce them here for convenience: a ∈ ftv (σ) sh  σ6ρ sh

 σ 6 ∀a.ρ

sh

skol

 [a → τ] ρ1 6 ρ2 sh

 ∀a.ρ1 6 ρ2

spec

sh

 τ6τ

mono

Rule mono deals with the trivial case of two monotypes. When quantifiers are involved, to prove that σoff 6 σreq we must find an instantiation of σoff that makes it match any given instantiation of σreq . In formal notation, to prove that ∀a.ρoff 6 ∀b.ρreq we must prove that ∀b ∃a such that ρoff 6 ρreq To this end, rule spec is straightforward: it allows us to instantiate the outermost type variables of σoff arbitrarily to match ρreq . But how can we check that σoff can be instantiated by spec to match any instantiation of σreq ? Suppose we were to instantiate the outermost type variables of σreq to arbitrary, completely fresh type constants, called skolem constants. If, having done this we can still make σoff match, then we will have shown that indeed σoff is at least as polymorphic as σreq . Cunningly, rule skol does not actually instantiate σreq with fresh constants; instead, it simply checks that the type variables of σreq are fresh with respect to σoff (perhaps by alpha-renaming σreq ); then these type variables will themselves serve very nicely as skolem constants, so we can vacuously instantiate ∀a.ρ with the types a to get ρ. That is the reason for the side condition in skol, a ∈ ftv (τ). Notice that one has to apply skol before spec, because the latter assumes a ρ type to the right of the 6. That is, we first instantiate σreq with skolem constants, and then choose how to instantiate σoff to make it match. Let us take a particular example. To prove that ∀a.a → a 6 ∀bc.(b, c) → (b, c)

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

17

Practical type inference for arbitrary-rank types

Rho-types ρ ::= τ | σ → σ Γt :σ Γ  i : Int

int

Γ, (x : σ)  x : σ

var

Γ, x : σ  t : σ

Γ, x : τ  t : σ abs

Γ  (\x .t) : (τ → σ)

Γ  t : (σ → σ ) Γu:σ Γt u:σ Γu:σ Γ, x : σ  t : σ Γ  let x = u in t : σ

Γ  (\(x ::σ).t) : (σ → σ ) Γt :σ

app



Γ  (t::σ) : σ a ∈ ftv (Γ) Γt :ρ

let

Γ  t : ∀a.ρ

aabs

annot Γ  t : σ ol  σ 6 σ

gen

Γt :σ

subs

 σ 6 σ ol

a ∈ ftv (σ) ol  σ6ρ ol

ol

 σ 6 ∀a.ρ

skol

 [a → τ] ρ1 6 ρ2

spec

ol

 ∀a.ρ1 6 ρ2

ol

 σ 3 6 σ1 ol  σ 2 6 σ4 ol

 (σ1 → σ2 ) 6 (σ3 → σ4 )

fun

ol

 τ6τ

mono

Fig. 5. The Odersky-L¨ aufer type system.

first use skol to skolemise b and c, checking that b and c are not free in ∀a.a → a, and then use spec to instantiate a with the type (b, c). The derivation looks like this: (b, c) → (b, c) 6 (b, c) → (b, c) ∀a.a → a 6 (b, c) → (b, c) ∀a.a → a 6 ∀bc.(b, c) → (b, c)

mono inst [a → (b, c)] skol

4.5 Higher-rank types We now turn our attention from the well-established Damas-Milner type system to the system of arbitrary-rank types proposed by Odersky and L¨aufer (1996). Figure 5 presents the Odersky/L¨ aufer type checking rules for our term language, in non-syntax-directed form.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

18

S. Peyton Jones et al.

Comparing these rules to those of the non-syntax-directed Damas-Milner system in Figure 3, the three significant differences are these: • The figure begins by defining rho-types, ρ, to complete the syntax of types: Rho-types

ρ

::=

τ | σ → σ

Crucially, a polytype may appear in both the argument and result positions of a function type, and hence polytypes may be of arbitrary rank. Providing this freedom is the whole point of this paper. • The syntax of terms is extended with a new form of lambda abstraction, \(x ::σ).t, in which the bound variable is explicitly annotated with a polytype, σ. The argument type of such an abstraction is σ (rule aabs) in contrast to an ordinary, unannotated lambda abstraction whose argument type is a mere monotype, τ (rule abs). • Rule gen is unchanged, but instantiation (rule inst) is replaced by subsumption (rule subs). The idea is that if we know (t : σ), then we also know (t : σ ) for any σ that is less polymorphic than σ. Checking the “at least as polymorphic ol as” condition is done by the type-subsumption judgement,  , shown in Figure 5. ol

sh

The definition of subsumption  in Figure 5 is just like that of  in Figure 4, with one crucial generalisation: it has an extra rule (fun) which allows it to “look inside” functions in the usual co- and contra-variant manner. Adding this single rule allows us to instantiate deeply nested quantifiers, rather than only outermost quantifiers. For example, we can deduce that: Bool → (∀a.a → a) 6 (Int → Int) → Bool 6 (∀b.[b] → [b]) → Bool 6

Bool → Int → Int (∀a.a → a) → Bool (∀a.a → a) → Bool

None of these types would have been syntactically legal in the Damas-Milner system. ol However, as we shall see in the next subsection,  is a little too small; that is, it does not relate enough types. 4.6 A syntax-directed higher-rank system The typing rules of Figure 5 have the same difficulty as those of the non-syntaxdirected rules for Damas-Milner: they are not syntax-directed, and are far removed from an algorithm. In particular, rule gen allows us to generalise anywhere, and rule subs allows us to specialise anywhere. The Damas-Milner idea is to specialise at variable occurrences, and generalise at lets (Figure 4). The obvious thing to do is simply to use the same idea at higher rank, which is done in Figure 6. Notice that the specialisation judgement, inst σ 6 ρ, instantiates only the outermost quantified type variables of σ; and  poly t : σ, generalises only the outermost similarly the generalisation judgement, Γ  type variables of σ. Any polytypes hidden under arrows are unaffected. Just as in the syntax-directed Damas-Milner system of Figure 4, we must invoke subsumption in rule annot of Figure 6, but we use yet another form of subsumption,

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

19

Practical type inference for arbitrary-rank types

Rho-types ρ ::= τ | σ → σ Γt :ρ inst

 Γ  i : Int

Γ, (x : σ)  x : ρ

var

Γ, x : σ  t : ρ

Γ, x : τ  t : ρ Γ  (\x .t) : (τ → ρ)

abs

poly

Γ  t : (σ1 → σ2 )

σ6ρ

int

Γ

Γ  (\(x ::σ).t) : (σ → ρ) dsk

u : σ



inst

σ 6 σ1



aabs σ2 6 ρ app

Γt u:ρ poly

dsk



Γ σ 6 σ

t : σ inst  σ6ρ

Γ  (t :: σ) : ρ

poly

Γ poly

annot

Γ  let x = u in t : ρ

inst



t :σ

a = ftv (ρ) − ftv (Γ) Γt :ρ Γ

poly

u:σ Γ Γ, x : σ  t : ρ

t : ∀a.ρ

gen

inst



let

σ6ρ

∀a.ρ 6 [a → τ] ρ

inst

Fig. 6. Syntax-directed higher-rank type system. dsk

 , for reasons we discuss next. The other new feature of the rules is that in rule poly to infer a polytype σ for the argument, because the function app we must use  may require the argument to have a polytype σ1 . These two types may not be identical, because the argument may be more polymorphic than required, so again dsk  is used to marry up the two. 4.6.1 A problem with subsumption In the new syntax-directed rules we have used a new form of subsumption (not yet dsk defined), which we write  . If we instead used the Odersky/L¨aufer subsumption, ol  , the type system would be perfectly sound, but it it would type fewer programs than the non-syntax-directed system of Figure 5. To see why, consider this program: let f = \x.\y.y in (f :: ∀a.a → (∀b.b → b)) A Haskell programmer would expect to infer the type (∀ab.a → b → b) for the letbinding for f, and that is what the rules of Figure 6 would do. The type-annotated occurence of f then requires that f’s type be more polymorphic than the supplied signature, but alas, under the subsumption rules of Figure 5, it is simply not the

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

20

S. Peyton Jones et al.

case that ol

 ∀ab.a → b → b 6 ∀a.a → (∀b.b → b) although the converse is true. On the other hand the typing rules of Figure 5 could ol give the let-binding the type (∀a.a → ∀b.b → b) and then  would succeed. In short the syntax-directed rules do not find the most general type for f, under the ol ordering induced by  . One obvious solution is to fix Figure 6 to infer the type ∀a.a → (∀b.b → b) for the let-binding for f. Odersky and L¨ aufer’s syntax-directed version of their language does this simply by generalising every lambda body in rules abs and aabs, so that the ∀’s in the result type occur as far to the right as possible. Here is the modified rule abs poly

Γ, x : τ 

t :σ

eager-abs Γ  (\x .t) : (τ → σ) We call this approach eager generalisation; but we prefer to avoid it. A superficial but practically-important difficulty is that it yields inferred types that programmers will find unfamiliar. Furthermore, if the programmer adds a type signature, such as f::∀ab.a → b → b, he may make the function less general without realising it. Finally, there is a problem related to conditionals. Consider the term if ... then (\x.\y.y) else (\x.\y.x) This term will type fine in Haskell, but eager generalisation would yield (∀a.a → ∀b.b → b) for the then branch, and (∀a.a → ∀b.b → a) for the else branch – and it is now un-clear how to unify these two types. Conditionals are not part of the syntax we treat formally, thus far, but we return to this question in Section 7.1. 4.6.2 The solution: deep skolemisation Fortunately, another solution is available. The difficulty arises because it is not the case that ol

 ∀ab.a → b → b 6 ∀a.a → (∀b.b → b) But that is strange, because the two types are isomorphic.4 So, from a semantic point of view, the two types should be equivalent; that is, we would like both of the following to hold: ∀ab.a → b → b ∀a.a → (∀b.b → b) 4

6 6

∀a.a → (∀b.b → b) ∀ab.a → b → b

More concretely, if f : ∀ab.a → b → b, then we can construct a System-F term of type ∀a.a → (∀b.b → b), namely: (Λa.λ(x : a).Λb.λ(y : b). f a b x y) : ∀a.a → (∀b.b → b) Likewise, if g : ∀a. → (∀b.b → b) then we can also construct: (Λa.Λb.λ(x : a).λ(y : b). g a x b y) : ∀ab.a → b → b Section 4.8 discusses System F in more detail.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

21

Practical type inference for arbitrary-rank types

pr (σ) = ∀a .ρ pr (ρ1 ) = ∀b.ρ2

pr (σ2 ) = ∀a.ρ2

a ∈ b

pr (∀a.ρ1 ) = ∀ab.ρ2

prpoly

a ∈ ftv (σ1 )

pr (σ1 → σ2 ) = ∀a.σ1 → ρ2

prfun

prmono pr (τ) = τ

σ 6 σ

dsk

 pr (σ2 ) = ∀a.ρ

dsk



dsk ∗

dsk ∗



∀a.ρ1 6 ρ2

σ1 6 ρ deep-skol

σ6ρ dsk

[a → τ]ρ1 6 ρ2

dsk ∗



σ 1 6 σ2

 

dsk ∗

a ∈ ftv (σ1 )

 spec

dsk ∗



σ 3 6 σ1

dsk ∗



τ6τ

dsk ∗



σ 2 6 ρ4

(σ1 → σ2 ) 6 (σ3 → ρ4 )

fun

mono

Fig. 7. Subsumption with deep skolemisation.

Hence, perhaps we can solve the problem by enriching the definition of subsumption, so that the type systems of Figure 5 and 6 admit the same programs. That is the dsk reason for the new subsumption judgement  , defined in Figure 7. This relation ol subsumes  ; it relates strictly more types. The key idea is that in deep-skol (Figure 7), we begin by pre-processing σ2 to float out all its ∀s that appear to the right of a top level arrow, so that they can be skolemised immediately. We call this rule “deep-skol” because it skolemises quantified variables even if they are nested inside the result type of σ2 . The floating process is done by an auxiliary function pr (σ), called weak prenex conversion, also defined in Figure 7. For example, pr (∀a.a → (∀b.b → b)) = ∀ab.a → b → b In general, pr (σ) takes an arbitrary polytype σ and returns a polytype of the form pr (σ) = ∀a. σ1 → . . . → σn → τ There can be ∀s in the σi , but there are no ∀s in the result types of the top-level

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

22

S. Peyton Jones et al.

arrows. Of course, when floating out the ∀s, we must be careful to avoid accidental capture, which is the reason for the side condition in the second rule for pr (). (We can always alpha-convert the type to satisfy this condition.) We call it “weak” prenex conversion because it leaves the argument types σi unaffected. To keep the system syntax-directed, we have split the subsumption judgement dsk into two. The main one,  , has a single rule that performs deep skolemisation dsk ∗ and invokes the auxiliary judgement,  . The latter has the remaining rules for ol dsk subsumption, unchanged from  , except that fun invokes  on the argument dsk ∗ on the result types. To see why the split is necessary, consider trying types but  dsk to check  ∀a.Int → a → a 6 Int → ∀a.a → a. Even though the ∀a on the right is hidden under the arrow, we must still use deep-skol before spec. The function pr (σ) converts σ to weak-prenex form “on the fly”. Another workable alternative – indeed one we used in an earlier version of this paper – is to ensure that all types are syntactically constrained to be in prenex form, using the following syntax: σ ρ

::= ∀a.ρ ::= τ | σ → ρ

This seems a little less elegant in theory, and is a little less convenient in practice because it is sometimes convenient for the programmer to write non-prenex-form types – the curious reader may examine the type of everywhere in Section 6.1 of (L¨ ammel & Peyton Jones, 2003) for an example. The syntactically-constrained system also seems more fragile if we wanted to move to an impredicative system, because instantiation could yield a syntactically-illegal type. The deep-skolemisation approach would not work for ML, because in ML the types ∀ab.a → b → b and ∀a.a → (∀b.b → b) are not isomorphic: one cannot push foralls around freely because of the value restriction. There are alternative approaches, as discussed by R´emy (Rmy, 2005), but we do not discuss this issue further here.

4.7 Bidirectional type inference The revised rules are now syntax-directed, but they share with the original Odersky/L¨ aufer system the property that the type of a lambda abstraction can only have a higher-rank type (i.e. polytype on the left of the arrow) if the lambda-bound variable is explicitly annotated; compare rules abs and aabs in Figure 6. Often, though, this seems far too heavyweight. For example, suppose we have the following definition5 : foo = (\i. (i 3, i True)) :: (∀a.a → a) → (Int, Bool)

5

In Haskell, one would instead use a separate type signature: foo :: (forall a. a -> a) -> (Int, Bool) foo = \i-> (i 3, i True)} but we use the one-line version to avoid adding declaration type signatures to our little language.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

23

In this example it is plain as a pike-staff that i should have the type (∀a.a → a), even though it is not explicitly annotated as such. Somehow we would like to “push the type annotation inwards”, so that the type signature for foo can be exploited to give the type for i. The idea of taking advantage of type annotations in this way is not new: it was invented by Pierce and Turner, who called it local type inference (Pierce & Turner, 1998). We use the Pierce/Turner formalism in what follows, and return to a discussion of their work in Section 9.4. 4.7.1 Bidirectional inference judgements Figure 8 gives typing rules that express the idea of propagating types inwards. The figure describes two very similar typing judgements. Γ ⇑ t : ρ means “in context Γ the term t can be inferred to have type ρ”, whereas Γ ⇓ t : ρ means “in context Γ, the term t can be checked to have type ρ”. The up-arrow ⇑ suggests pulling a type up out of a term, whereas the down-arrow ⇓ suggests pushing poly inst and  are generalised in the same a type down into a term. The judgements  way. The main idea of the bidirectional typing rules is that a term might be typeable in checking mode when it is not typeable in inference mode; for example the term (\x -> (x True, x ’a’)) can be checked with type (∀a.a → a) → (Bool, Char), but is not typeable in inference mode. However, if we infer the type for a term, we can always check that the term has that type. That is: If

Γ ⇑ t : ρ

then

Γ ⇓ t : ρ

Furthermore, checking mode allows us to impress on a term any type that is more specific than its most general type. In contrast, inference mode may only produce a type that is some substitution of the most general type. For example, if a variable has type b → (∀a.a → a) we can check that it has this type and also that it has types Int → (∀a.a → a) and Int → Int → Int. On the other hand, of these types, we will only be able to infer b → (∀a.a → a) and Int → (∀a.a → a). Finally, our intention is that any term typable by the uni-directional rules of Figure 6 is also typable in inference mode by Figure 8. That is: If

Γt :ρ

then

Γ ⇑ t : ρ

The reverse is of course false. That is the whole point: we expect that the definition of foo above will be typable with the new rules, whereas it is not with the old ones. 4.7.2 Bidirectional inference rules Many of the rules in Figure 8 are “polymorphic” in the direction δ. For example, the rules int, var, app, annot, and let are insensitive to δ, and can be seen as shorthand

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

24

S. Peyton Jones et al.

Rho-types ρ ::= τ | σ → σ Γ δ t : ρ

δ ::= ⇑ | ⇓ inst

Γ δ i : Int Γ, (x : τ) ⇑ t : ρ Γ ⇑ (\x .t) : (τ → ρ)

δ

int

σ6ρ

Γ, (x : σ) δ x : ρ poly

Γ, (x : σa ) ⇓

abs1

var

t : σr

Γ ⇓ (\x .t) : (σa → σr )

abs2

dsk

 σ a 6 σx poly Γ, (x : σx ) ⇓ t : σr

Γ, (x : σ) ⇑ t : ρ aabs1 Γ ⇑ (\(x ::σ).t) : (σ → ρ)

Γ ⇓ (\(x ::σx ).t) : (σa → σr ) poly

Γ ⇑ t : (σ → σ )

Γ ⇓

inst

δ

u:σ

σ 6 ρ app

Γ δ t u : ρ poly

Γ ⇓ t : σ inst δ σ 6 ρ Γ δ (t::σ) : ρ

aabs2

poly

Γ ⇑ u : σ Γ, x : σ δ t : ρ

annot

Γ δ let x = u in t : ρ

poly

Γ δ

let

t :σ

a = ftv (ρ) − ftv (Γ) Γ ⇑ t : ρ gen1 poly Γ ⇑ t : ∀a.ρ

a ∈ ftv (Γ) Γ ⇓ t : ρ pr (σ) = ∀a.ρ poly

Γ ⇓

gen2

t :σ

inst

δ σ 6 ρ inst ⇑

∀a.ρ 6 [a → τ] ρ

inst1



dsk

σ 6 ρ

inst ⇓

σ 6 ρ

inst2

Fig. 8. Bidirectional version of Odersky-L¨ aufer.

for two rules that differ only in the arrow direction. In a real language there are even more such constructs (case and if are other examples), so the notational saving is quite worth while. The rule app, which deals with function application (t u), is of particular interest. Regardless of the direction δ, we first infer the type σ → σ for t, and then check that u has type σ. In this way we take advantage of the function’s type (which is often

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

25

directly extracted from Γ), to provide the type context for the argument. We then inst to check that σ and ρ are compatible. Notice that, even in the checking use  case ⇓, we ignore the required type ρ when inferring the type for the function t. There is clearly some information loss here: we know the result type, ρ, for t, but we do not know its argument type. The rules provide no way to express this partial information about t’s type – but see the discussion in Section 9.4. Dually, ordinary (un-annotated) lambda abstractions are dealt with by rules abs1 and abs2. The inference case (abs1) is just as before, but the checking case (abs2) is more interesting. To check that \x .t has type σa → σr , we bind x to the polytype σa , even though x is not explicitly annotated, before checking that the body has type σr . In this way, we take advantage of contextual information, in a simple and precisely-specified way, to reduce the necessity for type annotations. We also need two rules for annotated lambda abstractions. In the inference case, aabs1, we extend the environment with the σ-type specified by the annotation, and infer the type of the body. In the checking case, aabs2, we extend the environment in the same way, before checking that the body has the specified type – but we must also check that the argument type expected by the environment σa is more polymorphic than that specified in the type annotation σx . Notice the contravariance! For example, this expression is well typed: (\(f::Int->Int). f 3) :: (∀a.a → a) → Int

4.7.3 Instantiation and generalisation inst

The δ judgement also has separate rules for inference and checking. Rule inst1 deals with the inference case: just as in the old inst rule of Figure 6, we simply instantiate the outer ∀’s. The checking case, inst2, is more interesting. Here, we are pushing inward a type ρ, and it meets a variable of known polytype σ. The right thing to do is simply to check that ρ is more polymorphic than σ, using our inst dsk subsumption judgement  . Rule annot and var both make use of the δ , just as they did in Figure 6, but annot becomes slightly simpler. In the syntax-directed rules of Figure 6, we inferred the most general type for t, and performed a subsumption check against the specified type; now we can simply push the specified type inwards, into t. The reader may wonder why we do not need deep instantiation as well as deep skolemisation. In particular, here is an alternative version of rule inst1: pr (σ) = ∀a.ρ inst ⇑

σ 6 [a → τ] ρ

deep-inst1

(The prenex-conversion function pr (σ), was introduced in Section 4.6.2.) This rule instantiates all the top-level ∀’s of a type, even if they are hidden under the right-hand end of an arrow. For example, under deep-inst1: inst

⇑

∀a.a → ∀b.b → b 6 [a → τa , b → τb ] a → b → b

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

26

S. Peyton Jones et al.

Adopting this rule would give an interesting invariant, namely that Γ ⇑ t : ρ

⇒

ρ is in weak-prenex form

However, there seems to be no other reason to complicate inst1, so we use the simpler version. poly The generalisation judgement Γ δ t : σ also has two cases. When we are inferring a polytype (rule gen1) we need to quantify over all free variables of the inferred ρ type that do not appear in the context Γ, just as before. On the other hand, when we check that a polytype can be assigned to a term (rule gen2), we simply skolemise the quantified variables, checking they do not appear free in the environment Γ. The situation is very similar to that of deep-skol in Figure 7, so gen2 must perform weak prenex conversion on the expected type σ, to bring all its quantifiers to the top. If it fails to do so, the following program would not typecheck: poly

f : (∀ab.Int → a → b → b) ⇓

f 3 : Bool → ∀c.c → c inst

The problem is that f’s type is instantiated by var before rule app invokes ⇓ to marry up the result type with the type of (f 3), and hence before the ∀c.c → c is skolemised. Once we use gen2, however, the reader may verify that Γ ⇓ t : ρ is invoked only when ρ is in weak-prenex form. However, for generality we prefer to define ⇓ over arbitrary ρ-types. For example, this generality allows us to state, without side conditions, that if Γ ⇑ t : ρ then Γ ⇓ t : ρ. 4.7.4 Summary In summary, the bidirectional type rules reduce the burden of type annotations by propagating type information inwards. As we shall see when we come to implementation in Section 5.4, the idea of propagating types inwards is desirable for reasons quite independent of higher-rank types, so the impact on implementation turns out to be rather modest. 4.8 Type-directed translation A type system tells whether a term is well-typed. In some compilers, the type inference engine also performs a closely-related task, that of performing a typedirected translation from the implicitly-typed source language into an explicitly-typed target language. The target language is “explicitly typed” because the term is decorated with enough type information to make type-checking very simple. The source language is “implicitly typed” because as much type clutter as possible is omitted. The business of the type inference engine is to fill in the missing type information. One very popular target language is System F (Girard, 1990), an extremely expressive, strongly-typed lambda calculus. Figure 9 gives the syntax of the variant

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types e, f

::= | | | | | |

i x Λα.t λ(x : σ).t eσ f e let x : σ = e1 in e2

27

Literal Variable Type abstraction Value abstraction Type application Value application Local binding

Fig. 9. Syntax of System F.

of System F that we will use here. It differs from the source language in the following ways: • The binding occurrence of every variable is annotated with its type. • An explicit type application (e σ) specifies the types that instantiate a polymorphic function f . • An explicit type abstraction (Λa.e) specifies where and how generalisation takes place. For example, consider: concat = (\ xs -> foldr (++) Nil xs) :: ∀a.[[a]] → [a] where the types of foldr, (++) and Nil are: foldr :: (++) :: Nil ::

∀xy.(x → y → y) → y → [x ] → y ∀z .[z ] → [z ] → [z ] ∀a.[a]

With explicit type abstractions and applications, concat would look like this: concat:∀a.[[a]] → [a] = Λa.λ(xs:[[a]]).foldr [a] [a] ((++) a) (Nil a) xs The “Λa” binds the type variable a; and the type applications instantiate the polymorphic functions foldr, (++), and the constructor Nil, whose types we give above for reference. We cannot give a full introduction to System F here, and readers unfamiliar with System F may safely skip this section. However, the System F translation is an extremely useful tool. On the theory side, we use it to prove that our type system is sound, in Section 4.9.3. In practical terms, the entire compiler after the type checker processes an explicitly-typed program, which gives the compiler helpful information. Furthermore, type-checking the System F program at a later stage (which is very easy to do) gives a very strong consistency check that the intermediate stages have not performed an invalid transformation (Morrisett, 1995; Tarditi et al., 1996; Shao, 1997; Peyton Jones & Santos, 1998). In the rest of this section we show how to specify the translation into System F. 4.8.1 Translating terms The term “type-directed” translation comes from the fact that the translation is specified in the type rules themselves. For example, the main judgement for our

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

28

S. Peyton Jones et al.

bidirectional system becomes Γ δ t : ρ → e meaning that t has type ρ, and translates to the System-F term e. Furthermore the term e will have type ρ in System F’s type system; we write Γ F e : ρ. (We do not give the type system for System F here because it is so standard (Pierce, 2002). The interested reader can find it in the Technical Appendix (Vytiniotis et al., 2005).) The translated, System F terms have explicit type annotations on binders. For example, rule abs1 from Figure 8 becomes Γ, (x : τ) ⇑ t : ρ → e Γ ⇑ (\x .t) : (τ → ρ) → (λ(x : τ).e)

abs1

The source program did not have an annotation on x , but the translated System F program does have one. Many of the other rules in Figure 8 can be modified in a similar routine way and, for completeness, Figure 10 shows the result. In effect, the translated program encodes the exact shape of the derivation tree, and therefore amounts to a proof that the original program is indeed well typed.

4.8.2 Instantiation, generalisation, and subsumption The translation of terms is entirely standard, but matters become more interesting when we consider instantiation and generalisation. Consider rule var from Figure 8: inst

δ

σ6ρ

Γ, (x : σ) δ x : ρ

var

What should x translate to? It cannot translate to simply x , because x has type σ, inst not ρ! After a little thought we see that the  judgement should return a coercion function of type σ → ρ, which can be thought of as concrete – indeed, executable – evidence for the claim that σ 6 ρ. Then we can add translation to the var rule as follows: inst

δ

σ 6 ρ → f

Γ, (x : σ) δ x : ρ → f x inst

Figure 10 shows the rules for the  inst ⇑

var

judgement:

∀a.ρ 6 [a → τ] ρ → λ(x :∀a.ρ).x τ

inst1



dsk

σ 6 ρ → e

inst ⇓

σ 6 ρ → e

inst2

The inference case, rule inst1, uses a System F type application (x τ) to record the dsk types at which x is instantiated. For the checking case, rule inst2 defers to  , which also returns a coercion function.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

29

Practical type inference for arbitrary-rank types

Γ δ t : ρ → e inst

Γ δ i : Int → i

δ

int

σ 6 ρ → f

Γ, (x : σ) δ x : ρ → f x

Γ, (x : τ) ⇑ t : ρ → e Γ ⇑ (\x .t) : (τ → ρ) → λ(x :τ).e poly

Γ, (x : σa ) ⇓

var

abs1

t : σr → e

Γ ⇓ (\x .t) : (σa → σr ) → (λx :σa ).e Γ, (x : σ) ⇑ t : ρ → e Γ ⇑ (\(x ::σ).t) : (σ → ρ) → λ(x :σ).e

abs2

aabs1

dsk

 f  σ a 6 σx → poly Γ, (x : σx ) ⇓ t : σr → e Γ ⇓ (\(x ::σx ).t) : (σa → σr ) → λ(x :σa ).[x → (f x )]e Γ ⇑ t : (σ → σ ) → e1

poly

Γ ⇓

inst

u : σ → e2

δ

aabs2

σ 6 ρ → f app

Γ δ t u : ρ → f (e1 e2 ) poly

Γ ⇓ t : σ → e inst δ σ 6 ρ → f

poly

annot

Γ δ (t::σ) : ρ → f e

poly

Γ δ a = ftv (ρ) − ftv (Γ) Γ ⇑ t : ρ → e poly

Γ ⇑

t : ∀a.ρ → Λa.e

gen1

Γ ⇑ u : σ → e1 Γ, x : σ δ t : ρ → e2 Γ δ let x = u in t : ρ → let x : σ = e1 in e2

let

t : σ → e pr (σ) = ∀a.ρ → f a∈ / ftv (Γ) Γ ⇓ t : ρ → e poly

Γ ⇓

t : σ → f (Λa.e)

gen2

inst

δ σ 6 ρ → f inst ⇑

∀a.ρ 6 [a → τ] ρ → λ(x :∀a.ρ).x τ

inst1



dsk

σ 6 ρ → f

inst ⇓

σ 6 ρ → f

Fig. 10. Bidirectional higher-rank type system with translation

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

inst2

30

S. Peyton Jones et al.

pr (σ) = ∀a .ρ → f pr (ρ1 ) = ∀b.ρ2 → f

a∈ /b

pr (∀a.ρ1 ) = ∀ab.ρ2 → λ(x :∀ab.ρ2 ).Λa.f (x a) pr (σ2 ) = ∀a.ρ2 → f

prpoly

a ∈ ftv (σ1 )

pr (σ1 → σ2 ) = ∀a.σ1 → ρ2 → λ(x :∀a.σ1 → ρ2 ).λ(y:σ1 ).f (Λa.x a y) pr (τ) = τ → λ(x :τ).x

dsk



prmono

σ 6 σ → f

pr (σ2 ) = ∀a.ρ → f1 dsk ∗ a ∈ ftv (σ1 )  σ1 6 ρ → f2 dsk



σ1 6 σ2 → (λx :σ1 ).f1 (Λa.f2 x )

dsk ∗

 dsk ∗

 dsk ∗

dsk

 dsk ∗



deep-skol

σ 6 ρ → f

[a → τ]ρ1 6 ρ2 → f

∀a.ρ1 6 ρ2 → λ(x :∀a.ρ).f (x τ)



prfun

σ3 6 σ1 → f1

dsk ∗



spec

σ2 6 σ4 → f2

(σ1 → σ2 ) 6 (σ3 → σ4 ) → λ(x :σ1 → σ2 ).λ(y:σ3 ).f2 (x (f1 y)) dsk ∗



τ 6 τ → λ(x :τ).x

fun

mono

Fig. 11. Creating coercion terms

So much for instantiation. Dually, generalisation is expressed by System-F type poly in Figure 10: abstraction, as we can see in the rules for  a = ftv (ρ) − ftv (Γ) Γ ⇑ t : ρ → e poly

Γ ⇑

t : ∀a.ρ → Λa.e

gen1

a ∈ ftv (Γ) pr (σ) = ∀a.ρ → f Γ ⇓ t : ρ → e poly

Γ ⇓

t : σ → f (Λa.e)

gen2

Rule gen1 directly introduces a type abstraction, while but gen2 needs a coercion function, just like var, to account for the prenex-form conversion. The rules for dsk prenex-form conversion, and for  , are given in in Figure 11.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

31

When reading the rules for type-directed translation, the key invariants to bear in mind are these: If this holds then so does this Γ δ t : ρ → e σ 6 ρ → e  σ1 6 σ2 → e pr (σ1 ) = σ2 → e

Γ F e : ρ F e : σ → ρ F e : σ1 → σ2 F e : σ2 → σ1

inst δ dsk

This type-directed translation also provides a semantics for our language. To determine the meaning of a term, translate it to System F and evaluate the result. Although this semantics is defined by translation, it is fairly simple and what we might expect. If we erase types in the source and target languages it is easy to verify that, except for the insertion of coercions, the translation is the identity translation. Furthermore, the coercions themselves only produce terms that, after type erasure, are eta-expansions of the identity function.

4.9 Metatheory of higher-rank type systems In this section we give formal statements of the most important properties of the type systems and subsumption relations presented so far. Again, the Technical Appendix (Vytiniotis et al., 2005) contains the proofs of the theorems in this section. We begin with properties of the various subsumption judgements in Section 4.9.1. In Section 4.9.2 we describe the precise connection between the type systems of this paper: the original Damas-Milner system, the non syntax-directed, the syntaxdirected, and the bidirectional higher-rank type system. Section 4.9.3 gives the most important properties of the bidirectional system.

4.9.1 Properties of the subsumption judgements We have now defined three different subsumption relations: sh

•  σ1 6 σ2 is the Damas-Milner shallow-subsumption relation (Figure 4), which we now extend to higher-rank types. The only difference is that the rule mono is replaced with sh

 ρ6ρ This way shallow-subsumption naturally applies to the type syntax defined in Figure 5. ol •  σ1 6 σ2 is the Odersky-L¨ aufer subsumption, defined in Figure 5. dsk •  σ1 6 σ2 refers to subsumption with deep skolemisation, defined in Figure 7. These three relations are connected in the following way: Deep skolemisation subsumption relates strictly more types than the Odersky-L¨aufer relation, which in turn relates strictly more types than the Damas-Milner relation.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

32

S. Peyton Jones et al.

Theorem 4.1 sh ol ol dsk If  σ1 6 σ2 then  σ1 6 σ2 . If  σ1 6 σ2 then  σ1 6 σ2 . dsk

The following theorem captures the essence of  prenex form.

; any type is equivalent to its

Theorem 4.2 dsk dsk  σ 6 pr (σ) and  pr (σ) 6 σ. ol

In contrast notice that only  σ 6 pr (σ). All three relations are reflexive and transitive. However, only deep skolemisation subsumption enjoys a distributivity property, that lets us distribute type quantification among the components of an arrow type: Theorem 4.3 (Distributivity) dsk  ∀a.σ1 → σ2 6 (∀a.σ1 ) → ∀a.σ2 . 4.9.2 Connections between the type systems At this point we have discussed the five type systems that appeared in the road map in Figure 1. We started with the Damas-Milner type system, and described its declarative and syntax-directed forms. We then presented an extension that supports higher-rank types, the Odersky-L¨ aufer type system, and developed a syntax directed version. Finally, we introduced the bidirectional type system, an extension of our syntax-directed version of the Odersky-L¨ aufer system. This section states the formal connections between all of these systems. The results of this section are summarised in Figure 12. In some of these results, it matters whether we are talking about Damas-Milner types and terms, or higher-rank types and terms. In the figure, dashed lines correspond to connections where we assume that the types appearing in the judgements are only Damas-Milner types and that the terms contain no type annotations. Some of the connections in this figure have already been shown. In particular the relation between the syntax-directed and the non syntax-directed Damas-Milner type system is captured by the theorem below. Theorem 4.4 ((Milner, 1978; Damas & Milner, 1982)) Suppose that t contains no type annotations and the context Γ contains only Damas-Milner types. DM poly

1. If Γ sd

DM

2. If Γ 

DM

t : σ then Γ 

t : σ. DM poly

t : σ then there is a σ such that Γ sd

sh

t : σ and  σ 6 σ.

We can show an analogous result for the higher-rank systems. We began our discussion of higher-rank polymorphism with the Odersky-Laufer type system (Section 4.5), and developed a syntax-directed version of it (Section 4.6). Recall that with the Odersky-L¨ aufer definition of subsumption, but without eager generalisation, the two type systems did not agree. There were some programs that typechecked in the original version, but did not typecheck in the syntax-directed version

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

33

Practical type inference for arbitrary-rank types

DM

Γ t :σ Damas-Milner

= 4.6

Γ nsd t : σ Higher-rank

poly

sh



Γ ⇓ t : σ Bidirectional checking

dsk



4.4 (2) =

4.5 (2) =

4.4 (1)

4.5 (1)

=

4.9

poly

DM poly

Γ sd t :σ Syntax-directed Damas-Milner

Γ ⇑ t : σ Bidirectional inference

= 4.8

= 4.7

poly

Γ sd t : σ Syntax-directed higher-rank =

4.10

Fig. 12. Relations between type systems in this paper

(Section 4.6.1). By changing the subsumption relation in the syntax-directed version to deep skolemisation, we can make it accept all of the programs accepted by the original type system. However, it turns out that the two systems are still not equivalent: the syntaxdirected system, using deep skolemisation, accepts some programs that are rejected by the original typing rules! For example, the derivation x : ∀b.Int → b  (x :: Int → ∀b.b) : Int → ∀b.b is valid in the syntax-directed version. But, because it uses deep skolemisation in checking the type annotation, there is no analogue in the original system. Fortunately, if we replace subsumption in the orginal system with deep skolemisation, the two type systems do agree. ol In what follows, let nsd refer to the typing rules of Figure 5 where the  relation dsk

has been replaced by the  rules in Figure 6.

relation. Also let Γ sd t : ρ refer to the syntax-directed

Theorem 4.5 (Agreement of nsd and sd ) poly

1. If Γ sd

t : σ then Γ nsd t : σ. poly

2. If Γ nsd t : σ then there is a σ such that Γ sd

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

dsk

t : σ and 

σ 6 σ.

34

S. Peyton Jones et al.

The first two clauses of this theorem say that if a term can be typed by the syntaxdirected system, then the non-syntax-directed system can also type it, and with the same type. The exact converse is not true; for example, in the non-syntax-directed system we have nsd \x.\y.y : ∀a.a → ∀b.b → b, but this type is not derivable poly in the syntax-directed system. Instead we have sd \x.\y.y : ∀ab.a → b → b. In general, as clause (3) says, if a term in typeable in the non-syntax-directed system, then it is also typeable in the syntax-directed system, but perhaps with a different type σ that is at least as polymorphic as the original one. Next, we show that the Odersky-L¨ aufer system is an extension of the DamasMilner system. Any term that type checks using the Damas-Milner rules, type checks DM t : σ refer to the with the same type using the Odersky-L¨aufer rules. Let Γ  Damas-Milner judgement, defined in Figure 3. Theorem 4.6 (Odersky-L¨aufer extends Damas-Milner) Suppose t contains no type annotations and the context Γ only contains DamasDM Milner types. If Γ  t : σ then Γ nsd t : σ. Likewise, our version of the Odersky-L¨aufer syntax-directed system extends the Damas-Milner syntax-directed system. Theorem 4.7 (Syntax-directed extension) Suppose t contains no type annotations and the context Γ only contains DamasDM poly

Milner types. If Γ sd

poly

t : σ then Γ sd

t : σ.

Furthermore, the bidirectional system extends the syntax-directed system. Anything that can be inferred by Figure 6 can be inferred in the bidirectional system. (The converse is not true, of course. The point of the bidirectional system is to typecheck more terms.) Theorem 4.8 (Bidirectional inference extends syntax-directed system) 1. If Γ sd t : ρ then Γ ⇑ t : ρ. poly poly 2. If Γ sd t : σ then Γ ⇑ t : σ. Checking mode extends inference mode for the bidirectional system. If we can infer a type for a term, we should be able to check that this type can be assigned to the term. Theorem 4.9 (Bidirectional checking extends inference) 1. If Γ ⇑ t : ρ then Γ ⇓ t : ρ. poly poly 2. If Γ ⇑ t : σ then Γ ⇓ t : σ. Finally, the bidirectional system is conservative over the Damas-Milner type system. If a term typechecks in the bidirectional system without any higher-rank annotations, and with a monotype, then the term type checks in the syntax-directed DM Damas-Milner system, with the same type. Let Γ sd t : τ refer to the judgement defined in Figure 4. Theorem 4.10 (Bidirectional conservative over Damas-Milner) Suppose t contains no type annotations, and Γ contains only Damas-Milner types. DM If Γ δ t : τ then Γ sd t : τ.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

35

4.9.3 Properties of the bidirectional type system The bidirectional type system, in Figure 8, is a novel contribution of this paper. Any type system must enjoy the self-consistency properties of type safety and principal types. In this section we describe these properties in more detail. The type safety theorem asserts that the type system rules out ill-behaved programs. In other words, the evaluation of any well-typed program will produce a value (or possibly diverge, if the language contains diverging terms). This theorem is proven with respect to a semantics – rules that describe how programs produce values. In Section 4.8 we defined the semantics of the bidirectional type system by translation to System F. To evaluate an expression, we translate it to System F and evaluate the System F term. System F is already known to be type safe. Therefore, to show type safety for the bidirectional type system, all we must do is show that the translation to System F produces well-typed terms. That way we know that all terms accepted by the bidirectional system will evaluate without error. In other words: Theorem 4.11 (Soundness of bidirectional system) 1. If Γ δ t : ρ → e then Γ F e : ρ. poly 2. If Γ δ t : σ → e then Γ F e : σ. The proof of this theorem relies on a number of theorems that say that the coercions produced by the subsumption judgment are well typed. The proof of these theorems is by a straightforward induction on the appropriate judgment. Theorem 4.12 (Coercion typing) 1. 2. 3. 4.

If If If If

pr (σ) = ∀a.ρ → e then F e : (∀a.ρ) → σ. dsk  σ 6 σ → e then F e : σ → σ . dsk ∗  σ 6 σ → e then F e : σ → σ . inst δ σ 6 ρ → e then F e : σ → ρ.

The bidirectional type system also has the principal types property. In other words, for all terms typable in a particular context, there is some “best” type for that term: Theorem 4.13 (Principal Types for bidirectional system) poly If there exists some σ such that Γ ⇑ t : σ , then there exists σ (the principal type of t in context Γ) such that poly

1. Γ ⇑

t :σ poly

2. For all σ , if Γ ⇑

sh

t : σ , then  σ 6 σ .

The principal types theorem is very important in practice. It means that an implementation can infer a single, principal type for each let-bound variable, that will “work” regardless of the contexts in which the variable is subsequently used. Notice that, in the second clause of the theorem, all types that are inferred for sh a given term are related by the Damas-Milner definition of subsumption,  . The sh dsk theorem holds a fortiori if  is replaced by  .

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

36

S. Peyton Jones et al.

We prove this theorem in the same way that Damas and Milner showed that their type system has principal types: by developing and algorithm that unambiguously assigns types to terms and showing that this algorithm is sound and complete with respect to the rules. The formalisation of the algorithm can be found in the Technical Appendix (Vytiniotis et al., 2005). The principal-types theorem above only deals with inference mode. An analogous version is not needed for checking mode because we know exactly what type the term should have – there is no ambiguity. And in fact, such a theorem is not true. For example, the term (\g.(g 3, g True)) typechecks in the empty context with types (∀a.a → Int) → (Int, Int) and (∀a.a → a) → (Int, Bool), but there is no type that we can assign to the term that is more general than both of these types. Even though there are no “most general” types that terms may be assigned in checking mode, checking mode still statisfies properties that make type checking predictable for programmers. For example, it is the case that if we can check a term, then we can always check it at a more specific type. The following theorem formalises this, and other, claims: Theorem 4.14 poly

dsk

dsk

2. If Γ ⇓ t : ρ1 and  Γ ⇓ t : ρ2 . poly

3. If Γ ⇓

poly

σ 6 σ then Γ ⇓

t : σ and 

1. If Γ ⇓

ρ1 6 ρ2 and ρ1 and ρ2 are in weak-prenex form, then

dsk

t : σ and  dsk

4. If Γ ⇓ t : ρ and 

t : σ .

poly

Γ 6 Γ then Γ ⇓

t : σ.

Γ 6 Γ and ρ is in weak-prenex form then Γ ⇓ t : ρ.

The first clause is self explanatory, but the second might seem a little surprising: why must ρ1 and ρ2 be in weak-prenex form? Here is a counter-example when they are not. Suppose σ1 = ∀a.a → ∀b.b → ∀c.b → c, σ2 = Int → ∀c.Int → c, and σ3 = ∀abc.a → b → b → c. Then it is derivable that ⇓ (\x .x 3) : (σ1 → σ2 ) but dsk

it is not derivable that ⇓ (\x .x 3) : (σ3 → σ2 ), although  σ1 → σ2 6 σ3 → σ2 . However, because gen2 converts the checked type into that form before continuing, poly any pair of related types may be used for the ⇓ judgement, so the first clause needs no side condition. Just as the first two clauses say that we can make the result type less polymorphic; dually, the third and fourth clauses allow us to make the context more polymorphic. dsk The notation  Γ 6 Γ means that the context Γ is point-wise more general (using dsk the relation  ) than the context Γ . We conclude our discussion of the properties of the bidirectional type system by observing that it lacks some properties of the traditional Damas-Milner system. In particular, in Damas-Milner one can always name a sub-expression using let, without affecting typeability: Γ  t1 [t2 ] : τ

implies

Γ  let x = t2 in t1 [x ]

(where x does not appear in t1 []. In the bidirectional system, however, the context

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

37

of t2 may provide type information that makes it typeable, so the let form might fail. To make it succeed, one would need to add a type signature for x .

5 Damas-Milner type inference The main claim of this paper is that a rather modest overhaul of a vanilla DamasMilner type inference engine will suffice to support arbitrary-rank polymorphism. To demonstrate this claim convincingly, we now describe how to transcribe the DamasMilner typing rules of Figure 4 into a type inference algorithm. Then, in later sections we will show how to modify this algorithm to support higher-rank polymorphism. Admittedly, the Damas-Milner inference engine is deliberately crafted so that it can readily be modified for higher-rank types – but no aspect of the former is there solely to prepare for the latter. Our implementations are written in Haskell, and we assume that the reader is familiar with Haskell including, in particular, the use of monads and do-notation. We also assume some familiarity with type inference using unification. The complete source code of our implementations is available in the Appendix, and online. 5.1 Terms and types The data type Term in Figure 13 is the representation for terms, whose syntax was given in Figure 2. The data type of types, also given in Figure 13, deserves a little more explanation. We use a single data type Type to represent σ-types, ρ-types, and τ-types, and declare type synonyms Sigma, Rho, and Tau as unchecked documentation about which particular flavour of type is expected at any particular place in the code.6 The data type Type has constructors for quantification (ForAll), functions (Fun), constants (TyCon). We maintain the invariant that the Type immediately inside a ForAll is not itself a ForAll; i.e. that it is a Rho. More interestingly, it has two different constructors for type variables, because the implementation distinguishes two kinds of type variable. Consider the syntax of Damas-Milner types: σ ::= τ ::=

∀a.τ Int | τ1 → τ2 | a

The type variable “a” is part of the concrete syntax of types: a → Int and ∀a.a → a are both legal types. On the other hand, “τ” and “σ” are meta-variables, part of the language that we use to discuss types, but not part of the language of syntax of types themselves. For example, τ → τ is not a legal type. The typing judgements for a type system (Figure 3, for example) uses both kinds of variables. It uses “a” to mean “a type variable”, and “τ” to mean “some type obeying the syntax of τ-types”. This distinction is reflected in two distinct data types of the implementation: 6

This tension between static and dynamic checks is a common one when writing software. The reader is invited to try stratifying the implementation, and compare the result with the version we present here.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

38

S. Peyton Jones et al.

---------------- Terms ------------------data Term = Var Name -- x | Lit Int -- 3 | App Term Term -- f x | Lam Name Term -- \x. x | Let Name Term Term -- let x = f y in x+1 | Ann Term Sigma -- f x :: Int type Name = String ---------------- Types ------------------type Sigma = Type type Rho = Type -- No top-level ForAll type Tau = Type -- No ForAlls anywhere data Type = | | | |

ForAll Fun TyCon TyVar MetaTv

[TyVar] Rho Type Type TyCon TyVar MetaTv

data TyVar = BoundTv String

------

Forall type Function type Type constants Always bound by a ForAll A meta type variable

-- A type variable bound by a ForAll

| SkolemTv String Uniq

-- A skolem constant; the String is -- just to improve error messages

data TyCon = IntT | BoolT (-->) :: Type -> Type-> Type arg --> res = Fun arg res

-- Build a function type

intType :: Tau intType = TyCon IntT Fig. 13. The Term and Type data types.

A concrete type variable, written a, b etc., has type TyVar and occurs with constructor TyVar in a Type. data TyVar = BoundTv String | SkolemTv String Uniq type Uniq = Int There are two kinds of concrete type variables, corresponding to the two constructors of TyVar. • A bound type variable, whose constructor is BoundTv, is always bound by an enclosing ForAll; it may appear in (the type annotations of) a source program; and it is represented by a simple String. No well-formed Type ever has a free BoundTv. • A skolem constant, whose constructor is SkolemTv, stands for a constant, but unknown type. It is never bound by a ForAll, and it can be free in a Type.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types -- Control flow check :: Bool -> String -> Tc () -- The type environment lookupVar :: Name -> Tc Sigma extendVarEnv :: Name -> Sigma -> Tc a -> Tc a getEnvTypes :: Tc [Sigma]

39

-- Type inference can fail

-- Look up in the envt (may fail) -- Extend the envt -- Get all types in the envt

-- Instantiation, skolemisation, quantification instantiate :: Sigma -> Tc Rho skolemise :: Sigma -> Tc ([TyVar], Rho) quantify :: [MetaTv] -> Rho -> Tc Sigma -- Unification and fresh type variables newMetaTyVar :: Tc Tau -- Make (MetaTv tv), where tv is fresh newSkolemTyVar :: Tc TyVar -- Make a fresh skolem TyVar unify :: Tau -> Tau -> Tc () -- Unification (may fail) -- Free type variables getMetaTyVars :: [Type] -> Tc [MetaTv] getFreeTyVars :: [Type] -> Tc [TyVar] Fig. 14. The TcMonad module.

It is represented by a Uniq, a unique integer that distinguishes it from others; the String is just for documentation. A meta type variable, written τ1 , τ2 etc.7 , is simply a temporary place-holder for an as-yet-unknown monotype. It has type MetaTv, and occurs with constructor MetaTv in a Type. data MetaTv = Meta Uniq TyRef It is never quantified by a ForAll (∀τ.τ would not make sense!); and it is created only by the type inference engine itself. Again we use a Uniq to give its identity; we will discuss the TyRef part later, in Section 5.7. Although we give the representation of types here, for the sake of concreteness, much of the type inference engine is independent of the details of the representation. The infix function (-->) helps to maintain this abstraction, by allowing the inference engine to construct a function type without knowing how it is represented internally. Similarly intType is the Type representing the type Int. 5.2 The type-checker monad The type constructor Tc is the type-checker monad, whose primitive operations are given in Figure 14. The monad serves the following roles: 7

It turns out that the implementation does not require a representation for the meta-variable σ.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

40

S. Peyton Jones et al. • • • •

It supports exceptions, when type inference fails (check). It carries the environment Γ (lookupVar and extendVarEnv). It allocates fresh meta type variables (newMetaTv). It maintains a global, ever-growing substitution that supports unification (unify).

The function check (Figure 14) is typically used in a context like this do { ... ; check (..condition..) "Error message" ; ... } It checks its boolean argument; if it is True, check returns (); but if it is False, check raises an exception in the monad, passing the specified string as an error message. Environment extension (extendVarEnv) is scoped, not a side effect. There is no need to restore the old environment after a call to extendVarEnv. For example, one might write: do { ... ; extendVarEnv "x" ty (do { ...; t intType) will fail. The monad handles the propagation of such failures behind the scenes. We will introduce the remaining functions in Section 5.5. 5.3 Simple inference Figure 4 expresses the Damas-Milner type system in syntax-directed form, which is crucial for eliminating search in type inference. When expressed in this way the rules are tantamount to an algorithm. For each judgement form we have a corresponding Haskell function; for example:  poly  sh 

inferRho inferSigma subsCheck

:: Term -> Tc Rho :: Term -> Tc Sigma :: Type -> Type -> Tc ()

We begin by looking at inferRho, derived from . Its simplest rule is int, and its translation is trivial: inferRho (Lit i) = return intType The return is necessary to lift intType into the Tc monad. The rule for applications (app) is a little more interesting:

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types inferRho = do { ; ; ; ;

41

(App fun arg) fun_ty Bool and we perform type inference on the application f (\x.True). The inference engine will infer the type a -> Bool for the argument (\x.True), and then it will attempt the following unification: ((Int -> Int) -> Bool) = ((a -> Bool) -> r) The unification will fail, but with a rather opaque error message. No human would do this when doing mental type inference. We know the type of f, and we use that information when performing inference on f’s argument. This simple intuition leads to a very well-known technique for improving the error messages, namely to propagate the expected type inwards. More concretely, we make a variant of inferRho, called checkRho, thus: checkRho :: Term -> Rho -> Tc () Instead of returning the inferred type as its result, checkRho now takes the expected type as an argument. We can recover the old inferRho by passing in a type variable: inferRho :: Term -> Tc Rho inferRho expr = do { exp_ty IO (Either ErrMsg a)) Throughout, we maintain the following invariant: A meta type variable can only be substituted by a τ-type.

11

12

See Peyton Jones (2001) for a tutorial on the IO monad. We could also have used the ST state transformer monad, since we are not performing any input/output. However, in real life the type checker does perform some limited I/O, mainly to consult interface files of imported modules, so we have used the IO monad here. The latter could be done via an exception in the IO monad, but we have elected to make failure more explicit here.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

47

This invariant is absolutely crucial. For example, suppose f :: τ, where τ is a meta type variable. If we see the expression (f ’c’, f True), we will first unify τ with Char → τ1 and then with Bool → τ2 , and will fail with a type error. But if τ were allowed to be unifiable with ∀b.b → b – that is, if the meta type variables were really σ variables – this failure would have been premature. (Le Botlan et al. deal with this issue by using a constraint system to collect the required instantiations of the type variables; see Section 9.2.) Similarly, if subsCheck (Section 5.6) is passed two type variables as its arguments, it will simply unify them. But if a different order of type inference first unified those type variables with polytypes, the call to subsCheck would need to do a full subsumption check rather than simple unification. In short, the invariant that a meta type variable can only be substituted by a τ-type ensures that the result of type inference does not depend on the order of type-inference. The invariant is, in turn, a direct consequence of predicativity (Section 3.4). 6 Inference for higher rank Having now completed type inference for Damas-Milner, we are ready to extend the type-inference engine for higher-rank types. 6.1 Changes to the basic structure In moving to higher rank, we first add a new constructor to the Term data type, ALam for an annotated lambda: data Term = ... | ALam Name Sigma Term The data type of types remains unchanged. Next, we consider the main judgement . At first it seems that we might need two tcRho functions, one for each direction: inferRho :: Term -> Tc Rho checkRho :: Term -> Rho -> Tc () Doing this would be very burdensome, because when we scale to a real language tcRho will have many, many equations. Much more attractive is to exploit the symmetry implied by the many syntactic forms for which Figure 8 has only one “polymorphic” rule, mentioning δ. Here is a neat way to express this idea in code: tcRho :: Term -> Expected Rho -> Tc () data Expected t = Check t | Infer (IORef t) When checking that an expression has a particular type ty (the ⇓ direction) we pass (Check ty) as the second parameter, in exactly the way that we discussed in Section 5.4. When inferring the type of an expression (the ⇑ direction) we pass (Infer ref) as the second parameter, expecting tcRho to return the result type

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

48

S. Peyton Jones et al.

by writing to the reference ref. This corresponds exactly to the common technique of passing as a parameter the address of the result location – a var parameter, in Pascal terminology. Unlike the reference cells in a MetaTv, which can be instantiated only to a τ-type, the reference cell in an Expected Rho can (indeed must) be filled in by a ρ-type; and we will later encounter tcPat which takes an Expected Sigma argument, which must be filled in by a σ-type. There is no difficulty here, because these Expected locations are always written exactly once – there is no question of unification. On the other hand, we continue to maintain the previous invariant, that a meta type variable can only be bound to a τ-type, for the reasons discussed in Section 5.7. As in the Damas-Milner case, we will write a Haskell function for each judgement form: δ poly ⇑ poly ⇓ inst δ dsk  dsk ∗ 

tcRho inferSigma checkSigma instSigma subsCheck subsCheckRho

:: :: :: :: :: ::

Term → Expected Rho -> Tc () Term -> Tc Sigma Term -> Sigma -> Tc () Sigma -> Expected Rho -> Tc () Sigma -> Sigma -> Tc () Sigma -> Rho -> Tc ()

We can write immediately inferRho and checkRho in terms of tcRho: checkRho :: Term -> Rho -> Tc () checkRho expr ty = tcRho expr (Check ty) inferRho :: Term -> Tc Rho inferRho expr = do { ref Tc () instSigma t1 (Infer r) = do { t1’ m b) -> [a] -> m [b]

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

59

Practical type inference for arbitrary-rank types

polymorphic than [Int → Int]. One might argue that it should certainly be so, but there are complications. First, in general, the direction of the relationship depends on the variance of the type parameter – consider types like data Contra a = Contra (a -> Int) Here, Contra (Int → Int) would be more, rather than less, polymorphic than Contra (∀a.a → a). The situation gets more complicated when there are multiple type arguments, when a type argument appears several times on the right-hand side, or when a type argument does not appear at all on the right-hand side (socalled phantom types). Second, if the system does type-directed translation (which we discuss in Section 4.8), one would actually need to traverse the entire list at runtime, coercing each function in the list from type (∀a.a → a) to (Int → Int). List traversal is a rather expensive operation to happen “behind the scenes” as a result of type inference. Still, one can make a case for special treatment for tuples, which are ubiquitous in functional programs, and allow them to have polymorphic components. Tuples are all co-variant, of course, and they come with special syntax for construction and pattern-matching. So a possible syntax for types could be this: Polytypes Rho-types Monotypes

σ ::= ρ ::= τ ::=

∀a.ρ σ1 → σ2 | (σ1 , . . . , σn ) | τ τ1 → τ2 | (τ1 , . . . , τn ) | K τ | a

so that types like (∀a.a → a, Int) would be legal. Along with this would come special typing judgements for tuples: Γ ⇑ ti : ρi

(1 6 i 6 n)

Γ ⇑ (t1 , . . . , tn ) : (ρ1 , . . . , ρn )

tup1

Γ ⇓ ti : σi

(1 6 i 6 n)

Γ ⇓ (t1 , . . . , tn ) : (σ1 , . . . , σn )

tup2

There would be similar extra typing judgements for patterns. Lastly, one could add an extra case to the subsumption judgement: dsk



dsk



σi 6 σi

(1 6 i 6 n)

(σ1 , . . . , σn ) 6 (σ1 , . . . , σn )

tuple

These new typing rules lead directly to new cases in the implementation. These extensions would allow one to construct, pass around, and pattern-match tuples with polymorphic components. However, a function such as fst :: ∀ab.(a, b) → a can still only be used predicatively, because it is an ordinary polymorphic function. For example, the application fst (id :: ∀a.a → a, Int) would be rejected. Still, the situation is no different with higher rank functions (one cannot apply map to a higher-rank function, for the same reason), so perhaps it is acceptable. GHC does not currently implement the impredicative-tuple extension, so we do not have any concrete experience to report on this question.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

60

S. Peyton Jones et al. 8 Type-directed translation

In Section 4.8 we showed how to incorporate a type-directed translation into the typing rules of the language. We now briefly discuss the following question: how can we adapt our type inference engine so that it performs type-directed translation at the same time as type inference? Fortunately, the answer is very straightforward. First, we must add type abstraction and application to the Term data type: data Term = ... | TyLam Name Term | TyApp Term Tau

-- Type abstraction -- Type application

The extra constructors are only used in the output of type inference, not the input. Notice that the argument of a type application is a τ-type; remember that the system is predicative. Next, we need to adjust the type of tcRho to return a translated term: tcRho :: Term -> Expected Rho -> Tc Term where the returned Term has all the type abstractions and applications that are implicit in the source term. Similarly, checkRho, inferRho, and tcPat all return translated terms and patterns respectively. For the most part, the changes are routine. For example, the code for lambdas becomes: tcRho (Lam pat body) (Check exp_ty) = do { (pat_ty, body_ty) Tc (Term -> Term) subsCheckRR t1 (Fun a2 r2) = do { (a1,r1) Rho -> Sigma -> Rho -> Tc (Term -> Term) r1 a2 r2 Int). \x. t (t x)) :: (∀a.a → a) → Int → Int This is well-typed in our system. The outer type signature gives a rather restrictive type to f, requiring f to be applied to a polymorphic argument, but the signature on t is more generous: any Int->Int function will do. When type-checking the pattern (t::Int->Int), the call to subsCheck inside checkPat (Section 6.3) will generate a non-trivial coercion, which must be recorded in the translated pattern. GHC does exactly this, and uses the coercions, recorded in the pattern, during the desugaring of nested pattern-matching, subsequent to type inference. Again, we omit the details. 8.3 Type classes One of Haskell’s most distinctive features is its type class system. Again, it turns out that the type inference engine we have described extends smoothly to embrace type classes, including their (non-trivial) type-directed translation. All that is needed is a mechanism to gather type constraints, which can conveniently be handled by the Tc monad, a constraint solver (which is entirely new), and a way to record the solution in the translated term (which works in much the same way as the typedirected translation we have already seen). We have found the mechanism required to support type classes in a non-higher-rank system (such as Haskell 98) requires virtually no change to support higher rank types; in that sense, the two features are almost entirely orthogonal. 8.4 Summary In this section we have briefly sketched how the type inference engine can be extended to support type-directed translation, including that required by Haskell’s type classes. We have only given sketchy details, for reasons of space, but GHC uses precisely the scheme we sketch, so we know that it scales up without difficulty.

9 Related work In this section we discuss how our work fits into the wider context of research in type inference algorithms. 9.1 Finite-rank fragments of System F System F is a very well-studied language whose type system is impredicative, and has arbitrary-rank types (Girard, 1990). It is extremely expressive: indeed, we take System F as the “gold standard” for expressiveness, to which we aspire. From a programming point of view, however, System F is extremely verbose and burdensome

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

63

to write, because it is explicitly typed. Here is an example: Λa. λ(g : ∀b.b → a). (g [Char] ’x’, g [Bool] True) Every binder must be annotated with its type (e.g. (g : ∀b.b → a)). Furthermore, the terms must include explicit type abstractions and type applications – the forms Λa.e and e [σ] respectively. Many people have studied the question: if we erased from System F all the type abstractions, type applications, and binder annotations, could they be reconstructed by type inference? The answer is a definite “no”. Even the question “is any type at all derivable for this expression” is undecidable (Wells, 1999). Well, then, perhaps there is a useful subset of System F for which we can perform type inference? This question has been studied by stratifying System F by rank; the rank-K subset of System F consists of all expressions that can be typed using types of rank 6 K . Kfoury and Wells show that typeability is decidable for rank 6 2, and undecidable for all ranks > 3 (Kfoury & Wells, 1994). For the rank-2 fragment, the same paper gives a type inference algorithm. This inference algorithm is somewhat subtle, does not interact well with user-supplied type annotations, and has not, to our knowledge, been implemented in a production compiler. All of these results are for the standard, impredicative, System F. We do not know of analogous results for the predicative fragment of System F.

9.2 MLF A big disadvantage of the Kfoury/Wells approach is that the finite-rank fragments of System F do not have principal types. Given a typeable expression, their inference algorithm will find a type for it, but it cannot guarantee to find a principal type – that is, one that is more general than any other derivable type for the same expression. This is a serious problem in practice, where we want to infer the type of a function and expect that type to be compatible with all possible call sites for that function. This desire is especially pressing when we want to support separate compilation with stable interfaces. Recently, Le Botlan and R´emy – building on previous work by Garrigue and R´emy on extending ML with semi-explicit first-class polymorphism (Garrigue & Remy, 1999) – have described a new and ingenious type system, MLF , which supports the impredicative polymorphism of System F while retaining principal types (Le Botlan & Rmy, 2003). They achieve this remarkable rapprochement using a form of constrained polymorphism, with a constraint domain very reminiscent of Huet’s classic higher-order unification algorithm (Huet, 2002). Hence their system is actually more expressive than System F. Like us, they do not attempt to infer higher-ranked polymorphism, and instead accept that the programmer will have to guide the type system using annotations. Also like us, every program typeable by Damas-Milner can be typed in MLF without any annotations at all. Though not described in their paper, they also suggest that annotations may be propagated as we have described here.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

64

S. Peyton Jones et al.

However, unlike us, they allow type variables to be instantiated to type schemes. Furthermore, their type system can discover an appropriate instantiation without the aid of any annotations, at least for arguments which are simply “passed through” functions. Additionally, MLF only supports covariant instantiation of type schemes. The price they pay for these remarkable results is a somewhat complicated type system. The constraints require that higher-ranked types be encoded in a form which makes manifest any potential sharing of type variables. The programmer must perform this encoding, and be prepared to interpret the type schemes and constraints which come back from type inference and type errors. On the other hand, even more recent work (Leijen & Lh, 2005) indicates that this complexity eventually may not be daunting. Overall, we can say MLF supports impredicativity but with a somewhat more indirect approach to higher-ranked types and a more sophisticated inference algorithm, while our system supports higher-ranked types directly and has a simple inference algorithm, but without support for impredicativity. Is the additional power of impredicativity worth the extra complexity? We have found it hard to find convincing examples that require impredicativity – but a few years ago no one thought much about higher-ranked types either. At least we can observe that there is a potential cost/benefit trade-off to be made, with our system and MLF occupying interestingly different points on the design spectrum. 9.3 Type inference in general Considering how many papers there are on type systems, there is surprising little literature on type inference that is aimed unambiguously at implementors. Cardelli’s paper was the first widely-read tutorial (Cardelli, 1987), with Hancock’s tutorial shortly afterwards (Hancock, 1987). More recently Mark Jones’s paper “Typing Haskell in Haskell” gave an executable implementation of Haskell’s type system (Jones, 1999). Apart from the higher-rank aspect, the distinguishing feature of our presentation is the pervasive use of a monad to structure the type inference engine, and the use of the Expected Rho argument to represent the bidirectional nature of local type inference. 9.4 Partial type inference The idea of employing type annotations written by the programmer to guide type inference is well known. Pierce and Turner call it partial type inference 15 in their influential paper (1998): “the job of a partial type inference algorithm should be to eliminate especially those type annotations that are both common and silly, i.e. those that can neither be justified on the basis of their value as checked documentation, nor ignored because they are rare”. Their paper presents a particular instantiation of partial type inference, which they call local type inference, to which our work has many similarities. They employ 15

“Partial” in the sense that not every program that can be typed will be accepted by the inference algorithm, rather than in the sense that type inference may diverge.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

65

the idea of pushing types inward to reduce the annotation burden; and we adopted their presentation of the type system using two judgements (one for inference and one for checking). However, the focus of their work is on type systems that allow sub-typing, such as System F6 . Even inferring type arguments (which is relatively simple in our work) then becomes tricky! These difficulties led them to a “fully un-curried” style of function application and abstraction, which is not necessary for us, as well as an interesting constraint solver that we do not need. Furthermore, in their system, no type can be inferred for a lambda abstraction, unless its binder is annotated; that is, they lack a rule like abs2 from Figure 8. One shortcoming of local type inference is that it only pushes completely known types inwards. For example, suppose g has type ∀a.(Int → a) → a, and consider the definition foo w = bar (\x. x+w) Since the call to bar is instantiated at some unknown type α, local type inference will not push the partially-known type Int → α into the argument of bar, and the program will be rejected. Odersky, Zenger and Zenger developed a more sophisticated scheme, called coloured local type inference, that is capable of propagating partial, as well as total, type information down the tree (Odersky et al., 2001). In effect, local type inference uses ⇑ and ⇓ in judgements, whereas coloured local type inference goes further and pushes ⇑ and ⇓ into types as well. The system is, however, rather complex. Coloured type inference was, like local type inference, originally developed in the context of a sub-typing system. It is possible that it could be adapted for the higherrank setting, but we have not yet attempted to do so, because we have not found motivating examples that are untypeable without it. For example, our system has no difficulty with the funcction foo above, simply because we are not concerned with sub-typing. For us it is simple to pass partial information downwards, by passing (Check t) as the Expected Rho parameter to the inference engine, where t is a type with unbound meta type variables. On the other hand, being able to pass in partial type information could still be useful: notably, in Section 4.7 we discussed the information-loss of rule app in Figure 8. An important point of our bidirectional system is that the types of terms may be determined with the help of user annotations that are not “on” the terms themselves, but maybe further away. A different approach to partial type inference, as suggested by R´emy (Rmy, 2005), is to introduce an elaboration phase prior to the actual type inference. During the elaboration phase, bidirectional propagation of user annotations determines the polymorphic shapes of terms. Shapes capture polymorphic information that cannot be inferred and originates in annotations. During elaboration monomorphic information is kept abstract. However at the end of the elaboration phase, each term need only be checked against its polymorphic shape – and the monomorphic type information can be inferred with a unificationbased mechanism. Additionally, in his paper Remy discusses the predicative fragment of System F and System F closed under η-expansion, and describes the necessary changes if side-effects are to be added.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

66

S. Peyton Jones et al. 9.5 Deep skolemisation subsumption

It turns out that our deep skolemisation relation corresponds to the predicative η restriction of a subsumption relation (denoted with  σ1 6 σ2 ) originally proposed by Mitchell (Mitchell, 1988). Theorem 9.1 dsk  σ1 6 σ2 if and only if

η

 σ1 6 σ2 .

Mitchell’s original relation, also referred to as Mitchell’s containment relation, is used in type inference for the System F language, closed under η-expansion. The impredicative version of this relation was shown to be undecidable (Tiuryn & Urzyczyn, 1996). Mitchell’s containment was originally presented in a declarative style; syntax-directed presentations of containment are also well known (Tiuryn, 2001; Longo et al., 1995). In particular, Longo et al. (1995) employ an idea similar to our deep skolemisation. To the best of our knowledge, no one had previously considered whether the predicative variant of the containment relation was decidable, although it is not a hard problem; our algorithm in Figure 7 shows that it is decidable. 9.6 Improving error messages Historically, the most common approach to inference for ML-style type systems, is the “top-down, left-right” approach, called Algorithm W (Damas & Milner, 1982), which we introduced in Section 5.3. One big improvement is to use the “pushing types inwards” trick that we have used extensively in this paper (Section 5.4). For a long time this idea was folk lore, but its properties are studied by Lee and Yi (1998), where it is called Algorithm M. This approach is a “cheap and cheerful” approach to improving error messages: it is simple to implement, gives a big improvement in most cases, and rewards the programmer for supplying type signatures, but it does not guarantee an improvement. The trouble is that even Algorithm M has a left-to-right bias. For example: f ys = head ys && ys The uses of ys cannot both be correct – because the first implies that ys is a list, while the second implies that it is a boolean – but which is wrong? The left-toright algorithm arbitrarily reports the second as an error, because when processing head ys it refines the type of ys to [τ], for some unknown, meta type τ. A more principled alternative is to remove the arbitrary left-to-right order. Instead of incrementally solving the typing constraints by unification, get the inference algorithm to return a set of constraints, and solve them all together. Each constraint can carry a location to say which source location gave rise to it, so the error message can say “these two uses of ys are incompatible”, rather than “the second use is wrong” or “the first use is wrong”. Apart from generating better error messages, this approach scales better to richer type systems where the constraints are more complicated than simple equalities – for example, subtype constraints, or Haskell’s class constraints. See Pottier and R´emy (2004) for a rather detailed treatment of this idea, which is also the basis for Helium’s type checker (Heeren et al., 2003).

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

67

Incidentally, it should be fairly easy to adapt the type inference engine in this paper to use the constraint-gathering approach. The Tc monad could carry an updatable bag of constraints; calls to unify would simply add a constraint to the bag, rather than solving the constraint immediately; and the constraint solver would be triggered by a call to getFreeTyVars or getMetaTyVars. In short, almost all of the necessary changes could be hidden in the implementation of the monadic primitives of Figure 14. 10 Summary This is a long paper, but it has a simple conclusion: higher-rank types are definitely useful, occasionally indispensable, and much easier to implement than one might guess. Every language should have them! Acknowlegements We would like to thank a number of people have given us extremely helpful feedback about earlier drafts of this paper: Umut Acar, Arthur Baars, Pal-Kristian Engstad, Matt Hellige, Dean Herrington, Ian Lynagh, Greg Morrisett, Amr Sabry, Yanling Wang, Keith Wansbrough, Geoffrey Washburn, Joe Wells, and Carl Witty. We are particularly indebted to Andres L¨ oh, Franc¸ois Pottier, Josef Svenningsson, Norman Ramsey and his students, and the JFP referees, for their detailed and insightful comments. A Appendix In the Appendix we give the complete code for the higher-rank type-inference engine. A.1 Type inference module TcTerm where import import import import import

BasicTypes Data.IORef TcMonad List( (\\) ) Text.PrettyPrint.HughesPJ

------------------------------------------The top-level wrapper ------------------------------------------typecheck :: Term -> Tc Sigma typecheck e = do { ty Rho -> Tc () -- Invariant: the Rho is always in weak-prenex form checkRho expr ty = tcRho expr (Check ty) inferRho inferRho = do { ; ;

:: Term -> Tc Rho expr ref Expected Rho -> Tc () if the second argument is (Check rho), then rho is in weak-prenex form exp_ty intType exp_ty

tcRho (Var v) exp_ty = do { v_sigma >= k = Tc (\env -> do { r1 return (Left err) Right v -> unTc (k v) env }) failTc :: Doc -> Tc a -- Fail unconditionally failTc d = fail (docToString d) check :: Bool -> Doc -> Tc () check True _ = return () check False d = failTc d runTc :: [(Name,Sigma)] -> Tc a -> IO (Either ErrMsg a) -- Run type-check, given an initial environment runTc binds (Tc tc) = do { ref Tc a -- Lift a state transformer action into the typechecker monad -- ignores the environment and always succeeds lift st = Tc (\_env -> do { r Tc (IORef a) newTcRef v = lift (newIORef v) readTcRef :: IORef a -> Tc a readTcRef r = lift (readIORef r) writeTcRef :: IORef a -> a -> Tc () writeTcRef r v = lift (writeIORef r v) --------------------------------------------------Dealing with the type environment --------------------------------------------------extendVarEnv :: Name -> Sigma -> Tc a -> Tc a extendVarEnv var ty (Tc m) = Tc (\env -> m (extend env)) where extend env = env { var_env = Map.insert var ty (var_env env) }

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

71

72

S. Peyton Jones et al.

getEnv :: Tc (Map.Map Name Sigma) getEnv = Tc (\ env -> return (Right (var_env env))) lookupVar :: Name -> Tc Sigma -- May fail lookupVar n = do { env return ty Nothing -> failTc (text "Not in scope:" quotes (pprName n)) } --------------------------------------------------Creating, reading, writing MetaTvs --------------------------------------------------newTyVarTy :: Tc Tau newTyVarTy = do { tv Tc () writeTv (Meta _ ref) ty = writeTcRef ref (Just ty) newUnique :: Tc Uniq newUnique = Tc (\ (TcEnv {uniqs = ref}) -> do { uniq Tc Rho -- Instantiate the topmost for-alls of the argument type -- with flexible type variables instantiate (ForAll tvs ty) = do { tvs’ newMetaTyVar) tvs ; return (substTy tvs (map MetaTv tvs’) ty) } instantiate ty = return ty

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

73

skolemise :: Sigma -> Tc ([TyVar], Rho) -- Performs deep skolemisation, retuning the -- skolem constants and the skolemised type skolemise (ForAll tvs ty) -- Rule PRPOLY = do { sks1 writeTv tv1 ty2 } unifyUnboundVar tv1 ty2 = do { tvs2 Tc (Sigma, Rho) -(arg,res) res)’ unifyFun (Fun arg res) = return (arg,res) unifyFun tau = do { arg_ty Tau -> Tc () -- Raise an occurs-check error occursCheckErr tv ty = failTc (text "Occurs check for" quotes (ppr tv) text "in:" ppr ty) badType :: Tau -> Bool -- Tells which types should never be encountered during unification badType (TyVar (BoundTv _)) = True badType _ = False

A.3 Basic types module BasicTypes where -- This module defines the basic types used by the type checker -- Everything defined in here is exported

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

75

76 import import import import

S. Peyton Jones et al. Text.PrettyPrint.HughesPJ Data.IORef List( nub ) Maybe( fromMaybe )

infixr 4 --> infixl 4 ‘App‘

-- The arrow type constructor -- Application

-----------------------------------Ubiquitous types -----------------------------------type Name = String

-- Names are very simple

-----------------------------------Expressions ------------------------------------data Term = Var Name -| Lit Int -| App Term Term -| Lam Name Term -| ALam Name Sigma Term -| Let Name Term Term -| Ann Term Sigma -atomicTerm atomicTerm atomicTerm atomicTerm

:: Term (Var _) (Lit _) _

Examples below x 3 f x \ x -> x \ x -> x let x = f y in x+1 (f x) :: Int

-> Bool = True = True = False

-----------------------------------Types -----------------------------------type Sigma = Type type Rho = Type type Tau = Type

-- No top-level ForAll -- No ForAlls anywhere

data Type = ForAll [TyVar] Rho | Fun Type Type | TyCon TyCon | TyVar TyVar | MetaTv MetaTv data TyVar = BoundTv String | SkolemTv String Uniq

data MetaTv = Meta Uniq TyRef

-- Forall type -- Function type -- Type constants -- Always bound by a ForAll -- A meta type variable

-- A type variable bound by a ForAll -- A skolem constant; the String is -- just to improve error messages -- Can unify with any tau-type

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types type TyRef = IORef (Maybe Tau) -- ’Nothing’ means the type variable is not substituted -- ’Just ty’ means it has been substituted by ’ty’ instance Eq MetaTv where (Meta u1 _) == (Meta u2 _) = u1 == u2 instance Eq TyVar where (BoundTv s1) == (BoundTv s2) = s1 == s2 (SkolemTv _ u1) == (SkolemTv _ u2) = u1 == u2 type Uniq = Int data TyCon = IntT | BoolT deriving( Eq ) ---------------------------------Constructors (-->) :: Sigma -> Sigma -> Sigma arg --> res = Fun arg res intType, boolType :: Tau intType = TyCon IntT boolType = TyCon BoolT ---------------------------------Free and bound variables metaTvs :: [Type] -> [MetaTv] -- Get the MetaTvs from a type; no duplicates in result metaTvs tys = foldr go [] tys where go (MetaTv tv) acc | tv ‘elem‘ acc = acc | otherwise = tv : acc go (TyVar _) acc = acc go (TyCon _) acc = acc go (Fun arg res) acc = go arg (go res acc) go (ForAll _ ty) acc = go ty acc -- ForAll binds TyVars only freeTyVars :: [Type] -> [TyVar] -- Get the free TyVars from a type; no duplicates in result freeTyVars tys = foldr (go []) [] tys where go :: [TyVar] -- Ignore occurrences of bound type variables -> Type -- Type to look at -> [TyVar] -- Accumulates result -> [TyVar] go bound (TyVar tv) acc | tv ‘elem‘ bound = acc | tv ‘elem‘ acc = acc | otherwise = tv : acc

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

77

78

S. Peyton Jones et al. go go go go

bound bound bound bound

(MetaTv _) (TyCon _) (Fun arg res) (ForAll tvs ty)

acc acc acc acc

= = = =

acc acc go bound arg (go bound res acc) go (tvs ++ bound) ty acc

tyVarBndrs :: Rho -> [TyVar] -- Get all the binders used in ForAlls in the type, so that -- when quantifying an outer for-all we can avoid these inner ones tyVarBndrs ty = nub (bndrs ty) where bndrs (ForAll tvs body) = tvs ++ bndrs body bndrs (Fun arg res) = bndrs arg ++ bndrs res bndrs _ = [] tyVarName :: TyVar -> String tyVarName (BoundTv n) = n tyVarName (SkolemTv n _) = n ---------------------------------Substitution type Env = [(TyVar, Tau)] substTy :: [TyVar] -> [Type] -> Type -> Type -- Replace the specified quantified type variables by -- given meta type variables -- No worries about capture, because the two kinds of type -- variable are distinct substTy tvs tys ty = subst_ty (tvs ‘zip‘ tys) ty subst_ty subst_ty subst_ty subst_ty subst_ty subst_ty where env’

:: Env -> Type -> Type env (Fun arg res) = Fun (subst_ty env arg) (subst_ty env res) env (TyVar n) = fromMaybe (TyVar n) (lookup n env) env (MetaTv tv) = MetaTv tv env (TyCon tc) = TyCon tc env (ForAll ns rho) = ForAll ns (subst_ty env’ rho) = [(n,ty’) | (n,ty’) Doc docToString :: Doc -> String docToString = render dcolon, dot :: Doc dcolon = text "::" dot = char ’.’

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types -------------- Pretty-printing terms --------------------instance Outputable Term where ppr (Var n) = pprName n ppr (Lit i) = int i ppr (App e1 e2) = pprApp (App e1 e2) ppr (Lam v e) = sep [char ’\\’ pprName v text ".", ppr e] ppr (ALam v t e) = sep [char ’\\’ parens (pprName v dcolon ppr t) text ".", ppr e] ppr (Let v rhs b) = sep [text "let {", nest 2 (pprName v equals ppr rhs char ’}’) , text "in", ppr b] ppr (Ann e ty) = pprParendTerm e dcolon pprParendType ty instance Show Term where show t = docToString (ppr t) pprParendTerm :: Term -> Doc pprParendTerm e | atomicTerm e = ppr e | otherwise = parens (ppr e) pprApp :: Term -> Doc pprApp e = go e [] where go (App e1 e2) es = go e1 (e2:es) go e’ es = pprParendTerm e’ sep (map pprParendTerm es) pprName :: Name -> Doc pprName n = text n

-------------- Pretty-printing types --------------------instance Outputable Type where ppr ty = pprType topPrec ty instance Outputable MetaTv where ppr (Meta u _) = text "$" int u instance Outputable TyVar where ppr (BoundTv n) = text n ppr (SkolemTv n u) = text n int u instance Show Type where show t = docToString (ppr t) type Precedence = Int topPrec, arrPrec, tcPrec, atomicPrec :: Precedence topPrec = 0 -- Top-level precedence arrPrec = 1 -- Precedence of (a->b)

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

79

80

S. Peyton Jones et al.

tcPrec = 2 atomicPrec = 3 precType precType precType precType

-- Precedence of (T a b) -- Precedence of t

:: Type -> Precedence (ForAll _ _) = topPrec (Fun _ _) = arrPrec _ = atomicPrec -- All the types are be atomic

pprParendType :: Type -> Doc pprParendType ty = pprType tcPrec ty

pprType :: Precedence -> Type -> Doc -- Print with parens if precedence arg > precedence of type itself pprType p ty | p >= precType ty = parens (ppr_type ty) | otherwise = ppr_type ty ppr_type :: Type -> Doc -- No parens ppr_type (ForAll ns ty) = sep [text "forall" hsep (map ppr ns) dot, ppr ty] ppr_type (Fun arg res) = sep [pprType arrPrec arg text "->", pprType (arrPrec-1) res] ppr_type (TyCon tc) = ppr_tc tc ppr_type (TyVar n) = ppr n ppr_type (MetaTv tv) = ppr tv ppr_tc :: TyCon -> Doc ppr_tc IntT = text "Int" ppr_tc BoolT = text "Bool"

References Baars, Arthur L, & Swierstra, S. Doaitse. (2002). Typing dynamic typing. Pages 157– 166 of: ACM SIGPLAN International Conference on Functional Programming (ICFP’02). Pittsburgh: ACM. Bird, Richard, & Paterson, Ross. (1999). De Bruijn notation as a nested datatype. Journal of Functional Programming, 9(1), 77–91. Cardelli, L. (1987). Basic polymorphic typechecking. Science of Computer Programming, 8(2), 147–172. Clement, D, Despeyroux, J, Despeyroux, T, & Kahn, G. (1986). A simple applicative language: Mini-ML. Pages 13–27 of: ACM Symposium on Lisp and Functional Programming. ACM. Damas, Luis, & Milner, Robin. (1982). Principal type-schemes for functional programs. Pages 207–12 of: Conference record of the 9th annual acm symposium on principles of programming languages. New York: ACM Press. Garrigue, Jacques, & Remy, Didier. (1999). Semi-explicit first-class polymorphism for ML. Journal of information and computation, 155, 134–169. Gill, A, Launchbury, J, & Peyton Jones, SL. (1993). A short cut to deforestation. Pages 223– 232 of: ACM Conference on Functional Programming and Computer Architecture (FPCA’93). Cophenhagen: ACM Press. ISBN 0-89791-595-X.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

Practical type inference for arbitrary-rank types

81

Girard, J-Y. (1990). The system F of variable types: fifteen years later. Huet, G (ed), Logical foundations of functional programming. Addison-Wesley. Hancock, P. (1987). A type checker. Pages 163–182 of: Peyton Jones, SL (ed), The implementation of functional programming languages. Prentice Hall. Heeren, B, Hage, J, & Swierstra, SD. (2003). Scripting the type inference process. In: (ICFP03, 2003). Hinze, Ralf. (2000). A new approach to generic functional programming. Pages 119–132 of: 27th ACM Symposium on Principles of Programming Languages (POPL’00). Boston: ACM. Hinze, Ralf. (2001). Manufacturing datatypes. Journal of Functional Programming, 1. Huet, G. (2002). Higher order unification 30 years later. 15th international workshop on higher order logic theorem proving and its applications (IWHOLTP’02). LNCS. ICFP03. (2003). ACM SIGPLAN International Conference on Functional Programming (ICFP’03). Uppsala, Sweden: ACM. ICFP05. (2005). ACM SIGPLAN International Conference on Functional Programming (ICFP’05). Tallinn, Estonia: ACM. Jones, Mark. (1999). Typing Haskell in Haskell. Meijer, Erik (ed), Proceedings of the 1999 haskell workshop. Technical Reports, nos. UU–CS–1999–28. Available at ftp://ftp.cs. uu.nl/pub/RUU/CS/techreps/CS-1999/1999-28.pdf. Kfoury, AJ, & Tiuryn, J. (1992). Type reconstruction in finite rank fragments of second-order lambda calculus. Information and Computation, 98(2), 228–257. Kfoury, AJ, & Wells, JB. (1994). A direct algorithm for type inference in the rank-2 fragment of the second-order lambda calculus. Pages 196–207 of: ACM Symposium on Lisp and Functional Programming. Orlando, Florida: ACM. L¨ammel, Ralf, & Peyton Jones, Simon. (2003). Scrap your boilerplate: a practical approach to generic programming. Pages 26–37 of: ACM SIGPLAN International Workshop on Types in Language Design and Implementation (TLDI’03). New Orleans: ACM Press. Launchbury, J, & Peyton Jones, SL. (1995). State in Haskell. Lisp and Symbolic Computation, 8(4), 293–342. Le Botlan, D, & R´emy, D. (2003). MLF: raising ML to the power of System F. In: (ICFP03, 2003). Lee, Oukseh, & Yi, Kwangkeun. (1998). Proofs about a folklore let-polymorphic type inference algorithm. ACM Transactions on Programming Languages and Systems, 20(4), 707–723. Leijen, Daan, & L¨ oh, Andres. (2005). Qualified types for MLF. In: (ICFP05, 2005). Longo, Giuseppe, Milsted, Kathleen, & Soloviev, Sergei. (1995). A logic of subtyping (extended abstract). Pages 292–299 of: |lics95|. Miller, Dale. (1992). Unification under a mixed prefix. J. symb. comput., 14(4), 321–358. Milner, R. (1978). A theory of type polymorphism in programming. Jcss, 13(3). Mitchell, John C. (1988). Polymorphic type inference and containment. Inf. comput., 76(2–3), 211–249. Morrisett, G. 1995 (Dec.). Compiling with types. Ph.D. thesis, Carnegie Mellon University. Odersky, M, & L¨ aufer, K. (1996). Putting type annotations to work. Pages 54–67 of: 23rd ACM Symposium on Principles of Programming Languages (POPL’96). St Petersburg Beach, Florida: ACM. Odersky, Martin, Zenger, Matthias, & Zenger, Christoph. (2001). Colored local type inference. 28th ACM Symposium on Principles of Programming Languages (POPL’01). London: ACM. Okasaki, C. (1999). From fast exponentiation to square matrices: an adventure in types. Pages 28–35 of: ACM SIGPLAN International Conference on Functional Programming (ICFP’99). Paris: ACM.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press

82

S. Peyton Jones et al.

Peyton Jones, Simon. (2001). Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell. Pages 47–96 of: Hoare, CAR, Broy, M, & Steinbrueggen, R (eds), Engineering theories of software construction, Marktoberdorf Summer School 2000. NATO ASI Series. IOS Press. Peyton Jones, SL, & Santos, A. (1998). A transformation-based optimiser for Haskell. Science of Computer Programming, 32(1–3), 3–47. Pierce, Benjamin. (2002). Types and programming languages. MIT Press. Pierce, Benjamin C., & Turner, David N. (1998). Local type inference. Pages 252–265 of: 25th ACM Symposium on Principles of Programming Languages (POPL’98). San Diego: ACM. Pottier, F, & Rmy, D. (2004). ML. Pierce, BC (ed), Advanced topics in types and programming languages. MIT Press. R´emy, Didier. (2005). Simple, partial type inference for System F, based on type containment. In: (ICFP05, 2005). Shao, Zhong. 1997 (June). An overview of the FLINT/ML compiler. Proc. 1997 ACM SIGPLAN workshop on types in compilation (TIC’97). Shields, Mark, & Peyton Jones, Simon. (2002). Lexically scoped type variables. Microsoft Research. Tarditi, D, Morrisett, G, Cheng, P, Stone, C, Harper, R, & Lee, P. (1996). TIL: A typedirected optimizing compiler for ML. Pages 181–192 of: ACM Conference on Programming Languages Design and Implementation (PLDI’96). Philadelphia: ACM. Tiuryn, J, & Urzyczyn, P. (1996). The subtyping problem for second order types is undecidable. Proc. IEEE Symposium on Logic in Computer Science (LICS’96). Tiuryn, Jerzy. (2001). A sequent calculus for subtyping polymorphic types. Inf. comput., 164(2), 345–369. Vytiniotis, Dimitrios, Weirich, Stephanie, & Peyton Jones, Simon. 2005 (July). Practical type inference for arbitrary-rank types, Technical Appendix. Tech. rept. MS-CIS-05-14. University of Pennsylvania. Wells, JB. (1999). Typability and type checking in system F are equivalent and undecidable. Ann. Pure Appl. Logic, 98, 111–156.

https://doi.org/10.1017/S0956796806006034 Published online by Cambridge University Press