Abstract not found

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 not found

with constraints. The basic idea is to factor out the common core of previous extensions of the Hindley/Milner system. I present a Hindley/Milner system where the constraint part is a parameter. Speci c applications can be obtained by providing speci c constraint systems which capture the application in mind. For instance, the Hindley/Milner system can be recovered by instantiating the constraint part to the standard Herbrand constraint system. Type system instances of the general framework are sound if the underlying constraint system is sound. Furthermore, I give a generic type inference algorithm for the general framework, under sucient conditions on the speci c constraint system type inference yields principal types.

Abstract not found

This paper presents the first machine-checked verification of Milner's type inference algorithm W for computing the most general type of an untyped -term enriched with let-expressions. This term language is the core of most typed functional programming languages and is also known as Mini-ML. We show how to model all the concepts involved, in particular types and type schemes, substitutions, and the thorny issue of "new" variables. Only a few key proofs are discussed in detail. The theories and proofs are developed in Isabelle/HOL, the HOL instantiation of the generic theorem prover Isabelle.

. This article presents a type system based on the DamasMilner system[DM82], that supports overloading. Types of overloaded symbols are constrained polymorphic types. The work is related to Haskell type classes[Wad89,NP93,HHJW96], System O[OWW95] and other similar type systems[Kae88,Smi91,Jon94,DCO96]. Restrictions imposed in these systems with respect to overloading are eliminated. User-defined global and local overloading is supported without restrictions. There is no need for declarations or annotations of any sort. No language construct is added in order to cope with overloading. The type system uses a context-dependent overloading policy, specified by a predicate used in a single inference rule. Overloading of functions defined over different type constructors is supported, as done with Haskell's constructor classes. No monomorphism restriction is required in order to solve ambiguity problems. The system uses an open-world approach, in which new overloaded definition...

Proof tools must be well designed if they...

The type systems of functional languages such as Haskell have recently become more powerful and expressive. They not only allow programmers to write code that works on values of any type (genericity), they also allow programmers to require that a particular type belongs to a given type class (constrained genericity). Such code may use any of the methods listed in the interface of the type class, since every type that is a member of the type class must implement those methods. This capability makes it significantly easier to express solutions to many common problems, and promotes code reuse. Incorporating type classes in a logic programming language provides some new challenges. In this paper, we explain how we have extended Mercury's type system to include support for type classes. We give a formal semantics for this extension to our type system, adapting the typing rules used in functional languages to the differing demands of logic programming languages. We show that type classes in...

In this paper we present an implementation of the general system for type inference algorithms HM(X) using Prolog and Constraint Handling Rules. In our implementation the difference between the general aspects of the type inference algorithms and the constraint resolution module becomes more clear when compared to other implementations of the same systems, usually made in a functional programming language. In the constraint module solving equality constraints, here implemented by Prolog unification, is completely separated from constraint simplification which is made by a solver implemented in CHR for each system. CHR rules become a clear and natural way of specifying the simpli cation mechanism.