Option contracts

Abstract

Many languages support behavioral software contracts so that programmers can describe a component's obligations and promises via logical assertions in its interface. The contract system monitors program execution, checks whether the assertions hold, and, if not, blames the guilty component. Pinning down the violator gets the debugging process started in the right direction. Quality contracts impose a serious runtime cost, however, and programmers therefore compromise in many ways. Some turn off contracts for deployment, but then contracts and code quickly get out of sync during maintenance. Others test contracts randomly or probabilistically. In all cases, programmers have to cope with lack of blame information when the program eventually fails.In response, we propose option contracts as an addition to the contract tool box. Our key insight is that in ordinary contract systems, server components impose their contract on client components, giving them no choice whether to trust the server's promises or check them. With option contracts, server components may choose to tag a contract as an option and clients may choose to exercise the option or accept it, in which case they also shoulder some responsibility. We show that option contracts permit programmers to specify flexible checking policies, that their cost is reasonable, and that they satisfy a complete monitoring theorem.

Refinement Type Contracts for Verification of Scientific Investigative Software

“…Paranoid Scientist has not been optimized for speed, though such optimization is possible in the future. Previous work has demonstrated improved performance of runtime checks through a client-server architecture [10] and through optional contracts [11]. Performance could also be improved by producing a certificate during runtime which can be checked after execution.…”

An extended account of contract monitoring strategies as patterns of communication

“…Dimoulas et al (2013) introduce option contracts, which allow modules to optionally enforce contracts or eschew contracts while adopting responsibility, avoiding unnecessary contract enforcement. It is possible to replicate this behavior in λ ⇒ /c , using the same pattern of encoding and structures as Dimoulas et al (2013) in the presence of the option strategy. Such an implementation would be particularly effective in a chaperone-based system.…”

“…Researchers have proposed myriad contract enforcement strategies in response to these rising complexities, including lazy monitors (Degen et al, 2009;Chitil, 2012), concurrent monitoring systems (Dimoulas et al, 2009), optional enforcement (Dimoulas et al, 2013), and probabilistic contract verification (Moore et al, 2016;Hickey, 2018).…”

“…These questions do not have definitive "yes-or-no" answers, but each represent a gradient of answers has led to a number of semantic specifications for verification monitors that each take different stances on these questions. For example, the option contract system presented by Dimoulas et al (2013) suggests that we should sometimes treat contracts as specifications we must verify, waiting while we do, and the user program plays a role in verification by choosing to postpone or eschew contracts. At the other end of the spectrum, we can eschew complete verification and removing the user's role in verification, but still suspend the program to check contracts, while we get spot-checking systems similar to those described by Ergün et al (1998).…”

SuperContra: Cross-Language, Cross-Runtime Contracts as a Service

“…SuperContra goes beyond such approaches to provide DbC that is both language and run-time agnostic. Other DbC advances target runtime overhead [24] and the complexity of writing contracts [25], [26]. SuperContra shares this motivation, but addresses the problem in a different way.…”