Results 1  10
of
72
Type Inference with Polymorphic Recursion
 Transactions on Programming Languages and Systems
, 1991
"... The DamasMilner Calculus is the typed Acalculus underlying the type system for ML and several other strongly typed polymorphic functional languages such as Mirandal and Haskell. Mycroft has extended its problematic monomorphic typing rule for recursive definitions with a polymorphic typing rule. H ..."
Abstract

Cited by 141 (1 self)
 Add to MetaCart
The DamasMilner Calculus is the typed Acalculus underlying the type system for ML and several other strongly typed polymorphic functional languages such as Mirandal 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 MilnerMycroft Calculus, sound with respect to Milnerâ€™s semantics, and showed that it preserves the principal typing property of the DamasMilner 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 MilnerMycroft Calculus is logspace equivalent to semiunification, the problem of solving subsumption inequations between firstorder terms. This result has been proved independently by Kfoury et al. In connection with the recently established undecidability of semiunification this implies that typability in the MilnerMycroft Calculus is undecidable. We present some reasons why type inference with polymorphic recursion appears to be practical despite its undecidability. This also sheds some light on the observed practicality of ML
From Symptom to Cause: Localizing Errors in Counterexample Traces
 In Principles of Programming Languages
, 2003
"... 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 ..."
Abstract

Cited by 115 (4 self)
 Add to MetaCart
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 stateoftheart 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.
What Are Principal Typings and What Are They Good For?
, 1995
"... We demonstrate the pragmatic value of the principal typing property, a property more general than ML's principal type property, by studying a type system with principal typings. The type system is based on rank 2 intersection types and is closely related to ML. Its principal typing property ..."
Abstract

Cited by 96 (0 self)
 Add to MetaCart
We demonstrate the pragmatic value of the principal typing property, a property more general than ML's principal type property, by studying a type system with principal typings. The type system is based on rank 2 intersection types and is closely related to ML. Its principal typing property provides elegant support for separate compilation, including "smartest recompilation" and incremental type inference, and for accurate type error messages. Moreover, it motivates a novel rule for typing recursive definitions that can type many examples of polymorphic recursion.
A Type System Equivalent to Flow Analysis
 ACM Transactions on Programming Languages and Systems
, 1995
"... Flowbased safety analysis of higherorder languages has been studied by Shivers, and Palsberg and Schwartzbach. Open until now is the problem of finding a type system that accepts exactly the same programs as safety analysis. In this paper we prove that Amadio and Cardelli's type system with s ..."
Abstract

Cited by 90 (16 self)
 Add to MetaCart
Flowbased safety analysis of higherorder languages has been studied by Shivers, and Palsberg and Schwartzbach. Open until now is the problem of finding a type system that accepts exactly the same programs as safety analysis. In this paper we prove that Amadio and Cardelli's type system with subtyping and recursive types accepts the same programs as a certain safety analysis. The proof involves mappings from types to flow information and back. As a result, we obtain an inference algorithm for the type system, thereby solving an open problem. 1 Introduction 1.1 Background Many program analyses for higherorder languages are based on flow analysis, also known as closure analysis. Examples include various analyses in the Standard ML of New Jersey compiler [3], and the bindingtime analyses for Scheme in the partial evaluators Schism [5] and Similix [4]. Such analyses have the advantage that they can be applied to untyped languages. This is in contrast to more traditional abstract inter...
Revised(4) report on the algorithmic language Scheme. http://wwwswiss.ai.mit.edu/ftpdir/schemereports/r4rs.ps
, 1991
"... ..."
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 58 (20 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.
Proofs about a Folklore LetPolymorphic Type Inference Algorithm
 ACM Transactions on Programming Languages and Systems
, 1998
"... The Hindley/Milner letpolymorphic type inference system has two different algorithms: one is the de facto standard Algorithm W that is bottomup (or contextinsensitive), and the other is a "folklore" algorithm that is topdown (or contextsensitive). Because the latter algorithm has not ..."
Abstract

Cited by 57 (1 self)
 Add to MetaCart
The Hindley/Milner letpolymorphic type inference system has two different algorithms: one is the de facto standard Algorithm W that is bottomup (or contextinsensitive), and the other is a "folklore" algorithm that is topdown (or contextsensitive). Because the latter algorithm has not been formally presented with its soundness and completeness proofs, and its relation with the W algorithm has not been rigorously investigated, its use in place of (or in combination with) W is not well founded. In this article, we formally define the contextsensitive, topdown type inference algorithm (named "M"), prove its soundness and completeness, and show a distinguishing property that M always stops earlier than W if the input program is ill typed. Our proofs can be seen as theoretical justifications for various typechecking strategies being used in practice.
Explaining Type Errors in Polymorphic Languages
 ACM Letters on Programming Languages and Systems
, 1994
"... Stronglytyped languages present programmers with compiletime 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 oc ..."
Abstract

Cited by 50 (0 self)
 Add to MetaCart
Stronglytyped languages present programmers with compiletime 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....
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 50 (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.
Type inference against races
 In SAS
, 2004
"... Abstract. The race condition checker rccjava uses a formal type system to statically identify potential race conditions in concurrent Java programs, but it requires programmersupplied type annotations. This paper describes a type inference algorithm for rccjava. Due to the interaction of parameteri ..."
Abstract

Cited by 48 (4 self)
 Add to MetaCart
Abstract. The race condition checker rccjava uses a formal type system to statically identify potential race conditions in concurrent Java programs, but it requires programmersupplied type annotations. This paper describes a type inference algorithm for rccjava. Due to the interaction of parameterized classes and dependent types, this type inference problem is NPcomplete. This complexity result motivates our new approach to type inference, which is via reduction to propositional satisfiability. This paper describes our type inference algorithm and its performance on programs of up to 30,000 lines of code. 1