1 <!-- λ Λ ∀ ≡ α β ρ ω Ω -->
6 # System F: the polymorphic lambda calculus
8 The simply-typed lambda calculus is beautifully simple, but it can't
9 even express the predecessor function, let alone full recursion. And
10 we'll see shortly that there is good reason to be unsatisfied with the
11 simply-typed lambda calculus as a way of expressing natural language
12 meaning. So we will need to get more sophisticated about types. The
13 next step in that journey will be to consider System F.
15 System F was discovered by Girard (the same guy who invented Linear
16 Logic), but it was independently proposed around the same time by
17 Reynolds, who called his version the *polymorphic lambda calculus*.
18 (Reynolds was also an early player in the development of
21 System F enhances the simply-typed lambda calculus with abstraction
22 over types. Normal lambda abstraction abstracts (binds) an expression
23 (a term); type abstraction abstracts (binds) a type.
25 In order to state System F, we'll need to adopt the
26 notational convention (which will last throughout the rest of the
27 course) that "<code>x:α</code>" represents an expression `x`
28 whose type is <code>α</code>.
30 Then System F can be specified as follows:
34 types τ ::= c | α | τ1 -> τ2 | ∀α.τ
35 expressions e ::= x | λx:τ.e | e1 e2 | Λα.e | e [τ]
37 In the definition of the types, "`c`" is a type constant. Type
38 constants play the role in System F that base types play in the
39 simply-typed lambda calculus. So in a lingusitics context, type
40 constants might include `e` and `t`. "α" is a type variable. In
41 various discussions, type variables are distinguished by using letters
42 from the greek alphabet (α, β, etc.), as we do here, or by
43 using capital roman letters (X, Y, etc.), or by adding a tick mark
44 (`'a`, `'b`, etc.), as in OCaml. "`τ1 -> τ2`" is the type of a
45 function from expressions of type `τ1` to expressions of type `τ2`.
46 And "`∀α.τ`" is called a universal type, since it universally
47 quantifies over the type variable `α`. You can expect that in
48 `∀α.τ`, the type `τ` will usually have at least one free occurrence of
49 `α` somewhere inside of it.
51 In the definition of the expressions, we have variables "`x`" as usual.
52 Abstracts "`λx:τ.e`" are similar to abstracts in the simply-typed lambda
53 calculus, except that they have their shrug variable annotated with a
54 type. Applications "`e1 e2`" are just like in the simply-typed lambda calculus.
56 In addition to variables, abstracts, and applications, we have two
57 additional ways of forming expressions: "`Λα.e`" is called a *type
58 abstraction*, and "`e [τ]`" is called a *type application*. The idea
59 is that <code>Λ</code> is a capital <code>λ</code>: just
60 like the lower-case <code>λ</code>, <code>Λ</code> binds
61 variables in its body, except that unlike <code>λ</code>,
62 <code>Λ</code> binds type variables instead of expression
63 variables. So in the expression
65 <code>Λ α (λ x:α. x)</code>
67 the <code>Λ</code> binds the type variable `α` that occurs in
68 the <code>λ</code> abstract.
70 This expression is a polymorphic version of the identity function. It
71 defines one general identity function that can be adapted for use with
72 expressions of any type. In order to get it ready to apply this
73 identity function to, say, a variable of type boolean, just do this:
75 <code>(Λ α (λ x:α. x)) [t]</code>
77 This type application (where `t` is a type constant for Boolean truth
78 values) specifies the value of the type variable `α`. Not
79 surprisingly, the type of the expression that results from this type
80 application is a function from Booleans to Booleans:
82 <code>((Λα (λ x:α . x)) [t]): (b->b)</code>
84 Likewise, if we had instantiated the type variable as an entity (base
85 type `e`), the resulting identity function would have been a function
88 <code>((Λα (λ x:α. x)) [e]): (e->e)</code>
90 Clearly, for any choice of a type `α`, the identity function can be
91 instantiated as a function from expresions of type `α` to expressions
92 of type `α`. In general, then, the type of the uninstantiated
93 (polymorphic) identity function is
95 <code>(Λα (λx:α . x)): (∀α. α->α)</code>
100 We saw that the predecessor function couldn't be expressed in the
101 simply-typed lambda calculus. It *can* be expressed in System F,
102 however. Here is one way:
104 let N = ∀α.(α->α)->α->α in
105 let Pair = (N->N->N)->N in
107 let zero = Λα. λs:α->α. λz:α. z in
108 let fst = λx:N. λy:N. x in
109 let snd = λx:N. λy:N. y in
110 let pair = λx:N. λy:N. λz:N->N->N. z x y in
111 let succ = λn:N. Λα. λs:α->α. λz:α. s (n [α] s z) in
112 let shift = λp:Pair. pair (succ (p fst)) (p fst) in
113 let pred = λn:N. n [Pair] shift (pair zero zero) snd in
115 pre (suc (suc (suc zero)));
117 [If you want to run this code in
118 [[Benjamin Pierce's type-checker and evaluator for
119 System F|http://www.cis.upenn.edu/~bcpierce/tapl/index.html]], the
120 relevant evaluator is called "fullpoly", and you'll need to
121 truncate the names of "suc(c)" and "pre(d)", since those are
122 reserved words in Pierce's system.]
124 Exercise: convince yourself that `zero` has type `N`.
126 [By the way, in order to keep things as simple as possible here, the
127 types used in this definition of the ancillary functions given here
128 are not as general as they could be; see the discussion below of type
129 inference and principal types in the OCaml type system.]
131 The key to the extra expressive power provided by System F is evident
132 in the typing imposed by the definition of `pred`. The variable `n`
133 is typed as a Church number, i.e., as <code>N ≡ ∀α.(α->α)->α->α</code>.
134 The type application `n [Pair]` instantiates `n` in a way that allows
135 it to manipulate ordered pairs: `n [Pair]: (Pair->Pair)->Pair->Pair`.
136 In other words, the instantiation turns a Church number into a certain
137 pair-manipulating function, which is the heart of the strategy for
138 this version of computing the predecessor function.
140 Could we try to accommodate the needs of the predecessor function by
141 building a system for doing Church arithmetic in which the type for
142 numbers always manipulated ordered pairs? The problem is that the
143 ordered pairs we need here are pairs of numbers. If we tried to
144 replace the type for Church numbers with a concrete (simple) type, we
145 would have to replace each `N` with the type for Pairs, `(N -> N -> N)
146 -> N`. But then we'd have to replace each of these `N`'s with the
147 type for Church numbers, which we're imagining is `(Pair -> Pair) ->
148 Pair -> Pair`. And then we'd have to replace each of these `Pairs`'s
149 with... ad infinitum. If we had to choose a concrete type built
150 entirely from explicit base types, we'd be unable to proceed.
152 [See Benjamin C. Pierce. 2002. *Types and Programming Languages*, MIT
159 In fact, unlike in the simply-typed lambda calculus,
160 it is even possible to give a type for ω in System F.
162 <code>ω = λx:(∀α.α->α). x [∀α.α->α] x</code>
164 In order to see how this works, we'll apply ω to the identity
167 <code>ω id ≡ (λx:(∀α.α->α). x [∀α.α->α] x) (Λα.λx:α.x)</code>
169 Since the type of the identity function is `∀α.α->α`, it's the
170 right type to serve as the argument to ω. The definition of
171 ω instantiates the identity function by binding the type
172 variable `α` to the universal type `∀α.α->α`. Instantiating the
173 identity function in this way results in an identity function whose
174 type is (in some sense, only accidentally) the same as the original
175 fully polymorphic identity function.
177 So in System F, unlike in the simply-typed lambda calculus, it *is*
178 possible for a function to apply to itself!
180 Does this mean that we can implement recursion in System F? Not at
181 all. In fact, despite its differences with the simply-typed lambda
182 calculus, one important property that System F shares with the
183 simply-typed lambda calculus is that they are both strongly
184 normalizing: *every* expression in either system reduces to a normal
185 form in a finite number of steps.
187 Not only does a fixed-point combinator remain out of reach, we can't
188 even construct an infinite loop. This means that although we found a
189 type for ω, there is no general type for Ω ≡ ω
190 ω. In fact, it turns out that no Turing complete system can be
191 strongly normalizing, from which it follows that System F is not
194 ## Polymorphism in natural language
196 Is the simply-typed lambda calclus enough for analyzing natural
197 language, or do we need polymorphic types? Or something even more expressive?
199 The classic case study motivating polymorphism in natural language
200 comes from coordination. (The locus classicus is Partee and Rooth
203 Type of the arguments of "and":
204 Ann left and Bill left. t
205 Ann left and slept. e->t
206 Ann read and reviewed the book. e->e->t
207 Ann and Bill left. (e->t)-t (i.e, generalize quantifiers)
209 In English (likewise, many other languages), *and* can coordinate
210 clauses, verb phrases, determiner phrases, transitive verbs, and many
211 other phrase types. In a garden-variety simply-typed grammar, each
212 kind of conjunct has a different semantic type, and so we would need
213 an independent rule for each one. Yet there is a strong intuition
214 that the contribution of *and* remains constant across all of these
217 Can we capture this using polymorphic types?
221 read, reviewed e -> e -> t
223 With these basic types, we want to say something like this:
225 and:t->t->t = λl:t. λr:t. l r false
226 gen_and = Λα.Λβ.λf:(β->t).λl:α->β.λr:α->β.λx:α. f (l x) (r x)
228 The idea is that the basic *and* (the one defined in the first line)
229 conjoins expressions of type `t`. But when *and* conjoins functional
230 types (the definition in the second line), it builds a function that
231 distributes its argument across the two conjuncts and then applies the
232 appropriate lower-order instance of *and*.
234 and (Ann left) (Bill left)
235 gen_and [e] [t] and left slept
236 gen_and [e] [e->t] (gen_and [e] [t] and) read reviewed
238 Following the terminology of Partee and Rooth, this strategy of
239 defining the coordination of expressions with complex types in terms
240 of the coordination of expressions with less complex types is known as
241 Generalized Coordination, which is why we call the polymorphic part of
242 the definition `gen_and`.
244 In the first line, the basic *and* is ready to conjoin two truth
245 values. In the second line, the polymorphic definition of `gen_and`
246 makes explicit exactly how the meaning of *and* when it coordinates
247 verb phrases depends on the meaning of the basic truth connective.
248 Likewise, when *and* coordinates transitive verbs of type `e->e->t`,
249 the generalized *and* depends on the `e->t` version constructed for
250 dealing with coordinated verb phrases.
252 On the one hand, this definition accurately expresses the way in which
253 the meaning of the conjunction of more complex types relates to the
254 meaning of the conjunction of simpler types. On the other hand, it's
255 awkward to have to explicitly supply an expression each time that
256 builds up the meaning of the *and* that coordinates the expressions of
257 the simpler types. We'd like to have that automatically handled by
258 the polymorphic definition; but that would require writing code that
259 behaved differently depending on the types of its type arguments,
260 which goes beyond the expressive power of System F.
262 And in fact, discussions of generalized coordination in the
263 linguistics literature are almost always left as a meta-level
264 generalizations over a basic simply-typed grammar. For instance, in
265 Hendriks' 1992:74 dissertation, generalized coordination is
266 implemented as a method for generating a suitable set of translation
267 rules, which are in turn expressed in a simply-typed grammar.
269 There is some work using System F to express generalizations about
270 natural language: Ponvert, Elias. 2005. Polymorphism in English Logical
271 Grammar. In *Lambda Calculus Type Theory and Natural Language*: 47--60.
273 Not incidentally, we're not aware of any programming language that
274 makes generalized coordination available, despite is naturalness and
275 ubiquity in natural language. That is, coordination in programming
276 languages is always at the sentential level. You might be able to
277 evaluate `(delete file1) and (delete file2)`, but never `delete (file1
280 We'll return to thinking about generalized coordination as we get
281 deeper into types. There will be an analysis in term of continuations
282 that will be particularly satisfying.
288 OCaml has type inference: the system can often infer what the type of
289 an expression must be, based on the type of other known expressions.
291 For instance, if we type
295 The system replies with
297 val f : int -> int = <fun>
299 Since `+` is only defined on integers, it has type
302 - : int -> int -> int = <fun>
304 The parentheses are there to turn off the trick that allows the two
305 arguments of `+` to surround it in infix (for linguists, SOV) argument
311 In general, tuples with one element are identical to their one
317 though OCaml, like many systems, refuses to try to prove whether two
318 functional objects may be identical:
321 Exception: Invalid_argument "equal: functional value".
325 [Note: There is a limited way you can compare functions, using the
326 `==` operator instead of the `=` operator. Later when we discuss mutation,
327 we'll discuss the difference between these two equality operations.
328 Scheme has a similar pair, which they name `eq?` and `equal?`. In Python,
329 these are `is` and `==` respectively. It's unfortunate that OCaml uses `==` for the opposite operation that Python and many other languages use it for. In any case, OCaml will accept `(f) == f` even though it doesn't accept
330 `(f) = f`. However, don't expect it to figure out in general when two functions
331 are equivalent. (That question is not Turing computable.)
333 # (f) == (fun x -> x + 3);;
336 Here OCaml says (correctly) that the two functions don't stand in the `==` relation, which basically means they're not represented in the same chunk of memory. However as the programmer can see, the functions are extensionally equivalent. The meaning of `==` is rather weird.]
340 Booleans in OCaml, and simple pattern matching
341 ----------------------------------------------
343 Where we would write `true 1 2` in our pure lambda calculus and expect
344 it to evaluate to `1`, in OCaml boolean types are not functions
345 (equivalently, they're functions that take zero arguments). Instead, selection is
346 accomplished as follows:
348 # if true then 1 else 2;;
351 The types of the `then` clause and of the `else` clause must be the
354 The `if` construction can be re-expressed by means of the following
355 pattern-matching expression:
357 match <bool expression> with true -> <expression1> | false -> <expression2>
361 # match true with true -> 1 | false -> 2;;
366 # match 3 with 1 -> 1 | 2 -> 4 | 3 -> 9;;
372 All functions in OCaml take exactly one argument. Even this one:
374 # let f x y = x + y;;
378 Here's how to tell that `f` has been curry'd:
381 - : int -> int = <fun>
383 After we've given our `f` one argument, it returns a function that is
384 still waiting for another argument.
386 There is a special type in OCaml called `unit`. There is exactly one
387 object in this type, written `()`. So
392 Just as you can define functions that take constants for arguments
398 you can also define functions that take the unit as its argument, thus
401 val f : unit -> int = <fun>
403 Then the only argument you can possibly apply `f` to that is of the
404 correct type is the unit:
409 Now why would that be useful?
411 Let's have some fun: think of `rec` as our `Y` combinator. Then
413 # let rec f n = if (0 = n) then 1 else (n * (f (n - 1)));;
414 val f : int -> int = <fun>
418 We can't define a function that is exactly analogous to our ω.
419 We could try `let rec omega x = x x;;` what happens?
421 [Note: if you want to learn more OCaml, you might come back here someday and try:
424 val id : 'a -> 'a = <fun>
425 # let unwrap (`Wrap a) = a;;
426 val unwrap : [< `Wrap of 'a ] -> 'a = <fun>
427 # let omega ((`Wrap x) as y) = x y;;
428 val omega : [< `Wrap of [> `Wrap of 'a ] -> 'b as 'a ] -> 'b = <fun>
429 # unwrap (omega (`Wrap id)) == id;;
431 # unwrap (omega (`Wrap omega));;
432 <Infinite loop, need to control-c to interrupt>
434 But we won't try to explain this now.]
437 Even if we can't (easily) express omega in OCaml, we can do this:
439 # let rec blackhole x = blackhole x;;
441 By the way, what's the type of this function?
443 If you then apply this `blackhole` function to an argument,
447 the interpreter goes into an infinite loop, and you have to type control-c
450 Oh, one more thing: lambda expressions look like this:
454 # (fun x -> x) true;;
457 (But `(fun x -> x x)` still won't work.)
459 You may also see this:
461 # (function x -> x);;
464 This works the same as `fun` in simple cases like this, and slightly differently in more complex cases. If you learn more OCaml, you'll read about the difference between them.
466 We can try our usual tricks:
468 # (fun x -> true) blackhole;;
471 OCaml declined to try to fully reduce the argument before applying the
472 lambda function. Question: Why is that? Didn't we say that OCaml is a call-by-value/eager language?
474 Remember that `blackhole` is a function too, so we can
475 reverse the order of the arguments:
477 # blackhole (fun x -> true);;
481 Now consider the following variations in behavior:
483 # let test = blackhole blackhole;;
484 <Infinite loop, need to control-c to interrupt>
486 # let test () = blackhole blackhole;;
487 val test : unit -> 'a = <fun>
490 - : unit -> 'a = <fun>
493 <Infinite loop, need to control-c to interrupt>
495 We can use functions that take arguments of type `unit` to control
496 execution. In Scheme parlance, functions on the `unit` type are called
497 *thunks* (which I've always assumed was a blend of "think" and "chunk").
499 Question: why do thunks work? We know that `blackhole ()` doesn't terminate, so why do expressions like:
501 let f = fun () -> blackhole ()
507 Type inference and principal types
508 ----------------------------------
510 As we mentioned, the types given to some of the functions defined
511 above in the System F definition of `pred` are not as general as they
514 let pair = λx:N. λy:N. λz:N->N->N. z x y in
517 For instance, in the definition of `pair`, repeated here, we assumed
518 that the function `z` would return something of type `N`, i.e., a
519 Church number. But we can give a more general treatment.
521 let general_pair = Λα. Λβ. λx:α. λy:β. Λρ. λz:α->β->ρ. z x y in
524 In this more general version, the pair function accepts any kind of
525 objects as its first and second element. The resulting pair will
526 expect a handler function (`z`) that is ready to handle arguments of
527 the same types the pair was built from, but there is no restriction on
528 the type (ρ) of the result returned by the handler function.
530 The number specific type we gave the `pair` function above (i.e.,
531 `N->N->(N->N->N)->N`) is a specific instance of the more general type,
532 with `α`, `β`, and `ρ` all set to `N`. Many practical type systems
533 guarantee that under reasonably general conditions, there will be a
534 ***principal type***: a type such that every other possible type for
535 that expression is a more specific version of the principal type.
537 As we have seen, it is often possible to infer a type for an
538 expression based on its internal structure, as well as by the way in
539 which it is used. In the simply-typed lambda calculus, types for a
540 well-typed expression can always be inferred; this is what enables
541 programs to be written "Curry-style", i.e., without explicit types.
543 Unfortunately, reliably inferring types is not always possible. For
544 unrestricted System F, type inference is undecidable, so a certain
545 amount of explicit type specification is required. OCaml places
546 restrictions on its type system that makes type inference feasible.
548 When programming language interpreters and compilers infer types, they
549 often (but not always) aim for the principal type (if one is
550 guaranteed to exist).
552 # let pair a b z = z a b;;
553 val pair : 'a -> 'b -> ('a -> 'b -> 'c) -> 'c = <fun>
555 For instance, when we define the same `pair` function given above in
556 the OCaml interpreter, it correctly infers the principal type we gave
557 above (remember that OCaml doesn't bother giving the explicit
558 universal type quantifiers required by System F).
560 Computing principal types involves unification algorithms. Inferring
561 types is a subtle and complicated business, and all sorts of
562 extensions to a programming language can interfere with it.
566 Bottom type, divergence
567 -----------------------
569 Expressions that don't terminate all belong to the **bottom type**. This is a subtype of every other type. That is, anything of bottom type belongs to every other type as well. More advanced type systems have more examples of subtyping: for example, they might make `int` a subtype of `real`. But the core type system of OCaml doesn't have any general subtyping relations. (Neither does System F.) Just this one: that expressions of the bottom type also belong to every other type. It's as if every type definition in OCaml, even the built in ones, had an implicit extra clause:
571 type 'a option = None | Some of 'a;;
572 type 'a option = None | Some of 'a | bottom;;
574 Here are some exercises that may help better understand this. Figure out what is the type of each of the following:
582 let rec blackhole x = blackhole x in blackhole;;
584 let rec blackhole x = blackhole x in blackhole 1;;
586 let rec blackhole x = blackhole x in fun (y:int) -> blackhole y y y;;
588 let rec blackhole x = blackhole x in (blackhole 1) + 2;;
590 let rec blackhole x = blackhole x in (blackhole 1) || false;;
592 let rec blackhole x = blackhole x in 2 :: (blackhole 1);;
594 By the way, what's the type of this:
596 let rec blackhole (x:'a) : 'a = blackhole x in blackhole
599 Back to thunks: the reason you'd want to control evaluation with
600 thunks is to manipulate when "effects" happen. In a strongly
601 normalizing system, like the simply-typed lambda calculus or System F,
602 there are no "effects." In Scheme and OCaml, on the other hand, we can
603 write programs that have effects. One sort of effect is printing.
604 Another sort of effect is mutation, which we'll be looking at soon.
605 Continuations are yet another sort of effect. None of these are yet on
606 the table though. The only sort of effect we've got so far is
607 *divergence* or non-termination. So the only thing thunks are useful
608 for yet is controlling whether an expression that would diverge if we
609 tried to fully evaluate it does diverge. As we consider richer
610 languages, thunks will become more useful.