1 A Quick Look at Impredicativity 2 3 ALEJANDRO SERRANO, 47 Degrees, Spain and Utrecht University, The Netherlands 4 JURRIAAN HAGE, Utrecht University, The Netherlands 5 6 SIMON PEYTON JONES, Microsoft Research, United Kingdom 7 DIMITRIOS VYTINIOTIS, DeepMind, United Kingdom 8 Type inference for parametric polymorphism is wildly successful, but has always suffered from an embarrassing 9 flaw: polymorphic types are themselves not first class. We present Quick Look, a practical, implemented, and 10 deployable design for impredicative type inference. To demonstrate our claims, we have modified GHC, a 11 production-quality Haskell compiler, to support impredicativity. The changes required are modest, localised, 12 and are fully compatible with GHC’s myriad other type system extensions. 13 Draft March 2020. We would appreciate any comments or feedback to the email addresses below. 14 Additional Key Words and Phrases: Type systems, impredicative polymorphism, 15 constraint-based inference 16 17 1 INTRODUCTION 18 Parametric polymorphism backed by Damas-Milner type inference was first introduced in ML [14], 19 and has been enormously influential and widely used. But despite its this impact, it has always 20 suffered from an embarrassing shortcoming: Damas-Milner type inference, and its many variants, 21 cannot instantiate a type variable with a polymorphic type; in the jargon, the system is predicative. 22 Alas, predicativity makes polymorphism a second-class feature of the type system. The type 23 a:»a¼ ! »a¼ is fine (it is the type of the list reverse function), but thetype » a:a ! a¼ is not, 24 because8 a is not allowed inside a list. So -types are not first class: they8 can appear in some 25 places but8 not others. Much of the time that8 does not matter, but sometimes it matters a lot; and, 26 tantalisingly, it is often “obvious” to the programmer what the desired impredicative instantiation 27 should be (Section 2). 28 Thus motivated, a long succession of papers have tackled the problem of type inference for 29 impredicativity [2, 11, 12, 24, 26, 27]. None has succeeded in producing a system that is simulta- 30 neously expressive enough to be useful, simple enough to support robust programmer intuition, 31 compatible with a myriad other type system extensions, and implementable without an invasive 32 rewrite of a type inference engine tailored to predicative type inference. 33 In Section 3 we introduce Quick Look, a new inference algorithm for impredicativity that, for the 34 first time, (a) handles many “obvious” examples; (b) is expressive enough to handle all ofSystemF; 35 (c) requires no extension to types, constraints, or intermediate representation; and (d) is easy and 36 non-invasive to implement in a production-scale type inference engine – indeed we have done so 37 in GHC. We make the following contributions: 38 39 • We formalise a higher-rank baseline system (Section 4), and give the changes required for 40 Quick Look (Section 5). A key property of Quick Look is that it requires only highly localised 41 changes to such a specification. In particular, no new forms of types are required, and progams 42 can be elaborated into a statically typed intermediate language based on System F. Some 43 other approaches, such as MLF [2], require substantial changes to the intermediate language, 44 but Quick Look does not. 45 Authors’ addresses: Alejandro Serrano, [email protected], 47 Degrees, San Fernando, Spain, A.SerranoMena@uu. 46 nl, Utrecht University, Utrecht, The Netherlands; Jurriaan Hage, [email protected], Utrecht University, Utrecht, The Netherlands; 47 Simon Peyton Jones, [email protected], Microsoft Research, Cambridge, United Kingdom; Dimitrios Vytiniotis, 48 [email protected], DeepMind, London, United Kingdom. 49 2 Alejandro Serrano, Jurriaan Hage, Simon Peyton Jones, and Dimitrios Vytiniotis 50 51 52 head :: p:»p¼ ! p runST :: d:¹ s:ST s dº ! d 8 8 8 53 tail :: p:»p¼ ! »p¼ argST :: s:ST s Int 54 » ¼ :: 8p:»p¼ poly :: ¹8 a:a ! aº ! ¹Int; Boolº 55 ¹:º :: 8p:p !»p¼ ! »p¼ inc :: Int8 ! Int 56 single :: 8p:p !»p¼ choose :: a:a ! a ! a 57 ¹++º :: 8p:»p¼ ! »p¼ ! »p¼ poly :: ¹8 a:a ! aº ! ¹Int; Boolº 58 id :: 8a:a ! a auto :: ¹8a:a ! aº ! ¹ a:a ! aº 59 ids :: »8 a:a ! a¼ auto0 :: ¹8a:a ! aº ! b8! b 60 8 :¹ ! º ! ! 8 :¹ ! º ! » ¼ ! » ¼ 61 app :: a b a b a b map :: p q p q p q revapp :: 8a b:a ! ¹a ! bº ! b 8 62 8 63 Fig. 1. Type signatures for functions used in the text 64 65 66 67 • We prove a number of theorems about our system, including about which transformations 68 do, and do not, preserve typeablity (Section 6). 69 • We give a type inference algorithm for Quick Look (Section 7). This algorithm is based on the 70 now-standard approach of first generating typing constraints and then solving them [21]. As 71 in the case of the declarative specification, no new forms of types or constraints are needed. 1 72 Section 7 proves its soundness compared with the declarative specification in Section 5. The 73 implementation is in turn based very closely on this algorithm. 74 The constraint generation judgements in Section 7 and appendix B also appear to be the first 75 formal account of the extremely effective combination of bidirectional type inference [18] 76 with constraint-based type inference [21, 25], 77 • Because Quick Look’s impact is so localised, it is simple to implement, even in a production 78 compiler. Concretely, the implementation of Quick Look in GHC, a production compiler for 79 Haskell, affected only 1% of GHC’s inference engine. 80 • To better support impredicativity, we propose to abandon contravariance of the function 81 arrow (Section 5.4). There are independent reasons for making this change [17], but it is 82 illuminating to see how it helps impredicativity. Moreover, we provide data on its impact 83 (Section 9). 84 The paper uses a very small language, to allow us to focus on impredicativity, but Quick Look scales 85 very well to a much larger language. Appendix B gives the details for a much richer set of features. 86 We present our work in the concrete setting of (a tiny subset of) Haskell, but there is nothing 87 Haskell-specific about it. Quick Look could readily be used in any other type inference system. 88 We cover the rich related work in Section 10. 89 90 2 MOTIVATION 91 The lack of impredicativity means that polymorphism is fundamentally second class: we cannot 92 abstract over polymorphic types. For example, even something as basic as function composition fails 93 on functions with higher-rank types (types with foralls in them). Suppose 94 95 f :: ¹ a:»a¼ ! »a¼º ! Int g :: Bool ! a:»a¼ ! »a¼ 96 8 8 97 1We conjecture that completeness is true as well – we are not aware of any counterexample. 98 A Quick Look at Impredicativity 3 99 Then the composition ¹f ◦ gº fails typechecking, despite the obvious compatibility of the types 100 involved, simply because the composition requires instantiating the type of (◦) with a polytype. 101 As another example, Augustsson describes an application [1] in which it was crucial to have a 102 function var of type 103 var :: RValue a ! IO ¹ lr:LR lr ) lr aº 104 8 105 The function var is an IO action that returns a polymorphic value. Yet in Haskell today, this is out 106 of reach; instead you have to define a new named type, thus: 107 108 newtype LRType a = MkLR ¹ lr:LR lr ) lr aº 8 109 var :: RValue a ! IO ¹LRType aº 110 Moreover, every use of var must use pattern-matching to unwrap the newtype. We call this approach 111 “boxed impredicativity”, because the forall is wrapped in an named “box”, here LRType. But boxed 112 impredicativity is tiresome at best, and declaring a new type for every polymorphic shape is 113 gruesome. 114 Why not simply allow first-class polymorphism, so that » a:a ! a¼ is a valid type? The problem 115 is in type inference. Consider the expression ¹single idº, where8 the type of single and id are given in 116 Figure 1. It is not clear whether to instantiate p with a:a ! a, or with Int ! Int, or some other 117 monomorphic type. Indeed ¹single idº does not even8 have a most general (principal) type: it has 118 two incomparable types: a:»a ! a¼ and » a:a ! a¼. Losing principal types, especially for such an 119 innocuous program, is a8 heavy price to pay8 for first-class polymorphism. 120 But in many cases there is no such problem. Consider ¹head idsº where, again, the types are 121 given in Figure 1. Now there is no choice: the only possibility is to instantiate p with a:a ! a. Our 122 idea, just as in much previous work [24], is to exploit that special case. Our overall goals8 are these: 123 124 • First class polymorphism. We want forall-types to be first class. A function like list reverse :: 125 a:»a¼ ! »a¼ should work as uniformly over » a:a ! a¼ as it does over »Int ¼ and »Bool¼, and 8 8 126 should do so without type annotations. No mainstream deployed language allows that; and 127 not being able to do so is a fundamental failure of abstraction. Using boxed impredicativity is 128 an anti-modular second best. 129 • Predictable type inference: programmers should acquire a robust mental model of what will 130 typecheck, and what will not. Typically they do so through a process of trial and error, but 131 our formalism in Section 5 is specifically designed to enshrine the common-sense idea that 132 when there is clear evidence (through the argument or result type) about how to instantiate 133 a call, type inference should take advantage of it.