Dynamic witnesses for static type errors (or, Ill-Typed Programs Usually Go Wrong)

Seidel, Eric L.; Jhala, Ranjit; Weimer, Westley

doi:10.1017/s0956796818000126

Cited by 6 publications

(5 citation statements)

References 46 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Type error debugging research has a vast history which covers a variety of solutions over a span of thirty-plus years [1,3,4,6,10,13,15,16,20,21,[23][24][25]30]. However, these solutions tended to need either a modified compiler or patch.…”

Section: Related Workmentioning

confidence: 99%

Refining the Delta Debugging of Type Errors

Sharrad

Chitil

2021

33rd Symposium on Implementation and Application of Functional Languages

View full text Add to dashboard Cite

show abstract

Section: Related Workmentioning

confidence: 99%

Refining the Delta Debugging of Type Errors

Sharrad

Chitil

2021

33rd Symposium on Implementation and Application of Functional Languages

View full text Add to dashboard Cite

show abstract

“…Since the seminal work of Wand [1986], which keeps track of all unification steps in order to help debugging, many algorithms have been proposed to better assist programmers. A large variety of techniques has been explored, including slicing [Haack and Wells 2003;Tip and Dinesh 2001], heuristics [Zhang et al 2015], SMT constraint solving [Pavlinovic et al 2014], counter-example generation [Nguyen and Horn 2015;Seidel et al 2016], machine learning [Seidel et al 2017], and other search-based approaches, such as Seminal [Lerner et al 2007] and counterfactual change inference .…”

Section: Related Workmentioning

confidence: 99%

“…Apart from Seidel et al [2016], which focuses on identifying dynamic witnesses for static refinement type errors, none of the above approaches target refinement types. In this work, we uncover a novel application of gradual typing for error explanation, by observing that the notion of concretizations of gradual types that stem from AGT, embed useful justifications (or lack thereof) that can be exploited to identify refinement errors and guide migration.…”

Section: Related Workmentioning

confidence: 99%

Gradual liquid type inference

Vazou

Tanter

Horn

2018

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Refinement types allow for lightweight program verification by enriching types types with logical predicates. Liquid typing provides a decidable refinement inference mechanism that is convenient but subject to two major issues: (1) inference is global and requires top-level annotations, making it unsuitable for inference of modular code components and prohibiting its applicability to library code, and (2) inference failure results in obscure error messages. These difficulties seriously hamper the migration of existing code to use refinements. This paper shows that gradual liquid type inference-a novel combination of liquid inference and gradual refinement types-addresses both issues. Gradual refinement types, which support imprecise predicates that are optimistically interpreted, can be used in argument positions to constrain liquid inference so that the global inference process effectively infers modular specifications usable for library components. Dually, when gradual refinements appear as the result of inference, they signal an inconsistency in the use of static refinements. Because liquid refinements are drawn from a finite set of predicates, in gradual liquid type inference we can enumerate the safe concretizations of each imprecise refinement, i.e. the static refinements that justify why a program is gradually well-typed. This enumeration is useful for static liquid type error explanation, since the safe concretizations exhibit all the potential inconsistencies that lead to static type errors.We develop the theory of gradual liquid type inference and explore its pragmatics in the setting of Liquid Haskell. To demonstrate the utility of our approach, we develop an interactive tool, GuiLT, for gradual liquid type inference in Liquid Haskell that both infers modular types and explores safe concretizations of gradual refinements. We report on the use of GuiLT for error reporting and discuss a case study on the migration of three commonly-used Haskell list manipulation libraries into Liquid Haskell. understanding error messages from liquid inference in turn makes it really hard to progressively migrate non-refined code to refined code, e.g. from Haskell to Liquid Haskell [Vazou et al. 2014b].For instance, consider the following function divIf that either inverts its argument x if it is positive, or inverts 1-x otherwise:The function relies on an imported function isPos of type Int → Bool. If we want to give divIf a refined type, liquid inference starts from the signature:and solves the predicate variables k x and k o based on the use sites. However, without any uses of divIf in the considered source code, and for reasons we will clarify in due course, liquid inference infers the useless refinements:The false refinement on the argument means that divIf is dead code, since liquid type inference relies on a closed world assumption; and divIf has, at inference time, no clients.Conversely, if the code base at inference time includes a "positive" client call divIf 1, the inferred precondition would be 0 < x, triggeri...

show abstract

“…Recently, Seidel et al (2016) developed an explanation approach from a very different perspective. Given an ill-typed expression, their approach finds an input such that the evaluation of the expression will fail with the given input.…”

Section: Reporting Single Locationsmentioning

confidence: 99%

Systematic identification and communication of type errors

Chen¹,

Erwig

2018

J. Funct. Prog.

View full text Add to dashboard Cite

When type inference fails, it is often difficult to pinpoint the cause of the type error among many potential candidates. Generating informative messages to remove the type error is another difficult task due to the limited availability of type information. Over the last three decades many approaches have been developed to help debug type errors. However, most of these methods suffer from one or more of the following problems: (1) Being incomplete, they miss the real cause. (2) They cover many potential causes without distinguishing them. (3) They provide little or no information for how to remove the type error. Any one of this problems can turn the type-error debugging process into a tedious and ineffective endeavor. To address this issue, we have developed a method named counter-factual typing, which (1) finds a comprehensive set of error causes in AST leaves, (2) computes an informative message on how to get rid of the type error for each error cause, and (3) ranks all messages and iteratively presents the message for the most likely error cause. The biggest technical challenge is the efficient generation of all error messages, which seems to be exponential in the size of the expression. We address this challenge by employing the idea of variational typing that systematically reuses computations for shared parts and generates all messages by typing the whole ill-typed expression only once. We have evaluated our approach over a large set of examples collected from previous publications in the literature. The evaluation result shows that our approach outperforms previous approaches and is computationally feasible.

show abstract

Dynamic witnesses for static type errors (or, Ill-Typed Programs Usually Go Wrong)

Cited by 6 publications

References 46 publications

Refining the Delta Debugging of Type Errors

Refining the Delta Debugging of Type Errors

Gradual liquid type inference

Systematic identification and communication of type errors

Contact Info

Product

Resources

About