From ML to ML ^F

Abstract

ML F is a type system that seamlessly merges ML-style type inference with System-F polymorphism. We propose a system of graphic (type) constraints that can be used to perform type inference in both ML or ML F . We show that this constraint system is a small extension of the formalism of graphic types, originally introduced to represent ML F types. We give a few semantic preserving transformations on constraints and propose a strategy for applying them to solve constraints. We show that the resulting algorithm has optimal complexity for ML F type inference, and argue that, as for ML, this complexity is linear under reasonable assumptions.

A Church-Style Intermediate Language for ML F

“…Independently, Rémy and Yakobowski (2008) have introduced graphic constraints, both to simplify the presentation of ML F and to improve its type inference algorithm. This also resulted in a simpler and more expressive definition of ML F .…”

“…We use the graphic constraint presentation of eML F (Rémy and Yakobowski, 2008;Yakobowski, 2008) which is more general than the syntactic presentation (Le Rémy, 2003, 2009) and also better suited for type inference.…”

“…The first phrase is just type inference in eML F , described by Rémy and Yakobowski (2008) and Yakobowski (2008). A source program of eML F is translated into a typing constraint, which can be seen as a decoration of the source program with (1) placeholders for missing types, and (2) type instantiation constraints that relate types (either known or unknown).…”

“…5 Readers familiar with ML F (Rémy and Yakobowski, 2008) may notice a slight change in terminology, as in this work we use the term "expansion" instead of "propagation", and we solve frontier unification edges on the fly, for conciseness. Figure 13: Example of solved instantiation edge…”

“…The type of a letexpression let x = b 1 in b 2 is just an instance of the type of b 2 : as explained above, the constraints b 2 will contain, for every occurrence of x in b 2 , one instance edge coming from the type of b 1 and ending at that occurrence. The typing constraint for let-expressions could be optimized to avoid taking an additional instance of b 2 , as done in (Rémy and Yakobowski, 2008;Yakobowski, 2008). The advantage of this unoptimized version, which still preserves the complexity of type inference, is that every subexpression introduces exactly one G-node; this establishes a one-toone mapping between subexpressions and G-nodes that is preserved during constraint resolution (G-nodes are never merged) and helps define the elaboration after constraint resolution.…”