## 2009-05-14

### A Polymorphic Question

Chris Conway asked a question that I replied, unwittingly, with a reference to a thread he started on the OCaml mailing list exactly two years ago: what is the difference between types `'a . int -> 'a vec -> 'a` and `int -> 'a vec -> 'a`?

Strictly speaking, the latter is, in isolation, ill formed: the type variable `'a` is unbounded! The convention is to implicitly universally quantify all unbound type variables in the type. This is the so-called prenex restriction:

The most popular of these is the let-polymorphism of ML […] which is sometimes called prenex polymorphism because it can be viewed as a fragment of System F in which type variables range only over quantifier-free types (monotypes) and in which quantified types (polytypes, or type schemes) are not allowed to appear on the left-hand side of arrows.

Pierce, Benjamin C. Types and Programming Languages, p. 356.

Suppose the latter type were a complete type abbreviation, to avoid dealing with the label:

```type 'a t = int -> 'a vec -> 'a
```

which as a TaPL-style type (a "tree" type) would be equivalent to a definition

```∀X.(T = int→Vec(X)→X)
```

You cannot directly use such a definition as is; the only thing you can do is to instantiate it with ("apply it" to) some type before expanding the definition, for instance:

```   (∀X.(T = int→Vec(X)→X))[X:=U]
→β
T = int→Vec(U)→U
```

In other words, there is no way to expand the right-hand side of T while keeping the variable X uninstantiated.

The first type, on the other hand, written as a type abbreviation would be:

```type t = 'a . int -> 'a vec -> 'a
```

which as a tree type would be equivalent to the definition:

```T = ∀X.int→Vec(X)→X
```

Now with this equation you can immediately replace T by its right-hand side, which would introduce a universal quantification as a subterm of the type being substituted into.

Seen in another way, and to bring it closer to the actual examples being discussed, labels are functions from records to the corresponding type. For instance:

```type 'a t = { index : int -> 'a vec -> 'a }
```

introduces the function `index`: ∀X.T→int→Vec(X)→X (note the position of the quantification). This is exactly the first definition I wrote, but with definitional equality replaced by the functional arrow. Now a polymorphic record type

```type t = { index: 'a . int -> 'a vec -> 'a }
```

introduces a different function `index`: T→∀X.(int→Vec(X)→X), which corresponds term by term to the second "tree" definition.

To see it in a whole different way, game semantics help in understanding the differences between linear formulas. In game theoretic terms, the type ∀X.T→int→Vec(X)→X corresponds to the game: "You get to choose and fix an X whatsoever. I give you a function. You give me a T, and I'll give you another function. You give me an `int` and I'll give you yet another function. You give me a `Vec` of the Xs you yourself chose, and I'll give you a certain X."

The second type T→∀X.(int→Vec(X)→X) corresponds to a different game: "You give me a T, and I give you back a thing, with the proviso that I reserve the right to choose and fix an X, which if given to you would result in a function." Only then you can give me back an `int` and so on. This is what makes X opaque to you.

I hope this helps.

Chris said...

Matias: I really appreciate this "private" tutoring session! This explanation helps a lot.

I'm not too familiar with game semantics for types (and I really should brush up on my Pierce), but I'm not sure I understand why the alternation lands on "me" at the quantifier in

T→∀X.(int→Vec(X)→X)

when in the previous example, all of the parameters (including the type parameter) where provided by the "adversary"? Usually, games alternate between universal and existential "moves," so I assume you have in mind some implicit conversion to an existential type?

Matías Giovannini said...

Chris,

in game semantics for LL, players take turns on arrows. You can think of an arrow X→Y as a function that given a proof of X produces a proof Y. In game semantics, if I have the "proof machine" X→Y, I can produce Y on demand whenever you give me an X, so that, taking turns: I have an X→Y, you give me an X, I give you a Y.

Maybe the "I give you a function" step I wrote should be "I show you that I have a function", as a kind of challenge.