Sound and complete models of contracts

Abstract

Even in statically typed languages it is useful to have certain invariants checked dynamically. Findler and Felleisen gave an algorithm for dynamically checking expressive higher-order types called contracts. They did not, however, give a semantics of contracts. The lack of a semantics makes it impossible to define and prove soundness and completeness of the checking algorithm. (Given a semantics, a sound checker never reports violations that do not exist under that semantics; a complete checker is – in principle – able to find violations when violations exist.) Ideally, a semantics should capture what programmers intuitively feel is the meaning of a contract or otherwise clearly point out where intuition does not match reality. In this paper we give an interpretation of contracts for which we prove the Findler-Felleisen algorithm sound and (under reasonable assumptions) complete. While our semantics mostly matches intuition, it also exposes a problem with predicate contracts where an arguably more intuitive interpretation than ours would render the checking algorithm unsound. In our semantics we have to make use of a notion of safety (which we define in the paper) to avoid unsoundness. We are able to eliminate the “leakage” of safety into the semantics by changing the language, replacing the original version of unrestricted predicate contracts with a restricted form. The corresponding loss in expressive power can be recovered by making safety explicit as a contract. This can be done either in ad-hoc fashion or by including general recursive contracts. The addition of recursive contracts has far-reaching implications, deeply affecting the formulation of our model and requiring different techniques for proving soundness.

Computational contracts

“…As this pattern is often seen in the construction of pre/-post contracts, an extension called dependent contracts was proposed [12] . Dependent contracts allow the argument values of a contracted function to be captured when the contracted function is applied in such a manner that it is accessible in the postcondition of the contract 3 . The canonical example of a dependent contract is a refinement of the sqrt contract.…”

“…Dependent contracts thus fall into the category of contracts where a contract is assumed to be always correct. This was criticised by Blume and McAllester [3]. They extended the work on depended contracts so that the domain contract is enforced both in the precondition and in the postcondition of the dependent contract.…”

“…Finally there is a whole line of work [3,18,19,38] spawned from the higher-order contracts as highlighted in section 5.1. While the wide range of programming languages presented here clearly shows the need for DbC, all these contract frameworks are basically pre/post contract systems and do not allow the programmer to specify any constraints over the actual computation.…”

Complete Monitors for Behavioral Contracts

“…2. Blume and McAllester [1] propose an alternative picky semantics. According to their proposal, the contracts for f and fp prohibits their application to complex numbers, and their reuse catches contract-internal problems [6].…”

“…Monitors carry three labels: k, l and j. 1 Labels are identifiers for the high-level components that make up a program. A monitor splits a program into three components, dubbed the contract parties: a server named k, a client named l, and a contract named j, which may coincide with k or l in a programming language.…”