Static contract checking for Haskell

Xu, Dana N.; Jones, Simon Peyton; Claessen, Koen

doi:10.1145/1594834.1480889

Cited by 28 publications

(59 citation statements)

References 41 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A completely different but more powerful approach can be found in ESC/Haskell [38] and its successor [39]. ESC/Haskell is based on preconditions and contracts, so, it is able to detect far more defects in programs: pattern matching failures, division by zero, out of bounds array indexing, etc.…”

Section: Verification Toolsmentioning

confidence: 99%

GADTs meet their match: pattern-matching warnings that account for GADTs, guards, and laziness

et al. 2015

View full text Add to dashboard Cite

For ML and Haskell, accurate warnings when a function definition has redundant or missing patterns are mission critical. But today's compilers generate bogus warnings when the programmer uses guards (even simple ones), GADTs, pattern guards, or view patterns. We give the first algorithm that handles all these cases in a single, uniform framework, together with an implementation in GHC, and evidence of its utility in practice.

show abstract

Section: Verification Toolsmentioning

confidence: 99%

GADTs meet their match: pattern-matching warnings that account for GADTs, guards, and laziness

et al. 2015

View full text Add to dashboard Cite

show abstract

“…The key idea of nested Hoare triples is also similar to static contract checking for higher order languages [23,29], which requires a pure specification of any callback's behavior up front. It is also similar to [22], except that it relies on separation logic and is applied to a stronger heap abstraction.…”

Section: Related Workmentioning

confidence: 99%

Desynchronized Multi-State Abstractions for Open Programs in Dynamic Languages

Cox

Chang

Rival

2015

Programming Languages and Systems

View full text Add to dashboard Cite

Abstract. Dynamic language library developers face a challenging problem: ensuring that their libraries will behave correctly for a wide variety of client programs without having access to those client programs. This problem stems from the common use of two defining features for dynamic languages: callbacks into client code and complex manipulation of attribute names within objects. To remedy this problem, we introduce two state-spanning abstractions. To analyze callbacks, the first abstraction desynchronizes a heap, allowing partitions of the heap that may be affected by a callback to an unknown function to be frozen in the state prior to the call. To analyze object attribute manipulation, building upon an abstraction for dynamic language heaps, the second abstraction tracks attribute name/value pairs across the execution of a library. We implement these abstractions and use them to verify modular specifications of class-, trait-, and mixin-implementing libraries.

show abstract

“…http://dx.doi.org/10. 1145/2737924.2737971 when verification fails (e.g., Rondon et al [2008]; Xu et al [2009]; Kawaguchi et al [2010]; Vytiniotis et al [2013]; Tobin-Hochstadt and Van Horn [2012]; Nguyễn et al [2014]). …”

Section: Introductionmentioning

confidence: 99%

Relatively complete counterexamples for higher-order programs

Nguyen

Horn

2015

SIGPLAN Not.

View full text Add to dashboard Cite

In this paper, we study the problem of generating inputs to a higherorder program causing it to error. We first approach the problem in the setting of PCF, a typed, core functional language and contribute the first relatively complete method for constructing counterexamples for PCF programs. The method is relatively complete with respect to a first-order solver over the base types of PCF. In practice, this means an SMT solver can be used for the effective, automated generation of higher-order counterexamples for a large class of programs.We achieve this result by employing a novel form of symbolic execution for higher-order programs. The remarkable aspect of this symbolic execution is that even though symbolic higher-order inputs and values are considered, the path condition remains a first-order formula. Our handling of symbolic function application enables the reconstruction of higher-order counterexamples from this first-order formula.After establishing our main theoretical results, we sketch how to apply the approach to untyped, higher-order, stateful languages with first-class contracts and show how counterexample generation can be used to detect contract violations in this setting. To validate our approach, we implement a tool generating counterexamples for erroneous modules written in Racket.

show abstract

Static contract checking for Haskell

Cited by 28 publications

References 41 publications

GADTs meet their match: pattern-matching warnings that account for GADTs, guards, and laziness

GADTs meet their match: pattern-matching warnings that account for GADTs, guards, and laziness

Desynchronized Multi-State Abstractions for Open Programs in Dynamic Languages

Relatively complete counterexamples for higher-order programs

Contact Info

Product

Resources

About