Temporal higher-order contracts

Abstract

Behavioral contracts are embraced by software engineers because they document module interfaces, detect interface violations, and help identify faulty modules (packages, classes, functions, etc). This paper extends prior higher-order contract systems to also express and enforce temporal properties, which are common in software systems with imperative state, but which are mostly left implicit or are at best informally specified. The paper presents both a programmatic contract API as well as a temporal contract language, and reports on experience and performance results from implementing these contracts in Racket.Our development formalizes module behavior as a trace of events such as function calls and returns. Our contract system provides both non-interference (where contracts cannot influence correct executions) and also a notion of completeness (where contracts can enforce any decidable, prefix-closed predicate on event traces). Categories and Subject Descriptors Contract ExpressivenessLarge software systems typically consist of many modules (e.g., packages, classes, functions) produced by different development teams. When the system fails, an initial difficulty is fault localization: identifying the module that failed to perform as expected. Undocumented module interfaces are problematic for various reasons, not least because they lead to disagreements about which module is considered "at fault" and should be fixed.Software engineers embrace behavioral contracts because they address many of these problems. In particular, behavioral contracts provide a mechanism to explicitly document each module's assumptions and guarantees; to dynamically detect contract violations; and to identify faulty modules. Behavioral contracts are widely used in procedural, object-oriented, and functional languages, including Eiffel [36] Existing contract systems can express a range of interface specifications. Below, we consider a range of possible specifications for Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 2. The argument function cmp in turn requires two arguments, both positive integers. This higher-order precondition constrains how the sort module can call the function argument cmp, and so is a guarantee provided by sort rather than an obligation on the client. Higherorder contract systems [19,15,22,24,45] support such preconditions by wrapping the cmp argument to enforce this property dynamically.3. The sort function is not re-entrant-it can only be called after all previous sort invocations have completed.Unlike the previous contracts that constrain how functions may be called, this temporal contract constrains when sort can be called [12,13]. This constra...

Chaperone contracts for higher-order sessions

“…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.…”

“…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 .…”

“…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 . An interesting question for future work is whether the primitives of λ CC allows for a convenient implementation of λCoS to avoid monitor migration in delegations.…”

Computational contracts

“…In this section we show computational contracts where the programmer describes a partial specification of the path of applications a certain function should or should not follow. In our implementation this path is expressed by a finite state machine 6 . As shown in Figure 8, this finite state machine describes which functions can be applied successively.…”

“…Finally, Higher Order Temporal (HOT) Contracts [6] extend prior higher-order contract systems to also express and enforce temporal properties between modules. In their formalisation, module behaviour is modelled as a trace of events such as function calls and returns, which does not include internal module calls.…”