Results 1  10
of
32
Practical type inference for arbitraryrank types
 Journal of Functional Programming
, 2005
"... Note: This document accompanies the paper “Practical type inference for arbitraryrank types ” [6]. Prior reading of the main paper is required. 1 Contents ..."
Abstract

Cited by 91 (23 self)
 Add to MetaCart
Note: This document accompanies the paper “Practical type inference for arbitraryrank types ” [6]. Prior reading of the main paper is required. 1 Contents
Type Error Slicing in Implicitly Typed HigherOrder Languages
, 2004
"... 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 ..."
Abstract

Cited by 45 (3 self)
 Add to MetaCart
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 higherorder languages like Standard ML.
Scripting the Type Inference Process
, 2003
"... To improve the quality of type error messages in functional programming languages, we propose four techniques which influence the behaviour of constraintbased type inference processes. These techniques take the form of externally supplied type inference directives, precluding the need to make any c ..."
Abstract

Cited by 30 (15 self)
 Add to MetaCart
To improve the quality of type error messages in functional programming languages, we propose four techniques which influence the behaviour of constraintbased 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.
On the Unification of Substitutions in Type Inference
 Implementation of Functional Languages (IFL ’98
, 1998
"... . 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 ..."
Abstract

Cited by 26 (3 self)
 Add to MetaCart
. 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 HindleyMilner 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...
Type Inference Builds a Short Cut to Deforestation
, 1999
"... Deforestation optimises a functional program by transforming it into another one that does not create certain intermediate data structures. Short cut deforestation is a deforestation method which is based on a single, local transformation rule. In return, short cut deforestation expects both produce ..."
Abstract

Cited by 25 (2 self)
 Add to MetaCart
Deforestation optimises a functional program by transforming it into another one that does not create certain intermediate data structures. Short cut deforestation is a deforestation method which is based on a single, local transformation rule. In return, short cut deforestation expects both producer and consumer of the intermediate structure in a certain form. Warm fusion was proposed to automatically transform functions into this form. Unfortunately, it is costly and hard to implement. Starting from the fact that short cut deforestation is based on a parametricity theorem of the secondorder typed λcalculus, we show how the required form of a list producer can be derived through the use of type inference. Typability for the secondorder typed λcalculus is undecidable. However, we present a lineartime algorithm that solves a partial type inference problem and that, together with controlled inlining and polymorphic type instantiation, suffices for deforestation. The resulting new sho...
Compositional Explanation of Types and Algorithmic Debugging of Type Errors
, 2001
"... The type systems of most typed functional programming languages are based on the HindleyMilner 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 ..."
Abstract

Cited by 23 (0 self)
 Add to MetaCart
The type systems of most typed functional programming languages are based on the HindleyMilner 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 HindleyMilner 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, semiautomatic 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.
TypeBased Useless Variable Elimination
, 1999
"... We show a typebased method for useless variable elimination, i.e., transformation that eliminates variables whose values contribute nothing to the final outcome of a computation, and prove its correctness. The algorithm is a surprisingly simple extension of the usual type reconstruction algorithm. ..."
Abstract

Cited by 20 (4 self)
 Add to MetaCart
We show a typebased method for useless variable elimination, i.e., transformation that eliminates variables whose values contribute nothing to the final outcome of a computation, and prove its correctness. The algorithm is a surprisingly simple extension of the usual type reconstruction algorithm. Our method seems more attractive than Wand and Siveroni's 0CFAbased method in many respects. First, it is efficient: it runs in time almost linear in the size of an input expression for a simplytyped calculus, while the 0CFAbased method may require a cubic time. Second, our transformation can be shown to be optimal among those that preserve welltypedness, both for the simplytyped language and for an MLstyle polymorphicallytyped language. On the other hand, the 0CFAbased method is not optimal for the polymophicallytyped language. ANY OTHER IDENTIFYING INFORMATION OF THIS REPORT Summary has been submitted for publication. Uptodate version of this report will be available through ...
Improved Type Error Reporting
 In Proceedings of 12th International Workshop on Implementation of Functional Languages
, 2000
"... . The error reports produced by compilers for languages with polymorphic type inference are often uninformative. Several attempts have been made to produce improved error reports. We dene a manifesto for good error reports and use it to evaluate both the traditional algorithms, and several improv ..."
Abstract

Cited by 19 (1 self)
 Add to MetaCart
. The error reports produced by compilers for languages with polymorphic type inference are often uninformative. Several attempts have been made to produce improved error reports. We dene a manifesto for good error reports and use it to evaluate both the traditional algorithms, and several improved algorithms, including two of our own devising. 1 Introduction Debugging type errors in programs written in polymorphic languages with type inference is hard [13, 7]. One reason is that much type information is implicit  inferred by the compiler. An error occurs in type inference when two uses of a program variable are found to be in conict, where each use occurs in some program text that we call a site. These concepts are best illustrated with an example. In Figure 1, inference proceeds lefttoright, initially assigning a type variable 'a to the function parameter x. From the rst use of x, sited at x 1, the algorithm infers that x is a function from integer to some unknown type, i....
Explaining Type Errors by Finding the Source of a Type Conflict
 In Greg Michaelson, Phil Trindler, and HansWolfgang Loidl, editors, Trends in Functional Programming
, 2000
"... 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 ..."
Abstract

Cited by 19 (1 self)
 Add to MetaCart
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
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.