An Investigation of Contracts as Projections

April 1, 2004 version) Software contracts help programmers enforce program properties that the language’s type system cannot express. Unlike types, contracts are (usually) enforced at run-time. When a contract fails, the contract system signals an error. Beyond such errors, contracts should have no other observable (functional) effect on the program’s results. In most implementations, however, the language of contracts is the full-fledged programming language, which means that programmers may (intentionally or unintentionally) introduce visible effects into their contracts. Here we present the results of investigating the nature of contracts from a denotational perspective. Specifically, we use SPCF and the category of observably sequential functions to show that contracts are best understood as projections. Thus far, the investigation has produced a significantly faster contract implementation and the insight that our contract language cannot express all projections, which in turn has produced a new contract combinator. 1 Modeling Contracts Many programming languages support dynamically enforced software contracts [1, 2, 6, 8, 9, 11, 12, 15, 16, 17, 18, 19, 20, 21, 22, 23, 25, 26, 28]. With software contracts, programmers can state program invariants that the type system cannot express. Unlike types, however, contracts are not verified at compile time but monitored at run-time.1 When the contract monitor discovers that a contract does not hold for a particular function argument or result, it signals an error. Thus, contracts impose an overhead on the execution of programs, and contract system designers therefore provide a mechanism to disable contract monitoring. The nature of contract systems suggests that contracts should not affect the functional behavior of programs. Otherwise, running a program without contracts may produce different results than running programs with contracts, even 1Extended static checking [7] and soft typing [5] are efforts to validate contracts statically and to generate code to check those parts of the contract that cannot be verified. without any contract violations. Unfortunately, ensuring that contracts have no observable effects is a difficult task. Therefore the designers of software contracts simply ignore the problem and have programmers formulate contracts in the full-fledged programming language. To improve our understanding of this problem, we developed an operational model of a functional programming language with contracts, λCON [9]. That model specifies the meaning of the language and the meaning of contracts. In particular, it shows how to blame a specific program component for a contract violation. In this paper we present the results of investigating this setting from a denotational perspective. Specifically, we develop a denotational model of contracts using SPCF and the category of observably sequential functions [3, 4]. We chose SPCF because it has a purely functional (“standard”) model that is fully abstract and yet includes errors, exceptions, and a modicum of exception handling. It is thus possible to study contracts in a minimally realistic setting with pleasant mathematical properties. The goal of this effort is to characterize contracts mathematically and to use this characterization to improve contract systems. We start from the conjecture that software contracts are projections and then ask whether all syntactic contracts denote projections and whether our contract syntax expresses all projections. The answers—though not surprising in retrospect—have already improved the implementation of our contract system [10]. The paper’s organization follows this introduction. The next section informally explains contracts and why we use projections to model them. Then we recall the Cartesianclosed category of manifestly sequential functions and introduce SPCF, its syntax, types, and semantics. Based on this prelude, we formally introduce projections as contracts, answer the above questions, and discuss the implications for our implementation of contracts. 2 Contracts as Projections A contract in an imperative programming language consists of a pair of assertions for a procedure, i.e., a precondition on the arguments of the procedure and the state