Correct Blame for ContractsNo More Scapegoating

Christos DimoulasNortheastern University

Robert Bruce FindlerNorthwestern University

Cormac FlanaganUniversity of California, Santa Cruz

Matthias FelleisenNortheastern University

Abstract

Behavioral software contracts supplement interface informationwith logical assertions. A rigorous enforcement of contracts pro-vides useful feedback to developers if it signals contract violationsas soon as they occur and if it assigns blame to violators withprecise explanations. Correct blame assignment gets programmersstarted with the debugging process and can significantly decreasethe time needed to discover and fix bugs.

Sadly the literature on contracts lacks a framework for mak-ing statements about the correctness of blame assignment and forvalidating such statements. This paper fills the gap and uses theframework to demonstrate how one of the proposed semantics forhigher-order contracts satisfies this criteria and another semanticsoccasionally assigns blame to the wrong module.

Concretely, the paper applies the framework to the lax enforce-ment of dependent higher-order contracts and the picky one. Ahigher-order dependent contract specifies constraints for the do-main and range of higher-order functions and also relates argu-ments and results in auxiliary assertions. The picky semantics en-sures that the use of arguments in the auxiliary assertion satisfiesthe domain contracts and the lax one does not. While the pickysemantics discovers more contract violations than the lax one, itoccasionally blames the wrong module. Hence the paper also in-troduces a third semantics, dubbed indy, which fixes the problemsof the picky semantics without giving up its advantages.

Categories and Subject Descriptors D.3.1 [Formal Definitionsand Theory]: Semantics; D.3.3 [Language Constructs and Fea-tures]: Constraints

General Terms Languages, Design, Reliability

Keywords Higher-order Programming, Behavioral Contracts,Blame Assignment

∗ Dimoulas and Felleisen were partly supported by AFOSR (FA9550-09-1-0110) and NSF (CRI 0855140 & CCF 0540818), Findler by NSF (0846012)and Flanagan by NSF (CNS-0905650).

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. To copy otherwise, to republish, to post on servers or to redistributeto lists, requires prior specific permission and/or a fee.

POPL’11, January 26–28, 2011, Austin, Texas, USA.Copyright c© 2011 ACM 978-1-4503-0490-0/11/01. . . $5.00

1. Dependent Contracts: Lax or Picky?

Software engineers embrace behavioral1 software contracts for tworeasons. On one hand, contracts help explain and protect the inter-face of components, e.g., modules, classes, procedures, functions.On the other hand, programmers can use the familiar programminglanguage to specify contracts, which makes it easy to read, write,and interpret them.

While both arguments obviously apply to contracts for first-order languages, Findler and Felleisen (2002)’s introduction of con-tracts for higher-order functions raises subtle, yet practically in-teresting questions. One particular question concerns dependenthigher-order contracts—that is, contracts that can state assertionsrelating the potentially higher-order argument to the potentiallyhigher-order result. Such contracts come with two distinct seman-tics in the literature. The first is the so-called lax semantics of Find-ler and Felleisen, which uses the argument in the assertion withoutmonitoring the argument contract. In contrast, the second, picky se-mantics of Blume and McAllester (2006) monitors the argumentcontract during the evaluation of the component and during theevaluation of the assertion.

;; for some natural number n and real δ(->d ([f (-> real? real?)][ε real?])

(fp (-> real? real?))#:post-cond(for/and ([i (in-range 0 n)])

(define x (random-number))(define slope

(/ (- (f (- x ε)) (f (+ x ε)))(∗ 2 ε)))

(<= (abs (- slope (fp x))) δ)))

Figure 1. A higher-order, dependent contract

To make this discussion concrete, consider the dependent func-tion contract in figure 1. This Racket fragment (formerly known asPLT Scheme) (Flatt and PLT 2010) specifies a function that maps areal-valued function f (and a real number ε) to a real-valued func-tion fp. The post-condition adds that for some number n of num-bers x, the slope of f at x is within δ of the value of fp at x. Apicky interpretation enforces that f and fp are applied to real num-bers and produce such numbers during the evaluation of the post-condition; a lax interpretation does not check these specifications.

Greenberg et al. (2010) compare these two forms of depen-dent contracts (and relate contracts to Flanagan (2006)’s hybridtypes). They come to the conclusion that picky contracts signalthe same violations as lax contracts and possibly more. For exam-ple, random-number may actually produce a complex number and

1 We use Beugnard et al. (1999)’s terminology.

215

Types τ ::= o | τ → τo ::= num | bool

Terms e ::= v | x | e e | µx:τ.e | e+e| e−e | e∧e | e∨e | zero?(e)| if e e e

Values v ::= 0 | 1 | −1 | . . . | λx:τ.e| tt | ff

E.Contexts E ::= [ ] | E e | v E | E +e | v+E| E −e | v−E | E ∧e | v∧E| E ∨e | v∨E | zero?(E )| if E e e

Figure 2. PCF syntax

the contract may thus misapply f; the picky interpretation catchesthis potential problem, while the lax one doesn’t. Our experienceshows, however, that Greenberg et al. (2010)’s result doesn’t trulysettle the issue. When a picky contract signals a contract violation,it may blame the wrong party.

In this paper, we develop a third notion of contract monitor-ing and demonstrate that it satisfies an intuitive correctness crite-rion. We start from the observation that Greenberg et al. are correctin that a picky interpretation is important for dependent contracts.If the “dependency assertion” violates a contract, the computationmay go wrong in all kinds of ways. The question is which partythe monitoring system should blame for such a problem. The pickyinterpretation blames either the server or the client. Our new inter-pretation, dubbed indy, treats the contract as an independent partyand blames it for problems where picky blames the wrong party.

To compare the three possible interpretations, we develop a uni-fied semantic framework, based on a reduction semantics (Felleisenet al. 2009) for a PCF-like language with contracts. The three inter-pretations are expressed as three different, one-rule extensions thatspecify the semantics of dependent contracts. We then enrich theframework with the necessary information to track code ownershipand contract obligations, two novel technical notions that mightprove useful in other contexts. This enriched framework is usedto formalize the following correctness criterion: a contract systemshould only blame a party if the party controls the flow or return ofvalues into the particular contract check that failed.

We can prove that our new indy interpretation satisfies this cri-terion while picky fails to live up to it. Inspired by our theoreticalresult, we equip Racket with an indy dependent contract combina-tor, ->i, in addition with the existing lax combinator, ->d.

Finally, we explain how to use the framework to implementa tool that explains the responsibilities that contracts imposes.Specifically, the tool teases out contract obligations from com-plicated contracts and highlights them with colors. We have im-plemented the tool and include some screenshots to illustrate itsusefulness.

2. Contract PCFPCF (Plotkin 1977) is the starting point for our model; figure 2summarizes the well-known syntactic domains. In this setting, aprogram is a closed term. Also, we equip the language with a stan-dard type system and a call-by-value reduction semantics, thoughfor lack of space, we omit the details (Plotkin 1975; Felleisen et al.2009). Similarly, we use type annotations only when needed.

2.1 Adding Higher-Order Contracts

Adding plain higher-order contracts (Findler and Felleisen 2002)to PCF is straightforward: see figure 3. First, PCF is enriched with

contracts, a contract type, and new terms for attaching contracts toterms and raising contract violations. Second, we extend our typesystem with rules for the extra terms. The resulting language isCPCF, PCF with contracts.

CPCF is equipped with two kinds of contracts: flat contracts,flat(e), and higher-order contracts, κ1 �→ κ2. The former arepredicates on base values. The latter combine a contract, κ1, onthe arguments of a function with a contract, κ2, on the result of thefunction.

Contracts κ ::= flat(e) | κ �→ κTypes τ ::= . . . | con(τ)Terms e ::= . . . | monl,l

l (κ,e) | errorl

Γ � e : o → boolΓ � flat(e) : con(o)

Γ � κ1 : con(τ1) Γ � κ2 : con(τ2)Γ � κ1 �→ κ2 : con(τ1 → τ2)

Γ � κ : con(τ) Γ � e : τ

Γ � monk,lj (κ,e) : τ Γ � errorl : τ

Figure 3. CPCF: syntax and types

The most important new construct is the monitoring constructmon

k,lj (κ,e), which places a contract κ between a term e (the server)

and its context (the client). It demands that any value that flowsbetween e and its context is monitored for conformance with thecontract. For a flat contract, the predicate is applied to the value;for a higher-order contract, the pieces of the contract are attachedto the argument and range position of a wrapper function and thecontract is monitored as the function flows through the program.

A monitor comes with three labels:2 a pair of distinct blamelabels k and l for the two parties to the contract and a contract labelj, for the origin of the contract. In source code, the contract label jusually differs from k and l but under some circumstances it may beequal to either of the two. Labels are drawn from the enumerable setL. The label lo is used as the label of the whole program; l denotes asubset of L. When a contract fails a contract error, errorl , is raisedwhere l denotes the party responsible for the violation.

E.Contexts E ::= . . . | monl,ll (κ,E )

E [monk,lj (κ1 �→ κ2,v)] �−→ E [λx.monk,l

j (κ2,v monl,kj (κ1,x))]

E [monk,lj (flat(e),v)] �−→ E [if (e v) v errork]

E [errorl ] �−→ errorl

Figure 4. CPCF: semantics

The introduction of contracts requires small changes to thereduction semantics. Figure 4 spells out the details, starting withthe slight modification of the set of evaluation contexts. The bottomhalf shows the reduction rules for contract checking and blameassignment, adapted from Findler and Felleisen (2002)’s originalsemantics. A higher-order monitor is split into two parts:

1. a monitor for the argument with reversed blame labels;

2. a monitor for the result with the original blame labels.

2 In an implementation, these labels are synthesized from the program text.

216

A first-order monitor is transformed to an if statement that checkswhether the guarded value satisfies the contract’s predicate. If thepredicate is satisfied, the value is returned; otherwise a contracterror is signaled using the first blame label to pinpoint the guiltyparty. Finally, when a contract error is raised the evaluation isaborted and the contract error is returned as the final result.

2.2 Adding Dependent Contracts

In contrast to conventional contracts for first-order functions, thehigher-order contracts of the preceding section cannot express de-pendencies between arguments and results. Therefore Findler andFelleisen (2002) equip CPCF with a functional contract form thatparameterizes the result contract over the argument:

Contracts κ ::= . . . | κ d�→(λx.κ)

Findler and Felleisen (2002)’s reduction rule for these dependentcontracts captures this intention:

E [monk,lj (κ1

d�→(λx.κ2),v)] �−→l (lax)E [λx.monk,l

j (κ2,v monl,kj (κ1,x))]

A dependent monitor acts like a higher-order monitor. The subtledifference is that the parameter x of the proxy function capturesthe free occurrences of x in the contract’s postcondition κ2. As aresult, any argument to the proxy function is substituted for x in κ2and is then used in the argument position, suitably wrapped with anargument monitor.

Blume and McAllester (2006) observe that the precondition κ1is not enforced during the evaluation of postcondition κ2. This gapopens the door for potential abuses of the argument in κ2, i.e., usesthat don’t conform to κ1. They rightly consider this a problem and,in turn, they propose the following change to the rule:3

E [monk,lj (κ1

d�→(λx.κ2),v)] �−→p (picky)E [λx.monk,l

j ({monl,kj (κ1,x)/x}κ2,v mon

l,kj (κ1,x))]

Specifically, every free occurrence of x in κ2 is replaced withmon

l,kj (κ1,x). Thus, any argument to the function remains protected

by κ1 even inside κ2. Note how the injected monitor carries thesame blame labels as the monitor for the argument in the body ofthe function.4

Greenberg et al. (2010) compare the lax and picky contract sys-tems and conclude that the former signals strictly fewer contracterrors than a picky contract system. More precisely, for any pro-gram, the following statements hold:

• neither contract system signals a contract error;

• both raise an error and blame the same party; or

• the picky contract system discovers a contract violation and thelax system does not raise a contract error.

Their results characterizes two different philosophies of contractcode. On the one hand, a lax contract system treats contracts astrusted code. Both parties have agreed to the contract and have pre-sumably ensured that its evaluation doesn’t violate any invariants.On the other hand, a picky contract system considers contracts tocontain potentially faulty code. To enforce the contracts within thiscode, a picky system protects values that flow into the contracts.

The problem with the picky system is that it may blame theserver or the client for violations of a contract κ when neither of

3 In principle, this reduction rule should use a let to preserve a strict call-by-value regime. But, due to the restrictions on our grammar for contracts,a straight substitution is technically correct and superior.4 An alternative definition for the picky rule is to not switch the blame labelson the internal monitor. Doing so does not affect our results.

them can control the flow of values into the responsible monitor.To illustrate this point and to provide an alternative, we introducea third contract monitoring system that considers contracts as inde-pendent entities. When a dependent contract abuses a value accord-ing to κ1, this revised system blames the contract for the violation.

Here is the reduction rule:

E [monk,lj (κ1

d�→(λx.κ2),v)] �−→i (indy)

E [λx.monk,lj ({monl, j

j (κ1,x)/x}κ2,v monl,kj (κ1,x))]

The rule makes the contract responsible if it supplies an inappro-priate value to a function argument during the evaluation of the“dependency.” It accomplishes this switch of responsibility withthe creation of a new monitoring expression for the argument withthe contract label as the negative blame label. This new argumentexpression is substituted into the range part of the contract.5

For an example, consider this monitor expression:

Π0 = monk,lj (κ,λx.(—0—)) λx.(—1—)

where

κ = κ1d�→(λ f .flat(λx. f (λx.(—2—)) > 0))

κ1 = (P? �→ P?) d�→(λg.flat(λx.g 3 > 0))

Here the server is the function λx.(—0—), while the client is thecontext [ ] λx.(—1—). The mediating contract κ is a higher-order,dependent contract where P? checks for positive numbers, i.e.,P? = flat(λx.x > 0) and > has the standard recursive definition.

The argument λx.(—1—) flows to the postcondition of κ andreplaces f . To protect it from potentially misbehaving contractcode, it is wrapped with a monitor that enforces κ1:

monl, jj (κ1,λx.(—1—)) .

Since κ1 is a dependent contract, too, the story continues. Whenthe postcondition is eventually checked, this proxy function forλx.(—1—) is applied to λx.(—2—). In that case, the latter flowsto the postcondition of κ1 and replaces g with another monitoreddomain contract.

Each of the three rules gives rise to a semantics for CPCF. Inprincipal, we extend �−→ with �−→m where m ∈ {l, p, i} to getthe three complete reduction relations. Since there is no dangerof ambiguity, we overload the symbol �−→m and use it for thecomplete semantics.

2.3 Two More Flavors

The treatment of contracts as independent parties is compatiblewith some practical uses in our Racket implementation. First, con-tracts for Racket’s unit system are given as part of the signature.Strickland and Felleisen (2009) show that linking such units maynecessitate blaming the signature itself. Our framework finally pro-vides a semantic explanation for this phenomenon.

Second, in Racket’s first-order module system, contracts arespecified via provide/contract, i.e., in the export interface ofmodules. This form combines identifiers with contracts and at-taches contracts to these values as they flow across the moduleboundary. When things go wrong with the dependencies in such

5 Morally, the monitor should not apply when the client is already labeledwith the contract label. In that case, the value flow is entirely within thecontract party and should strictly speaking not be monitored. To model thisbehavior, we would have to add the side condition l = j and add a secondrule:

E [monk,lj (κ1

d�→(λx.κ2),v)] �−→i E [λx.monk,lj (κ2,v mon

l,kj (κ1,x))]

if l = j

Both variants of indy satisfy the main theorem, which is why this paperfocuses on the theoretically simpler approach.

217

contracts, the monitoring system considers the contract a part ofthe server module and blames the server module. We can expressthis idea—dubbed +indy—in our framework with the small changeof using the module name as the contract label.

Finally, Typed Racket (Tobin-Hochstadt and Felleisen 2010,2008) protects the interaction of typed and untyped modules withcontracts derived from types. Since one of the basic assumptionsof Typed Racket is that untyped modules stay unchanged, it imple-ments this protection mechanism with require/contract. Thiscontract form guarantees that values from an untyped module sat-isfy the specified contract. Put differently, the form protects the im-port boundary. If a programmer attached dependencies to these con-tracts, the code would have to be considered as a part of the clientmodule. We can capture this semantics, dubbed −indy, by using theimporting module’s name as the contract label.

2.4 Comparing Contract Systems

Equipped with three additional contract monitoring systems, wecan now explore their relationship. Consider this example:

Π1 = monk,l∗ (κ,λ f . f 42) λx.x

where κ = (P? �→ P?) d�→(λ f .flat(λx. f 0 > −1))

The example uses the placeholder ∗ for the contract label so that wecan include +indy and −indy—the two additional flavors of indy—in our comparisons. As needed, we replace ∗ with k for +indy,with l for −indy, and a distinct label j for indy. Recall that thereduction rules for the lax and picky contract monitoring systemsdo not employ the contract label.

The evaluation of Π1 yields the following results for the fivedifferent contract monitoring systems:

program * monitoring system resultΠ1 — lax 42Π1 — picky errork

Π1 j indy error j

Π1 k +indy errork

Π1 l −indy errorl

The table demonstrates several points. First, when a program yieldsa plain value according to the lax system, the picky system may stillfind a fault during contract checking and signal a violation. Second,the picky system here blames party k, the server component, fora contract violation. The specific violation is that f is applied to0 in the dependency assertion, even though the domain contractpromises that the function is only applied to positive numbers.Third, the indy system blames the contract itself, rather than theserver. Fourth, the system based on the +indy rule agrees with thepicky system, because it considers all code in a contract as part ofthe server. Finally, the −indy system blames party l; after all, themisapplication of f is internal to the client, which chooses to defythe restrictions on the domain of f .

Another example shows that picky can also blame the clientwhen things go wrong with the contract:

Π2 = monk,l∗ (κ,λ f . f λx.x) λg.g 42

where κ = ((P? �→ P?) d�→(λ f .flat(λx. f 0 > −1))) �→ P?

Specifically, evaluating Π2 yields the following results:

program * monitoring system resultΠ2 — lax 42Π2 — picky errorl

Π2 j indy error j

Π2 k +indy errork

Π2 l −indy errorl

Again the lax system does not signal contract violations, while theother four report one. Here the indy system blames the contractitself rather than the client, which is blamed by the picky and −indysystems. The +indy system blames the server.

Together the two examples demonstrate that none of our newmonitoring rules are logically related to picky if we take blameinto account. In short, the introduction of contracts as independentparties calls for a comparison that takes into account why a contractviolation is detected and why the accused party is blamed.

Note, however, that the indy contract system signals an errorwhen the picky system signals an error and vice versa, though theerrors aren’t necessarily labeled with the same party.

PROPOSITION 1. e ∗�−→i errork iff e ∗�−→p error

k′

PROOF IDEA. By a straightforward bi-simulation argument. Thebi-simulation used for the proof relates two expressions that arestructurally identical except that their labels can differ.

3. Tracking Ownership and ObligationsWhile the preceding section illuminates the problems of the pickycontract system and the difficulty of comparing contract systemsin general, it also implies a new way of thinking about contractviolations. The first major insight is that the picky system mayblame either the server module or the client module when, in fact,the contract itself is flawed. From here, it is obvious to inspect whata contract monitoring system would do if contracts were a part ofthe server, a part of the client, or a third party. Doing so producesthe second major insight, namely, that none of these alternativesagrees with the picky semantics.

Putting the two insights together implies that we need a seman-tics that (1) for each party, keeps track of its contract obligationsand (2) for each value, accounts for its origin. Once a semanticsprovides this additional information, we can check whether a con-tract system ever blames a party for violating an obligation if theparty has no control over the value’s flow into the contract. In thissection, we equip CPCF’s semantics with ownership and obligationinformation, which is maintained across reductions. In the next sec-tion, we use this information to state a contract correctness propertyand to measure how the various monitoring systems fare with re-spect to this property.

3.1 Ownership . . .

To model an ownership relationship between parties and code, weextend CPCF with a new construct that relates terms and values toparties:6

Terms e ::= . . . | ‖e‖l

Values v ::= . . . | ‖v‖l

During reductions, terms and values come with a stack of own-ers, reflecting transfers from one party to another. The notations

‖e‖→ln and ‖e‖

←ln are short-hands for such stacks, abbreviating

‖ . . .‖e‖l1 . . .‖ln and ‖ . . .‖e‖ln . . .‖l1 , respectively. Ownership l foran expression means its result is attributed to l. In turn, a valuewith an ownership l originates from component l or is affected bya traversal through component l.

3.2 . . . and Obligations

CPCF contracts consist of trees with flat contracts at the leafs.Exploiting the analogy with function types, Findler and Felleisen(2002) implicitly decompose these trees into obligations for servers

6 The inspiration of ownership comes from the work of Zdancewic et al.(1999) on principals. For a comparison, see section 6.

218

(positive positions) and clients (negative positions). Their seman-tics tracks this connection via labels; errors use them to pinpointcontract violators.

Dimoulas and Felleisen use this idea for a static decompositionof contracts into server and client obligations. They define twofunctions from contracts to contracts that tease out the respectiveobligations. The one for teasing out server obligations replaces flatcontracts in negative positions with � = flat(λx.tt) and thenreconstructs the overall contract; analogously, the decompositionmap for teasing out client obligations replaces flat contracts inpositive positions with �. For instance the contract of the Π2

example in section 2 yields these decompositions:

((P? �→ P?) d�→(λ f .flat(λx. f 0 > −1))) �→ P?

server ((� �→ P?) d�→(λ f .�)) �→ P?client ((P? �→ �) d�→(λ f .flat(λx. f 0 > −1))) �→ �

Decomposition implies that each flat contract imposes obliga-tions on a specific component, i.e., party to a contract. Since oneand the same server may connect with many different clients andsince indy systems may use the contract itself as a component, it isnot just one party that is associated with a flat contract but many.Hence we modify the syntax of contracts to statically associate flatcontracts and owners:

Contracts κ ::= �flat(‖e‖l)�l | κ �→ κ | κ d�→(λx.κ)

In contrast with ownership, obligations come as sets of labels l,not vectors. After all, there is no need to order obligations or tochange them during an evaluation. Of course, a static attribute abouta dynamic obligation calls for a way to determine whether suchannotations are well-formed.

3.3 Well-formed Ownership and Obligations

Only some annotations make sense for a source program. Bothownership and contract monitors specify boundaries and, at thesource level, these boundaries should coincide. We therefore intro-duce a well-formedness judgment to enforce these conditions forsource programs. Before doing so, we present the simple typingrules for the two new constructs:

Γ � e : o → bool

Γ � �flat(e)�l : con(o)Γ � e : τ

Γ � ‖e‖l : τ

Concerning ownership annotations, a CPCF source programmay contain those at only two places: in contract monitors andin flat contracts. Since contract monitors establish a boundary be-tween the client component and the server component, we demandan ownership annotation on the server component and that a matchof these annotation with the positive label of the monitor. Con-versely, the context of such an expression must belong to the client.Finally, flat contracts must come with ownership labels consistentwith the surrounding monitors because they are turned into plaincode during the evaluation, and the semantics must track wherethey originated from.

We express this constraint with the well-formedness relationl � e, which says that l “owns” e and checks that e is well-formed.Equivalently, l is the owner for the context of e. A closed expressione is a well-formed program if lo � e where lo is the label reservedfor the owner of the program.

Figure 5 defines most of this well-formedness judgment. Forterms that do not involve monitors and contracts the definitionis a structural judgment, and base values and variables are well-formed under any owner. The actual key is the one for contractmonitor, which we present separately. According to our informaldescription, a well-formed contract monitor is a boundary between

l � e

l � e1 l � e2

l � e1 e2

l � el � λx.e

l � el � µx.e

l � e1 l � e2 l � e3

l � if e1 e2 e3

l � e1

l � zero?(e1)

l � e1 l � e2

l � e1 +e2

l � e1 l � e2

l � e1−e2

l � e1 l � e2

l � e1∧e2

l � e1 l � e2

l � e1∨e2

l � n l � tt l � ff l � x

Figure 5. Ownership coincides with contract monitors

a client and a server, implying this shape for the judgment:

l � monk,lj (κ,‖e‖k)

It says that if l owns the context and k is the blame label for theserver, then the blame label for the client should be l and thewrapped expression e should come with an ownership annotationthat connects it to k. Next, e must be well-formed with respect toits owner k, because it may contain additional contract monitors.But even with this antecedent, the well-formedness judgment isincomplete. After all, the contract κ that governs the flow of valuesbetween the server and the client contains code and this code mustbe inspected. Furthermore, we must ensure that all flat contractswithin κ are obligations of the appropriate parties including thecontract monitor itself, which is represented by the contract label j.

Putting everything together, we get this well-formedness rulefor contract monitors in source programs:

k � e {k};{l}; j � κ

l � monk,lj (κ,‖e‖k)

It relies on a secondary well-formedness judgment for contracts, towhich we turn next.

l; k; j � κ1 k; l; j � κ2

k; l; j � κ1 �→ κ2

l; k∪{ j}; j � κ1 k; l; j � κ2

k; l; j � κ1d�→(λx.κ2)

j � e

k; l; j � �flat(‖e‖ j)�k

Figure 6. Obligations coincide with labels on monitors

Roughly speaking, k; l; j � κ says that contract κ is well-formedfor sets of positive and negative obligation labels k and l, respec-tively, and the owner j of the contract monitor that attaches thecontract to a boundary. As the definition in figure 6 shows, the twosets are swapped for the antecedents of higher-order (dependent)contracts. For the negative positions in the precondition of depen-dent contract label j is added to indicate that these are also obli-gations of the owner of the contract monitor. For flat contracts the

219

positive obligation labels must coincide with the obligation labelsof the contract.

Note that the well-formedness of flat contracts also enforcesan ownership annotation. Specifically, the owner of the context—which, by assumption, is a contract monitoring construct labeledwith j—is also the owner of the predicate in the flat contract.The antecedent of the rule recursively uses the well-formednessjudgments for ownership to ensure that e itself is well-formed.

3.4 Ownership and Obligations Semantics

The final change to the CPCF model concerns the reduction seman-tics. Specifically, we change the reduction relations so that each re-duction step keeps track of ownership rights and obligations. Whileownership and obligations do not affect the semantics per se, theinformation is critical for characterizing the behavior of contractmonitoring systems, as we show in the next section.

Our first step is to equip the grammar of evaluation contextswith a parameter that accounts for the owner of the hole. In theparameterized grammar, El , of figure 7 the parameter l points tothe ownership annotations that is closest to the hole of the context.

E.Contexts El ::= Gl

Gl ::= Gl e | v Gl | Gl +e | v+Gl

| Gl −e | v−Gl | Gl ∧e | v∧Gl

| Gl ∨e | v∨Gl | zero?(Gl)| if Gl e e | monk,l

j (κ,Gl)| ‖F‖l | ‖Gl‖l′

F ::= [ ] | F e | v F | F +e | v+F| F −e | v−F | F ∧e | v∧F| F ∨e | v∨F | zero?(F)| if F e e | monk,l

j (κ,F)

Figure 7. Parameterized evaluation contexts

Evaluation contexts are labeled with the label lo—the label re-served for the whole program—if they do not contain an ownershipconstructs on the path from the hole to the root: Elo ::= F .

From now on, all reduction relations assume labeled evalua-tion contexts. This implies that newly created values are alwaysassigned an owner. For the reduction relations concerning primi-tive operators and conditionals, the changes are straightforward andsummarized in the top part of figure 8. For the rules concerningmonitors with flat and plain higher-order contracts and their blameassignments, specified in the lower part of the same figure, we alsoknow that they do not need to manipulate any ownership annota-tions. These reduction rules remain unchanged, modulo the labeledevaluation contexts. The obligation annotation on flat contracts isignored. For details, see the bottom part of figure 8. We add onelast simple rule separately:

El [errork] �−→m errork

Since the act of signaling errors erases the surrounding evaluationcontext, the format of this rule doesn’t fit the table. Note that thecontext on the right is [ ]lo and l may not equal lo.

The reduction of βv redexes typically demands several re-alignments with respect to ownership. To start with, the functionand the argument may belong to different parties. Furthermore,the context brings together the operand and operator, and the se-mantics should keep track of this responsibility. Together, the twoobservations suggest the following relation:

El [‖λx.e‖→ln v] �−→m El [‖{‖v‖l

←ln /x}e‖

→ln ]

El [· · · ] �−→m El [· · · ]‖n1‖

→k +‖n2‖

→l · n where n1 +n2 = n

‖n1‖→k −‖n2‖

→l · n where n1 −n2 = n

zero?(‖0‖→l ) · tt

zero?(‖n‖→k ) · ff if n = 0

‖v1‖→k ∧‖v2‖

→l · v where v1 ∧ v2 = v

‖v1‖→k ∨‖v2‖

→l · v where v1 ∨ v2 = v

if ‖tt‖→l e1e2 · e1

if ‖ff‖→l e1e2 · e2

monk,lj (κ1 �→ κ2,v) · λx.monk,l

j (κ2,v monl,kj (κ1,x))

monk,lj (�flat(e)�l′ ,v) . if (e v) v errork

Figure 8. Ownership and obligation propagation

The relation says that after tagging the value with the ownershiplabel l of the context, the value moves under the ownership annota-tions of the function. The result is a value whose innermost owneris l and whose outermost owner is l1 of

→ln:

‖v‖l←ln

The properly annotated value is then substituted into the body e ofthe function for its parameter x. The result itself is owned by thesame owner as the function.

Put differently, it is best to view function application as a formof communication between two components: the function and itscontext. The context picks the argument, declares itself its owner,and then passes it to the function. The function accepts the argu-ment, adjusts its ownership, and integrates the result into its body.

Recursion is treated as a special form of function application:

El [µx.e] �−→m El [{‖µx.e‖l/x}e]The owner of the context l and user of the recursive functiondeclares itself owner of µx.e before substituting it in the body ofthe recursive function.

All the complexity of tracking ownership is due to dependentfunction contracts. Consider the simplest variant, lax:

E [monk,lj (κ1

d�→(λx.κ2),v)] �−→l (lax)E [λy.monk,l

j ({y/x}κ2,v monl,kj (κ1,y))]

For emphasis, this version of the reduction rule uses y as theparameter of the proxy function on the right hand side. The useof y as parameter demands that we also replace all occurrences ofx in κ2 with y so that when the proxy function is applied, the actualargument is substituted into the dependent range contract; withoutthe substitution, the reduction would create free variables.7

Rewriting the lax rule in this way reveals that it encodes amasked function application. The problem is that, as discussedabove, a function application must add the label of the responsi-ble owner at the bottom of the stack, and this label is not availablehere. Instead, it is found at the flat leafs of the contract, which—according to the static semantics of the preceding subsection—must come with an ownership annotation. The solution is to intro-duce the substitution function {e/cx}κ, which copies the ownershiplabel from flat contracts to the substituted term.

7 The value v is unaffected by this change of parameters, because we assumethe usual hygiene condition (Barendregt 1984) for metavariables.

220

With this substitution function in place, it is easy to specify thethree variants for the reduction of dependent functional contracts:

El [· · · ] . . . El [· · · ]mon

k,lj (κ1

d�→(λx.κ2),v) �−→l

λx.monk,lj ({x/cx}κ2,v mon

l,kj (κ1,x)) (lax)

monk,lj (κ1

d�→(λx.κ2),v) �−→p

λx.monk,lj ({monl,k

j (κ1,x)/cx}κ2,v monl,kj (κ1,x)) (picky)

monk,lj (κ1

d�→(λx.κ2),v) �−→c

λx.monk,lj ({monl, j

j (κ1,x)/cx}κ2,v monl,kj (κ1,x)) (indy)

We conclude this section with the definition of the auxiliarysubstitution function:

{e/cx}�flat(‖e′‖l′)�l = �flat({‖e‖l′/x}‖e′‖l′)�l

{e/cx}κ1 �→ κ2 = {e/cx}κ1 �→ {e/cx}κ2

{e/cx}κ1d�→(λx.κ2) = {e/cx}κ1

d�→(λx.κ2){e/cx}κ1

d�→(λy.κ2) = {e/cx}κ1d�→(λy.{e/cx}κ2)

where x = y

The definition is total. The redefinition of the contract syntax en-forces that flat contracts always have the annotations expected bythe domain of the substitution function. This also guarantees thatthe reduction relations �−→m are well-defined.

4. Correct BlameUsing ownership and obligation annotations, we can formulatewhat it means for a contract system to correctly blame a violator.After all, the tracking of ownership and obligations is entirelyindependent of the contract checking, and it is thus appropriate touse tracking as an independent specification of contract monitoring.

Values should be originating from one of the parties of thecontract are checked only against flat pieces of the contract forwhich the party is responsible. Now we can phrase this propertyin terms of ownership and obligations: when the evaluation reachesa redex that checks a flat contract on a value, then the owner ofthe value must be the same as the positive party of the monitor andin addition the positive party is included in the obligations of thecontract.

DEFINITION 2 (Blame Correctness). A contract system m is blamecorrect if for all terms e0 such that lo � e0, and

e0∗�−→m E†[monk,†

† (�flat(e1)�l ,v)]

v = ‖v1‖k and k ∈ l. The identity of the † labels is irrelevant.

The definition says that when the reduction of a well-formedprogram reaches a state in which it checks a flat contract, then theserver (positive) label of the monitor and the ownership label on thevalue must coincide and, furthermore, the set of obligations for theflat contract must contain this label. Conversely, if these obligationsare not met, the monitor may blame k for a contract failure eventhough the party had no control over the flow of v into this monitor.

We can prove that the indy contract system and even the lax sys-tem are blame correct, while picky isn’t. The proof of the positivetheorem directly follows from a subject reduction theorem for own-ership annotations. This latter theorem requires a complex proof,which is the subject of the second subsection. The third subsectionexplains how to prove the two main theorems. To start with, how-ever, we clarify that ownership annotations and obligations do areorthogonal to semantics.

4.1 It is all about Information Propagation

The addition of ownership and obligation annotations does notaffect the behavior of any programs. Our revised semantics simply

propagates this information so that it can be used to characterizeexecution states. In order to formulate this statement, we use thesymbol ∗�−→m

cpc f for the transitive-reflexive reduction relations ofsection 2 and ∗�−→m

anno for the relations of section 3.

PROPOSITION 3. The following statements hold for m ∈ {l, p,c}.

1. Let e be a well-formed CPCF program: lo � e. Let e be theplain CPCF expression that is like e without annotations. Ife ∗�−→m

anno e′, then e ∗�−→mcpc f e′.

2. Let e be a plain CPCF program. There exists some labeledCPCF program e such that lo � e. Furthermore, if e ∗�−→m

cpc f e′,then e ∗�−→m

anno e′.

PROOF IDEA. By a straightforward bi-simulation argument.One consequence of this proposition is that picky and indysignal

still the same number of contract violations (proposition 1).

4.2 Subject Reduction

While l � e specifies when source programs are well-formed, thereduction semantics creates many expressions that do not satisfythese narrow constraints. For example, a well-formed program con-tains only monitor terms of the form mon

k,lj (κ,‖e0‖k). A reduction

sequence may contain programs with differently shaped monitors,however. In particular due to the reductions of higher-order de-pendent contracts, the monitored expressions may be applications,mon

k,lj (κ,‖e0‖k er), or variables, monk,l

j (κ,x). Fortunately, such de-viations are only temporary. In the case of the application the ar-gument er is always well-formed under l and, when it is absorbedby ‖e0‖k, the monitor expression is once again well-formed. In thecase of the free variable we can show that x is always replaced witha value of the form ‖v0‖k, which conforms to the standard form.

To formulate a subject reduction theorem, we must generalizeboth the judgment for well-formed programs, l � e, and the one forwell-formed contracts, k; l; j � κ. First, we equip the two relationswith an environment that records the label of bound variables:

l;Γ�{x : l} � e

l;Γ � λx.e

l;Γ\{x} � e

l;Γ � µx.e

With environments, it becomes possible to check variable occur-rences in monitor terms.

Second, we add a rule for checking expressions that alreadyhave an owner:

k;Γ � e

l;Γ � ‖e‖k

While these terms show up only within monitors in source pro-grams, they flow into many positions during evaluations. Using thisnew rule, we can check these cases, too.

All other rules—except those concerning monitors—propagatethe environment and otherwise check expressions in the same wayas the corresponding rules of the preceding section. The rule forvariables ignores the environment. Variables not in monitor termscan be replaced with well-formed terms of any owner. For details,see figure 9.

The purpose of the environment is to check expressions withoutownership annotations in monitor terms. Here is the key rule:

k;Γ � e {k};{l}; j;Γ � κ

l;Γ � monk,lj (κ,e)

To check whether the wrapped expression is well-formed, it dele-gates to the auxiliary relation k;Γ � e. The contract is checked asbefore, though, with an environment.

With k;Γ � e, we can check the ordinary ownership terms butalso applications and variables as introduced during reductions. For

221

j;Γ � e

j;Γ � e1 j;Γ � e2

j;Γ � e1 e2

j;Γ � e1

j;Γ � zero?(e1)

j;Γ � errork

j;Γ � e1 j;Γ � e2 j;Γ � e3

j;Γ � if e1 e2 e3

j;Γ � e1 j;Γ � e2

j;Γ � e1 +e2

j;Γ � e1 j;Γ � e2

j;Γ � e1−e2

j;Γ � e1 j;Γ � e2

j;Γ � e1∧e2

j;Γ � e1 j;Γ � e2

j;Γ � e1∨e2

j;Γ � n j;Γ � tt j;Γ � ff j;Γ � x

k; l; j;Γ � κ

l; k; j;Γ � κ1 k; l; j;Γ � κ2

k; l; j;Γ � κ1 �→ κ2

l; k∪{ j}; j;Γ � κ1 k; l; j;Γ � κ2

k; l; j;Γ � κ1d�→(λx.κ2)

j;Γ � e k ⊆ k′

k; l; j;Γ � �flat(‖e‖ j)�k′

Figure 9. Obligations coincide with labels on monitors (2)

function applications, the label serves as ownership label for theoperator and the operand, similar to the standard application rule:

k;Γ � e1 k;Γ � e2

k;Γ � ‖e1‖k e2

For free variables, the environment serves as the source of theownership label:

Γ(x) = k

k;Γ � x

After all, the variable in this position is going to be replaced by avalue via a function application, and the substitution is going to usea value with the specified label. Finally, for a guarded term with anownership annotation, it suffices to check if it is well-formed withrespect to the specified owner:

k;Γ � e

k;Γ � ‖e‖k

A well-formed program in the sense of the preceding section isa well-formed program in the sense of revised judgment, too.

PROPOSITION 4. For all e and l, l � e implies l;∅ � e.

PROOF IDEA. By straightforward induction on the height of thederivation l � e.

A program that is well-formed according to l;Γ � e reduces towell-formed programs. This statement holds for a contract systemusing the lax reduction rule as well as for or those using indy.

THEOREM 5. Let e be a program such that lo;∅ � e. Then:

1. if e �−→l e0, then lo;∅ � e0;2. if e �−→i e0, then lo;∅ � e0.

PROOF. (1) We proceed by case analysis on the reduction of e:

• El [‖n1‖→k +‖n2‖

→l ] �−→ lEl [n]. By assumption lo;∅ � e, for

which lemma 6 implies that l;∅ � ‖n1‖→k +‖n2‖

→l . We can use

the same label to check n via the inference rules, i.e., l;∅ � n.Hence, lo;∅ � El [n].

• The cases for other primitive operations are similar to the first.

• El [µx.e] �−→l El [{‖µx.e‖l/x}e]: By assumption and lemma 6,l;∅ � µx.e. From lemma 7 we get that l;∅ � {‖µx.e‖l/x}e and,in turn, lo;∅ � El [{‖µx.e‖l/x}e].

• El [‖λx.e0‖→k v] �−→l El [‖{‖v‖l

←k /x}e0‖

→k ]: Again by assump-

tion and lemma 6, we conclude that l;∅ � ‖λx.e0‖→k v and,

therefore, l;∅ � ‖λx.e0‖→k and l;∅ � v.

Next we distinguish two cases, depending on the length of→k .

First assume the vector is empty. In that case, the inference rulesimply l;{x : l} � e0. Combining this judgment with l;∅ � v,we may conclude that l;∅ � {‖v‖l/x}e0 via lemma 8. Finallyfrom here it is easy to get lo;∅ � El [{‖v‖l/x}e0], the desiredconclusion.

Second, let k1 be the first element of→k . In that case, the infer-

ence rules imply k1;{x : k1} � e0. Since l;∅ � v still holds, we

conclude again via lemma 8 that k1;∅ � {‖v‖l←k /x}e0. Since k1

is the outermost element of→k , we finally get the desired conclu-

sion, lo;∅ � El [‖{‖v‖l←k /x}e0‖

→k ].

• El [monk,lj (�flat(ec)�l′ ,v)] �−→l El [if (ec v) v errork]: The

assumptions imply l;∅ � monk,lj (�flat(ec)�l′ ,v) via lemma 6

and hence, ec = ‖e′c‖ j with j;∅ � e′c. Furthermore, the samereasoning yields v = ‖v0‖k and k;∅ � v0. Since the rules forwell-formed expressions imply l;∅ � if (ec v) v errork iswell-formed, the desired conclusion follows immediately.

• El [monk,lj (κ1 �→ κ2,v)] �−→l El [λx.monk,l

j (κ2,v monl,kj (κ1,x))]:

With the usual reasoning, we get l;∅ � monk,lj (κ1 �→ κ2,v),

v = ‖v0‖k, and k;∅ � v0. The contract check yields two piecesof knowledge:

{l};{k}; j;∅ � κ1

and{k};{l}; j;∅ � κ2

From an additional application of the inference rules for well-formedness we get k;{x : l}� v monl,k

j (κ1,x) and, with the help

of lemma 9, l;{x : l} � monk,lj (κ2,v mon

l,kj (κ1,x)). Finally from

a last application of the inference rules for well-formedness weget l;∅ � λx.monk,l

j (κ2,v monl,kj (κ1,x)).

• Finally, let e = El [monk,lj (κ1

d�→(λx.κ2),v)] and observe that

e �−→l El [λx.monk,lj ({x/cx}κ2,v mon

l,kj (κ1,x))].

Via lemma 6 we derive l;∅ � monk,lj (κ1

d�→(λx.κ2),v) . Thus,

v = ‖v‖k with k;∅ � v, but also

{l};{k, j}; j;∅ � κ1

and{k};{l}; j;∅ � κ2 .

The rest of this argument uses the same strategy as the preced-ing case, except that we use lemmas 10 and 14 to derive the keyresult, l;{x : l} � mon

k,lj ({x/cx}κ2,v mon

l,kj (κ1,x)).

222

(2) The proof of part (2) differs from the proof of part (1)only in the case for monitors with dependent contracts. Therefore,let e = El [monk,l

j (κ1d�→(λx.κ2),v)] and recall that the contraction

proceeds as follows:

e �−→i El [λx.monk,lj ({monl, j

j (κ1,x)/cx}κ2,v monl,kj (κ1,x))].

Once again, we derive l;∅ � monk,lj (κ1

d�→(λx.κ2),v) via lemmas 6.

Hence, v = ‖v‖k with k;∅ � v, but also

{l};{k, j}; j;∅ � κ1

and{k};{l}; j;∅ � κ2 .

By the well-formedness, k;{x : l} � v monl,kj (κ1,x). Now, with the

help of lemmas 12 and 14, we can derive

l;{x : l} � monk,lj ({monl, j

j (κ1,x)/cx}κ2,v monl,kj (κ1,x)) .

Thus we conclude the proof with another application of the infer-ence rules for well-formedness.

The proofs of the central lemmas depend on a series of auxiliarylemmas about the properties of well-formed terms and contracts,substitution, and contract substitution.

LEMMA 6. If l;∅ � Ek[e] then k;∅ � e.

PROOF IDEA. By induction on the size of Ek.

LEMMA 7. If l;Γ� e, k;Γ� e0, and x ∈ dom(Γ), l;Γ� {‖e0‖k/x}e.

PROOF IDEA. By induction on the height of l;Γ � e.

LEMMA 8. If l;Γ�{x : k} � e, v = ‖v0‖k and k;Γ � v0, then

l;Γ � {v/x}e .

PROOF IDEA. By induction on the height of l;Γ�{x : k} � e. Notethat l;Γ�{x : k} � mon

k,lj (κ,x) is a base case.

LEMMA 9. If l;Γ � e and x /∈ dom(Γ), then l;Γ�{x : k} � e.

PROOF IDEA. By induction on the height of l;Γ � e.

LEMMA 10. If k; l; j;Γ � κ and x /∈ dom(Γ), then

k; l; j;Γ�{x : l′} � {x/cx}κ .

PROOF IDEA. By induction on the height of k; l; l;Γ � κ. For theflat contracts case we employ lemma 11.

LEMMA 11. If l;Γ � e and x /∈ dom(Γ), l;Γ�{x : k} � {‖x‖l/x}e.

PROOF IDEA. First, we generalize the lemma’s statement: If l;Γ� eand x /∈ dom(Γ), l;Γ�{x : k} � {‖x‖ j/x}e. Then we proceed byinduction on the height of l;Γ � e.

LEMMA 12. If k; l; j;Γ � κ and k;Γ�{x : l} � monk,lj (κ′,x), with

x /∈ dom(Γ) then k; l; j;Γ�{x : k} � {monk,lj (κ′,x)/cx}κ

PROOF IDEA. By induction on the height of k; l; j;Γ � κ. For theflat contracts case we employ lemma 13.

LEMMA 13. If l;Γ � e, l;Γ�{x : k} � monk,lj (κ′,x), & x /∈ dom(Γ),

then l;Γ�{x : k} � {‖monk,lj (κ′,x)‖l/x}e

PROOF IDEA. First, we generalize the lemma’s statement as fol-lows: If l′;Γ � e, l;Γ�{x : k} � mon

k,lj (κ′,x), & x /∈ dom(Γ), then

l′;Γ�{x : k} � {‖monk,lj (κ′,x)‖l/x}e We proceed by induction on

the height of l′;Γ � e.

LEMMA 14. If k; l; j;Γ � κ, k′ ⊆ k and l′ ⊆ l then k′; l′; j;Γ � κ.

PROOF IDEA. By induction on the height of k; l; j;Γ � κ.

4.3 Main Theorems

When a program is well-formed, its monitors obviously satisfy theblame correctness criterion.

THEOREM 15. �−→l and �−→i are blame correct.

PROOF. This theorem is a straightforward consequence of theo-rem 5. To wit, the subject reduction theorem says that a programsatisfies the subject including when its redex is a monitor term con-taining a flat contract. From the proof of the subject reduction the-orem, we know that the subject implies

l;∅ � monk,lj (�flat(ec)�l′ ,‖v‖k)

The label on the context is the same as the client label by lemma 6but we also need to know that the server label l is a member ofthe contract’s obligations l′. This has to be the case given that themonitor term is well-formed. Note how the proof is independent ofthe reduction semantics as long as it satisfies the subject reductionproperty.

The picky contract system fails to satisfy an analogous theorem.

THEOREM 16. There exists a program e such that lo � e and

e ∗�−→p El [monk,l2j (�flat(e)�l ,‖v‖l1)]

but k = l1.

PROOF. Here is one such program where k = lo:

Π3l = mon

k,lol (κl ,‖λh1.h1 λx.5 (λg.g 1)‖k) (λ f .λh2.h2 λx.6)

The restriction on the labels intuitively corresponds to the compo-sition of the two different modules k and lo through the contract κl .Note that Π3

l is a family of programs, one per label l. This labelis the label of the contract monitor and, consequently, must be theowner of all embedded flat contracts. In principle, l could be thelabel of the client, the server, or any other non-top-level (lo) labelbut in the end, our choice must obey subject reduction.

While Π3l performs no interesting computation, its contract κl

plays a critical role. To explain the contract though, it is best to startwith the type of h1:

[(num → num) →{([num → num] → num) → num}] → num

The type tells us that h1 consumes a complex higher-order functionand produces a number. Instead of plain numbers, however, wewish to deal with positive numbers only. We thus know that κl musthave at least something like the following shape:

[(P?l �→ P?l) �→ {([P?l �→ P?l ] �→ P?l) �→ P?l}] �→ P?l

Next we add two dependencies:

[(P?l �→ P?l)d�→(λ f .{([P?l �→ P?l ]

d�→(λg.P?l)) �→ P?l})] �→ P?l

The two key points to notice are: (1) in this contract, g is inthe scope of f and (2) while f originates in the server (wrappedexpression), g originates in the client (context) and both flow intothe contract.

Equipped with this informal and approximate understanding,we can now turn to the actual contract:

κl = ((�P?l�lo �→ �P?l�k) d�→(λ f .κ1l )) �→ �P?l�k

κ1l = ((�P?l�k �→ �P?l�lo) d�→(λg.κ2

l )) �→ �P?l�k

κ2l = �flat(‖λx.zero?( f 1−g 0)‖l)�k

P?l = flat(‖λx.x > 0‖l)

Note how κ2l invokes f on a positive number and g on 0.

223

Now we show that l must be set to lo in order to satisfy blamecorrectness. First, note that for for all l ∈ L, lo � Π3

l if k = lo.Second, the reduction of Π3

l eventually checks that 1 is greater than0, i.e., that the post-condition contract κ2

l is satisfied:

Π3l

∗�−→p El0[mon

lo,kl (�P?l�lo ,‖‖1‖l‖l)]

In order for the picky system to satisfy the blame correctness con-dition, l must be equal to lo, which means the term looks like this:

Elo0 [monlo,k

lo(�P?lo�lo ,‖‖1‖lo‖lo)]

Unfortunately, the next few steps of the reduction process pro-duces a state that is inconsistent with blame correctness. Specifi-cally, κ2

l also checks that g’s pre-condition holds for 0:

Elo0 [monlo,k

lo(�P?lo�lo ,‖‖1‖lo‖lo)] ∗�−→p

Elo1 [monk,lo

lo(�P?lo�lo ,‖‖0‖lo‖lo)]

This last state, however, is inconsistent with the subject becausek cannot equal lo. Indeed, the next few reduction steps result in afailed check. The contract monitor blames k, which isn’t the ownerlo of the value. The picky system fails to assign blame properly.

In essence the proof of the theorem shows that there is no correctstrategy for associating (pieces of) contracts with components ina picky semantics. No matter which labeling strategy we use, acontract violation may blame a component that has no control overthe faulty value.

5. ConsigliereOur model introduces two concepts that are potentially useful forpractical programmers: obligations and ownership. According toour judgments for well-formed contracts and expressions, a con-tractual obligation is a static property of contract text. When con-fronted with complex contracts, a programmer may benefit fromdisplaying such information in the IDE. In contrast, ownership in-formation is a dynamically evolving property, and it is particularlyuseful in a debugger for determining the creator and current ownerof values as they flow from one component to another.

To test the practicality of displaying obligation information, wehave implemented a tool that analyzes modules and contracts andannotates them with obligation information. The tool is a plug-infor DrRacket (Findler et al. 2002), our IDE for the Racket program-ming language. In this section, we refer to the tool as consigliere,though in DrRacket, it is simply a part of the CheckSyntax tool.

The consigliere tool operates on Racket modules in two differ-ent modes. In server mode, consigliere analyzes the module fromthe perspective of the supplier of services. It retrieves all the con-tracts that are attached to exported identifiers and uses

• red to tag the server’s obligations;

• green to highlight the server’s assumptions, i.e., the parts of thecontract that the other party is responsible for; and

• yellow to signal that a part of the contract is both an assumptionand an obligation.

In client mode, consigliere analyzes the module from the per-spective of a consumer of services. Once it has the results, it pro-ceeds as in server mode except that it uses red for the client’s obli-gations and green for the client’s assumptions.

For a simple example, consider the module in figure 10. Themodule provide/contract specification lists one exported func-tion, pick-one. According to its contract, the function consumes anon-empty list of numbers and returns an number. A code inspec-tion shows that the function actually returns a random element ofthe given list.

Figure 10. Obligations and assumptions for one-of

The top of figure 10 shows the result of using the tool inclient mode. As expected, the non-empty list part of the contractis colored in red, because any user of pick-one is required touse a non-empty list of numbers as an argument. Also, becausethe client may assume that pick-one is a function and not somearbitrary value, consigliere colors the -> contract constructor withgreen. The reverse reasoning explains the coloring of the lower partof figure 10, which shows the result of using consigliere in servermode.

For a second example, consider a deriv function with the con-tract from section 1. Its contract is significantly more complex thanpick-one, because it comes with two higher-order components anda post-condition. Note that this contract uses the ->i contract com-binator, turning the contract provider into a party with obligationsand assumptions. Here the contract provider is the server module,meaning ->i is interpreted using the +indy semantics. Practicallyspeaking, the obligations and assumptions of the server also includethe obligations and assumptions of the contract provider.

The top screenshot of figure 11 shows the result of using thetool in client mode. The color assignment roughly follows thesame contravariant traversal of pattern as the contract in figure 10.When it comes to the #:post−cond code, however, the color ofthe keyword indicates that the post-condition is an assumption forthe client just like the other post-condition of the contract.

The lower screenshot depicts the server’s obligations and as-sumptions, which are more interesting than the client’s. The dif-ference is due to the server’s dual role as both a service providerand as the owner of the contract. Recall that the contract provideris responsible for meeting the pre-conditions of f and fp in thepost-condition, while the server may assume that f and fp meettheir post-conditions. As a result, the colors used for f from theserver’s perspective coincide with those used in the client mode.For fp, however, both parts are colored yellow because the obli-gation of the server is the contract provider’s assumption and viceversa. Since the server is both the server and the contract providerparty in this case, the user must be ready to treat the pre-conditionand post-condition of fp either as an assumption or as an obligationdepending on the use.

224

Figure 11. Obligations and assumptions for deriv

6. Related WorkProvenance is the book-keeping of origin, context and history infor-mation of data. It plays an important role for the correct and securebehavior of large software and hardware systems (Simmhan et al.2005; Bose and Frew 2005). The study of provenance from a for-mal linguistic perspective is still at an initial stage (Cheney et al.2009). Our notion of ownership is a means of keeping around someorigin and context information about program values. So it can beviewed as a form of provenance. Also ownership can be used asa basis for studying formal properties of this kind of provenance.However our technique and its use to prove properties of contractsystems is not related to any provenance tracking technology.

Tracking information flow in a computer system is a specializedkind of provenance. Secure information flow as pioneered by Den-ning (1976) is the restriction of flow of data in a computer systemonly between agents that have the appropriate level of clearance.There are both software and hardware techniques for imposing se-cure information flow. Our instrumentation of the dynamic seman-tics resembles techniques used for proving sound type systems thatenforce secure information flow.

Zdancewic et al. (1999) introduce (program) principals as ameans to prove type abstraction properties related to informationflow with a syntactic proof technique. In a principal semantics, dif-ferent principals “own” different components and exported valuescarry the principal of their component of origin. Since the prin-cipals semantics prevents reductions that involve values with dif-ferent principals, a client component is obliged to use a server’sfunctions on the server’s values. In short, the semantics dynami-cally enforces a form of information hiding. It is now easy to seehow a principals semantics supports a syntactic soundness proof forabstract types. If the interface between the server component and

the client employs abstract types and if the type system soundlyenforces type abstraction, stuck states become unreachable duringcomputation.

Although both principals and ownership annotations point to thesource of values and functions, the principal semantics differs sub-stantially from our ownership semantics. Most importantly, prin-cipals may change the evaluation of a program; ownership doesnot. When a function from one server is applied to a value from aclient or a different server, the principal semantics is stuck. In con-trast, ownership annotations are simply propagated in our reductionrules; they do not affect computation. Ownership information is in-stead used to formulate a criteria for determining the correctness ofblame assignment. We can imagine using an ownership semanticsto formulate syntactic soundness proofs for type abstraction, whilewe do not see any advantages over the principals semantics for thisapplication.

As explained in the introduction, Greenberg et al. (2010) studythe full relationship between lax and picky contract systems on onehand and manifest contract systems on the other. For the latter,the type system propagates some of the contract constraints. WhileGronski and Flanagan (2007) established a tight relationship for aworld without dependent contracts, Greenberg et al. (2010) demon-strate that the full picture is rather complex. In particular, they showthat as far as contract violations are concerned, manifest contractssit strictly between lax contracts and picky contracts.

In general, this work extends our decade-old linguistic investi-gation of behavioral software contracts. Meyer (1988, 1991, 1992)introduced software contracts via the design of the Eiffel program-ming language and the creation of a contract-oriented software en-gineering curriculum. Since then contracts have been used bothfor extended static checking (Detlefs et al. 1998; Barnett et al.2004) and runtime monitoring of higher-order programs (Findlerand Felleisen 2002). Blume and McAllester (2006) introduce pickycontract monitoring and explore a quotient model for higher-ordercontracts and use it to prove properties of Findler and Felleisen’shigher-order contracts. Findler et al. (2004; 2006) propose an al-ternative view, namely, “contracts as projections,” which relatescontracts to Scott (1976)’s denotation model of types. Gronski andFlanagan (2007) relate Findler and Felleisen’s higher-order con-tract to type casts. Their result motivates a type-oriented form ofextended static checking (Knowles et al. 2006), which Greenberget al. consider a manifest form of contract. Xu et al. (2009) useBlume and McAllester’s ideas to develop static contract checkingfor Haskell using symbolic evaluation. Hinze et al. (2006) and Chi-til et al. (2003) both introduce contracts to Haskell but end up withtwo different contract systems. The first performs eager contractchecking while the second is lazy. Degen et al. (2010) compare ea-ger and lazy contract checking for lazy languages through a seriesof formal properties but do not reach a definite conclusion.

Finally, in the context of JML (Leavens et al. 1999), Rudichet al. (2008) develop a method for proving the well-formedness ofpure-method specifications and they discuss how their techniquecan benefit from automated theorem proving. The goal of this lineof research is significantly different than ours. It concerns extrac-tion of proof obligations for the verification of JML contracts in-ternal consistency. Unfortunately, JML contracts capture only first-order properties, and it is unclear if their technique is applicablein a higher-order world. Furthermore, their static semantics lacks aformalization of the contract parties which plays an important rolein our work.

7. Conclusion

This paper introduces a new semantics for dependent contracts inresponse to Greenberg et al. (2010)’ s comparison of two alterna-tives. Our work acknowledges the motivation behind the picky con-

225

tract system and turns the lax system into a choice for the confidentprogrammer. Like the picky system, the new indy system protectsarguments and results inside dependency assertions. In contrast tothe picky system, each contract is treated as an independent partywith its own obligations to meet.

Most importantly, we introduce a semantics that tracks valueownership and contract obligations, and we formulate the first evercorrectness criterion for blame assignment. Our major theoremsshow that the indy system guarantees that contract monitors blameonly components that are in control while the picky system fails tosatisfy this intuitive correctness property for blame assignment.

Our results suggest several changes to the implementation ofcontracts in Racket. First, even though the lax semantics is blamecorrect, we now support the indy semantics for dependent contractsto ensure that only guilty parties are blamed. Second, by instantiat-ing the contract party, we obtain flavors of an indy semantics thatsupport the entire variety of Racket contracts in use: server-sidecontracts, client-side contracts, and contracts for ML-like moduleswhere signatures have an independent existence.Third, the notionof well-formed contractual obligations is the basis of a DrRackettool that can remind module programmers of their obligations andassumptions in complex, higher-order contracts.

Acknowledgments

Thanks to Matthew Flatt for suggesting how to exploit Racket’smacro system to implement consigliere. We appreciate fruitfuldiscussions with Riccardo Pucella, Sam Tobin-Hochstadt, StevieStrickland and Carl Eastlund. We are grateful to the anonymousreviewers of POPL 2011 for their useful feedback.

ReferencesH. P. Barendregt. The Lambda Calculus – Its Syntax and Semantics, volume

103 of Studies in Logic and the Foundations of Mathematics. North-Holland, 1984.

M. Barnett, K. R. M. Leino, and W. Schulte. The Spec# programmingsystem: an overview. In Construction and Analysis of Safe, Secure andInteroperable Smart Devices, pages 49–69, 2004.

A. Beugnard, J.-M. Jezequel, N. Plouzeau, and D. Watkins. Making com-ponents contract aware. IEEE Computer, 32(7):38–45, July 1999.

M. Blume and D. McAllester. Sound and complete models of contracts.Journal of Functional Programming, 16(4-5):375–414, 2006.

R. Bose and J. Frew. Lineage retrieval for scientific data processing: asurvey. ACM Computing Survey, 37(1):1–28, 2005.

J. Cheney, S. Chong, N. Foster, M. Seltzer, and S. Vansummeren. Prove-nance: a future history. In Proceeding of the 24th ACM SIGPLANConference Companion on Object Oriented Programming Systems Lan-guages and Applications: Onward! Session (OOPSLA Onward!), pages957–964, 2009.

O. Chitil, D. McNeill, and C. Runciman. Lazy assertions. In Revised Papersof the 15th International Workshop on Implementation of FunctionalLanguages (IFL), pages 1–19, 2003.

M. Degen, P. Thiemann, and S. Wehr. Eager and delayed contract monitor-ing for call-by-value and call-by-name evaluation. Journal of Logic andAlgebraic Programming, page to appear, 2010.

D. E. Denning. A lattice model of secure information flow. Communicationsof the ACM, 19(5):236–243, 1976.

D. L. Detlefs, K. R. M. Leino, G. Nelson, and J. B. Saxe. Extended staticchecking. Technical Report 158, Compaq SRC Research Report, 1998.

C. Dimoulas and M. Felleisen. On contract satisfaction in a higher-orderworld. ACM Transactions on Programming Languages and Systems.accepted (with revisions) for publication.

M. Felleisen, R. B. Findler, and M. Flatt. Semantics Engineering with PLTRedex. MIT Press, 2009.

R. B. Findler and M. Blume. Contracts as pairs of projections. In Pro-ceedings of the 8th International Symposium on Functional and LogicProgramming (FLOPS), pages 226–241, 2006.

R. B. Findler and M. Felleisen. Contracts for higher-order functions. InProceedings of the 7th ACM SIGPLAN International Conference onFunctional Programming (ICFP), pages 48–59, 2002.

R. B. Findler, J. Clements, C. Flanagan, M. Flatt, S. Krishnamurthi,P. Steckler, and M. Felleisen. DrScheme: A programming environmentfor Scheme. J. Funct. Program., 12(2):159–182, Mar. 2002.

R. B. Findler, M. Felleisen, and M. Blume. An investigation of contractsas projections. Technical Report TR-2004-02, University of Chicago,Computer Science Department, 2004.

C. Flanagan. Hybrid type checking. In Proceedings of the 33th An-nual ACM SIGPLAN-SIGACT Symposium on Principles of Program-ming Languages (POPL), pages 245–256, 2006.

M. Flatt and PLT. Reference: Racket. Technical Report PLT-TR-2010-1,PLT Inc., 2010. http://racket-lang.org/tr1/.

M. Greenberg, B. C. Pierce, and S. Weirich. Contracts made manifest. InProceedings of the 37th Annual ACM SIGPLAN-SIGACT Symposium onProgramming Languages (POPL), pages 353–364, 2010.

J. Gronski and C. Flanagan. Unifying hybrid types and contracts. In Pro-ceedings of the 8th Symposium on Trends in Functional Programming(TFP), pages 54–69, 2007.

R. Hinze, J. Jeuring, and A. Loh. Typed contracts for functional program-ming. In In Proceedings of the 8th International Symposium on Func-tional and Logic Programming (FLOPS), pages 208–235, 2006.

K. Knowles, A. Tomb, J. Gronski, S. N. Freund, and C. Flanagan. Sage:Unified hybrid checking for first-class types, general refinement types,and dynamic, 2006. URL http://sage.soe.ucsc.edu/.

G. T. Leavens, A. L. Baker, and C. Ruby. JML: A notation for detaileddesign. In H. Kilov, B. Rumpe, and I. Simmonids, editors, BehavioralSpecifications of Businesses and Systems, pages 175–188. Kluwer Aca-demic Publishers, 1999.

B. Meyer. Design by contract. In Advances in Object-Oriented SoftwareEngineering, pages 1–50. Prentice Hall, 1991.

B. Meyer. Eiffel: The Language. Prentice Hall, 1992.

B. Meyer. Object-oriented Software Construction. Prentice Hall, 1988.

G. D. Plotkin. Call-by-name, call-by-value, and the λ-calculus. TheoreticalComputer Science, 1(2):125–159, 1975.

G. D. Plotkin. LCF considered as a programming language. TheoreticalComputer Science, 5(3):223–255, 1977.

A. Rudich, A. Darvas, and P. Muller. Checking well-formedness of pure-method specifications. In Proceedings of the 15th International Sympo-sium on Formal Methods (FM), pages 68–83, 2008.

D. S. Scott. Data types as lattices. SIAM Journal of Computing, 5(3):522–587, 1976.

Y. L. Simmhan, B. Plale, and D. Gannon. A survey of data provenance ine-science. ACM SIGMOD Record, 34(3):31–36, 2005.

T. S. Strickland and M. Felleisen. Contracts for first-class modules. InProceedings of the 5th Symposium on Dynamic Languages (DLS), pages27–38. ACM, 2009.

S. Tobin-Hochstadt and M. Felleisen. Logical types for untyped languages.In Proceedings of the 15th ACM SIGPLAN Internation Conference onFunctional Programming (ICFP), pages 117–128, 2010.

S. Tobin-Hochstadt and M. Felleisen. The design and implementation ofTyped Scheme. In Proceedings of the 35th Annual ACM SIGPLAN-SIGACT Symposium on the Pronciples of Programming Languages(POPL), pages 395–407, 2008.

D. Xu, S. Peyton Jones, and K. Claessen. Static contract checking forHaskell. In Proceedings of the 36th Annual ACM SIGPLAN-SIGACTSymposium on Programming Languages (POPL), pages 41–52, 2009.

S. Zdancewic, D. Grossman, and G. Morrisett. Principals in programminglanguages: A syntactic proof technique. In Proceedings of the 4thACM SIGPLAN International Conference on Functional Programming(ICFP), pages 197–207, 1999.

226