Results 1  10
of
16
A theory of overloading
 ACM Transactions on Programming Languages and Systems (TOPLAS
, 2002
"... Abstract We introduce a novel approach for debugging illtyped 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 f ..."
Abstract

Cited by 53 (18 self)
 Add to MetaCart
Abstract We introduce a novel approach for debugging illtyped 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 Haskellstyle type class overloading. The approach has been implemented as part of the Chameleon system.
Type inference for guarded recursive data types
, 2005
"... Abstract. We consider type inference for guarded recursive data types (GRDTs) – a recent generalization of algebraic data types. We reduce type inference for GRDTs to unification under a mixed prefix. Thus, we obtain efficient type inference. Inference is incomplete because the set of type constrai ..."
Abstract

Cited by 16 (0 self)
 Add to MetaCart
Abstract. We consider type inference for guarded recursive data types (GRDTs) – a recent generalization of algebraic data types. We reduce type inference for GRDTs to unification under a mixed prefix. Thus, we obtain efficient type inference. Inference is incomplete because the set of type constraints allowed to appear in the type system is only a subset of those type constraints generated by type inference. Hence, inference only succeeds if the program is sufficiently type annotated. We present refined procedures to infer types incrementally and to assist the user in identifying which pieces of type information are missing. Additionally, we introduce procedures to test if a type is not principal and to find a principal type if one exists. 1
Type Inference for GADTs via Herbrand Constraint Abduction
, 2008
"... 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 usin ..."
Abstract

Cited by 13 (8 self)
 Add to MetaCart
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 “nonintuitive” 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.
Searching for TypeError Messages
, 2007
"... 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 illtyped programs. This work pursues a new approach to constructing compilers and presenting typeerror messages in which the typechecker i ..."
Abstract

Cited by 13 (0 self)
 Add to MetaCart
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 illtyped programs. This work pursues a new approach to constructing compilers and presenting typeerror messages in which the typechecker itself does not produce the messages. Instead, it is an oracle for a search procedure that finds similar programs that do typecheck. Our twofold 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.
Type class directives
 In Seventh International Symposium on Practical Aspects of Declarative Languages
, 2005
"... 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 propos ..."
Abstract

Cited by 9 (1 self)
 Add to MetaCart
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 highlevel 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.
Heuristics for type error discovery and recovery (revised
 Implementation of Functional Languages – IFL 2006, volume 4449, pages 199 – 216
, 2006
"... 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 responsibl ..."
Abstract

Cited by 6 (5 self)
 Add to MetaCart
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.
Type processing by constraint reasoning
 Pages 1–25 of: Proc. of APLAS’06. LNCS
, 2006
"... 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 ter ..."
Abstract

Cited by 4 (1 self)
 Add to MetaCart
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
The Chameleon System
 Source Code: Optimal UnionFind ufd rank make @ make(X) <=> root(X,0). findNode @ X ~> PX , find(X,R) <=> find(PX,R), X ~> R. findRoot @ root(X,_) \ find(X,R) <=> R=X. linkEq @ link(X,X) <=> true. linkLeft @ link(X,Y), root(X,RX) root(Y,RY) <=> RX >= RY 
, 2004
"... 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 ..."
Abstract

Cited by 4 (1 self)
 Add to MetaCart
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
Ordering type constraints: A structured approach
, 2005
"... 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 s ..."
Abstract

Cited by 3 (3 self)
 Add to MetaCart
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 nondeterminism 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.
A first attempt at type class directives
, 2004
"... www.cs.uu.nl A first attempt at type class directives ..."
Abstract

Cited by 1 (1 self)
 Add to MetaCart
www.cs.uu.nl A first attempt at type class directives