The Damas-Milner Calculus is the typed -calculus underlying the type system for ML and several other strongly typed polymorphic functional languages such as Miranda 1 and Haskell. Mycroft has extended its problematic monomorphic typing rule for recursive definitions with a polymorphic typing rule. He proved the resulting type system, which we call the Milner-Mycroft Calculus, sound with respect to Milner's semantics, and showed that it preserves the principal typing property of the Damas-Milner Calculus. The extension is of practical significance in typed logic programming languages and, more generally, in any language with (mutually) recursive definitions. In this paper we show that the type inference problem for the Milner-Mycroft Calculus is log-space equivalent to semi-unification, the problem of solving subsumption inequations between first-order terms. This result has been proved independently by Kfoury, Tiuryn, and Urzyczyn. In connection with the recently establish...

There is significant room for improving users' experiences with model checking tools. An error trace produced by a model checker can be lengthy and is indicative of a symptom of an error. As a result, users can spend considerable time examining an error trace in order to understand the cause of the error. Moreover, even state-of-the-art model checkers provide an experience akin to that provided by parsers before syntactic error recovery was invented: they report a single error trace per run. The user has to fix the error and run the model checker again to find more error traces.

Type inference is the compile-time process of reconstructing missing type information in a program based on the usage of its variables. ML and Haskell are two languages where this aspect of compilation has enjoyed some popularity, allowing type information to be omitted while static type checking is still performed. Type inference may be expected to have some application in the prototyping and scripting languages which are becoming increasingly popular. A difficulty with type inference is the confusing and sometimes counter-intuitive diagnostics produced by the type checker as a result of type errors. A modification of the Hindley-Milner type inference algorithm is presented, which allows the specific reasoning which led to a program variable having a particular type to be recorded for type explanation. This approach is close to the intuitive process used in practice for debugging type errors. 1 Introduction Type inference refers to the compile-time process of reconstructing missing t...

Strongly-typed languages present programmers with compile-time feedback about the type correctness of programs. Errors during polymorphic type checking take the form of a unification failure for two types. Finding the source of the type error in the code is often difficult because the error may occur far from the spot where the inconsistency is detected. As functional languages use more and more complex type systems, the difficulty of interpreting and locating these errors will increase. To locate the source of type errors the programmer must unravel the long chain of deductions and type instantiations made during type reconstruction. This paper describes an approach that maintains the deductive steps of type inference and the reasons for type instantiations. The approach could be used in an interactive system to guide the programmer to the source of a type error or to explain why the compiler assigned a particular type to an expression. Categories and Subject Descriptors: D....

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...

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.

In the last ten years declaration-free programming languages with a polymorphic typing discipline (ML, B) have been developed to approximate the flexibility and conciseness of dynamically typed languages (LISP, SETL) while retaining the safety and execution efficiency of conventional statically typed languages (Algol68, Pascal). These polymorphic languages can be type checked at compile time, yet allow functions whose arguments range over a variety of types. We investigate several polymorphic type systems, the most powerful of which, termed Milner-Mycroft Calculus, extends the so-called let-polymorphism found in, e.g., ML with a polymorphic typing rule for recursive definitions. We show that semi-unification, the problem of solving inequalities over firstorder terms, characterizes type checking in the Milner-Mycroft Calculus to polynomial time, even in the restricted case where nested definitions are disallowed. This permits us to extend some infeasibility results for related combinato...

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