Finding the source of type errors

Wand, Mitchell

doi:10.1145/512644.512648

Cited by 96 publications

(74 citation statements)

References 3 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Prior work has attempted to address this problem by reporting either the complete slice of the program relating to a type inference failure, or a smaller subset of unsatisfiable constraints [7,14,34,35]. Unfortunately, both variants of this approach can still require considerable manual effort to identify the actual error within the program slice, especially when the slice is large.…”

Section: Type Inferencementioning

confidence: 99%

“…We are motivated to study this problem based on experience with two programming languages: ML, whose unification-based type inference algorithm sometimes generates complex, even misleading error messages [35], and Jif [30], a version of Java that statically analyzes the security of information flow within programs but whose error messages also confuse programmers [19]. Prior work has explored a variety of methods for improving error reporting in each of these languages.…”

Section: Introductionmentioning

confidence: 99%

“…Unfortunately, this simple approach often results in misleading error messages-the actual error may be far from that program point. Another approach is to report all expressions that might contribute to the error (e.g., [7,14,34,35]). But such reports are often verbose and hard to understand [16].…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Toward general diagnosis of static errors

Zhang

Myers

2014

Proceedings of the 41st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages

View full text Add to dashboard Cite

We introduce a general way to locate programmer mistakes that are detected by static analyses such as type checking. The program analysis is expressed in a constraint language in which mistakes result in unsatisfiable constraints. Given an unsatisfiable system of constraints, both satisfiable and unsatisfiable constraints are analyzed, to identify the program expressions most likely to be the cause of unsatisfiability. The likelihood of different error explanations is evaluated under the assumption that the programmer's code is mostly correct, so the simplest explanations are chosen, following Bayesian principles. For analyses that rely on programmer-stated assumptions, the diagnosis also identifies assumptions likely to have been omitted. The new error diagnosis approach has been implemented for two very different program analyses: type inference in OCaml and information flow checking in Jif. The effectiveness of the approach is evaluated using previously collected programs containing errors. The results show that when compared to existing compilers and other tools, the general technique identifies the location of programmer errors significantly more accurately.

show abstract

Section: Type Inferencementioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Toward general diagnosis of static errors

Zhang

Myers

2014

Proceedings of the 41st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages

View full text Add to dashboard Cite

show abstract

“…Soosaipillai [29] maintains a list of the types inferred for each subexpression. Duggan and Bent [9] as well as Wand [30] retain a list of the instantiations of all type variables. This method is similar to Rémy's keeping around a constraint set corresponding to instantiations and unification problems.…”

Section: Related Workmentioning

confidence: 99%

A Rewriting Semantics for Type Inference

Kuan

MacQueen

Findler

2007

Programming Languages and Systems

View full text Add to dashboard Cite

Abstract. When students first learn programming, they often rely on a simple operational model of a program's behavior to explain how particular features work. Because such models build on their earlier training in algebra, students find them intuitive, even obvious. Students learning type systems, however, have to confront an entirely different notation with a different semantics that many find difficult to understand.In this work, we begin to build the theoretical underpinnings for treating type checking in a manner like the operational semantics of execution. Intuitively, each term is incrementally rewritten to its type. For example, each basic constant rewrites directly to its type and each lambda expression rewrites to an arrow type whose domain is the type of the lambda's formal parameter and whose range is the body of the lambda expression which, in turn, rewrites to the range type.

show abstract

“…A probably incomplete list includes [41,25,26,23,33,32,27,34,29,52,53,54,50,44,67,68]. Independently from this separation, there exist other approaches toward improving errors [66]: error explanation systems [8,20,19,65] which focus on explaining the reasoning steps leading to a type error, and error reporting systems [60,57,13] which focus on trying to precisely locate errors in pieces of code. There are also approaches that report type errors together with sugges-tions for changes that would solve the errors [28,38].…”

Section: Introductionmentioning

confidence: 99%

Skalpel: A constraint-based type error slicer for Standard ML

Rahli

Wells

Pirie

et al. 2017

Journal of Symbolic Computation

View full text Add to dashboard Cite

Compilers for languages with type inference algorithms often produce confusing type error messages and give a single error location which is sometimes far away from the real location of the error. Attempts at solving this problem often (1) fail to include the multiple program points which make up the type error; (2) report tree fragments which do not correspond to any place in the user program; and (3) give incorrect type information/diagnosis which can be highly confusing. We present Skalpel, a type error slicing tool which solves these problems by giving the programmer all and only the information involved with a type error to significantly aid in diagnosis and repair of type errors. Skalpel relies on a simple and general constraint system, a sophisticated constraint generator which is linear in program size, and a constraint solver which is terminating. Skalpel's constraint system can elegantly and efficiently handle intricate features such as SML's open. We also show that the Skalpel tool is general enough to deal not only with one source code file and one single error, but highlights all and only the possible locations of the error(s) in all affected files and produces all the culprit multiple program slices.

show abstract

Finding the source of type errors

Cited by 96 publications

References 3 publications

Toward general diagnosis of static errors

Toward general diagnosis of static errors

A Rewriting Semantics for Type Inference

Skalpel: A constraint-based type error slicer for Standard ML

Contact Info

Product

Resources

About