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.

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.

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.

Type systems for programming languages can be used by compilers to reject programs which are found to be potentially unsound and which may, therefore, fail to execute successfully. When a program is rejected the programmer must repair it so that it can be type-checked correctly and then executed safely. Diagnostic error messages are essential to help the programmer repair the program. Hindley-Milner type systems give the programmer a great deal of flexibility (polymorphism and implicit typing) while still ensuring type safety. As a consequence of this flexibility repairing mistakes can be difficult and programmers have previously observed that the type error messages produced by compilers are not helpful enough. This thesis examines the problem of producing more helpful error messages for ill-typed programs written in programming languages with a Hindley-Milner typing discipline. Three main results are described. Firstly, type inference algorithms which infer types in different orders are described, and the ability of these to produce more meaningful error messages is investigated. Secondly, the results of several other authors on helping explain type inference are condensed into a single generalisation. Thirdly, error messages which suggest concrete changes to the program to remove errors are produced using the theory of linear isomorphisms. This theory is implemented as an extension to the MLj compiler. Finally, extensions to Hindley-Milner are explored, taking the type system of MLj as an example.

Polymorphic types in programming languages facilitate code reuse, increase reliability and reduce semantic errors in programs. Hindley-Milner type inference forms a strong basis for checking polymorphic types but is less well suited to explaining them, as it introduces intermediate constructs that relate poorly to a programmer's understanding of the program.

The order in which unfications take place during type inference algorithms strongly determines where an error is detected. We use a constraint based type inferencer which separates between collecting, ordering, and solving constraints. We use a small set of combinators as part of the type rules to specify a degree of non-determinism in the order in which constraints may be solved. In the ordering phase, the user can make the type inference process (more) deterministic by choosing an appropriate ordering, yielding a large degree of control on his part: the scientist can easily compare the behaviors of various existing type inferencers and algorithms by describing them in terms of these orderings; the programmer can experiment with various orderings, and choose the one which suits his style of programming best. Compilers based on this technology naturally support multiple solvers, multiple error message for a single compilation, and using various orderings “in parallel”, so that the user can easily browse through different views on the type error. The framework has been implemented, and used to build the Helium compiler for the language Haskell.

www.cs.uu.nl Abstract. The problem of type correctness of a functional program can be formulated as a constraint satisfaction problem. Detecting that the set of constraints is inconsistent is not enough: to improve programming efficiency, finding the constraints that are most likely to be responsible for the inconsistency is crucial. Being able to indicate how the source program should be changed to resolve the inconsistency is yet another step forward. First, a collection of constraints is represented as a type graph. Then we propose heuristics that work on the type graph data structure, each of which may suggest reasons for inconsistencies by selecting a constraint. Some of the more domain specific heuristics can even show how the program may be corrected, by considering local reformulation of the constraint satisfaction problem.

Abstract. When students first learn programming, they often rely on a simple operational model of a program’s behavior to explain how particular features work. Because such models build on their earlier training in algebra, students find them intuitive, even obvious. Students learning type systems, however, have to confront an entirely different notation with a different semantics that many find difficult to understand. In this work, we begin to build the theoretical underpinnings for treating typechecking in a manner like the operational semantics of execution. Intuitively, each term is incrementally rewritten to its type. For example, each basic constant rewrites directly to its type and each lambda expression rewrites to an arrow type whose domain is the type of the lambda’s formal parameter and whose range is the body of the lambda expression which, in turn, rewrites to the range type. 1

Since version 1.5, generics (parametric polymorphism) are part of the Java language. However, adding parametric polymorphism to a language that is built on inclusion polymorphism can be confusing to a novice programmer, because the typing rules are suddenly different and, in the case of Generic Java, quite complex. Indeed, the main Java compilers, Eclipse’s ejc compiler and Sun’s javac, do not even accept the same set of programs. Moreover, experience with these compilers shows that the error messages provided by them leave more than a little to be desired. To alleviate the latter problem, we describe how to adapt the type inference process of Java to obtain better error diagnostics for generic method invocations. The extension has been implemented into the Jastad extensible Java compiler. 1 1