Abstract We introduce a novel approach for debugging ill-typed programs in the Hindley/Milner system. We map the typing problem for a program to a system of constraints each attached to program code that generates the constraints. We use reasoning about constraint satisfiability and implication to find minimal justifications of type errors, and to explain unexpected types that arise. Through an interactive process akin to declarative debugging, a user can track down exactly where a type error occurs. We are able to capture various extensions of the Hindley/Milner system such as type annotations and Haskell-style type class overloading. The approach has been implemented as part of the Chameleon system.

Abstract. The goal of this paper is to improve the type error messages inthepresenceofHaskell 98 type classes, in particular for the nonexpert user. As a language feature, type classes are very pervasive, and strongly influence what is reported and when, even in relatively simple programs. We propose four type class directives, and specialized type rules, to lend high-level support to compilers to improve the type error messages. Both have been implemented, and can be used to easily modify the behavior of the type inference process.

Advanced type systems often need some form of type inference to reduce the burden of explicit typing, but type inference often leads to poor error messages for ill-typed programs. This work pursues a new approach to constructing compilers and presenting typeerror messages in which the type-checker itself does not produce the messages. Instead, it is an oracle for a search procedure that finds similar programs that do type-check. Our two-fold goal is to improve error messages while simplifying compiler construction. Our primary implementation and evaluation is for Caml, a language with full type inference. We also present a prototype for C++ template functions, where type instantiation is implicit. A key extension is making our approach robust even when the program has multiple independent type errors.

Abstract. Herbrand constraint solving or unification has long been understood as an efficient mechanism for type checking and inference for programs using Hindley/Milner types. If we step back from the particular solving mechanisms used for Hindley/Milner types, and understand type operations in terms of constraints we not only give a basis for handling Hindley/Milner extensions, but also gain insight into type reasoning even on pure Hindley/Milner types, particularly for type errors. In this paper we consider typing problems as constraint problems and show which constraint algorithms are required to support various typing questions. We use a light weight constraint reasoning formalism, Constraint Handling Rules, to generate suitable algorithms for many popular extensions to Hindley/Milner types. The algorithms we discuss are all implemented as part of the freely available Chameleon system. 1

We give an overview of the major features of the Chameleon programming language, as well as use of the system, from a Haskell programmer's point of view. Chameleon supports typeclass overloading a la Haskell. The novelty of Chameleon is to allow the programmer to specify almost arbitrary conditions on type classes in terms of Constraint Handling Rules (CHRs). In fact, Chameleon's entire type inference system and evidence translation of programs is phrased in terms of CHRs. 1

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.

www.cs.uu.nl A first attempt at type class directives

We often need more expressive power. f r =... r.l...-- record selection f’s type should state that its first input value is a record which has at least a field labelledl. f:: ∀r,a,.... (r::< l: a>) record constraint ⇒ r →...

Type inference for Hindley/Milner and variants is well understood as a constraint solving problem. Recent extensions to Hindley/Milner such as generalized algebraic data types (GADTs) force us to go beyond this approach to inference. In this paper we show how to perform type inference for GADTs using Herbrand constraint abduction, a solving method to infer missing facts in terms of Herbrand constraints, i.e. conjunctions of type equations. But typeinference for GADTs is very hard, we are the first to give example programs with an infinite number of maximal types. We propose to rule out several kinds of “non-intuitive ” solutions and show that we can construct in this way a complete and decidable type inference approach for GADTs and sketch how to support type error diagnosis. Our results point out new direction how to perform type inference for expressive type systems.