Eager and delayed contract monitoring for call-by-value and call-by-name evaluation

Degen, Markus; Thiemann, Peter; Wehr, Stefan

doi:10.1016/j.jlap.2010.07.006

Cited by 8 publications

(15 citation statements)

References 4 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The SAGE system [Knowles et al 2006] combines dynamic contract checking with extended static checking and thus it resides between tight contract satisfaction and loose contract satisfaction on the horizontal axis and between run-time checking and static analysis on the vertical axis. Degen et al [2010] develop an eager contract system for an eager language and an eager and a 1 : [Xu et al 2009], 2: [Knowles et al 2006], 3: [Findler and Felleisen 2002] 4: [Hinze et al 2006], 5: [Degen et al 2010], 6: [Chitil et al 2003] Fig. 1.…”

Section: Resultsmentioning

confidence: 99%

“…Again, the literature differs on this view, with Xu et al [2009] suggesting that the above example should trigger an error and with Chitil et al [2003] arguing that the contract should be ignored for being too strict. Degen et al [2010] study the different approaches to contract checking for lazy languages: they formulate and implement an eager and a delayed contract checking system for a lazy language and compare them using monadic semantics. On this basis, they show that eager contract checking does not satisfy contract idempotence unless severe restrictions are imposed on contracts.…”

Section: Pragmatics Of Contractsmentioning

confidence: 99%

See 1 more Smart Citation

On contract satisfaction in a higher-order world

Dimoulas

Felleisen

2011

ACM Trans. Program. Lang. Syst.

View full text Add to dashboard Cite

Behavioral software contracts have become a popular mechanism for specifying and ensuring logical claims about a program's flow of values. While contracts for first-order functions come with a natural interpretation and are well understood, the various incarnations of higher-order contracts adopt, implicitly or explicitly, different views concerning the meaning of contract satisfaction. In this paper, we define various notions of contract satisfaction in terms of observational equivalence and compare them with each other and notions in the literature. Specifically, we introduce a small model language with higher-order contracts and use it to formalize different notions of contract satisfaction. Each of them demands that the contract parties satisfy certain observational equivalences.

show abstract

Section: Resultsmentioning

confidence: 99%

Section: Pragmatics Of Contractsmentioning

confidence: 99%

On contract satisfaction in a higher-order world

Dimoulas

Felleisen

2011

ACM Trans. Program. Lang. Syst.

View full text Add to dashboard Cite

show abstract

“…Findler and Felleisen [2002] use delayed checks to lift contracts to the world of higher order functions. This work has since led to a significant body of research on the design of higher order contract systems [Disney et al 2011;Feltey et al 2018;Findler and Blume 2006;Findler et al 2007;Greenberg 2015;Greenberg et al 2010;Heidegger et al 2012;Hinze et al 2006;Jia et al 2016;Keil and Thiemann 2015;Moore et al 2016Moore et al , 2014Scholliers et al 2015;Strickland and Felleisen 2009a,b;Swords et al 2015;Takikawa et al 2012;Waye et al 2017] and their semantics [Blume and McAllester 2006;Degen et al 2008Degen et al , 2009Degen et al , 2010Degen et al , 2012Findler et al 2004].…”

Section: Contracts and Blamementioning

confidence: 99%

Does blame shifting work?

Lazarek

King

Sundar

et al. 2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Contract systems, especially of the higher-order flavor, go hand in hand with blame. The pragmatic purpose of blame is to narrow down the code that a programmer needs to examine to locate the bug when the contract system discovers a contract violation. Or so the literature on higher-order contracts claims. In reality, however, there is neither empirical nor theoretical evidence that connects blame with the location of bugs. The reputation of blame as a tool for weeding out bugs rests on anecdotes about how programmers use contracts to shift blame and their attention from one part of a program to another until they discover the source of the problem. This paper aims to fill the apparent gap and shed light to the relation between blame and bugs. To that end, we introduce an empirical methodology for investigating whether, for a given contract system, it is possible to translate blame information to the location of bugs in a systematic manner. Our methodology is inspired by how programmers attempt to increase the precision of the contracts of a blamed component in order to shift blame to another component, which becomes the next candidate for containing the bug. In particular, we construct a framework that enables us to ask for a contract system whether (i) the process of blame shifting causes blame to eventually settle to the component that contains the bug; and (ii) every shift moves blame łcloserž to the faulty component. Our methodology offers a rigorous means for evaluating the pragmatics of contract systems, and we employ it to analyze Racket's contract system. Along the way, we uncover subtle points about the pragmatic meaning of contracts and blame in Racket: (i) the expressiveness of Racket's off-the-shelf contract language is not sufficient to narrow down the blamed portion of the code to the faulty component in all cases; and (ii) contracts that trigger state changes (even unexpectedly, perhaps in the runtime system's data structures or caches) interfere with program evaluation in subtle ways and thus blame shifting can lead programmers on a detour when searching for a bug. These points highlight how evaluations such as ours suggest fixes to language design. CCS Concepts: • Theory of computation → Program specifications; • Software and its engineering → Empirical software validation.

show abstract

“…The over-evaluation in eager verification suggests an immediate alternative: we may maintain the user program suspension during verification, but postpone each individual contract's verification until the program demands the contracted value. This semi-eager verification strategy, originally presented by Hinze et al (2006) and later refined (Findler et al, 2008;Degen et al, 2009;Degen et al, 2010;Chitil, 2012), specifies that only those values the program uses will have their contracts verified.…”

Section: Semi-eager Verificationmentioning

confidence: 99%

“…Eager contract enforcement for software contracts, first presented by Meyer (1992), brought into the functional world by Findler & Felleisen (2002), and repeatedly refined (Ou et al, 2004;Findler & Blume, 2006;Flanagan, 2006;Degen et al, 2009;Degen et al, 2010;Greenberg et al, 2010;, presents the idea that contracts are fully-verified specifications, over-evaluating their input to ensure the contract holds while the user program waits for the verification result. To demonstrate this behavior, consider eagerly monitoring nat/c: (λx.…”

Section: Eager Verificationmentioning

confidence: 99%

An extended account of contract monitoring strategies as patterns of communication

Swords¹,

Sabry²,

Tobin-Hochstadt³

2018

J. Funct. Prog.

View full text Add to dashboard Cite

Contract systems have come to play a vital role in many aspects of software engineering. This has resulted in a wide variety of approaches to enforcing contracts—ranging from the straightforward pre-condition and post-condition checking of Eiffel to lazy, optional, and parallel enforcement strategies. Each of these approaches has its merits, but each has required ground-up development of an entire contract monitoring system. We present a unified approach to understanding this variety, while also opening the door to as-yet-undiscovered strategies. By observing that contracts are fundamentally about communication between a program and a monitor, we reframe contract checking as communication between concurrent processes. This brings out the underlying relations between widely studied enforcement strategies, including strict and lazy enforcement as well as concurrent approaches, including new contracts and strategies. We show how each of these can be embedded into a core calculus, and demonstrate a proof (via simulation) of correctness for one such encoding. Finally, we show that our approach suggests new monitoring approaches and contracts not previously expressible.

show abstract

Eager and delayed contract monitoring for call-by-value and call-by-name evaluation

Cited by 8 publications

References 4 publications

On contract satisfaction in a higher-order world

On contract satisfaction in a higher-order world

Does blame shifting work?

An extended account of contract monitoring strategies as patterns of communication

Contact Info

Product

Resources

About