Note: This document accompanies the paper “Practical type inference for arbitrary-rank types ” [6]. Prior reading of the main paper is required. 1 Contents

Previous methods have generally identified the location of a type error as a particular program point or the program subtree rooted at that point. We present a new approach that identifies the location of a type error as a set of program points (a slice) all of which are necessary for the type error. We identify the criteria of completeness and minimality for type error slices. We discuss the advantages of complete and minimal type error slices over previous methods of presenting type errors. We present and prove the correctness of algorithms for finding complete and minimal type error slices for implicitly typed higher-order languages like Standard ML.

To improve the quality of type error messages in functional programming languages, we propose four techniques which influence the behaviour of constraint-based type inference processes. These techniques take the form of externally supplied type inference directives, precluding the need to make any changes to the compiler. A second advantage is that the directives are automatically checked for soundness with respect to the underlying type system. We show how the techniques can be used to improve the type error messages reported for a combinator library. More specifically, how they can help to generate error messages which are conceptually closer to the domain for which the library was developed. The techniques have all been incorporated in the Helium compiler, which implements a large subset of Haskell.

. Traditional type inference and type checking algorithms work well with correctly typed programs, but their results when given programs containing type errors can be unpredictable. This leads to a problem with implementations of type checkers: they are often inaccurate when announcing the apparent locations of mistakes in programs, tending to notice problems towards the end of the program even if the mistake occurs much earlier. This is a particular problem with programming languages with Hindley-Milner type systems such as used by Standard ML. A common technique for type inference is unification. Unifying types creates substitutions which are applied to types and type environments. The substitutions which have been applied to the type environment influence whether type errors are encountered in particular subexpressions of a program. This paper defines the operation of unifying substitutions and shows how type inference algorithms can be modified to use this operation to delay the ap...

Deforestation optimises a functional program by transforming it into another one that does not create certain intermediate data structures. Short cut deforestation is a deforestation method which is based on a single, local transformation rule. In return, short cut deforestation expects both producer and consumer of the intermediate structure in a certain form. Warm fusion was proposed to automatically transform functions into this form. Unfortunately, it is costly and hard to implement. Starting from the fact that short cut deforestation is based on a parametricity theorem of the second-order typed λ-calculus, we show how the required form of a list producer can be derived through the use of type inference. Typability for the second-order typed λ-calculus is undecidable. However, we present a linear-time algorithm that solves a partial type inference problem and that, together with controlled inlining and polymorphic type instantiation, suffices for deforestation. The resulting new sho...

The type systems of most typed functional programming languages are based on the Hindley-Milner type system. A practical problem with these type systems is that it is often hard to understand why a program is not type correct or a function does not have the intended type. We suggest that at the core of this problem is the difficulty of explaining why a given expression has a certain type. The type system is not defined compositionally. We propose to explain types using a variant of the Hindley-Milner type system that defines a compositional type explanation graph of principal typings. We describe how the programmer understands types by interactive navigation through the explanation graph. Furthermore, the explanation graph can be the foundation for algorithmic debugging of type errors, that is, semi-automatic localisation of the source of a type error without even having to understand the type inference steps. We implemented a prototype of a tool to explore the usefulness of the proposed methods.

. The error reports produced by compilers for languages with polymorphic type inference are often uninformative. Several attempts have been made to produce improved error reports. We dene a manifesto for good error reports and use it to evaluate both the traditional algorithms, and several improved algorithms, including two of our own devising. 1 Introduction Debugging type errors in programs written in polymorphic languages with type inference is hard [13, 7]. One reason is that much type information is implicit | inferred by the compiler. An error occurs in type inference when two uses of a program variable are found to be in conict, where each use occurs in some program text that we call a site. These concepts are best illustrated with an example. In Figure 1, inference proceeds left-to-right, initially assigning a type variable 'a to the function parameter x. From the rst use of x, sited at x 1, the algorithm infers that x is a function from integer to some unknown type, i....

We show a type-based method for useless variable elimination, i.e., transformation that eliminates variables whose values contribute nothing to the final outcome of a computation, and prove its correctness. The algorithm is a surprisingly simple extension of the usual type reconstruction algorithm. Our method seems more attractive than Wand and Siveroni's 0CFA-based method in many respects. First, it is efficient: it runs in time almost linear in the size of an input expression for a simply-typed -calculus, while the 0CFA-based method may require a cubic time. Second, our transformation can be shown to be optimal among those that preserve well-typedness, both for the simply-typed language and for an ML-style polymorphically-typed language. On the other hand, the 0CFA-based method is not optimal for the polymophically-typed language. ANY OTHER IDENTIFYING INFORMATION OF THIS REPORT Summary has been submitted for publication. Up-to-date version of this report will be available through ...

Typically a type error is reported when unification fails, even though the programmer 's actual error may have occurred much earlier in the program. The and inference algorithms report the site where a type conflict is detected, but the error message is isolated information: it is not clear what the relationship is between the site where error is reported and the context in which the subexpression was typed. As a result, the error message may give little help to locate the source of the error. This report investigates better methods of explaining type conflicts. We aim to find a method that may be effective even when the user has little knowledge of type checking. The philosophy of our approach is to find sources of type errors by reporting which parts of the program conflict, rather than isolated error sites. We implement two new inference algorithms with this philosophy: the Unification of Assumption Environments ( AE) and the Incremented Error Inference ( ). 1

This chapter introduces a novel system for generating type error messages which suggest ways of repairing mistakes. Both the theory behind this, and the implementation (as part of the MLj compiler) are described.