Nested and Dynamic Contract Boundaries

Abstract

Abstract. Previous work on software contracts assumes fixed and statically known boundaries between the parties to a contract. Implementations of contract monitoring systems rely on this assumption to explain the nature of contract violations and to assign blame to violators. In this paper, we explain how to implement arbitrary, nested, and dynamic contract boundaries with two examples. First, we add nestable contract regions to a static, first-order module system. Second, we show that even a dynamic, higher-order, and hierarchical module system can be equipped with software contracts that support precise blame assignment. Contracts for ModulesPLT Scheme [1] comes with a widely used contract system for specifying behavioral (functional) properties of module exports and imports. Roughly speaking, a behavioral software contract imposes restrictions on the domain and range of a function that flows from one module to another. If the function does not produce the kind of values promised in a contract, the run-time monitoring system raises a contract exception and blames the server module for exporting an ill-behaved function. Conversely, if the client module applies an imported function to values that fail to satisfy the domain contract, the run-time system blames the client for not living up to its promises.Unlike other systems for monitoring behavioral software contracts [2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17], PLT Scheme's contract system does not restrict contracts to first-order functions and methods. Instead, programmers may formulate contracts for all kinds of values, including higher-order values [18]. The module system, however, is restrictive. In particular, modules are merely first-order namespaces, without mechanism for nesting them or linking them in a recursive fashion. Naturally programmers chafe under this module system and call for more flexibility.At the same time, the theory of contracts assumes fixed and statically known boundaries between contract parties. Contract implementations combine compilers that can determine the parties to each contract from the source text with a run-time checking system that exploits this knowledge for blaming violators.In this paper, we relax these restrictions and show how to add arbitrary contract boundaries to the PLT Scheme module system and how to implement

Option contracts

“…Instead of having that lexer call directly the language lexers, we could insert a lexer manager function that accesses the list of trusted lexers and attaches to each lexer an appropriate contract. In Racket we can implement this idea easily with with-contract, a construct for creating nested contract regions inside a component [27]:…”

Behavioral software contracts

“…Delimited and composable control operators provide new ways for values to flow and thus require special contract support ). Classes and object systems also lead to new concerns for contracts, from behavioral subtyping to support for first-class classes (Strickland and Felleisen 2010; Strickland and Felleisen (2009) explore the crucial pragmatic question of how to draw boundaries between components. A number of researchers have also explored parametric polymorphic contracts (Guha et al 2007;Matthews and Ahmed 2008;Ahmed et al 2011), using the idea that runtime sealing is the dynamic analog of polymorphic type checking.…”