## Section: New Results

### Type systems

#### Partial type inference with first-class polymorphism

Participants : Didier Rémy, Boris Yakobowski, Didier Le Botlan [ INSA Toulouse ] .

The ML language uses simple types (first-order types without quantifiers) enriched with type schemes (simple types with outer-most universal quantifiers). This allows for simple type inference based on first-order unification, relieving the user from the burden of writing type annotations. However, it only enables a limited form of parametric polymorphism. In contrast, System F uses second-order types (types with inner universal quantifiers at arbitrary depth) that are much more expressive. As a result, type inference is undecidable in System F which forces the user to provide all type annotations.

Didier Le Botlan and Didier Rémy have proposed a type system, called MLF, which enables type synthesis as in ML while retaining the expressiveness of System F. Only type annotations on parameters of functions that are used polymorphically in their body are required. All other type annotations, including all type abstractions and type applications are inferred. Remarkably, type inference in MLF reduces to a new form of unification that amounts to performing first-order unification in the presence of second-order types.

The initial study of MLF was the topic of Didier Le Botlan's Ph.D. dissertation [46] . There is an interesting restriction of MLF that retains most of its expressiveness while being simpler and more intuitive for which types can be interpreted as sets of System-F types and type-instantiation becomes set inclusion on the semantics. This justifies a posteriori the type-instance relation of MLF that was previously defined only by syntactic means. This works has been accepted for publication in the journal Information and Computation [45] .

Boris Yakobowski completed his Ph.D., defended in December, under the supervision of Didier Rémy. His dissertation is a new simplification of MLF using graphs rather than terms to represent types. Graph types are the superposition of a DAG representation of first-order terms and a
binding tree that describes
*where* and
*how* variables are bound. This representation is much more canonical than syntactic types and eliminates most of the notational redundancies of the syntactic presentation.

This exposed a linear-time unification algorithm on graph types, which can be decomposed into standard first-order unification on the underlying dags and a simple computation on the underlying binding trees. These results were presented at the workshop on Types in Language Design and Implementation (TLDI 07) last year [51] .

Graphic types can also be used to represent type inference constraints internally. This is a stepping stone for efficient type inference for MLF. This also allows for a direct specification of type inference via generation of typing constraints. This result was presented at the International Conference on Functional Programming (ICFP 08) [25] .

Although the implicitly typed version of MLF preserves well-typedness during reduction, explicit type annotations cannot be maintained during reduction in the type-inference version of MLF because types are still too implicit. Didier Rémy and Boris Yakobowski have designed a fully explicit version of MLF with a type-preserving reduction semantics. This work is described in Boris Yakobowski's Ph.D. dissertation [11] and is to be submitted for publication [38] .

#### Type-based analysis of hidden state in imperative programs

Participant : François Pottier.

François Pottier studied the notion of
*hidden state* , and proposed a type-theoretic explanation of it.

In earlier work, Charguéraud and Pottier designed a type system, featuring regions, capabilities, and notions of linearity, which allows fine-grained reasoning about aliasing and ownership in imperative programs with dynamic memory allocation. This work was presented this year at the International Conference on Functional Programming (ICFP 2008) [17] .

In the type system of Charguéraud and Pottier, all side effects are explicit. A function that wishes to write to a memory region must be passed a
*capability* over that region as an argument. A function has access to no capabilities other than those provided by its caller, so it is impossible for a function to have
*persistent, private state* .

The lack of private state can be considered a problem. It leads to a loss of modularity. Furthermore, it means that there is no satisfactory encoding of a traditional type system, such as ML's, into Charguéraud and Pottier's system.

Pottier has investigated this problem and extended Charguéraud and Pottier's system with a single new typing rule, known as the
*anti-frame rule* , which permits hidden state. This not only makes the system more expressive, but also sheds light on the essence of hidden state and of ML references. This work has strong connections with the higher-order frame rules found in separation logic. It was published and
presented at the Logic in Computer Science symposium (LICS 2008)
[22] .

#### Type-based complexity analysis

Participants : Alexandre Pilkiewicz, François Pottier.

Alexandre Pilkiewicz and François Pottier have investigated how type systems can be used to state and check complexity properties.

The goal is fairly simple: a function type should not only indicate what kind of argument a function expects, and what kind of result it produces, but also how much time it consumes. For instance, the types of the “push” and “pop” operations in a FIFO queue could indicate that these are constant-time operations; the type of a sorting algorithm could indicate that it requires time proportional to nlog n , where n is the length of the sequence that is being sorted. The type checker should be able to verify these claims.

The technical means that are being used are also quite simple. Pilkiewicz and Pottier begin with an existing linear type system. To this system, they add a linear type of
*credits* , representing units of computation time. Furthermore, they change the way in which function applications are typechecked, so that every function call requires (and consumes) a credit. They show that this approach is sound, and allows stating both worst-case and amortized
complexity estimates.