Computational contracts

Scholliers, Christophe; Tanter, Éric; Meuter, Wolfgang De

doi:10.1016/j.scico.2013.09.005

Cited by 14 publications

(8 citation statements)

References 42 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Thus, protocols are a natural extension for Racket's contract system. In general, there have been some steps towards protocol contracts Disney et al 2011;Heidegger et al 2012;Moore et al 2016Moore et al , 2014Scholliers et al 2015], but understanding how to design and implement them remains largely an open research question.…”

Section: Lessons Learnedmentioning

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

Section: Lessons Learnedmentioning

confidence: 99%

Does blame shifting work?

Lazarek

King

Sundar

et al. 2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

show abstract

“…The interplay between higher-order contracts and behavioral/temporal aspects of modules, such as restricting the order in which functions can be invoked, has been previously addressed by Disney et al [2011] and Scholliers et al [2015]. In both approaches, the enforcement of temporal constraints is done dynamically and the contract language allows for the specification of both allowed and disallowed traces.…”

Section: Related Workmentioning

confidence: 99%

“…On the contrary, in λCoS, the usage of endpoints is regulated by a combination of static and dynamic constraints: static constraints are enforced by session types, which guarantee that processes use session endpoints according to their protocol; dynamic constraints, which concern the content of exchanged messages and may affect the selection and availability of choices and branches (Section 6.3), are checked at runtime by monitors. None of the previous works on behavioral/temporal contracts Scholliers et al [2015], Disney et al [2011] provides a characterisation of module correctness or a formal statement about the correctness of blame assignment akin to our blame soundness result (Section 5). Swords et al [2015] proposed λ CC , a language tailored to the implementation of alternative approaches to monitoring, and discussed a possible implementation of the temporal contracts of Disney et al [2011] on top of λ CC .…”

Section: Related Workmentioning

confidence: 99%

Chaperone contracts for higher-order sessions

Melgratti

Padovani

2017

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Contracts have proved to be an effective mechanism that helps developers in identifying those modules of a program that violate the contracts of the functions and objects they use. In recent years, sessions have been established as a key mechanism for realizing inter-module communications in concurrent programs. Just like values flow into or out of a function or object, messages are sent on, and received from, a session endpoint. Unlike conventional functions and objects, however, the kind, direction, and properties of messages exchanged in a session may vary over time, as the session progresses. This feature of sessions calls for contracts that evolve along with the session they describe.In this work, we extend to sessions the notion of chaperone contract (roughly, a contract that applies to a mutable object) and investigate the ramifications of contract monitoring in a higher-order language that features sessions. We give a characterization of a correct module, one that honors the contracts of the sessions it uses, and prove a blame theorem. Guided by the calculus, we describe a lightweight implementation of monitored sessions as an OCaml module with which programmers can benefit from static session type checking and dynamic contract monitoring using an off-the-shelf version of OCaml.

show abstract

“…Their work is closer to the use of tags than effect annotations in the framework of Marino & Millstein (2009), as it focuses on annotations on values and on atomic types instead of function types, with the goal of gradualizing the annotation part of annotated type systems. Extensions to contract systems for higher order functions (Findler & Felleisen, 2002), such as computational contracts (Scholliers et al, 2015) and temporal contracts , have the ability to monitor for the occurrence of specific (sequences of) execution events, in particular effectful operations. These approaches rely on full runtime monitoring; it is not clear if they could be reconciled with the pay-as-you-go model of gradual checking.…”

Section: Related Workmentioning

confidence: 99%

Gradual type-and-effect systems

Schwerter¹,

García²,

Tanter³

2016

J. Funct. Prog.

Self Cite

View full text Add to dashboard Cite

Effect systems have the potential to help software developers, but their practical adoption has been very limited. We conjecture that this limited adoption is due in part to the difficulty of transitioning from a system where effects are implicit and unrestricted to a system with a static effect discipline, which must settle for conservative checking in order to be decidable. To address this hindrance, we develop a theory of gradual effect checking, which makes it possible to incrementally annotate and statically check effects, while still rejecting statically inconsistent programs. We extend the generic type-and-effect framework of Marino and Millstein with a notion of unknown effects, which turns out to be significantly more subtle than unknown types in traditional gradual typing. We appeal to abstract interpretation to develop and validate the concepts of gradual effect checking. We also demonstrate how an effect system formulated in the framework of Marino and Millstein can be automatically extended to support gradual checking. We use gradual effect checking to develop a fully gradual type-and-effect framework, which permits interaction between static and dynamic checking for both effects and types

show abstract

Computational contracts

Cited by 14 publications

References 42 publications

Does blame shifting work?

Does blame shifting work?

Chaperone contracts for higher-order sessions

Gradual type-and-effect systems

Contact Info

Product

Resources

About