7 Qualified types

In the previous lecture, we saw how ML infers types for programs that lack type annotations. In this lecture, we see how to extend ML with a principled form of overloading, similar to how it appears in Haskell and Rust. In particular, we will extend type schemes to a form , where is a logical formula over types that must be satisfied to use a value having that type scheme.

7.1 Syntax

7.2 Dynamic semantics

The metafunction gives the results for applying constants to values:

7.3 Static semantics

As in ML the static semantics assigns prenex type schemes to let-bound values, but type schemes now have an additional component. The syntax of types is as follows.

7.3.1 Syntax of types

Monotypes include type variables, the base type , product types, and function types:

To represent overloading, we define a fixed set of type classes , which are used to construct predicates on types :

For any type , the predicate means that type supports equality, and the predicate means that type supports less-than. In a real system, the set of type classes (and thus the possible predicates) would be extensible by the user.

A predicate context is a collection of predicates:

Then a qualified type is a monotype qualified by some predicate context:

For example, type scheme describes a function that takes (curried) two arguments of any type supporting equality and returns an integer.

7.3.2 The types of constants

We can now define the metafunction, which gives type schemes for the constants:

Note that and are overloaded.

7.3.3 Instantiation and entailment

7.3.4 Syntax-directed typing

The typing judgment is of the form , where gives constraints on the types in . Even though it appears on the left, should be thought of as an out-parameter.

The rule for typing a variable says to look up its type scheme in the environment and then instantiate the bound variables of the type scheme. The predicate context from the instantiated type scheme becomes the predicate context for the judgment:

Typing a constants is substantially the same, except we get its type scheme using the metafunction:

First we type , which produces a predicate context . Then we apply the entailment relation to reduce to a context that entails it, . (This step can be omitted, but it reflects the idea that we probably want to simplify predicate contexts before including them in type schemes.) Then we build a type scheme by generalizing all the type variables in and that do not appear in , and bind that in the environment to type . Note that the resulting predicate context for the judgment is only , the constraints required by , since the constraints required by are carried by the resulting type scheme.

Alternatively, we could split the predicates of (or ) into those relevant to , which we would package up in the type scheme, and those irrelevant to , which we would propogate upward.

Exercise 53. Use Haskell’s type classes to implement bijections between the natural numbers and lists.

The class declaration introduces a new predicate XEnum that supports two operations, into and outof. These are two functions that realize a bijection between the type a and the natural numbers.

The instance declaration says that the type Natural supports enumeration by giving the functions that translate from the naturals to the naturals (i.e., the identity function).

For our first substantial instance, fill in the into and outof functions to define a bijection between the natural numbers and the integers:

Once you have finished that, add the support for (disjoint) unions. To do that we need to assume we have two enumerable things and then we are going to add a bijection using the Either type:

Be aware that the formulas and the bijections you’ve built work only for infinite sets (i.e., the naturals, the integers, pairs of them, etc.) If you want to use these bijections on sets that are finite, you need to add a size operation:

7.4 Type inference algorithm

The above type system provides a satisfactory account of which terms type and which do not, but it does not give us an algorithm that we can actually run. In this section, we extend ML’s Algorithm W for qualified types.

Algorithm W for qualified types takes a type environment and a term, and returns a substitution, a type, and a predicate context: .

To infer the type of a variable or constant, we look up its type scheme (in the environment or the metafunction, respectively) and instantiate it with fresh type variables, yielding a qualified type . The is the type of the variable or constant, and is the predicate context that must be satisfied:

Finally, the let rule follows the let rule from the previous section, packaging up the predicate context generated for in the type scheme assigned to . We (optionally) assume a metafunction that simplifies the predicate context before constructing the type scheme.

7.5 Evidence translation

Exercise 54. What is the most general type scheme of the term ?

How would you implement such a function—in particular, how does it figure out the equality for a generic/unknown type parameter? Well, our operational semantics cheated by relying on Racket’s underlying polymorphic equal? function. Racket’s equal? relies on Racket’s object representations, which include tags that distinguish number from Booleans from pairs, etc. But what about in a typed language that does not use tags and thus cannot support polymorphic equality?

One solution is called evidence passing, wherein using a qualified type requires passing evidence that it is inhabited, where this evidence specifies some information about how to perform the associated operations. In our type classes example, the evidence is the equality or less-than function specialized to the required type. (In a real evidence-passing implementation such as how Haskell is traditionally implemented, the evidence is a dictionary of methods.)

We can use the evidence environment to summon or construct evidence if it’s available. In particular, the judgment uses evidence environment to construct , which is evidence of predicate . In particular, if is then should be an equality function of type ; if is then should be a less-than function of type .

For base type , the evidence is just a primitive function performing the correct operation:

Four rules of the typing judgment are unremarkable, simply passing the evidence environment through and translating homomorphically:

The let form, as above, generalizes, by abstracting the right-hand side over evidence corresponding to its inferred evidence context:

Exercise 55. Rust uses monomorphization to implement generics and traits. It does this by duplicating polymorphic code, specializing it at each required type. Write a relation that formalizes monomorphization for describes λ-qual.