To What Extent Is Type Inference for Parameteric Polymorphism Possible in the Presence of Ad-Hoc and Subtype Polymorphism

Transcription

1 To What Extent Is Type Inference for Parameteric Polymorphism Possible in the Presence of Ad-Hoc and Subtype Polymorphism Daniel Marty University of Applied Sciences Rapperswil Supervised by Prof. Dr. Farhad D. Mehta Seminar Spring 2017 Abstract The aim of this paper is to compare the capabilities of type inference in different contexts. While complete type inference is possible in pure functional programming, mainstream languages still lack this feature and only slowly make progress in this area. The problems and limitations arising if subtype polymorphism and overloading, basic features in object-oriented programming, are components in such languages, are captured and analyzed in this paper. Finally, the type inference capabilities of modern multi-paradigm languages like Scala and Swift are studied and compared to type inference available in Haskell. 1 Introduction Type inference for functional languages is common nowadays and is finding a way into mainstream languages with subtypes like Java (SE 7) and C++ (11) to get rid of the tedious task of adding type annotations to every identifier [Pot01]. Languages with a shorter history than above-mentioned languages, for example, Scala and Swift, offer type inference since their first release. Even though, their type systems were constructed with type inference in mind, they do not provide this to the same extent as representatives of pure functional programming languages. Definition 1 (Type Inference) Reconstructing the type information of terms without type annotations in their external form (the language programmers use to write the code) at compile time, is called type reconstruction or type inference. In explicitly typed languages, where the external and the internal form both contain type annotations, type inference is equivalent to the identity function. [PT00] Modern programming languages offer different kinds of polymorphism to write generic code and therefore avoid code duplication. The term polymorphism is confusing and refers to different forms of polymorphism depending on the context. In functional programming, the term mostly is associated with parametric polymorphism while object-oriented programmers link it to subtype polymorphism and call parametric polymorphism generics [Pie02]. It is common to differentiate three kinds of polymorphism [Sut15]. Definition 2 (Parametric Polymorphism) If a function is defined over a range of types and acts the same for each type, it is called parametric polymorphism [WB89]. Definition 3 (Ad-hoc Polymorphism) In contrast to parametric polymorphism, a different meaning for the same function name can be achieved by overloading a meaning for each combination of the arguments. That means the function is acting differently for each type [CW85]. 1

2 Definition 4 (Subtype Polymorphism) Subtype polymorphism introduces a hierarchy S <: T that allows substituting values of a supertype T by values of a subtype S. This is based on the Liskov substitution principle [Lar11]. instances. The following sections cover the question how polymorphism affects the possibility to infer types and how modern programming languages combine different kinds of polymorphism. With Haskell as the representative for functional languages and Scala and Swift for multi-paradigm languages, the capability of type inference depending on the presence of subtype polymorphism is scrutinized. Section 2 gives an overview of the Hindley-Milner type system for parametric polymorphism. In section 3, the problem occurring if the Hindley- Milner type system is extended with ad-hoc polymorphism is discussed and solutions therefor are analyzed. The complexity of type inference in the presence of subtype polymorphism and why it is not possible to infer a most general type is shown in section 4. A lot of research was done in System F and many functional languages uses a type system similar to System F. Section 5 shows why type inference in System F is undecidable and how this affects Haskell whose core coincides with a fragment of System F. How modern multiparadigm languages are still able to offer type inference is shown in section 6. It deals with local type inference which is used in Swift and Scala. 2 Hindley-Milner This section serves to give an introduction to the Hindley-Milner type system which is named after its inventors J. Roger Hindley and Robin Milner. With the Hindley-Milner type system, an approach to parametric polymorphism is available that infers the most general type of a given program if such a type exists. It first appeared in Standard ML and can be found in Haskell and other functional languages in an extended form [Wie11]. Definition 5 (Principal Type) Alongside the interpreted base types, an infinite collection of 2 uninterpreted types, also called principal types or most general types, exist. Principal types serve as type variables that can be instantiated with other types. It has all other types that are possible as The function λx : t.x has the type t t and represents the identity function for all elements of t, independently of what t may be [Pie02]. The annotation :t specifies the type of the argument that the function can be applied to. 2.1 Complete Type Inference Defining an inference rule for recursive functions involves a problem. Inferring the type of the newly bound identifier needs the type of the expression on the right-hand side which however requires the type of the newly bound identifier. This problem is solved by dividing type inference into the phases constraint generation and generalization [Wie11]. During constraint generation, each expression is analyzed which results in a constraint set C. Constraints are statements about the types of an expression. The order of the traversal does not matter [Kri14]. Definition 6 (Constraint Set C) A set of equations is called a constraint set. If the substitution instances σs and σt are identical, the equation is said to unify. A substitution σ satisfies C if every equation unifies [Pie02]. Definition 7 (Substitution S) A substitution S is a finite mapping from type variables to types. A single untyped function has infinitely many types. (a b) a b (1) If the type (1) where s and t correspond to type variables is given, it has every type that is a substitution instance of it. The types shown in (2) and (3) are therefore valid types for this untyped function. (Int Bool) Int Bool (2) (F loat Int) F loat Int (3)

3 Given a type expression σ and a substitution S, the type expression Sσ is obtained by replacing each variable t in σ with S(t) [Mit91]. In the generalization phase, a unification (solving the constraints) of the constraint set C is done, which results in a type substitution σ. If the unification is successful, σ is the principal unifier to the constraint set C. After applying this unifier to a type τ, it yields the principal type τ p [Wie11]. How parametric polymorphism works in Haskell is shown in the following example without going into detail. Example 1 Everytime an unknown type is encountered, a new principal type gets introduced (in this example, a new type is introduced in alphabetical order, but it does not matter how the names are chosen). The function swap shown in Listing 1 has two parameters, so its type has to be a b c. The second argument has to be a list (denoted by [ ] and (x:xs)). With this information, the principal type c has to be a list type [d]. Further, f has to be a function that takes an element of that list and returns an element of type e. The type returned by the map function has to be a list of type e. The most general type therefore is (d e) [d] [e]. 1 mymap f [ ] = [ ] 2 mymap f ( x : xs ) = f x : mymap f xs Listing 1: Map function in Haskell and ad-hoc polymorphism is that only one algorithm is used for parametric polymorphic functions, whereas a different algorithm may be used for an overloaded function depending on its types [HHPJW96]. 3.1 Early Approaches The equality operation is used in this section to show the limitations of the ad-hoc polymorphism before Haskell introduced type classes. The equality operation has distinct implementations associated with it. Int Int Bool (4) F loat F loat Bool (5) The types shown in (4) and (5) represent two types for the same operation. The first and simplest approach is to overload equality without adding abstract or function types as it was done in the first version of Standard ML. With this approach, it is possible to check for equality of integers (2*8 == 16) or characters ( A == B ). But it is not possible to define a function like figured in Listing 2 and call it as shown in Listing 3. 1 member [ ] y = False 2 member ( x : xs ) y = ( x == y ) 3 member xs y Listing 2: Function member in a functional language 3 Extending Hindley-Milner with ad-hoc polymorphism In this section, problems arising by adding ad-hoc polymorphism to Hindley-Milner and the solution provided with type classes are presented. Type classes are an approach to add ad-hoc polymorphism to the Hindley-Milner type system. Before the time of Haskell, there was no standard approach to overloading. The difference between parametric polymorphism 3 1 member [ 4, 9, 8 ] 9 2 member Member? b Listing 3: Calling the function member A second approach is to make it work with all types (fully polymorphic). Listing 4 shows the type of the equality operation. 1 (==) : : a > a > Bool Listing 4: Signature of the equality operation

4 The type of the member function defined in Listing 3 with this approach is figured in Listing 5. 1 member : : [ a ] > a > Bool. Listing 5: Signature of the function member with the second approach However, not all types possess a meaningful implementation for equality. The equality of functions, for example, is undecidable because it is a form of the halting problem. The third approach is to limit polymorphism instead of making the equality fully polymorphic. This is done by adding an equality type variable and is the current approach in Standard ML. Listing 6 shows how such a type looks. 1 (==) : : a (==) > a (==) > Bool Listing 6: Signature of the equality operation with an equality type variable Applying equality on a function type or an abstract type causes a type error because there is no substitution available [WB89]. Definition 8 (Equality Type Variable) Other than principal types, equality type variables can only be substituted by types that admit equality. 3.2 Type Classes Type classes bring parametric and ad-hoc polymorphism, two kinds of polymorphism that were separated, together. The idea is to generalize the approach of equality types to allow user-defined collections of types. Type signatures and names of the class are provided in a class declaration as shown in Listing 7. 1 class Eq a where 2 (==), (/=) : : a > a > Bool 3 x /= y = not ( x == y ) 4 x == y = not ( x /= y ) Listing 7: Class declaration in Haskell It means that a belongs to the class Eq if the equality operation (==) or (/=) with the signature a a Bool is defined on it. It also provides a default implementation of (/=) or (==) in case that one operation is implemented. This reduces the operations that must be implemented to conform to the type class. Additionally, to the class declaration (Listing 8), there is an instance declaration in which implementations of all class operations for a given type are provided. The instance declaration says that the type Int belongs to the type class Eq and the implementation of the equality is given by the function primeqint which has to be of type (Int Int Bool). 1 instance Eq Int where 2 (==) = primeqint 3 instance Eq Char where 4 (==) = primeqchar 5 instance Eq Bool where 6 (==) = primeqbool Listing 8: Instance declaration in Haskell If the type is Char or Bool the implementation can be found in primeeqchar respectively primeqbool instead. The function primeqbool could be implemented like figured in Listing 9. If the first argument is true, the id function is called on the second argument, else the not function is called which returns true if the argument is false and vice versa. 1 primeqbool : : Bool > Bool > Bool 2 primeqbool true = id 3 primeqbool false = not Listing 9: Example implementation of primeqbool Listing 10 shows the signature that the function defined in Listing 2 has in Haskell. The type variable a can only be substituted with types that belong to the class Eq. 1 member : : Eq a => [ a ] > a > Bool Listing 10: Signature of the function member in Haskell 4

5 3.2.1 Superclasses Sometimes it makes sense to require type classes that were already defined when constructing new type classes. 1 class ( Eq a ) => Ord a where 2 (<) : : a > a > Bool 3 (<=) : : a > a > Bool 4 5 instance Ord Int where 6 ( <) = primltint 7 (<=) = primleint Listing 11: Superclass of Eq The term (Eq a) in Listing 11 is called a context of the type and limits the type of a to those admitting equality. Thus, if the operations (==), (<) and (<=) are defined on a type, the type is an instance of the type class Ord. This allows simpler signatures to be inferred. The inferred signature of the function defined in Listing 12 which is using Eq and Ord is shown in Listing search = \ x ys > not ( null ys ) && 2 ( x == head ys 3 ( x < head ys && search x ( tail ys ) ) ) Listing 12: Function search in Haskell Without superclasses, the context would be (Eq a, Ord a). The hierarchy formed by superclasses must be a directed acyclic graph [HHPJW96]. 1 search : : Ord a => a > [ a ] > Bool Listing 13: Signature of the function search in Haskell Translation It is possible to translate a program with type classes to an equivalent program without overloading during the inference process. This program without overloading is then typable in the Hindley-Milner type system. All the instance declarations generate a corresponding dictionary declaration. Overloaded functions will be translated to functions without overloading using this dictionary. The class dictionary contains tuples of functions and sub-dictionaries for all its functions and operators. This allows calling specific 5 functions depending on the type of the input and the operator. dicteqint =, primeqint dictordint = primeqint, primltint, primleint A dictionary is built using e 1...e n. The dictionary dictordint contains a dictionary dicteqint (the dictionary for instances of Eq Int) for its superclass and methods for (<) and (<=). To extract a method from the corresponding dictionary, a selector is offered for each operation in a class. There is also a selector for each superclass to extract the superclass dictionary from the subclass dictionary. The selectors for the class Eq and Ord look like following [HHPJW96]: (==) = \, == == geteqf romord = \ dicteq, <, <= dicteq (<) = \ dicteq, <, <= < (<=) = \ dicteq, <, <= <= Listing 14 shows the translation of the function search defined in Listing search = \ dord x ys > not ( null ys )&& 2 ((==) ( geteqfromord dord ) x ( head ys ) 3 (( <) dord x ( head ys )&& 4 search dord x ( tail ys ) ) ) Listing 14: Translation of the function search 4 Type Inference with Subtype Polymorphism Subtyping and overloading are basic features of typed, object-oriented programming languages. In section 3, a solution to enrich the Hindley- Milner type system with ad-hoc polymorphism was presented. The focus in this section is the complexity and the possibility to obtain most general types of expressions including additional subtype assumptions. 4.1 Complexity The typability of the simply typed lambda calculus can be reduced to unification [ASU86]. This

6 subsection shows that a problem exists to which type inference in the presence of subtyping can be reduced to and shows in which complexity class the problem belongs. Definition 9 (TIS) The decision problem for type inference in the presence of subtyping (TIS) is defined as follows: Is M typable over Σ for a given signature Σ and a term M. A signature Σ consists of a set B of base types, a partial order on this B ( B ) and a set T of pairs c, σ where c is a term constant and σ is a ground type (no type variable). Definition 10 (SSI) The satisfiability of subtype inequalities (SSI) is a decision problem of the following form: Is I satisfiable in B for a given finite partial order B and a system I of inequalities? A partial order on a set S is given if the relation has following properties: (i) Reflexivity: x x for all x S (ii) Antisymmetry: a b and b implies a = b (iii) Transitivity: a b and b c implies a c Figure 1: The relation among complexity classes [psp] 4.2 Most General Type In this subsection, it is shown that it is impossible to find a most general type in the presence of subtyping. The untyped lambda calculus with following grammar will be used to demonstrate examples with subtype polymorphism: M := x MM λx.m A polynomial time reduction from the decision problem for type inference in the presence of subtyping to the satisfiability of subtype inequalities (TIS m SSI) and vice versa (SSI m TIS) exist. The problems are therefore proven to be algorithmically equivalent and the lower bound of SSI can be transferred to TIS. The lower bound of SSI is known to be PSPACE hard [HM95]. Definition 11 (PSPACE hard) PSPACE is the class of problems solvable in polynomial space with unlimited time available. An NP problem has a certificate with polynomial size such that the problem can be solved in polynomial time if the certificate is known. Since checking if the certificate is valid takes polynomial time, it takes polynomial space as well. Therefore, no problem in NP is harder than any problem in PSPACEhard [Aar]. It is not known but conjectured that PSPACE > NP as shown in Figure 1. The first term x may be any variable. The application of the function M to an argument M is denoted by MM and the function obtained by treating M as a function of x as λx.m. Function application is left-associative, that means wxyz is the same as ((wx)y)z. A lambda abstraction extends as far to the right as possible. The term λx.λy.y corresponds to λx.(λy.y) [Mit91]. Example 2 Let M = λf.λ.xλy.k(f x)(f y) where K is the combinator (λx.(λy.x)) that returns the first argument and discards the second. With Hindley-Milner the typing for the term M is: (e d) e e d (6) 6

7 The typing (6) was received in the same manner as described in section 2. If the coercion set C is nonempty for example {s u, t u, v w}, and the argument x has type s and the argument y has type t, a possible typing for M is: (u v) s t w (7) Per definition, the most general typing has all other possible typings as an instance. However, there is no substitution S such that Sσ = σ where σ corresponds to the typing shown in (6) and σ to (7) [HM95]. Therefore, the type (9) is contained in (10) but neither the containment shown in (14) nor the containment in (15) is valid [Mit91]. Int Int Real Real (14) Real Real Int Int (15) 5 Undecidability in System F The second-order polymorphic lambda calculus also known as System F was independently invented by Girard and Reynolds. Both formulated the system in the Church-style where type an- Definition 12 (Coercion Set C) A Coercion notations are explicitly added to terms. This set C is a set of coercions. The coercions, in section deals with the System F in the Currystyle where type annotations are omitted. The this case, are subtype assertions between arbitrary types. A subtype assertion has the form σ τ, type systems used in functional programming languages are often related to System F. In software where σ and τ are base types. engineering, programmers wish to avoid code duplications. System F exhibits parametric polymor- Example 3 Given a function f that has the type shown in (8), the expression λx.k.x(fx) and the phism and all computations on typable λ-terms containment Int Real. are guaranteed to halt. Although this property gets destroyed by adding features that allow nontermination, it still can be helpful for handling Real Bool (8) subexpressions which do not use those features. Haskell is a functional language that uses a type The combinator K has the types listed in (9) - system whose core coincides with a fragment of (11) in this context. System F [Wel99]. Int Int (9) Int Real (10) Definition 13 (TYP) The typability problem is defined as follows: Do assumptions A and a type τ exist such that A M : τ is derivable? Real Real (11) The type σ τ is a functional type which takes arguments of type σ and results in a type τ. If subtyping is regarded as an ordering, then the arrow operator is antimonotonic in its first argument (12) and monotonic in its second argument (13). if σ ρ then ρ τ σ τ (12) if σ ρ then τ σ τ ρ (13) Definition 14 (TC) The type checking problem is defined as follows: Is A M : τ derivable for arbitrarily chosen assumptions A and type τ? Definition 15 (SUP) The semi-unification is a generalization for matching and unification for a given pair of terms s and t. Do substitutions ρ and σ exist such that ρ(σ(s)) = σ(t)? Unification solves equations by finding all substitutions that make the term equal. Matching solves equations where only one term has to be instantiated by the substitution [KMNS91]. 7

8 SUP is reducible to TC in System F (SUP TC). A proof that SUP is undecidable can be found in [KTU90]. Moreover, it is also proven that TC is reducible to TYP. Therefore, TC and TYP are algorithmically equivalent and undecidable in System F [Wel99]. It was mentioned that Haskell s core coincides with a fragment of System F. Does that mean Haskell s type system is undecidable as well? TYP is decidable for the simply typed lambda calculus [Hin69]. The problems TC and TYP are undecidable in System F that uses types of finite rank 3 [Wel99]. Haskell s types are Rank-1 types. The Haskell type shown in (16) implies that the type variables are universally quantified like figured in (17). a b a (16) ab.a b a (17) If appears on the right-hand side of the arrow operator, it can be floated out. That means the signature shown in (18) is equivalent to the signature (17) and therefore a Rank-1 type as well. a.a ( b.b a) (18) (19) is a Rank-2 type because there are two levels of universal quantification [ran]. ( a.a a) ( b.b b) (19) Some explicit type annotations are required for Rank-N type reconstruction. Haskell s types are limited to Rank-1 types and is therefore decidable. 6 Local Type Inference In section 4, it was shown that type inference is undecidable in the presence of subtype 8 polymorphism. This section focuses on local type inference which is used in Scala and Swift. It only recovers type annotations with information from adjacent nodes in the syntax tree. Because only local information is used, long distance constraints such as unification variables are not taken into consideration [PT00]. The reason Scala does not have Hindley/Milner type inference is that it is very difficult to combine with features such as overloading (the ad-hoc variant, not type classes) [...] and subtyping. [...] I m just saying it s very difficult to make this work well in practice, where one needs to have small type expressions, and good error messages. - Martin Odersky, designer of Scala [Ode08] Scala s type inference aims to provide the same level of comfort as languages like Haskell with complete type inference. The restriction to a local context allows combining subtype polymorphism with type inference in the style of Hindley-Milner. The idea behind this is to use type annotations in some situations which are not common and rarely occur but provide type inference for desirable cases such as: Types of local bindings. Types of parameters of anonymous functions. Type arguments in applications of polymorphic functions. Bound variables of top-level functions should remain explicitly annotated because type annotation in that position serve as useful documentation which also is considered good practice in Haskell or other languages with complete type inference [Wie11]. 6.1 Local Type Argument Synthesis In this subsection, a type inference technique is introduced which deals with inferring type arguments in applications of polymorphic functions. The polymorphic identity function id has the type t t as shown in Definition 5. The goal is

9 to allow applying the identity function without the need of a type argument. It should be possible to use id(8) instead of id[int](8). The first problem is to decide where type arguments have been omitted and therefore need to be synthesized. It is easy to see that if a function is defined polymorphic and no explicit type argument is given, it has to be synthesized [PT00]. The second problem is that a number of different type arguments could be picked for a particular application. This is solved by picking the type argument that yields the best type for the result. Following example shows how the best type is chosen: Example 4 The containment Int Real is given. Both id[int](x) and id[real](x) are possible completions for id(8). In this case, Int is chosen over Real since Int is more informative. In subsection 4.2, it was shown that such a best type does not always exist. Following example shows the problem again: Example 5 The containment Int Real and a function f with type t (t t) are given. Two possible completions for f() are f[int]() and f[real](). The result types Int Int and Real Real are incompatible. Therefore, the type argument synthesis will fail. 6.2 Bidirectional Checking Bidirectional checking deals with inferring the types on bound variables in anonymous function abstractions as well as on local variable bindings. The type checker needs to operate in two distinct modes: synthesis and checking [PT00]. The typing judgment known from the simply typed lambda calculus (20) has to be replaced. Γ e : τ (20) Instead of trying to figure out the type of an expression, the idea behind bidirectional typing judgments is to use two directions of information. The first direction is synthesizing types. The other direction is checking expressions against already known types. Definition 16 (Context Γ) The context Γ represents the type declarations of the free variables (variables not bound by a lambda abstraction) used in a program. Γ (21) Γ, x : τ (22) (21) shows an empty context, while (22) is a context with the assumption that the free variable x is of type τ. The direction of the arrow shows which parts of the judgment are inputs and which are outputs. In (23), τ is unknown and has to be figured out, as in type inference (synthesis). The rule shown in (24) does only make sure that e does conform to the already known type τ (checking) [Dun12]. Γ e τ (23) Γ e τ (24) For function application a simple heuristic is used: The type of the function is always synthesized first. The information is then used to check the argument expression. Example 6 Given are the function f with type (25) and the application (26) (Int Int) Int (25) f(fun(x : Int)x) (26) Because the type of the function f is known, the type of fun(x: Int)x has to be Int Int. That means x has to be of type Int as well (Real would also be possible, but it always takes the most specific). Therefore, the type annotation can be omitted like shown in (27). f(fun(x)x) (27) 9

10 During type checking of (27), the type of f is synthesized by looking it up in the context. With this resulting information, the type checker switches into checking mode where fun(x)x is checked against the type Int Int [PT00]. 7 Conclusion The Hindley-Milner algorithm allows global type inference for functional programming and infers a general type if such a type exists. Extending Hindley-Milner with type classes, which adds adhoc polymorphism to the type system does not harm this property. However, Hindley-Milner is not decidable if subtype polymorphism is present. With subtyping values may have multiple types. Finding a most general type for a value that may have multiple types is undecidable. Moreover, the set of constraints no longer consists of simple equations. Instead, a set of inequations has to be solved. The complexity therefore increases. If higher-ranked types with a rank k>2 are available in a type system, it is also undecidable. Languages like Scala are offering type inference with a reduced scope while supporting subtyping and overloading at the same time. However, it is not guaranteed anymore that the chosen type is the best type in all cases. 10

11 References [Aar] [CW85] [Dun12] Scott Aaronson. P, np, and friends. democritus/lec6.html [accessed: May 17]. Luca Cardelli and Peter Wegner. On understanding types, data abstraction, and polymorphism. ACM Comput. Surv., 17(4): , December Joshua Dunfield. Bidirectional typechecking. November [HHPJW96] Cordelia V. Hall, Kevin Hammond, Simon L. Peyton Jones, and Philip L. Wadler. Type classes in haskell. ACM Trans. Program. Lang. Syst., 18(2): , March [Hin69] R. Hindley. The principal typescheme of an object in combinatory logic. Trans. Amer. Math. Soc, 146:29 60, December [HM95] My Hoang and John C. Mitchell. Lower bounds on type inference with subtypes. In Proceedings of the 22Nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, POPL 95, pages , New York, NY, USA, ACM. [KMNS91] Deepak Kapur, David Musser, Paliath Narendran, and Jonathan Stillman. Semi-unification. Theoretical Computer Science, 81(2): , [Kri14] Shriram Krishnamurthi. A tour of scala /Type_Inference.html [accessed: Apr 17]. [KTU90] [Lar11] [Mit91] A. J. Kfoury, J. Tiuryn, and P. Urzyczyn. The undecidability of the semiunification problem. In Proceedings of the Twenty-second Annual ACM Symposium on Theory of Computing, STOC 90, pages , New York, NY, USA, ACM. Hupel Lars. Type classes and subtyping. June John C. Mitchell. Type inference with simple subtypes. J. Funct. Program., 1(3): , [Ode08] Martin Odersky. Universal type inference is a bad thing blog/scala/universal-typeinference-is-a-bad-thing [accessed: Mar 17]. [Pie02] Benjamin C. Pierce. Types and Programming Languages. Cambridge, MA, USA, [Pot01] François Pottier. Simplifying subtyping constraints: A theory. Information and Computation, 170(2): , [psp] Pspace. org/wiki/pspace [accessed: May 17]. [PT00] Benjamin C. Pierce and David N. Turner. Local type inference. ACM Trans. Program. Lang. Syst., 22(1):1 44, January [ran] Rank-n types. haskell.org/rank-n_types [accessed: May 17]. [Sut15] Toni Suter. Polymorphism [WB89] P. Wadler and S. Blott. How to make ad-hoc polymorphism less ad hoc. In Proceedings of the 16th ACM SIGPLAN-SIGACT Symposium on Principles of Programming 11

12 Languages, POPL 89, pages 60 76, New York, NY, USA, ACM. [Wel99] J.B. Wells. Typability and type checking in system f are equivalent and undecidable. Annals of Pure and Applied Logic, 98(1): , [Wie11] Sebastian Wiesner. Type Inference