A Relational Program Logic with Data Abstraction and Dynamic Framing

To introduce the problem addressed in this article, we begin by sketching Hoare’s story about proofs of correctness of data representations. Often a software component is revised with the intent to improve some characteristic such as performance while preserving its functional behavior. As a minimal example, consider this program in an idealized object-based language, with integer global variables \(\texttt {x, y}\) :

It is a client of the interface in Figure 1. An obvious implementation of the module² is for class \(\texttt {Cell}\) to declare an integer field \(\texttt {val}\) that stores the value. Suppose we change the implementation: store the negated value, in a field named \(\texttt {f}\) , and let \(\texttt {cget}\) return its negation. Client programs like the one above should not be affected by this change, at the usual level of abstraction (e.g., ignoring timing). To be specific, we have equivalence of the two programs obtained by linking the client with one or the other implementation of the module. (Equivalence means equal inputs lead to equal outputs.) This has nothing to do with the specific client. The point of data abstraction is to free the client programmer from dependence on internal representations, and to free the library programmer from needing to reason about specific clients.

The (relational) reasoning here is familiar in practice and in theories of representation independence. There is a coupling relation that connects the two data representations; in this case, for corresponding object references \(o,o^{\prime }\) of type \(\texttt {Cell}\) ,This relation is maintained, by paired execution of the two implementations, for each method of the module and for all instances of the class. The fields are encapsulated within the module, so a client can neither falsify the relation nor behave differently from related states, since the visible part of the relation is the identity.

Figure 2 depicts steps of two executions of the example client, linked with alternate implementations of the methods it calls. The top line indicates a relation between the initial states of the left and right executions. The client’s precondition P holds in both ( \(\mathbb {B}\) ), and the initial states agree ( \(\mathbb {A}\) ) on the part of the state that is client-visible. Unknown to the client, the module coupling relation \(\mathcal {M}\) is established by the constructors and can be assumed in reasoning about the calls, provided the method’s implementations preserve the relation. A client step, like \(\texttt {x:=x+1}\) here, should preserve \(\mathcal {M}\) for reasons of encapsulation. The bottom line indicates agreement on the final result. Each method has alternate implementations; the ones for \(\texttt {cset}\) are labelled (as \(B,B^{\prime }\) ) for expository purposes.

In this work, we introduce a logic in which one can specify relational properties such as the preservation of a coupling relation by the two implementations \(B,B^{\prime }\) , as well as equivalence of the two linked programs for a client C. Moreover, the equivalence can be inferred directly from the preservation property. Equivalence is expressed in local terms, referring just to the part of the state that C acts on: In the example client program, the pre-relation is agreement on the value of \(\texttt {x}\) and the post-relation is agreement on \(\texttt {y}\) . If C is part of a larger context, then a relational frame rule can be applied to infer that relations on separate parts of the state are also maintained by C as discussed later.

Encapsulation. The above reasoning depends crucially on encapsulation, and many programming languages have features intended to provide encapsulation. In unary verification, encapsulation serves to protect invariants on internal data structures. It is well known, and often experienced in practice, that references and mutable state can break encapsulation in conventional languages like Java and ML. There has been considerable research on methodologies using type annotations and assertions to enforce disciplines including ownership for the sake of encapsulation and local reasoning. This work focuses on heap encapsulation, without commitment to any specific discipline, but provides a framework in which such disciplines can be used.

In this article, encapsulation is at the granularity of a module, not a class or object. Thus, the implementation of a method \(\texttt {cswap(c, d: Cell)}\) that swaps the values of two cells can exploit that the cells have the same internal representation. However, it is often useful for each instance of an abstraction, say a cell or a stack, to “own” some locations that are separate from those of other instances, so we can do framing at the granularity of an instance. This is manifest in frame conditions, as we will see for \(\texttt {cset}\) , and it is also manifest in invariants. For example, a module for stacks implemented using linked lists has the invariant that distinct stacks use disjoint list nodes.

Let us sketch how encapsulation and module invariants can be formalized in a unary logic. The linking of a client C with a method implementation B can be represented by a simple construct, \(\mathsf {let}~m \mathbin {=}B~\mathsf {in}~C\) that binds B to method name m. (For clarity, we ignore parameters and consider a single method rather than simultaneous linkage of several methods.) The modular linking rule looks as follows, where we use notation \(C:P\leadsto Q\) instead of the usual Hoare triple \(\lbrace P\rbrace C\lbrace Q\rbrace\) (for partial correctness)³:

The first premise says C is correct under the hypothesis that m satisfies the spec \(R\leadsto S\) . (The general form allows other hypotheses, which are retained in the conclusion.) The second premise says the body B of m satisfies a different spec, \(R\wedge I\leadsto S\wedge I\) (and assumes the same, as needed in case of recursive calls to m in B). The spec \(R\leadsto S\) should be understood as the interface on which C relies—indeed, C is modularly correct in the sense that it satisfies its spec when linked with any correct implementation of m, so C never calls m outside its specified precondition R. In the verification of B, the internal invariant I can be assumed initially and must be reestablished. The invariant is hidden from clients of the module.

As displayed, rule (2) is obviously unsound, because C might write a location on which I depends and then call m in a state where I does not hold. The idea is to prevent that by encapsulation, for which we are required to

Relational modular linking. Encapsulation licenses more than just the hiding of invariants. Once the requirements (E1)–(E4) are met in a way that makes Equation (2) sound, we can contemplate the adaptation of Equation (2) to relational reasoning and in particular proving equivalence of two linkages, \(\mathsf {let}~m \mathbin {=}B~\mathsf {in}~C\) and \(\mathsf {let}~m \mathbin {=}B^{\prime }~\mathsf {in}~C\) . The labels (E1)–(E4) are used to also refer to the requirements as adapted to relational reasoning.

The two linkages cannot be expected to behave identically: B and \(B^{\prime }\) typically have different internal state on which they act differently. What can be expected is that from initial states that are equivalent in terms of client-visible locations, the two linkages yield final states that are equivalent on visible locations, as indicated by the deliberately vague “vis” in Figure 2. We say equivalent states, because B and \(B^{\prime }\) may do different allocations; so, the resulting heap structure should be isomorphic but need not be identical. (For many purposes one wants to reason at the source language level of abstraction, ignoring differences due to timing, code size, and absolute addresses; that is our focus.) Given that we have framing (E3), it suffices to establish “local equivalence” in the sense that initial agreement on locations readable by C leads to final agreement on locations writable by C—and on freshly allocated locations. Agreement on other visible locations should then follow.

We write \((B|B^{\prime }): \mathcal {R}\mathrel {{\approx\!\!\!\! \gt }}\mathcal {S}\) , for relations \(\mathcal {R}\) and \(\mathcal {S}\) on states, to say that pairs of terminated executions of programs B and \(B^{\prime }\) , from states related by \(\mathcal {R}\) , end in states related by \(\mathcal {S}\) . For example, \((C|C): \mathbb {A}x\mathrel {{\approx\!\!\!\! \gt }}\mathbb {A}y\) says two runs of C from states that agree on the value of x end in states that agree on the value of y. The relational generalization of Equation (2) is a relational modular linking rule of this form:

The first premise is unary correctness of C assuming the interface spec of m as in rule (2). The conclusion of Equation (3) expresses local equivalence of the two linkages, under precondition P. The second premise relates the two implementations B and \(B^{\prime }\) and is meant to say that if the client-visible “input” locations are in agreement then the resulting visible outputs are in agreement. In addition, a relation \(\mathcal {M}\) is conjoined to the pre- and postcondition. A coupling relation \(\mathcal {M}\) usually has three conjuncts: it says the left state satisfies some invariant I on the internal state used by B, the right state satisfies invariant \(I^{\prime }\) on the internal state used by \(B^{\prime }\) , and there is some connection between the internal states. (We often use “left” and “right” in connection with two programs, states, or executions to be related.) The hypothesis for m in the second premise is the same spec as proved for \((B|B^{\prime })\) , following the pattern in Equation (2). We elide that hypothesis for readability: relational reasoning involves two of everything and the notations quickly become cluttered! As with the modular linking rule (2), the relational modular linking rule (3) is unsound unless we satisfy requirements (E1)–(E4). For relational reasoning, (E2) and (E4) are adapted to relations, and (E3) is strengthened to ensure separation for reads, as one would expect to avoid dependence on internal representations.

Alignment. One technique for proving some relation on final states is to leverage functional specs: a strong constraint on the output values, such as \(out=f(in)\) for some mathematical function f, entails that initial agreement on in leads to final agreement on out. But the need to find and prove functional specs can often be avoided through judicious alignment of intermediate points in execution. This technique is used to prove soundness of Equation (3). To illustrate, consider an instantiation of the general rule in which the three methods in Figure 1 are bound simultaneously ( \(\texttt {cset}\) , \(\texttt {cget}\) , and the \(\texttt {Cell}\) constructor). We show that two executions of the example client can be aligned as in Figure 2, with the indicated relations holding at the aligned points. After the two constructor calls, the resulting states should agree on visible locations and be related by the coupling, according to the premise proved for the constructor. From any pair of states related by \(\mathbb {A}x\wedge \mathbb {A}c\wedge \mathcal {M}\) , two executions of \(\texttt {x:=x+1}\) maintain agreement on visible variables including x, and according to (E3) this step in the client code is not touching internal locations on which \(\mathcal {M}\) depends, so \(\mathcal {M}\) continues to hold. From any pair of states related by \(\mathbb {A}vis\wedge \mathcal {M}\) , a pair of calls to \(\texttt {cset}\) results in states related, by the premise for \(\texttt {cset}\) . Similarly for \(\texttt {cget}\) . In fact, \(\mathcal {M}\) relates the final states in Figure 2, but we omit it there, to emphasize that it is an ingredient of proof rather than the property of ultimate interest.

In a good alignment, most of the intermediate relations are agreements ( \(\mathbb {A}\) ) that amount to simple equalities connecting values in locations of the two states. Finding and exploiting good alignments is essential to leverage automatic theorem provers. For \(\texttt {cset(c,v)}\) in Figure 1, the first implementation is \(\texttt {c.val:= v; return c.val}\) and the second is \(\texttt {c.f:= -v; return -c.f}\) . If we align their executions at the semicolons, then we can assert the coupling relation Equation (1) at that point, by unary reasoning about the effect of the two field updates. Again by unary reasoning about the return expressions we get that the same values are returned, as needed for the final agreement on visible variable y. Alignment does not eliminate the need for unary/functional reasoning, but rather reduces it to small program fragments for which precise semantics can be computed by a theorem prover.

Alignment can be expressed by means of a product program, that is, a program, or some kind of automaton, whose executions correspond to paired executions of the given programs. We call this well known technique the product principle: to prove a correctness judgment \((C|C^{\prime }): \mathcal {R}\mathrel {{\approx\!\!\!\! \gt }}\mathcal {S}\) relating programs C and \(C^{\prime }\) , it suffices to prove the spec for some product program whose executions cover the executions of C and \(C^{\prime }\) .

To emphasize the role of alignment, we consider another example, not about representation independence but about secure information flow. The following program acts on a linked list of integer values, where each node has a boolean field, \(\texttt {pub}\) , meant to indicate that this value is public:

We want to specify and prove that this does not reveal any information about non-public values. Suppose we can define \(listpub(p)\) to be the mathematical list of public values reached from \(\texttt {p}\) . To express that the final value of s depends only on public elements of the list we use the spec \(\mathbb {A}listpub(p)\mathrel {{\approx\!\!\!\! \gt }}\mathbb {A}s\) . The program satisfies the unary spec \(true\leadsto s=sum(listpub(head))\) , and any program that satisfies this must also satisfy \(\mathbb {A}listpub(head)\mathrel {{\approx\!\!\!\! \gt }}\mathbb {A}s\) . But, we can prove the relational spec without recourse to the unary spec. At points in execution where two runs have passed the same number of public nodes, the relation \(\mathbb {A}s\wedge \mathbb {A}listpub(p)\) holds; this suggests an alignment where it suffices to use relational invariant \(\mathbb {A}s\wedge \mathbb {A}listpub(p)\) . Adding the same value to s on both sides maintains \(\mathbb {A}s\) and there is no need to reason that s is the sum of previously traversed public values. The same relational invariant should suffice if sum is replaced by a more complicated function. The alignment can be described as follows: consider an iteration just on the left (respectively, right), if the next left (respectively, right) node is not public; and simultaneous execution of the body on both sides, if both next nodes are public.

We cannot in fact define listpub as a function of p, owing to the possibility of cycles in the heap. Instead, we use an inductive relation when we work out the details of this example Section 4.5.

Summary of ingredients needed. To achieve the three goals in Section 1, we need:

These ingredients need to be provided in ways that facilitate verification tools that leverage automated provers especially SMT solvers. Reasoning under hypotheses is straightforward to implement, but effective expression of specs and alignment is less obvious.

Our relational logic is based on prior work in which ghost state is used in frame conditions to describe sets of heap locations. This approach, dubbed dynamic frames [54], has been shown to be amenable to SMT-based automated reasoning in verification tools [62, 81, 87, 91], and shown to be effective in expressing relations on dynamically allocated data structures [3, 11]. In particular, we build on a series of articles on region logic(RL); it provides a methodologically neutral basis for heap encapsulation with sufficient generality for sequential first-order object-based programs featuring callbacks between modules. We refer to key articles as RLI [14], RLII [9], and RLIII [12], and summarize key ideas in the following.

Framing. In current tools, the most common form of frame condition is a “modifies clause” that lists some expressions, meant to designate the writable locations. A reads clause is similar. In the formalization of RL, specifications are written in the compact form \(pre\leadsto post\:[{{frame}}]\) where the effect expressions in the frame condition are tagged by keywords \(\mathsf {wr}\,\) and \(\mathsf {rd}\,\) to designate writables and readables. We use \(\mathsf {rw}\,\) to abbreviate the possibility to both read and write. In this work, a region is a set of object references. For example, a possible spec of \(\texttt {cset(c,v)}\) is \(c\ne \mathsf {null}\leadsto cget(c)=v\:[\mathsf {rw}\,\lbrace c\rbrace {{\bf `}}\mathsf {any}],\) where the postcondition refers to the mathematical interpretation of the pure method \(\texttt {cget}\) (as in RLIII). The singleton region \(\lbrace c\rbrace\) is used in the frame condition. In the image expression \(\lbrace c\rbrace {{\bf `}}\mathsf {any}\) , the token \(\mathsf {any}\) is a data group [64] that abstracts from field names. Concrete field names can also be used in image expressions, e.g., \(\lbrace c\rbrace {{\bf `}}val\) . This example designates a single location, which may as well be written \(c.val\) . But the image notation can be used for larger sets of heap locations. For variable r of type region, \(r{{\bf `}}val\) designates the set of val fields of all \(\texttt {Cell}\) objects in r. So \(\mathsf {rd}\,r{{\bf `}}val\) in a frame condition allows any of these fields to be read.

Following separation logic, RL features local reasoning in the form of a frame rule, but achieves this with ordinary first-order assertions. For an example, strengthening the precondition of \(\texttt {cset(c,v)}\) gives \(c\ne \mathsf {null}\wedge d\ne c\leadsto cget(c)=v\:[\mathsf {rw}\,\lbrace c\rbrace {{\bf `}}\mathsf {any}]\) . The frame rule lets us add \(d.val=z\) to the pre- and postcondition. Why? Because the condition \(d.val=z\) cannot be falsified: the writes allowed by the frame condition are separate from what is read<sup>4</sup> by the formula \(d.val=z\) . In case of the variables d and z, this is a matter of checking that d and z are not writable. Distinctness of field names can be used similarly. But here, \(\mathsf {rw}\,\lbrace c\rbrace {{\bf `}}\mathsf {any}\) allows that \(c.val\) can be written and val also occurs in the formula \(d.val=z\) . Separation holds, because the regions \(\lbrace c\rbrace\) and \(\lbrace d\rbrace\) are disjoint, written \({\lbrace c\rbrace }{\#}{\lbrace d\rbrace }\) , which follows from precondition \(d\ne c\) . As in the frame rule of separation logic [76], this reasoning is inherently state dependent; separation would not hold if variables d and c held the same reference. Our frame rule has this form:In the frame rule of RL, separation is expressed by a conjunction of set disjointness formulas derived syntactically from the frame condition \(\varepsilon\) and the read effects of R. In this example, the relevant effects are \(\mathsf {wr}\,c.val\) and \(\mathsf {rd}\,d.val\) and there is a single disjointness formula: \({\lbrace c\rbrace }{\#}{\lbrace d\rbrace }\) . This formula is obtained by applying the separator function \(\mathbin {\cdot {{\bf /}}.}\) introduced later, in Figure 11.

Encapsulation. RLII features dynamic boundaries, in which the idea of dynamic frame is adapted to encapsulation for module interfaces. The dynamic boundary of a module is simply an effect expression that designates the locations meant to be internal to the module. Technically, it is a read effect, in keeping with its role to cover the footprint of the module invariant. In addition to the usual meaning of a partial correctness judgment, there is an additional obligation: the program must not write locations within the boundary of any module other than its own module.

For the example module \(\texttt {MCell}\) , the dynamic boundary (omitted from Figure 1) is formulated in terms of a ghost variable, pool, of type region. The postcondition of the \(\texttt {Cell}\) constructor says the new cell is added to pool. The boundary is \(\mathsf {rd}\,pool,\mathsf {rd}\,pool{{\bf `}}\mathsf {any}\) , so clients must not write the variable pool or any field of an object in pool. One could as well achieve this effect using module-scoped field names, so let us briefly consider a less degenerate example: a module for stacks.

In addition to ghost variable pool containing all instances of the stack class, that class would have a ghost field rep of type region. In an implementation using linked lists, each stack’s list nodes would be in its rep, and the module invariant would specify some “object invariant” for each stack together with its nodes. This is depicted in Figure 3. In an implementation using arrays, rep would contain the stack’s array, and the module invariant would express some condition that holds for each stack object and its array. Of course there is a single interface for the module. Method frame conditions will refer to pool and rep, and not expose implementation details. To facilitate per-instance framing, an invariant like \(s\ne t\Rightarrow {s.rep}{\#}{t.rep}\) is used, which says the representations for distinct stacks are disjoint. A suitable dynamic boundary is \(\mathsf {rd}\,pool, \mathsf {rd}\,pool{{\bf `}}\mathsf {any}, \mathsf {rd}\,pool{{\bf `}}rep{{\bf `}}\mathsf {any}\) . It designates fields of the stack objects in pool and also fields of all their rep objects. (Array slots can be viewed as fields.) The mentioned invariant enables use of the frame rule to consider updates of a single instance, and it is suitable to be included in the module interface for use by clients. (Either as explicit conjunct in method pre- and postconditions, or declared as a public invariant for syntactic sugar.) For example, \(\texttt {s.push(n)}\) writes \(s.rep{{\bf `}}\mathsf {any}\) ; in states where \(s\ne t\) this preserves the value of \(\texttt {t.top()}\) , which reads \(t.rep{{\bf `}}\mathsf {any}\) —and preservation holds in virtue of frame conditions, without recourse to postconditions that specify functional behavior.

In summary, a module interface comprises a collection of method specs, and a dynamic boundary. A module implementation maintains an internal invariant I, the footprint of which should be framed by the boundary. The invariant I should be such that it follows from the initial conditions of the main program. For example, universal quantification over elements of pool holds when pool is empty. An alternate approach is to require clients to call a module initializer.

Modular linking. Following the lead of O’Hearn et al. [77], the logic in RLII derives a modular linking rule like Equation (2) from two simpler rules: An obviously-sound rule for the linking construct ( \(\mathsf {let}~m \mathbin {=}B~\mathsf {in}~C\) ) and a second-order frame (SOF)rule that accounts for hiding of invariants on encapsulated state. A minimalistic formalization of modules is used, to keep the focus on the main ideas. The unary correctness judgment takes the form \(\Phi \vdash _M C: P\leadsto Q\:[\varepsilon ]\) with M the name of the module in which C is to be used. It says that, under hypotheses \(\Phi\) and precondition P, command C stays within the effects \(\varepsilon\) and establishes Q if it terminates—and in addition, C respects the boundaries of any modules in \(\Phi\) other than its own module M. This formalizes requirement (E3). In RLII, “respect of dynamic boundaries” means not writing locations inside them. In the present article, we must strengthen respect to prohibit reading, to ensure that C has no dependency—neither reads nor writes—on the internal representation of modules other than its own.

Our relational specs have the form \(\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\mathcal {Q}\:[\varepsilon |\varepsilon ^{\prime }]\) where \(\mathcal {P}\) (respectively, \(\mathcal {Q}\) ) is the relational pre- (respectively, post-)condition. There is a separate frame condition \(\varepsilon\) for the left execution and \(\varepsilon ^{\prime }\) for the right. Often those are the same, in which case we abbreviate as \(\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\mathcal {Q}\:[\varepsilon ]\) . The meaning of frame conditions and encapsulation is the same as in the unary logic. Leaving effects aside, there are several ways one could interpret a spec \((C|C^{\prime }): \mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\mathcal {Q}\:[\varepsilon |\varepsilon ^{\prime }]\) in regards to termination. All ways consider a pair of initial states, say \(\sigma ,\sigma ^{\prime }\) , that satisfy \(\mathcal {P}\) . The “ \(\forall \exists\) interpretation” says that for every execution of C from \(\sigma\) , terminating in a state \(\tau\) , there is an execution of \(C^{\prime }\) from \(\sigma ^{\prime }\) that terminates in a state related to \(\tau\) by \(\mathcal {Q}\) . The \(\forall \exists\) interpretation asserts relative termination and caters for nondeterminacy. The “ \(\forall \forall\) interpretation” was already mentioned just before (3): every pair of terminating runs of C and \(C^{\prime }\) from \(\mathcal {P}\) -related states end in \(\mathcal {Q}\) -related states. The \(\forall \forall\) form is fine for deterministic programs, which is what we consider, and it is simpler, so we use it.

For relation formulas, we build directly on image expressions. Agreements are interpreted in terms of a partial bijection between the dynamically allocated references of the left and right states, as commonly used to account for bijective renaming of references at the Java/ML level of abstraction [7, 8, 23, 27]; we call these refperms. For region expression G, the relation \(\mathbb {A}G{{\bf `}}f\) asserts agreement on f-fields for objects in G that correspond according to the refperm. We do not require every allocated reference to be in the refperm: this is important, to specify relational properties that allow differences in allocation behavior. Examples of such differences include internal data structures and reasoning about secure information flow (under low branch condition, allocated locations can be added to the refperm, but not under high branch condition).

We formulate the logic in terms of an explicit representation for product programs that designate alignments. The biprogram form \((C|C^{\prime })\) indicates no alignment except for the initial and final states. Other biprogram forms express, for example, that iterations of a loop are to be aligned in lockstep, or conditionally as needed for the sumpub example (4). For the implementations of \(\texttt {cset}\) , the alignment described earlier is expressed as \(\texttt {(c.val:= v | c.f:= -v); (return c.val | return -c.f)}\) .

A judgment for \((C|C^{\prime })\) directly entails the expected relation between unary executions of commands C and \(C^{\prime }\) (as confirmed by our adequacy theorem). The choice to use a different alignment of C with \(C^{\prime }\) is formalized by an explicit proof rule. The rule is formulated in terms of a weaving relation that connects a biprogram with a more tightly aligned version, typically chosen, because it admits use of simpler relational assertions. The rule says that properties of the woven program hold also for \((C|C^{\prime })\) .

Given that we confine attention to sequential code, it seems natural to expect that programs are deterministic, but we also aim for reasoning at the source code level abstraction—for which determinacy is unrealistic owing to dynamic allocation! The behavior of an allocator typically depends on things that are not visible at the source level. There is no need to make unrealistic assumptions. Our program semantics allows that the allocator may be nondeterministic (while not assuming that it is “maximally nondeterministic” as often done in the literature). Our program semantics is quasi-deterministic in the sense that outcomes are unique up to bijective renaming of references. Our relation formulas do not allow pointer arithmetic or comparisons other than equality, so they are invariant under renaming. These design decisions entail some complications in the technical development, but ensure that interesting programs do provably satisfy expected \(\forall \forall\) properties.

As already mentioned, the unary modular linking rule (2) is derived (in RLII) from two simpler rules: a basic linking rule, where assumed and proved specs match exactly, together with a second-order frame rule. Our novel relational modular linking rule (3) is derived from a relational linking rule, a relational second-order frame rule, and a third rule. The third rule lifts a unary correctness judgment to a relational judgment that says a program is locally equivalent to itself. For this to be proved, it is stated in a stronger form: a program can be aligned with itself in lockstep such that local equivalence holds at each intermediate step.

As for the goal of foundational justification, our approach is to work directly with a conventional operational semantics for unary correctness, for which we formulate a semantics of encapsulation. The biprogram semantics is based directly on that, so that soundness for rules in the relational logic has a direct connection—adequacy theorem—to unary semantics. One benefit from carrying out the development in terms of this elementary semantics is that one can see that most of the soundness proofs can be adapted easily to total correctness (both runs always terminate) and to relative termination (right run terminates whenever left does).

We highlight the following contributions.

A unary logic for modular reasoning about sequential object-based programs using first-order assertions. The key contribution and most difficult definition to get right is the extensional semantics of encapsulation, which is part of the meaning of correctness judgments. Small-step operational semantics is used, so we can define what it means for a given step to be outside the boundaries of all modules but its own. We build on the semantics in RLII but completely revamp it to handle encapsulation of reads in addition to writes. Dynamic boundaries are taken from RLII; most of the proof rules of RLII need little or no revision, but they must all be re-proved for the new semantics. Owing to the need for quasi-determinacy (for \(\forall \forall\) extensional semantics of read effects), the new semantics of hypothetical judgments quantifies over possible denotations (called context interpretations) rather than a single “least refined” denotation as in RLII and in O’Hearn et al. [77]. We present detailed soundness proofs of the key rules (Theorem 6.1).

A relational logic. The logic relies on unary judgments for reasoning about atomic commands and for enforcing encapsulation. Relational assertions are first-order formulas. Our presentation focuses on data abstraction, because this is the first relational logic to embody representation independence as a proof rule using only first-order means. But the logic is general, with a full range of rules that facilitate reasoning with convenient alignments.

We present detailed soundness proofs of the key rules (Theorem 8.1). Formally, judgments of the relational logic give properties of biprograms; the adequacy Theorem 7.11 connects those properties with the expected properties in terms of paired unary executions in standard semantics (the product principle).

Demonstration of suitability for automation via case studies in a prototype relational verifier. The prototype translates biprograms and verification conditions specific to our logic, which are all first-order, into Why3 code and lemmas, proved using SMT solvers (why3.lri.fr). The modular linking rules (unary and relational) are implemented by generating suitable Why3 specs for the programs involved. The case studies include noninterference, program transformations, and representation independence.

The most difficult technical result is the lockstep alignment lemma (Lemma 8.9). It brings together the semantics of encapsulation in the unary logic, which involves a single context interpretation, with the semantics of relational correctness—which involves three context interpretations, to account for un-aligned calls as well as aligned calls and relational specs.

The direct use of small-step semantics makes for lengthy soundness proofs that require, in some cases, intricate inductive hypotheses. But transition semantics is a critical ingredient for a first-order definition of heap encapsulation. It was quite difficult to arrive at rules for relational linking and second-order framing that are provably sound. Several variations on the semantics of encapsulation turned out to be sound for the unary linking and second-order frame rules but failed to validate a sufficiently strong lockstep alignment property on which relational linking can be based.

Aside from lockstep alignment, the soundness proofs for linking rely on denotational semantics, which in turn relies on quasi-determinacy. This property is also used to establish embedding/projection results on which the adequacy theorem is based.

The semantics of correctness judgments is extensional in the sense that it refers only to behavior in a standard transition semantics—no instrumentation artifacts. Like in RLII, it does rely on use of transition semantics to express that control is currently within a specific module and outside the boundaries of other modules in scope. This affects which program transformations are correctness-preserving; more on this in Section 8.6.

Once the right definitions, lemmas, and induction hypotheses have been determined, the soundness proofs go by induction on traces, with many details to check. We relegate them to appendices.

The formal development omits some features that were handled in the prior works on which we build: parameters, private methods, constructor methods, pure methods for abstraction in specs. These are all compatible with the formal development; all are implemented in the prototype and used in exposition. The theory is compatible with standard forms of encapsulation based on scoping mechanisms (e.g., module scoped variables), which for practical purposes should be leveraged as much as possible; for simplicity, we refrain from formalizing such mechanisms.⁵ The prototype also supports public invariants; as noted in connection with the stack example, these are important for client reasoning about boundaries using patterns like ownership. Public invariants need not be formalized in the theory, as they can be explicitly included in method specs.

The simplicity of our semantic framework (e.g., standard semantics of formulas and programs) may facilitate foundational justification of a verifier, but we have not formally proved the correctness of our prototype.

There are two technical limitations. First, the semantics of encapsulation and the proved rules handle collections of modules with both import hierarchy and callbacks. But the key rules for relational linking and relational second-order framing (rSOF) only handle simultaneous linking of a collection of modules. This is enough to model linking as implemented in a verifier. However, one may hope for a theory that accounts for distinct inference steps that successively link different layers of hierarchy, as in our unary logic. To achieve this, the lockstep alignment lemma needs to be strengthened to ensure agreements for already-linked methods. This requires to further complicate an already intricate theory. In this article, we just sketch the issue (Section 8.5).

Second, the current formulation has a technical condition (boundary monotonicity) that prevents release of encapsulated locations, in the sense of reasoning with specs that describe outward ownership transfer. (Inward transfer is fine.) Modules can create new objects for clients, as in the shared handle objects for priority queues, one of our running examples. But a location that has been within the boundary must stay there. Overcoming this restriction, or finding idiomatic specification patterns that dodge it, is left to future work. Both inward and outward transfer are possible in RLII (an example is in Section 2.2 of that article).

Addressing the limitations is the subject of ongoing and future work.

A running example is introduced in Figure 4. We consider the priority queue module \(\texttt {PQ}\) , which exposes a class whose instances represent priority queues that store integer values and priorities, referred to as “keys” (smaller key means higher priority) [98]. Our implementations (based on Reference [98]) use pairing heaps, where each queue contains a head field that points to a \(\texttt {Pnode}\) object and each \(\texttt {Pnode}\) contains sibling, prev, and child fields that point to other \(\texttt {Pnode}\) s. The rep field of a queue is used to hold references to the objects notionally owned by the queue.

The syntax of programs in our formal development is in Figure 5. The grammar includes biprograms, to which we return in Section 4. Field read and write commands are written with dereferencing implicit, as in Java (though using the symbol \(:=\) ), and are desugared to have a single heap access that simplifies proof rules. The \(\mathsf {let}\) construct, featured in the modular linking rule (2), represents scoped method declarations.⁶ Some examples, like Figure 4, use the syntax of our prototype, in which keyword \(\texttt {meth}\) corresponds to the \(\mathsf {let}\) construct. Examples use some syntax sugars implemented in our prototype, e.g., invocation of method \(\texttt {link}\) in an update of field \(\texttt {self.head}\) (Figure 4). A method named after a class (e.g., \(\texttt {Pqueue}\) ) is meant to be used as a constructor, i.e., invoked on a newly allocated object, the fields of which are initialized with default values (null for classes, \(\varnothing\) for regions).

To lessen the need for uninteresting transitions in program semantics, we equate certain syntactic forms. For example, there is no transition from \((\mathsf {skip};C)\) to C, because we consider them to be the same syntactic object, see Figure 6. Working with syntax trees up to (i.e., quotiented by) syntactic equivalence is done in the previous RL articles and elsewhere.⁷ We sometimes use the symbol \(\equiv\) for equality of other syntactic forms, like variables, just to emphasize that they are syntactic.

Programs and specs are typed in a conventional way. A typing context \(\Gamma\) maps variable names to data types and method names to the token \(\mathsf {meth}\) , written as usual as lists, e.g., \(x\mathord {:}T,y\mathord {:}T,m\mathord {:}\mathsf {meth}\) . (In the formalization, we omit method parameters and results.) Various definitions refer to a typing context typically meant to be the global variables, including ghost variables, which may be of type \(\mathsf {rgn}\) (region). We do not formalize ghost variables as such [14, 42].

The idea of ghost code is to instrument a program with extra state for the sake of reasoning, in such a way that the termination and behavior of the original program is not affected. This can be formalized in terms of a rule for elimination of ghost state [14, 42, 78]. We refrain from doing so in this article; the additions would not be illuminating.

A class is just a named record type. In the formal development we assume an ambient class table that declares some class types and the types of their fields. For simplicity this has global scope. We assume that field names in different class declarations are distinct, so any declared field f determines a unique class, \(\text{ {DeclClass}}(f)\) , that declares it, and also a type, which we write \(f:T\) .

Section 2.2 introduced the region expressions used in frame conditions. In addition to (mutable) variables of type region, there are set operations like union, singleton, subtraction ( \(\backslash\) ), and image expressions. The expression \(\lbrace x\rbrace\) denotes the singleton set containing the value of x. For G a region expression, the image expression \(G{{\bf `}}f\) is the empty region if \(f:\mathsf {int}\) . If f is of some class type, then \(G{{\bf `}}f\) is the set of current values of f-fields of objects (i.e., object references) in G. For f of type \(\mathsf {rgn}\) the image is the union of the field values. For example, in the idiom using global variable \(pool:\mathsf {rgn}\) containing some objects with field \(rep:\mathsf {rgn}\) , the image \(pool{{\bf `}}rep\) is the union of their rep fields. The type restriction expression \(G/K\) denotes the elements of G of type K (which excludes null).

As usual in program logics, field access and update is limited to the primitive forms \(x:=y.f\) and \(x.f:=y\) . In specs and ghost code, a dereference chain like \(x.f.g.h\) (for reference type fields) can be expressed by the region expression \(\lbrace x\rbrace {{\bf `}}f{{\bf `}}g{{\bf `}}h\) ; if x is null the value is the empty set.

Owing to the simple model of classes, the notation can be defined as shorthand for \(G{{\bf `}}\overline{f}\) where \(\overline{f}\) is the list of all field names. An implementation can support user-defined data groups, which can be used to abstract from specific sets of fields [64].

The typing rules for expressions and commands are straightforward and omitted, with the exception of those in Figure 7. We highlight those, because we allow f in an image expression \(G{{\bf `}}f\) to have any type; as noted above, its value is empty unless f has region or class type.⁸

Program variables are partitioned into two sets, ordinary variables and spec-only variables.⁹ The distinguished variable \(\mathsf {alloc}:\mathsf {rgn}\) is an ordinary variable, but it is treated specially: It is present in all states, and is automatically updated in the transition semantics by the transition for \(\mathsf {new}\) , so in every state its value is exactly the set of allocated references. Spec-only variables are used in specs to “snapshot” initial values for reference in the postcondition. Spec-only variables do not occur in code, even ghost code, or in effects.¹⁰ In our prototype, “old” expressions are used to abbreviate the use of snapshot variables [60].

Commands are typed in a context \(\Gamma\) . We omit the straightforward rules for typing of commands, except to note that a call \(\Gamma \vdash m()\) is well formed only if \(m:\mathsf {meth}\) is in \(\Gamma\) . To streamline the formal development, we omit parameters for methods; by-value parameters can be handled straightforwardly as in RLII and RLIII.¹¹

Program expressions E are heap independent. For expressions of reference type, the only constant is \(\mathsf {null}\) and the only operation is equality test, written \(=\) . Region expressions can depend on the heap but are always defined. Null dereference faults only occur in the primitive load and store commands \(x:=y.f\) and \(x.f:=y\) . By contrast, if x is null then \(\lbrace x\rbrace {{\bf `}}f\) is defined to be empty.

Assume given a set ModName of module names, and map \({ {mdl}}:{ {MethName}}\rightarrow { {ModName}}\) that associates each method with its module. Usually, we use letters \(M,N,L\) for module names, but there is a distinguished module name, \({ \bullet }\) , that serves both as main program and as default module in the proof rules for atomic commands. Assume given a preorder \(\preceq\) (read “imports”) on ModName, which models the reflexive transitive closure of the import relation of a complete program. We write \(\prec\) for the irreflexive part. Cycles are allowed, as needed for interdependent modules that respect each other’s encapsulation boundaries. A module interface includes a spec for each method. The function \({ {bnd}}\) from \({ {ModName}}\) to effect expressions associates each module with its dynamic boundary, which is thus part of its interface along with its method specs. This lightweight formalization of modules is adapted from RLII (its Section 6.1).

For the \(\texttt {PQ}\) interface in Figure 8, \({ {mdl}}(\texttt {insert})=\texttt {PQ}\) . In one of our case studies, the main program implements Dijkstra’s single-source shortest-paths (SSSP) algorithm, as a client of \(\texttt {PQ}\) and another module \(\texttt {Graph}\) . The import relations are then \({ \bullet }\prec \texttt {PQ}\) and \({ \bullet }\prec \texttt {Graph}\) .

A module M specifies a dynamic boundary \({ {bnd}}(M)\) . The boundary can be expressed using regions and data groups for abstraction, to cater for implementations that have differing internals. This is why there is a single type, \(\mathsf {rgn}\) , for sets of references of any type. Well-formedness conditions for boundaries are defined in Section 3.3.

A proper module system would include module-scoped variables and fields that need not be part of the interface and need not be the same in different implementations of a module N. Our simplified formulation streamlines the formal development, because we do not need syntax, typing contexts, and so on, for a full-fledged module calculus, nor correctness judgments for modules. But this comes at a price: some well-formedness conditions on correctness judgments (in the following subsections) and side conditions (in proof rules) merely serve to express lexical scoping that could be handled more neatly using a proper module system.

We assume a first-order signature providing primitive type, function, and predicate symbols for use in specs and in ghost code. Predicate formulas are in Figure 9. The points-to relation \(x.f=E\) says that x is non-null and the value of field f equals the value of E. For examples, see the postcondition of \(\texttt {insert}\) in Figure 8. The predicate \(\mathsf {type}(G,\overline{K})\) says that every non-null reference in G has one of the class types in the list \(\overline{K}\) .

Typing of unary predicate formulas P is straightforward. For example, the points-to formula \(x.f=E\) is well formed (wf) in \(\Gamma\) provided \(\Gamma (x)\) is some type K that declares \(f:T\) and E has type T. An expression E counts as an atomic formula if it has type \(\mathsf {bool}\) ; this includes equality tests. The signature may include equality at other math types, with standard interpretation.

Quantifiers at a class type K range over allocated references of type K. The logic does not require quantification at type \(\mathsf {rgn}\) , but we include it to simplify the grammar. It is often useful to bound the range of quantification at reference type to a specific region, in the form \(\forall x:K .\:x\in G \Rightarrow P\) , to facilitate framing. (This is explored in RLI.) In sugared form: \(\forall x:K\in G .\:P\) .

Effect expressions. A spec comprises precondition P, postcondition Q, and frame condition \(\varepsilon\) . Frame conditions are effect expressions \(\varepsilon\) , defined by

Left-expressions, LE, are a subset of expressions (category F in Figure 5). They have l-values, as discussed below, and are used in effects and in agreement formulas.¹² An effect \(\varepsilon\) is wf in \(\Gamma\) provided each of its left-expressions is.

Notation: Besides \(\varepsilon\) , we often use identifiers \(\eta\) and \(\delta\) for effect expressions. We use the short term effect for effect expressions, including compound ones like \(\mathsf {rd}\,x,\mathsf {wr}\,x,\mathsf {wr}\,\lbrace x\rbrace {{\bf `}}f\) . The singleton image \(\mathsf {wr}\,\lbrace x\rbrace {{\bf `}}f\) can be abbreviated as \(\mathsf {wr}\,x.f\) . We use the abbreviation \(\mathsf {rw}\,\) to mean \(\mathsf {rd}\,\) and \(\mathsf {wr}\,\) . The empty effect is given explicit notation \({ \bullet }\) for clarity in certain parts of the development, but we omit it when confusion seems unlikely. We often treat compound effects as sets of atomic reads and writes. We also omit repeated tags, e.g., \(\mathsf {rd}\,x,y\) abbreviates \(\mathsf {rd}\,x,\mathsf {rd}\,y\) ; and then reads are separated from writes by semicolon, e.g., \(\mathsf {rd}\,x,y;\mathsf {wr}\,z,w\) .

l-value and r-value. In common usage, the term r-value refers to the meaning of an expression in contexts like the right side of an assignment. For those expressions allowed on the left of an assignment, the l-value is the location to be assigned and the r-value is the current contents of that location [95]. In our language there are two forms of mutable location: variables and heap locations. A heap location is a pair \((o,f)\) where o is an object reference and f a field name; we write the pair as \(o.f\) .

We identify a subset of expressions, called left-expressions (6), which have an l-value—in addition to the r-values described in Section 3.1 (and formalized in Figure 21). In general, the l-value of a left-expression designates a set of locations. In frame conditions, left-expressions are interpreted for their l-values as is common in spec languages. (Note that our left-expression form \(G{{\bf `}}f\) is not an assignment target.)

In the write effect \(\mathsf {wr}\,x\) , the l-value of expression x is a single location, the variable x itself, independent of the current state. For the left-expression \(\lbrace x\rbrace {{\bf `}}f\) , the l-value is again a single location, namely, \(o.f\) , where o is the r-value of x in the current state—unless that value is null, in which case the l-value is the empty set.

Consider a variable \(r:\mathsf {rgn}\) . The l-value of \(r{{\bf `}}f\) is the set of \(o.f\) where o is a non-null reference that is an element of the current value of r. (We may say “object in r” to be casual.)

What about the l-value of \(r{{\bf `}}f {{\bf `}}g\) ? It is the set of \(o.g\) where o is a non-null reference in the region \(r{{\bf `}}f\) —that is, o is an element of the r-value of \(r{{\bf `}}f\) . In case f has type \(\mathsf {int}\) , that region is empty. In case f has some class type K, the region \(r{{\bf `}}f\) is the set of contents of f fields of objects in r. So, for \(o.g\) to be in the l-value of \(r{{\bf `}}f{{\bf `}}g\) means o is the value in \(p.f\) for some non-null reference p in r.

Suppose instead that f has type \(\mathsf {rgn}\) . Then the r-value of \(r{{\bf `}}f\) is defined to be the union of the values of the f-fields of objects in r. (We use the union to avoid sets of sets.) So, for \(o.g\) to be in the l-value of \(r{{\bf `}}f{{\bf `}}g\) means o is an element of the set \(p.f\) for some non-null p in r.

In general, the l-value of a left-expression is dependent on the state, for the values of variables and for the values of fields of allocated objects. For example, consider the private method, \(\texttt {link}\) , used internally by \(\texttt {insert}\) (Figure 4). The ascribed effect of method \(\texttt {link}\) is Here, \(\lbrace \mathsf {self}\rbrace {{\bf `}}rep\) is used for its r-value, which is a set of objects in the rep field (the same as \(\mathsf {self}.rep\) ), and the left-expression \(\lbrace \mathsf {self}\rbrace {{\bf `}}rep{{\bf `}}child\) is used in the effect to refer to the locations of the child fields of all the \(\texttt {Pnode}\) s in \(\mathsf {self}{{\bf `}}rep\) .

Dynamic boundary and operations on effects. For expressions and atomic formulas, read effects can be computed syntactically by the footprint function, \({ {ftpt}}\) , defined in Figure 10. For example, the private invariant for the \(\texttt {PQ}\) module (Figure 8) includes \(q.rep{{\bf `}}prev\subseteq q.rep\) . Its footprint, computed by \({ {ftpt}}\) , is \(\mathsf {rd}\,q, \mathsf {rd}\,\lbrace q\rbrace {{\bf `}}rep, \mathsf {rd}\,\lbrace q\rbrace {{\bf `}}rep{{\bf `}}prev\) , which can be abbreviated as \(\mathsf {rd}\,q, \lbrace q\rbrace {{\bf `}}rep, q.rep{{\bf `}}prev\) . It has a closure property, framed reads, that will play a role in reasoning about encapsulation.

In addition to the well-formedness assumption that the module import relation, \(\preceq\) , is a preorder, we also assume that every declared boundary, \({ {bnd}}(M)\) , is a candidate dynamic boundary. The distinguished default module name \({ \bullet }\) has empty boundary: \({ {bnd}}({ \bullet })={ \bullet }\) . For a finite set \(X\subseteq { {ModName}}\) , we use the abbreviation for the catenation (union) of the boundaries. Note that such combined boundaries are themselves candidate dynamic boundaries. For \(\texttt {PQ}\) , the dynamic boundary, \({ {bnd}}(\texttt {PQ})\) , is \(\mathsf {rd}\,pool, pool{{\bf `}}\mathsf {any}, pool{{\bf `}}rep{{\bf `}}\mathsf {any}\) .

The syntactic operation of effect subtraction, , is used to formulate local equivalence specs; in particular, we subtract a dynamic boundary from a method’s frame condition. Subtraction is defined as follows. First, put \(\varepsilon\) and \(\eta\) into the following normal form¹³: No field occurs outermost in more than one field read or more than one field write. This can be achieved by merging \(\mathsf {rd}\,G{{\bf `}}f,\mathsf {rd}\,H{{\bf `}}f\) into \(\mathsf {rd}\,(G\mathbin {\mbox{$\cup $}}H){{\bf `}}f\) and likewise for write. (Occurrences of field images within G and H, not being outermost, are untouched.) Assuming \(\varepsilon ,\eta\) are in normal form, define \(\varepsilon \backslash \eta\) to be \((\delta _0,\delta _1,\delta _2,\delta _3)\) whereand \(\delta _2,\delta _3\) are defined the same way for writes. For example, let r and s be region variables. Then \((\mathsf {rd}\,r,\mathsf {rd}\,s,\mathsf {rd}\,(r\mathbin {\mbox{$\cup $}}s){{\bf `}}nxt,\mathsf {rd}\,r{{\bf `}}val)\backslash (\mathsf {rd}\,r,\mathsf {rd}\,\lbrace x\rbrace {{\bf `}}nxt)\) is \(\mathsf {rd}\,s,\mathsf {rd}\,((r\mathbin {\mbox{$\cup $}}s)\backslash \lbrace x\rbrace){{\bf `}}nxt,\mathsf {rd}\,r{{\bf `}}val\) .

The separator function , mentioned in connection with the frame rule (5) is defined by structural recursion on effects (Figure 11).¹⁴ Given effects \(\varepsilon ,\eta\) it generates a formula \(\varepsilon \mathbin {\cdot {{\bf /}}.}\eta\) that implies the read effects in \(\varepsilon\) are disjoint locations from the writes in \(\eta\) . Please note that \(\mathbin {\cdot {{\bf /}}.}\) is not syntax in the logic; it’s a function in the metalanguage that is used to obtain formulas, dubbed separator formulas, from effects. For example, \(\mathsf {rd}\,r{{\bf `}}nxt \mathbin {\cdot {{\bf /}}.}\mathsf {wr}\,r{{\bf `}}val\) is the formula true and \(\mathsf {rd}\,r{{\bf `}}nxt \mathbin {\cdot {{\bf /}}.}\mathsf {wr}\,s{{\bf `}}nxt\) is the disjointness formula¹⁵ \({r}{\#}{s}\) . Note that \(\varepsilon \mathbin {\cdot {{\bf /}}.}\eta\) is identical to \({ {rds}}(\varepsilon) \mathbin {\cdot {{\bf /}}.}{ {wrs}}(\eta)\) where \({ {rds}}\) keeps just the read effects and \({ {wrs}}\) the writes. The separator function can be used to obtain disjointness conditions for two read effects, say \(\varepsilon\) and \(\eta\) , by using the function we call \({ {r2w}}\) , which discards write effects and changes reads to writes, as in \(\varepsilon \mathbin {\cdot {{\bf /}}.}{ {r2w}}(\eta)\) . Function \({ {w2r}}\) does the opposite. The upcoming Example 3.5 shows a use of \(\mathbin {\cdot {{\bf /}}.}\) and the frame rule.

On the way to formalizing correctness judgments, we first consider specs. Spec-only variables are implicitly scoped over the spec but not explicitly declared.

The last item says spec-only variables are used as “snapshot” variables.¹⁷ In this article, the \(^{\prime }\) symbol is often used for identifiers on the right side of a pair, so we avoid it for other decorative purposes, instead using \(\hat{hats}\) and \(\dot{dots}\) .

A hypothesis context \(\Phi\) (context, for short) maps some procedure names to specs and is written as a comma-separated list of entries \(m: P\leadsto Q\:[\varepsilon ]\) .

A correctness judgment has the form where \(\Phi\) is a hypothesis context and M is a module name. The judgment is for code of the current module M. We distinguish two kinds of method calls in C: environment calls are those where a called method is bound by let within C; the others, context calls, are those where a called method is specified in \(\Phi\) . Informally, the correctness judgment says executions of C from P-states read and write only as allowed by \(\varepsilon\) , and Q holds in the final state if execution terminates. A context call to m in \(\Phi\) may involve reading and writing encapsulated state for the module, \({ {mdl}}(m)\) , of m, and these effects must be allowed by \(\varepsilon\) . Commands are given small step semantics, with bodies of let-bound methods kept in an environment. The judgment also says that, aside from context calls, steps of C must neither read nor write locations encapsulated by any module in \(\Phi\) except its own module M. These conditions must hold for any correct implementation of \(\Phi\) , so the judgment expresses “modular correctness” [61].

Typically, in a judgment \(\Phi \vdash _M C:\ldots\) we will have \(M\preceq N\) for each N in \(\Phi\) (i.e., each N for which some m in \(\Phi\) has \({ {mdl}}(m)=N\) ). However, we do not want to say \(\Phi\) must contain every N with \(M\preceq N\) , because we use “small axioms” [76] to specify atomic commands, which are stated in terms of the minimum relevant context. Additional hypotheses can be added using “context introduction” rules with side conditions that enforce encapsulation, as discussed in Sections 3.5 and 6.3. At the point in a proof where a client C is linked with implementations of its context \(\Phi\) , the judgment for C will include all methods of the modules in \(\Phi\) , and all transitive imports.

Because we are not formalizing a separate calculus of modules and module judgments, some module-related scoping and typing conditions are associated with correctness judgments for commands. The lack of an explicit binder for the spec-only variables of a spec also requires some care.

For example,is a wf judgment; in particular, we have the typing \(x\mathord {:}\mathsf {int},y\mathord {:}\mathsf {int},m\mathord {:}\mathsf {meth}\vdash x:=0;m()\) .

Summary. So far, we introduced the syntax of commands, unary specs and unary correctness judgments. The symbol \(\equiv\) is sometimes used for equality of syntactic objects like variable names, and especially in the case of commands and biprograms, which we identify up to the equivalences in Figure 6.

There are also a number of meta-operators on syntax that are used pervasively and should not be confused with the syntax: effect subtraction ( \(\varepsilon \backslash \eta\) ), separator ( \(\varepsilon \mathbin {\cdot {{\bf /}}.}\eta\) ), footprint ( \({ {ftpt}}(\eta)\) ), converting write effects to reads ( \({ {w2r}}\) ), and so on. There is no concrete syntax for modules; instead there are meta-operators for the boundary \({ {bnd}}(M)\) of the module named M, the import relation \(\preceq\) on module names, and the module name \({ {mdl}}(m)\) associated with method m.

Appendix E has a table of notations and a table of metavariables.

In this subsection, we consider how the requirements (E1)–(E4) for encapsulation in Section 2.1, are met in the unary logic. Figure 12 shows the interface of a module that provides a class whose instances are union-find structures. The first requirement for encapsulation, (E1), is to delimit some locations internal to the module. That is the purpose of the dynamic boundary, which in the logic would be written \(\mathsf {rd}\,pool,\mathsf {rd}\,pool{{\bf `}}\mathsf {any},\mathsf {rd}\,pool{{\bf `}}rep{{\bf `}}\mathsf {any}\) (in accord with Definition 3.1) and abbreviated as \(\mathsf {rd}\,pool, pool{{\bf `}}\mathsf {any}, pool{{\bf `}}rep{{\bf `}}\mathsf {any}\) . An equivalent formulation of the boundary is \(\mathsf {rd}\,pool, (pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep){{\bf `}}\mathsf {any}\) .

In this example, we follow the idiom, and even the naming convention, sketched in Section 2.2 for a module providing stacks. Aside from rep, the boundary does not mention specific fields but rather uses the data group \(\mathsf {any}\) for the sake of abstraction.

Because \(\mathsf {rd}\,pool\) is in the boundary of \(\texttt {UnionFind}\) , client programs may neither read nor write this variable. It serves in specs to designate references to, at least, the \(\texttt {Ufind}\) instances managed by the module; so the constructor method \(\texttt {Ufind}\) , which should be invoked on newly allocated \(\texttt {Ufind}\) objects, adds the new object to pool. The boundary includes \(\mathsf {rd}\,pool{{\bf `}}\mathsf {any}\) , which says fields of these objects may neither be read nor written by client programs. In specs and reasoning about clients, the rep field of a \(\texttt {Ufind}\) is important: it is used to delimit the locations modified by method calls on that instance, and a public invariant of the module says distinct \(\texttt {Ufind}\) instances have disjoint rep. This enables reasoning that performing an operation on one \(\texttt {Ufind}\) does not affect the state of another \(\texttt {Ufind}\) —which is locality, not encapsulation. Fields of objects in rep are encapsulated by the module, as expressed by \(\mathsf {rd}\,pool{{\bf `}}rep{{\bf `}}\mathsf {any}\) . Here \(pool{{\bf `}}rep\) is the union of the rep fields of all allocated \(\texttt {Ufind}\) s.

We consider an implementation based on the quick-find data structure [88]. Math type \(\texttt {partition}\) represents a partition on a set of numbers \(0\dots n-1\) . It is used in ghost code and specs, in particular, the private invariant, which says each queue p satisfies a predicate defined on its internal representation, which is an array referenced by field id.

The union-find implementation uses a representative element for each block of the partition, with \(id[x]\) being the representative of x, for each x in \(0\ldots n-1\) . If x is a representative, then \(id[x]=x\) . The private invariant says that for any x, \(id[x]\) is a representative: \(p.id[p.id[x]] = p.id[x]\) . The last conjunct says x and y have the same representative in \(p.id\) just if they are in the same block of the abstract partition. The ghost field rep has nothing to do with representatives; as in our usual idiom it holds references to the internal representation objects, in this case just the id.

Requirement (E2) for encapsulation is that a private invariant depends only on locations within the boundary. This is formalized in the logic by a framing judgment, which in our example is written \(\models (\mathsf {rd}\,pool, \mathsf {rd}\,(pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep){{\bf `}}\mathsf {any}) \mathrel {\mathsf {frm}} I_{qf}\) . As formalized later, its meaning is that if \(I_{qf}\) holds in some state, then it holds in any other state that agrees on the values in the locations designated by the read effect. Looking at its definition, \(I_{qf}\) depends on only one variable, pool. The heap locations on which it depends are in expressions \(p.id\) and index expressions \(p.id[x]\) . As we have \(p.id \in p.rep\) , by the invariant, and the slots of the array are effectively fields of id, these heap locations are indeed covered by \(\mathsf {rd}\,(pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep){{\bf `}}\mathsf {any}\) . The meaning of the framing judgment can be encoded as a universally quantified formula; this and other framing judgments in our case studies are easily validated by SMT solvers.

Here, we consider the quick-find implementation, which for the \(\texttt {find}\) method is

A key postcondition of the spec of \(\texttt {find}\) is that \(result \in \mathit {pfind}(k,\mathit {self}.part)\) , where \(\mathit {pfind}\) is the function that returns the block of the abstract partition that contains k. The postcondition holds in virtue of conditions in the private invariant, including that \(id[k]\) is a representative, for any k, and the connection between \(\mathit {self}.part\) and \(\mathit {self}.id\) .

Encapsulation of a client. As a case study, we have verified Kruskal’s minimum spanning tree algorithm as client, but for present purposes we consider a very simple client:

To verify the client code, its hypothesis context needs to include the module specs, in particular for \(\texttt {find}\) . So \(\texttt {UnionFind}\) is in scope and its boundary must be respected by the client. The logic enforces encapsulation of clients, i.e., requirement (E3), using separation checks similar to those for frame-based reasoning as in Example 3.5.

To explain the checks, let us write \(\delta _{\mbox{uf}}\) for the boundary of \(\texttt {UnionFind}\) . The command \(x:=\mathsf {new}\;\texttt {Thing}\) has frame \(\mathsf {wr}\,x,\mathsf {rw}\,\mathsf {alloc}\) . Respect of \(\delta _{\mbox{uf}}\) by this command is formulated in terms of the separator function, in this case \(\delta _{\mbox{uf}} \mathbin {\cdot {{\bf /}}.}\mathsf {wr}\,x,\mathsf {alloc}\) . Unfolding the definition (Figure 11) yields the formula \(\mathsf {true}\wedge \mathsf {true}\) . The only variable designated by \(\delta _{\mbox{uf}}\) is pool, and this is distinct from x and from \(\mathsf {alloc}\) . The proof obligation here also rules out client code that assigns or reads pool. In general, it is untenable to include \(\mathsf {rd}\,\mathsf {alloc}\) in a boundary, or even an image expression mentioning \(\mathsf {alloc}\) , because clients typically do allocation.

The command \(x.f:=y\) has frame condition \(\mathsf {rd}\,x,\mathsf {rd}\,y,\mathsf {wr}\,\lbrace x\rbrace {{\bf `}}f\) . For the write to be outside the boundary, the obligation can be written \(\delta _{\mbox{uf}} \mathbin {\cdot {{\bf /}}.}\mathsf {wr}\,\lbrace x\rbrace {{\bf `}}f\) . Unfolding by definition of the separator function, and expanding the abbreviation \(\mathsf {any}\) to be all field names in scope, we get a conjunction of trues (because the read and written variables are distinct) and two nontrivial conjuncts: \({pool}{\#}{\lbrace x\rbrace }\) and \({pool{{\bf `}}rep}{\#}{\lbrace x\rbrace }\) . That is, the assigned object must be in neither pool nor any rep fields of objects in pool. One way this obligation can be proved is via freshness: neither pool nor rep have been updated since x was assigned a fresh object. A related idiom used in some method specs is a postcondition that says all fresh objects are in \(\mathit {self}.rep\) , which a client can use to reason that its own regions remain disjoint. In a postcondition, the fresh references are denoted by \(\mathsf {alloc}\backslash \mathsf {old}(\mathsf {alloc})\) . In the formal logic state predicates only refer to a single state, so a postcondition must be expressed in the same way that tools desugar “old” expressions. That is, a fresh spec-only variable, say r, is used to snapshot the initial value: the precondition includes \(r=\mathsf {alloc}\) and the idiomatic postcondition is now \(\mathsf {alloc}\backslash r \subseteq \mathit {self}.rep\) .

We are not finished with \(x.f:=y\) . In addition to its writes, its reads must be outside the boundary, specifically, x and y must be outside \(\delta _{\mbox{uf}}\) . This can be written \(\delta _{\mbox{uf}} \mathbin {\cdot {{\bf /}}.}\mathsf {wr}\,x,\mathsf {wr}\,y\) . Why \(\mathsf {wr}\,\) ? Just so we can use the separator function \(\mathbin {\cdot {{\bf /}}.}\) unchanged from prior work, though it is defined to separate read effects from writes. (The proof rule for field update uses another metafunction, \({ {r2w}}\) , to convert the reads to writes.)

As an example of how encapsulation checks can fail, consider a bad client of the \(\texttt {PQ}\) interface (Figure 8) that calls \(\texttt {insert}\) and assigns the returned \(\texttt {Pnode}\) to variable nd, and then writes the key field of nd—potentially invalidating a private invariant. The boundary of \(\texttt {PQ}\) is similar to the one for \(\texttt {UnionFind}\) , so the separator formula is \({pool}{\#}{\lbrace nd\rbrace } \wedge {pool{{\bf `}}rep}{\#}{\lbrace nd\rbrace }\) . This is not valid, since the value of nd is in \(pool{{\bf `}}rep\) .

So far, we saw how the frame conditions of atomic commands give rise to proof obligations that ensure the client reads and writes are to locations disjoint from the locations designated by the boundary. Please note that the interpretation of the boundary is at the point in execution where the atomic command has its effects. This does not make a difference for variables, in the sense that a separator \(\mathsf {rd}\,x \mathbin {\cdot {{\bf /}}.}\mathsf {wr}\,y\) is just true or false depending on whether the variable names are distinct. It does make a difference for heap locations, designated by expressions like \(pool{{\bf `}}\mathsf {any}\) and \(\lbrace x\rbrace {{\bf `}}f\) ; in this case the obligation \({pool}{\#}{\lbrace x\rbrace }\) discussed above must hold in the pre-state of the assignment command \(x.f:=y\) .

Loops and conditionals also incur an encapsulation obligation that their test expressions read outside the boundary. In our desugared syntax (Figure 5) these expressions are heap independent. In the example the check is simply that variable pool does not occur in a test expression, since the other locations in the boundary are heap locations. Here is an example where a test crosses the boundary of \(\texttt {PQ}\) :

This client works fine with the first implementation of \(\texttt {PQ}\) , since \(nd.prev\) will be null. But for the implementation with sentinels, the second call to \(\texttt {insert}\) will fault due to null dereference. The client is not representation independent and the read of \(nd.prev\) will fail the encapsulation check.

In our prototype, WhyRel, encapsulation checks like this are straightforward. At points where the encapsulation check is state dependent, like \(x.f:=y\) , WhyRel generates an assert statement that encodes the disjointness obligation (Section 9). In the logic, encapsulation checks are disentangled from other reasoning considerations by the context introduction proof rules. The modules whose boundary must be respected are those of the methods in the hypothesis context, given using the \({ {mdl}}\) function defined in Section 3.2. The technical details are not conceptually important, and are explained in Section 6.3.

In summary, encapsulation requirement (E3) is achieved by checking separation from the relevant boundaries, for each part of the client command. Separation is checked the same way as it is for the ordinary Frame rule, using formulas generated from the effects using the separator function ( \(\mathbin {\cdot {{\bf /}}.}\) ). For effects on variables it is true or false depending on whether the requisite variables are distinct, but for effects on heap locations (load and store commmands, method calls) the separation checks are region disjointness formulas that must hold at the relevant points in control flow.

Modular linking. Suppose we verify the client, using the public specs, and discharge the proof obligations, just discussed, for encapsulation. We verify the implementation of \(\texttt {find}\) , \(\texttt {union}\) , etc using the private invariant \(I_{qf}\) , i.e., assuming it as precondition and establishing it as post, in accord with the modular linking rule sketched as Equation (2) in Section 2.1. Having verified the client and the implementations of module methods, we would like to conclude that the linked program is correct, i.e., satisfies the client spec as per rule (2). The private invariant is hidden from the client, in the sense that the method bodies are verified for specs that include it, but it is omitted from the hypotheses used to verify the client. There is one more requirement for this to be sound, namely, (E4): the client precondition implies the private invariant of the module. An appropriate such precondition is \(pool=\varnothing\) , the default value for regions, which implies \(I_{qf}\) owing to its quantification over pool.

The intuition that justifies Equation (2) is that, given the client’s respect for the boundary, any judgment \(D:P\leadsto Q\:[\varepsilon ]\) about a client subprogram D yields \(D:P\wedge I\leadsto Q\wedge I\:[\varepsilon ]\) by an application of the frame rule (because the encapsulation obligation ensured the footprint of the private invariant I is disjoint from the effects in \(\varepsilon\) ). In particular, at a point where the client has established public precondition R of a method that has been verified using precondition \(R\wedge I\) , we do in fact have \(R\wedge I\) . For example, having proved the judgment \(\texttt {find}:R\leadsto S \vdash C:P\leadsto Q\) (omitting frame condition) together with the encapsulation obligations for client C, we haveThis is formalized as the second-order frame rule, SOF in Figure 23. The modular linking rule (2) is a consequence of SOF together with the obvious linking rule that requires the method bodies to satisfy exactly the specs assumed by the client. Please note that all formulas involved in the specs are first-order; the SOF rule is called second order only in the sense that the framed formula is conjoined to specs in the hypothesis context as well as to the consequent of the judgment.

On dynamic boundaries. In this article, we repeatedly use the idiom with pool and rep, but this is merely one convenient way to write specs that support module-based encapsulation and per-instance local reasoning. Ghost variables and fields can just as well be used to express hierarchical ownership or cooperating clusters of objects as in design patterns like subject-observer. Such examples can be found in RLI–III.

A key point is that the dynamic boundary is part of a module interface, and should be expressed in such a way that different module implementations can have different internal data structures. Thus, the same dynamic boundary may denote different locations for different implementations. This can be achieved using ghost state, data groups, and pure methods. In this article, we only formalize a single data group, \(\mathsf {any}\) , and we omit pure methods (see Section 2.6).

To prove the disjointnesses needed for client code to be outside a boundary, one can rely on invariants that constrain the relevant ghost state. For this purpose it is convenient for a module interface to include public invariants such as Equation (8) in Example 3.4.

Figure 5 gives the grammar of biprograms. A biprogram CC represents a pair of commands, which are given by syntactic projections defined in Figure 13. For example, the left projection \(\mathop {{(\mathsf {skip}|x:=0);(y:=0|z:=1)}}\limits^{\leftharpoonup\!\!-\!-\!-\!-\!-\!-\!-\!-\!-\!\!-\!\!-\!\!-\!\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!}\) is \(y:=0\) , taking into account that we identify \(\mathsf {skip};y:=0\) with \(y:=0\) (see Figure 6). The symbol \(|\) is used throughout the article, in program and spec syntax and also as alternate notation for pairing in the metalanguage, when the pair represents a pair of states or similar.²⁰

Biprograms are given small-step semantics. The bi-com form \((C|D)\) represents executions of commands C and D, which are meant to be aligned on their initial state and, if they terminate, final state. Their execution steps are interleaved (i.e., dovetailed, in the terminology of automata theory), to ensure that the traces of \((C|D)\) cover all traces of C and D by making progress on both sides even if one diverges. The parentheses of bi-coms are obligatory and the operator binds less tightly than others: \((A;B|C;D)\) is the same as \(((A;B)|(C;D))\) . In Section 4.5 we consider how the other biprogram forms are introduced for a verification problem specified using a bi-com. For now, we briefly explain the other forms.

The sync form \(\lfloor A \rfloor\) represents two executions of the atomic command A, aligned as a single step. This is mainly of interest for allocations and method calls. For a call, \(\lfloor m() \rfloor\) indicates that a relational spec should be used to reason about the two calls. For an allocation, the form \(\lfloor x:=\mathsf {new}\;K \rfloor\) has a proof rule in which the two new references are considered in agreement, i.e., “added to the refperm.” In the grammar (Figure 5), the bi-var form allows different names and types but one also wants to allow multiple variables on each side; this is implemented in our prototype. The bi-if form, \(\mathsf {if}\ {E\mbox{$|$}E^{\prime }}\ \mathsf {then}\ {CC}\ \mathsf {else}\ {DD}\) , asserts that the two initial states agree on the value of the test expressions E and \(E^{\prime }\) . The bi-while form \(\mathsf {while}\ {E\mbox{$|$}E^{\prime }} \cdot {\mathcal {P}\mbox{$|$}\mathcal {P}^{\prime }}\ \mathsf {do}\ {CC}\) incorporates relation formulas \(\mathcal {P}\) and \(\mathcal {P}^{\prime }\) , which serve as alignment guards. These serve as directives to indicate how to align iterations of the loop, catering for situations like the sumpub program in Equation (4). This is explained in more detail in Section 4.5; see the aligned sumpub in Equation (15).

Typing of biprograms can be defined in terms of syntactic projection, roughly as \(\Gamma |\Gamma ^{\prime }\vdash CC\) iff \(\Gamma \vdash \mathop {CC} \limits^{\leftharpoonup}\) and \(\Gamma ^{\prime }\vdash \mathop {CC} \limits^{\rightharpoonup}\) . But the alignment guard formulas in a bi-while should also be typechecked in \(\Gamma |\Gamma ^{\prime }\) , and are required to be free of agreement formulas, i.e., those of the form \(\mathbb {A}G{{\bf `}}f\) and \(F\mathrel {\ddot{=}}F^{\prime }\) ; this ensures that the formula is refperm-independent as explained later. Although the two sides of a biprogram may have different typing contexts, for simplicity a single class table is assumed. It is straightforward to generalize this to allow different field declarations for a given class (and it is implemented in our prototype).

Relation formulas are interpreted over a pair of states, meant to be at aligned points in two executions. What is important is to express not only conditions relating integers and other mathematical values but also conditions relating structures between the two heaps. There are many ways to formalize such formulas; it is only in the treatment of heap relations that the design choices made here have significant impact on the later development.

The relation formulas are defined in Figure 14. Quantifiers range over allocated references; the relational form binds a variable on each side. The form \({\langle \! [} P {\langle \! ]}\) (respectively, \({[\! \rangle } P {]\! \rangle }\) ) says unary predicate P holds in the left state (respectively, right). Left and right embedded expressions are written \({\langle \! [} F {\langle \! ]}\) and \({[\! \rangle } F {]\! \rangle }\) and have nothing to do with left-expressions LE. They may be used as arguments to atomic predicates in the ambient mathematical theories: \({\langle \! [} F {\langle \! ]}\) (respectively, \({[\! \rangle } F {]\! \rangle }\) ) evaluates F in the left (respectively, right) state.²¹

The forms \(\mathbb {A}\, LE\) and \(F\mathrel {\ddot{=}}F^{\prime }\) are called agreement formulas. For E and \(E^{\prime }\) of some reference type K, the form \(E\mathrel {\ddot{=}}E^{\prime }\) (pronounced “E bi-equals \(E^{\prime }\) ”) says the value of E in the left is the same as \(E^{\prime }\) on the right, modulo refperm in the case of reference values. Similarly with \(G\mathrel {\ddot{=}}G^{\prime }\) for regions. The form \(\mathbb {A}G{{\bf `}}f\) says for each reference \(o\in G\) , with corresponding value \(o^{\prime }\) in the other state, the value of \(o.f\) is the same as the value of \(o^{\prime }.f\) , modulo refperm if the value is of reference type. For example, \(\mathbb {A}r{{\bf `}}rep{{\bf `}}val\) means the val fields agree, for all objects in the rep field of all objects in r.

The form \(\mathbb {A}x\) is equivalent to \(x\mathrel {\ddot{=}}x\) . But the form \(\mathbb {A}G{{\bf `}}f\) is not equivalent to \(G{{\bf `}}f\mathrel {\ddot{=}}G{{\bf `}}f\) . The former means pointwise field agreement (modulo refperm) and the latter means equal values (modulo refperm), the two values being reference sets.

The modal form \(\Diamond \mathcal {P}\) , read possibly \(\mathcal {P}\) (for lack of a better word), says \(\mathcal {P}\) holds in a refperm possibly extended from the current one. More on these points later.

Relation formulas and relational correctness judgments are typed in a context of the form \(\Gamma |\Gamma ^{\prime }\) comprises contexts \(\Gamma\) and \(\Gamma ^{\prime }\) for the left and right sides.²² Leaving aside left/right embedded expressions, typing can be reduced to typing of unary formulas: \(\Gamma |\Gamma ^{\prime }\vdash \mathcal {P}\;\) iff \(\; \Gamma \vdash \mathop {\mathcal{P}} \limits^{\leftharpoonup}\mbox{ and }\Gamma ^{\prime }\vdash \mathop {\mathcal{P}} \limits^{\rightharpoonup}\) . This refers to syntactic projections defined in Figure 15. This does not work for left/right embedded expressions; we gloss over those for clarity, in the following sections as well, but handle them in our prototype.

In accord with the definition of projections, we have the formula typing \(\Gamma |\Gamma ^{\prime }\vdash \mathbb {A}x\) just if \(x\in { {dom}}\,(\Gamma)\mathbin {\mbox{$\cap $}}{ {dom}}\,(\Gamma ^{\prime })\) . We have \(\Gamma |\Gamma ^{\prime }\vdash \mathbb {A}G{{\bf `}}f\) just if \(\Gamma \vdash G:\mathsf {rgn}\) and \(\Gamma ^{\prime }\vdash G:\mathsf {rgn}\) , with f of any type. Similarly, \(\Gamma |\Gamma ^{\prime }\vdash F\mathrel {\ddot{=}}F^{\prime }\) provided \(\Gamma \vdash F:T\) and \(\Gamma ^{\prime }\vdash F^{\prime }:T\) . Also \(\Gamma |\Gamma ^{\prime }\vdash {\langle \! [} P {\langle \! ]}\) if \(\Gamma \vdash P\) and \(\Gamma |\Gamma ^{\prime }\vdash {[\! \rangle } P {]\! \rangle }\) if \(\Gamma ^{\prime }\vdash P\) .

A relational spec has relational pre- and postconditions and a pair of frame conditions. We write to abbreviate the frame condition \([\varepsilon |\varepsilon ]\) . A spec \(\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\mathcal {Q}\:[\varepsilon |\varepsilon ^{\prime }]\) is wf in \(\Gamma |\Gamma ^{\prime }\) provided \(\mathop {{\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\mathcal {Q}\:[\varepsilon |\varepsilon ^{\prime }]}}\limits^{\leftharpoonup\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!}\) is wf in \(\Gamma\) (respectively, \(\mathop {\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\mathcal {Q}\:[\varepsilon |\varepsilon ^{\prime }]}\limits^{\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!\rightharpoonup}\) in \(\Gamma ^{\prime }\) ), as per Definition 3.2. See Figure 15 for syntactic projections. The precondition \(\mathcal {P}\) of a wf relational spec has spec-only variables only as snapshot equations in top level conjuncts of \(\mathcal {P}\) (inside the left and right embedding operators \({\langle \! [} - {\langle \! ]}\) , \({[\! \rangle } - {]\! \rangle }\) ). Any spec-only variables in postcondition \(\mathcal {Q}\) must occur in \(\mathcal {P}\) .

Recall from Section 2.1 that one important relational property is local equivalence. Later, we define a general construction, \({ {locEq}}\) , that applies to a unary spec \(P\leadsto Q\:[\varepsilon ]\) and yields a relational spec (Example 4.3 and Section 8.1). The general form takes into account that encapsulated locations are not expected to be in agreement; that is formalized by means of effect subtraction.

For local equivalence and other purposes, we often want postconditions that assert agreements on fresh locations. These agreements are modulo refperm, so a relational correctness judgment should say there is some refperm for which the final states are related. This can be expressed using the \(\Diamond\) modality. Many specs of interest have the form \(\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {Q}\:[\eta |\eta ^{\prime }]\) where \(\mathcal {P},\mathcal {Q}\) are \(\Diamond\) -free. Such specs are said to be in standard form. We gloss over this in some examples. In our prototype, the encoding maintains a “current refperm” in ghost state to interpret agreement formulas, and does not use the \(\Diamond\) modality explicitly in specs. The dual, \(\mathord {{\Box }}\) , is used in a couple of proof rules.

A relational hypothesis context for \(\Gamma |\Gamma ^{\prime }\) is a triple \(\Phi = (\Phi _0,\Phi _1,\Phi _2)\) comprising unary hypothesis contexts \(\Phi _0\) for \(\Gamma\) and \(\Phi _1\) for \(\Gamma ^{\prime }\) , together with a mapping \(\Phi _2\) of method names to relational specs that are wf.

The constraint on preconditions ensures a compatibility condition needed to connect relational with unary context models, see Definition 7.9. Definition 4.1 allows left and right to have different global variables. It also allows that some spec-only variables on the left may also occur on the right. However, well formedness is in the context of a single module structure (module names and their association with methods and dynamic boundaries; import relation).

We consider an example of relational verification, which is modular in the sense of using relational method specs, but no information hiding. We highlight how regions are used in relational specs, and how biprograms are used to represent convenient alignments.

List tabulation: illustrating procedure-modular reasoning. Consider the two programs in Figure 16, which both tabulate a linked list of the values of some method \(\texttt {mf}\) that computes a function, applied to the numbers n down to 1. Objects of class \(\texttt {List}\) have two fields: \(head: \texttt {Node}\) references the head of a linked list and \(nds:\mathsf {rgn}\) is ghost state, to which we return soon. The goal in this example is to prove the programs are equivalent. We reason about executions of the two programs in close alignment, to exploit their similarities and make use of a relational spec for \(\texttt {mf}\) . The example also serves to show the use of regions to describe heap structure and in particular to express the equivalence of the lists returned. The example illustrates two aspects of modular reasoning: procedural abstraction and local reasoning; the third aspect, data abstraction, is considered in Section 4.6.

Both versions of the program use field nds to hold references to the nodes reached from head. It is initially empty (the default value), and in each iteration the newly allocated node is added to the list’s nds. An invariant of the loop, in both programs, is \(t.nds{{\bf `}}next \subseteq t.nds\) . Here \(t.nds\) is set of references. The image expression \(t.nds{{\bf `}}next\) denotes the set of values in the next fields of objects in \(t.nds\) (a direct image, thinking of the field as a relation). The containment \(t.nds{{\bf `}}next \subseteq t.nds\) says for any object reference in \(t.nds\) , the value of the object’s next field is in \(t.nds\) . There are no recursive definitions involved. The containment, together with invariant \(t.head \in t.nds\) , implies that everything reachable from \(t.head\) is in \(t.nds\) . It does not say that \(t.nds\) is exactly the reachable set, though it will be; we do not need that stronger fact.

Method \(\texttt {mf}\) has an integer parameter x and returns an integer result. Its unary spec is \(true\leadsto true\:[{ \bullet }]\) , which says very little but the empty frame condition says it has no effect on the heap or global variables. In particular, it does no allocation, since otherwise its frame condition would have to include \(\mathsf {rw}\,\mathsf {alloc}\) . Implicitly it is allowed to read its parameter x and write its result, as we saw in Example 3.5. As relational spec, we use \(\mathbb {A}x\mathrel {{\approx\!\!\!\! \gt }}\mathbb {A}result\:[{ \bullet }]\) , which expresses determinacy as self-equivalence in a way that is local: it refers only to locations that may be read or written. It is this relational spec, and nothing more, that we wish to use for \(\texttt {mf}\) in relational reasoning about \(\texttt {tabulate}\) .

For \(\texttt {tabulate}\) , the frame condition is \([\mathsf {rw}\,\mathsf {alloc}]\) . It allocates, which implicitly updates the special variable \(\mathsf {alloc}\) by adding the newly allocated reference; the new value of \(\mathsf {alloc}\) depends on its old value, so the frame condition says \(\mathsf {alloc}\) may be both read and written. Like method \(\texttt {mf}\) , method \(\texttt {tabulate}\) reads its parameter and writes its result, but neither reads nor writes any other preexisting locations.

Although we aim to prove equivalence of the two versions of \(\texttt {tabulate}\) without recourse to a precise functional spec, we do include a postcondition that constrains nds, as this plays a role in specifying equivalence. The postcondition says nds contains head and is closed under next; formally: \(result.nds{{\bf `}}next \subseteq result.nds\) and \(result.head \in result.nds\) .

To express equivalence of the two versions, the (relational) precondition is agreement on what is readable, namely, the parameter n. The agreement formula \(\mathbb {A}n\) , or equivalently \(n\mathrel {\ddot{=}}n\) , simply means the two initial states have the same value for n. We do not assume agreement on \(\mathsf {alloc}\) ; we want the equivalence to encompass initial states without constraint on allocated but irrelevant objects.

For the postcondition, we want agreement on what is writable (aside from \(\mathsf {alloc}\) ), thus \(\mathbb {A}result\) . We also specify that the unary postcondition holds in both final states:But result is just a reference to newly allocated list structure. To express that the two result lists have the same content, we need more than \(\mathbb {A}result\) . A first guess is the agreement formula \(\mathbb {A}result.nds{{\bf `}}val\) . The formula uses syntax sugar, to abbreviate \(\mathbb {A}\lbrace result\rbrace {{\bf `}}nds {{\bf `}}val\) . Agreement formulas, as mentioned in Section 2.3, are interpreted with respect to a refperm, that is, a type-respecting partial bijection on references of the two states. Whereas \(\mathbb {A}n\) means identical values for integer n, the formula \(\mathbb {A}result\) means equivalent reference values, i.e., connected via the bijection. The formula \(\mathbb {A}result.nds{{\bf `}}val\) says that for pairs \(o,o^{\prime }\) of references connected by the bijection, with \(o\in result.nds\) , the fields \(o.val\) and \(o^{\prime }.val\) have equal contents (equal because the type is integer).

To fully constrain the lists to have the same structure, we use this postcondition:Here \(\Diamond\) says there exists some refperm. The formula \(\mathbb {A}result.nds\) abbreviates \(\mathbb {A}\lbrace result\rbrace {{\bf `}}nds\) and says the refperm cuts down to a (total) bijection between the regions \(result.nds\) in the two states. The condition \(\mathbb {A}result.nds`next\) says that bijection is compatible with the linked list structure.

The semantics of relation formulas is formalized in Section 7.1. It is a little subtle: \(\lbrace x\rbrace {{\bf `}}f \mathrel {\ddot{=}}\lbrace x\rbrace {{\bf `}}f\) is different from \(\mathbb {A}\lbrace x\rbrace {{\bf `}}f\) , unless guarded by \(\mathbb {A}x\) (as a conjunct or antecedent). We invariably use such guarded formulas, e.g., conjuncts in Equation (11) and antecedents in the coupling of Example 4.3.

Taken together, Equations (10) and (11) say the results from \(\texttt {tabulate}\) are lists for which the nodes can be put in bijective correspondence that is compatible with the nxt pointers and for which corresponding elements have the same value. They serve as postcondition, with precondition \(\mathbb {A}n\) , to specify equivalence for \(\texttt {tabulate}\) . What else would we mean by equivalence of the programs? We do not want to say they have literally identical values, because we want equivalence to be local: It should not involve what else may have been allocated, so we do not assume agreement on \(\mathsf {alloc}\) . Hence, the resulting lists may not have identical reference values. What matters is that the heap data produced by the two implementations has the same structure.

On the modality \(\Diamond\) . The modal operator \(\Diamond\) is needed for the relational postcondition (11) and in any spec where allocation is possible. We gloss over it in some examples, but specs of interest usually have this standard form: \(\mathcal {R}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {S}\:[\varepsilon ]\) where \(\Diamond\) does not occur in \(\mathcal {R}\) or \(\mathcal {S}\) . The \(\texttt {tabulate}\) spec can be put in standard form, because Equation (10) expresses unary conditions, with no dependence on refperm, so that formula can be put inside the \(\Diamond\) in Equation (11).

While SMT solvers typically provide some heuristic support for quantifiers, existential quantifiers are problematic, and we cannot expect a solver to find witnesses for the existential expressed by \(\Diamond\) . In the WhyRel prototype, specs do not include \(\Diamond\) explicitly. Instead, a refperm is maintained in ghost state, thus witnessing the existential. A ghost instruction, \({\color{blue} {\texttt{connect}}} \ - \ {\color{blue} {\texttt{with}}} \ -\) , can be used to designate which references the user wants to be considered as corresponding. For example, the biprogram Figure 16(c) uses \({\color{blue} {\texttt{connect}}} \ \texttt {p}\) , which abbreviates \({\color{blue} {\texttt{connect}}} \ \texttt {p} \ {\color{blue} {\texttt{with}}} \ \texttt{p}\) , to add newly allocated \(\texttt {Node}\) references to the refperm, thereby establishing \(p\mathrel {\ddot{=}}p\) . The general form of \({\color{blue} {\texttt{connect}}}\) caters for programs using different variables.

Alignment for \(\texttt {tabulate}\) . Recall that Equations (10) and (11) are meant to comprise the postcondition of a spec to relate the bodies, tabu and \(tabu^{\prime }\) , of the two implementations of \(\texttt {tabulate}\) in Figure 16(a) and (b). To say that they satisfy the relational spec, we use a judgment like this:The hypothesis context specifies \(\texttt {mf}\) ; \(\Phi\) is a triple, with \(\Phi _2(\texttt {mf})\) being the relational spec \(\mathbb {A}x\mathrel {{\approx\!\!\!\! \gt }}\mathbb {A}result\) . The unary specs \(\Phi _0(\texttt {mf})\) and \(\Phi _1(\texttt {mf})\) are not relevant to this example.

We derive the judgment for \((tabu|tabu^{\prime })\) from a judgment with the same spec for the more conveniently aligned biprogram \(CC_{tabu}\) in Figure 16(c), in a way that will be justified in Section 4.5. Several features of \(CC_{tabu}\) are important. First, its left and right syntactic projections are the two commands, tabu and \(tabu^{\prime }\) , to be related; semantically it represents pairs of their executions, aligned in a particular way. Second, the calls to \(\texttt {mf}\) are in the sync’d form, which signals that reasoning is to be done using the relational spec of \(\texttt {mf}\) . A comment in the biprogram indicates that we get agreement on \(p.val\) following the calls to \(\texttt {mf}(i)\) , in virtue of that spec. Similarly, the two allocations are also in the sync’d form and followed by the \({\color{blue} {\texttt{connect}}}\) ghost operation, achieving agreement on the allocated references. In the proof system, there is a rule for sync’d allocations, with postcondition that yields for example \(\Diamond \mathbb {A}p\) for the \(\texttt {Node}\) allocation. Using this rule (or the connect ghost operation) is a good choice in the present example, but in general it is not necessary to connect allocations, even if they happen to be aligned; this is important when relating programs that are not building the same heap structure, or when proving noninterference and reasoning about branches with tests that depend on secrets. Finally, the bi-while in \(CC_{tabu}\) signals that we reason in terms of lockstep alignment of the loop iterations. This enables us to reason that the two executions are building isomorphic pointer structures, using a relational invariant similar to the postcondition of the relational spec (11), conjoined with a simple relation between the counter variables:The biprogram provides a convenient alignment but incurs an additional proof obligation: the invariant must imply that the loop tests agree, as otherwise it would be unsound to assume the iterations can be considered to be aligned in lockstep. Indeed, the implication is valid: \(\mathbb {A}n\) and \(i-1 \mathrel {\ddot{=}}i\) implies \(i\lt n \mathrel {\ddot{=}}i \le n\) .

In summary, this example shows biprograms express alignment of the programs under consideration to facilitate procedure-modular reasoning using relational specs and to facilitate the use of simpler relational invariants for loops. In passing, we introduced ways to express relations on pointer structures, abstracting from specific addresses (as appropriate for Java- and ML-like languages) and making it possible to specify relations where some parts of the heap are meant to have isomorphic structure while other parts may be entirely different. There are at least two important use cases for such differences: encapsulated data structures, when relating implementations of a module interface, and structure manipulated by “secret” computations, when proving information flow properties.

The example happens to work well with close alignment of the program structure and agreement on all the data involved. The logic must handle aligned allocation in a loop, as in this example. It must also handle differing allocations, for example to relate programs using different encapsulated data representations. Differing allocations also arise when proving noninterference, in cases where allocation occurs under high branch conditions.

The proof rules used to derive a relational modular linking rule like Equation (3) make use of a general form of local equivalence specification, derived from the frame condition of a unary spec (and defined in Section 8.1). But it is also possible to express local equivalence notions suited to specific situations, as in the example, and it is possible to work with differing program structures as illustrated in some case studies (e.g., Figure 19 and Section 4.6).

In this subsection, we define the weaving relation on biprograms. The purpose of the weaving relation is to connect a bi-com \((C|C^{\prime })\) , that expresses a relational verification problem, with a more tightly aligned version that facilitates reasoning. If \((C|C^{\prime })\) weaves to DD, written \((C|C^{\prime })\looparrowright DD\) , then the syntactic projections of DD are C and \(C^{\prime }\) , so DD models executions of the two commands. The weaving relation \(\looparrowright\) is used in a proof rule that realizes the product principle: any judgment that holds for DD also holds for \((C|C^{\prime })\) , given \((C|C^{\prime })\looparrowright DD\) . In general, weaving brings together similarly structured subprograms, introducing additional alignment points while preserving syntactic projections. In addition to defining the relation \(\looparrowright\) , the rest of this section gives examples of its use, and sketches the semantic considerations that justify the proof rule and explain the orientation of the relation.

The weaving relation is defined inductively by axioms and congruence rules in Figure 18. The axioms replace a bi-com by another biprogram form including those that can assert agreements (bi-if and bi-while). The congruence rules, displayed as one rule with multiple conclusions, allow weaving in all contexts except the procedure bodies in bi-let. Apropos congruence for bi-let, note that bi-let does not bind general biprograms but only pairs of commands despite the appearance of the concrete syntax (see Figure 5).

The weaving that introduces bi-while allows the introduction of so-called alignment guards. The biprogram \(CC_{tabu}\) omits them (Figure 16(c)), which is syntax sugar taking them to be \(\mathsf {false}\) . As an example of their use, later in this subsection, we follow up on the example program (4) discussed in Section 2.1, sketching the three-premise relational loop rule that enables verification of the example using a simple invariant.

Using the sequence axiom and congruence, we have \((a;b;c|d;e;f) \looparrowright (a|d);(b;c|e;f) \looparrowright (a|d);(b|e);(c|f)\) , which illustrates how fine-grained alignment can be achieved when desired. We also have \((tabu|tabu^{\prime })\looparrowright ^* CC_{tabu}\) , which connects \(tabu,tabu^{\prime }\) to the particular alignment we choose for reasoning about them.

As noted earlier, the bi-if and bi-while forms are meant to designate reasoning in which it will be shown that the test conditions are in agreement. Technically, we define small step semantics for biprograms, in which these forms can have a fault—dubbed alignment fault—if the tests are not in agreement. This can be seen as a kind of assertion failure. As an example, recall the implementation of \(\texttt {insert}\) in the \(\texttt {PQ}\) module in Figure 4. Part of the alternate implementation using sentinels (mentioned in Example 3.4) is shown in Figure 19. We weave the two conditionals using a bi-if, which introduces the possibility of alignment fault. We can use this weaving, because our coupling relation will ensure that \(\mathit {self}.head = \mathsf {null}\) in the left state just when \(\mathit {self}.head = \mathit {self}.sntnl\) on the right.

Use of bi-if or bi-while incurs additional proof obligations that ensure the absence of alignment fault, which in turn implies that the designated alignment covers all pairs of executions of the underlying programs. The weaving transformations can introduce the bi-if and bi-while forms but not eliminate them; nor can they eliminate any other faults. For example, \((\mathsf {if}\ {x\gt 0}\ \mathsf {then}\ {y.f:=x}\ \mathsf {else}\ {\mathsf {skip}} \mid \mathsf {if}\ {x\gt 0}\ \mathsf {then}\ {y.f:=x}\ \mathsf {else}\ {\mathsf {skip}})\) weaves to \(\mathsf {if}\ {x\gt 0|x\gt 0}\ \mathsf {then}\ {(y.f:=x\mid y.f:=x)}\ \mathsf {else}\ {\lfloor \mathsf {skip} \rfloor }\) , noting that \((\mathsf {skip}|\mathsf {skip}) \equiv \lfloor \mathsf {skip} \rfloor\) . Both biprograms can fault due to null dereference, but the second also faults in a pair of states where \(x\gt 0\) on one side but \(x\le 0\) on the other.

Suppose DD can be obtained from CC by a sequence of weavings, i.e., \(CC\looparrowright ^* DD\) . The relation \(\looparrowright\) can introduce the possibility of additional alignment faults, but it cannot eliminate such possibility. In this sense, \(\looparrowright\) is oriented (and not symmetric). A consequence is the following: if, under some precondition, DD has no faults, then under that precondition the executions of DD cover all those of CC. This is the gist of the argument for soundness of the following proof rule:(See rule rWeave in Figure 30.) It is this rule that yields a relational judgment for \((tabu|tabu^{\prime })\) from the same judgment for \(CC_{tabu}\) (Figure 16).

In general, a biprogram may admit several possible weavings. For the form \((C|C)\) relating C to itself there is a biprogram that is maximal in the sense that it allows us to reason about two executions aligned in lockstep. We write \(\lfloor\!\!\lfloor C \rfloor\!\!\rfloor\) for the full alignment defined in Figure 20. Apropos linking, we have \((\mathsf {let}~m \mathbin {=}B~\mathsf {in}~C \mid \mathsf {let}~m \mathbin {=}B^{\prime }~\mathsf {in}~C) \looparrowright ^* \mathsf {let}~m \mathbin {=}(B|B^{\prime })~\mathsf {in}~ \lfloor\!\!\lfloor C \rfloor\!\!\rfloor\) . Full alignment plays a key role in deriving the relational modular linking rule that was sketched as Equation (3) and is formalized in Figure 31.

As a corollary, we have \((C|C)\looparrowright ^* \lfloor\!\!\lfloor C \rfloor\!\!\rfloor\) for any C, because \(\mathop {{\lfloor\!\!\lfloor C \rfloor\!\!\rfloor }}\limits^{\leftharpoonup} \equiv \mathop {{\lfloor\!\!\lfloor C \rfloor\!\!\rfloor }} \limits^{\rightharpoonup}\equiv C\) .

Sumpub: illustrating conditionally aligned loops. For the \(\texttt {tabulate}\) example it is effective to reason by aligning all iterations of the two loops in lockstep. This is not the case for program (4) in Section 2.1, recalled here:

It sums the elements of a list that are flagged public. It has an information flow property: the output, in variable s, depends only on the public elements of the input list. (This can be viewed as a declassification or as a value-dependent classification [4].) Typically such properties are expressed using a precondition of agreement on some expression, which in this case should denote “the public elements of the input list.”

As a pointer structure, the list can have cycles, so care needs to be taken in defining predicates and functions. In the \(\texttt {tabulate}\) example, we choose specs that do not involve inductively defined predicates or relations. Here, we inductively define a predicate \(listpub(p,ls)\) that says ls is the list of values of the public elements in a null-terminated list from p:We consider the following relational spec, eliding the frame condition for clarity. The bound variables, \(ls,ls^{\prime }\) are of the math type \(\texttt {int list}\) :The syntax of quantifiers in relation formulas explicitly designates left- and right-side variables, which is important in case of reference or region type (since the values must be allocated in the respective states). There is no need to use distinct names here, so we can use a more succinct precondition for the spec: \(\exists ls|ls .\: \mathbb {B} (listpub(head,ls)) \wedge \mathbb {A}ls\) .

We want to prove that \((sumpub|sumpub)\) satisfies the relational spec. One way is to first prove unary judgment \(sumpub: listpub(p,ls)\leadsto s=sum(ls)\) , again treating ls as spec-only, and thus universally quantified over the spec. A simple embedding rule (rEmb in Figure 30) lifts this to \((sumpub|sumpub): \mathbb {B} (listpub(p,ls))\mathrel {{\approx\!\!\!\! \gt }}\mathbb {B} (s=sum(ls))\) . The relational frame rule lets us conjoin agreement on ls, to getThe postcondition implies \(\mathbb {A}s\) , so we complete the proof using the relational consequence rule.

Lifting unary judgments is an important pattern of reasoning and is satisfactory for reasoning about assignment commands including those in the \(\texttt {tabulate}\) example. But sumpub has a loop, so this argument comes at the cost of proving functional correctness, i.e., the judgment \(sumpub: listpub(p,ls)\leadsto s=sum(ls)\) . Finding a loop invariant is not difficult in this case, but it would be if sum is replaced by a sufficiently complex computation.

There is an alternative proof of the relational spec that avoids functional correctness, using for the loops a simple relational invariant:We verified the example using WhyRel, and instead of asking the solvers to handle the existential, we used the standard technique: xs on each side is a ghost variable, initialized based on the precondition and explicitly updated as appropriate.

The point of this example is that this simple invariant only suffices if we align the iterations judiciously. In case \(p.pub\) holds on both left and right, we take a lockstep iteration, i.e., both sides execute the loop body, and it is straightforward to show the invariant holds afterwards using the last clause in the definition of listpub and the fact that \(\mathbb {A}xs\) , i.e., equality of the mathematical lists, implies agreement on their tails. If pub is true on one side but not the other, then lockstep iteration does not preserve Equation (14). However, if \(p.pub\) is false on the left, then \(listpub(p,xs)\) implies \(listpub(p.nxt,xs)\) , and executing the body just on the left maintains the relation Equation (14). Notice Equation (14) does not include agreement on p; indeed the precondition requires no agreement on references. Mutatis mutandis on the right side. To express this reasoning, we weave \((sumpub|sumpub)\) to this biprogram:

Although the program is being related to itself, we do not bother to fully align the initialization or loop body: these do not involve allocation or method calls, so reasoning about those parts of the code is straightforward. For this reason, some uses of sync in Figure 16(c) could as well be bi-coms. What is important is to use a bi-while. For loop alignment guards, we choose the relation formulas \({\langle \! [} \lnot p.pub {\langle \! ]}\) and \({[\! \rangle } \lnot p.pub {]\! \rangle }\) . The alignment guards are used in the proof rule for bi-while, which has the following form:

This rule has omissions! For clarity, we omit details not relevant to the current discussion: frame conditions, hypothesis context, and side conditions that enforce encapsulation and immunity. The encapsulation condition is discussed later and is lifted from the unary logic, as is immunity, a technical condition needed for stateful frame conditions (adapted unchanged from RLI).

In the rule, \(\mathcal {Q}\) is the relational loop invariant, like Equation (14) in the example. The three premises cover a lockstep iteration, a left-side iteration, and a right-side iteration. The one-sided iterations are expressed using the syntactic projection metafunctions (Figure 13) to obtain unary commands. In the example the two projections of the loop body are the same, namely, \(\texttt {if p.pub then s := s+p.val; fi; p := p.nxt}\) . In each premise the invariant must be preserved, but each has a strengthened precondition based on the alignment guards. For the example, the first premise applies when both sides are at a public element. The second (respectively, third) premise applies when the element on the left (respectively, right) is not public. Besides alignment guards, the premises include the loop tests in the usual way, as does the conclusion of the rule.

The side condition, \(\mathcal {Q}\Rightarrow E\mathrel {\ddot{=}}E^{\prime } \vee (\mathcal {P}\wedge {\langle \! [} E {\langle \! ]}) \vee (\mathcal {P}^{\prime }\wedge {[\! \rangle } E^{\prime } {]\! \rangle })\) , ensures that for any initial states satisfying \(\mathcal {Q}\) , at least one of the three premises is applicable. The reader can confirm that the side condition holds in the example, and thus the rule can be used to carry out the proof as described.

As another example, for \(\texttt {tabulate}\) in Figure 16(c), we use false alignment guards, so the one-sided premises hold trivially and the side condition simplifies to the implication mentioned earlier: the invariant implies agreement on loop tests. That is, \(i-1 \mathrel {\ddot{=}}i \wedge \mathbb {A}n \Rightarrow i\lt n \mathrel {\ddot{=}}i \le n\) .

The biprogram syntax allows \(\mathcal {P}\) and \(\mathcal {P}^{\prime }\) to be relation formulas, but it happens that in the example \({\langle \! [} \lnot p.pub {\langle \! ]}\) only constrains the left state and the other alignment guard constrains the right state. As stated in Section 3.1, \(\mathcal {P}\) and \(\mathcal {P}^{\prime }\) are not allowed to have agreement formulas; it is not evident what refperm would be used to interpret agreements in such a context.

Having illustrated general relational reasoning (Sections 4.4 and 4.5) and the use of dynamic framing for encapsulation in unary reasoning (Section 3.5), we now illustrate encapsulation in relational reasoning. In doing so, we sketch how requirements (E1)–(E4) adapt to the relational setting.

In Section 3.5, we considered the verification of a client linked with a quick-find implementation of \(\texttt {UnionFind}\) , hiding the private invariant. Here, we consider two implementations of that interface and consider a more interesting client: an implementation, MST, of Kruskal’s minimum spanning tree algorithm. For a second implementation of \(\texttt {UnionFind}\) , we consider the quick-union data structure [88].

The goal is to prove a relational property: equivalence of the two programs made by linking MST with the two module implementations. To do so, we use relational modular linking, as sketched in the rule (3), hiding a coupling relation between the two implementations, which includes their private invariants. To use the rule, we do the following:

It then follows that the two linkages satisfy a local equivalence property, specifically a relational spec that is derived by a general construction from the unary spec of MST. Similar to the relational spec of \(\texttt {tabulate}\) in Section 4.4, it requires agreement on inputs and ensures agreement on outputs. But encapsulation must be taken into account: the two linkages will be equivalent in terms of client-visible inputs and outputs, but the encapsulated data structures are different. More on this later.

For item (i), we choose MST for the sake of a nontrivial example, but we do not use a functional correctness spec, i.e., we do not specify that it produces a minimum spanning tree. All we need is a precondition under which MST does not fault, and a frame condition. The global variables of MST are g of type \(\texttt {Graph}\) and es of type \(\texttt {List}\) . For simplicity, g is an abstract mathematical graph; es references a list like that used in Section 4.4. The graph interface provides an enumeration of edges and MST produces, in es, a list of edge numbers for edges in the spanning tree:Note that the effects here include effects produced by call to \(\texttt {UnionFind}\) methods. We verify the judgment \(\Phi _{uf} \vdash _{ \bullet }MST: spec\) where spec is Equation (17) and \(\Phi _{uf}\) has the public specs of \(\texttt {find}\) and \(\texttt {union}\) , i.e., without the private invariants. The current module is \({ \bullet }\) , the default module with empty boundary.

The local equivalence spec for the two linked programs is derived, by a general construction called \({ {locEq}}\) , based on the frame condition of a unary spec, and the dynamic boundaries of the modules in scope. In the example there is just one module with a nontrivial boundary, \(\texttt {UnionFind}\) ; math modules like \(\texttt {Graph}\) have empty boundaries. Agreements in the precondition are derived directly from the read effects and boundary, using the effect subtraction operator that excludes from agreement the encapsulated locations. In this example, the relational precondition isThe conjunct \(\mathbb {B} (s_{\mathsf {alloc}}=\mathsf {alloc})\) introduces snapshot variable \(s_{\mathsf {alloc}}\) to be used in the postcondition to express freshness. The agreement \(\mathbb {A}es\) is in simplified form. The general construction takes the read effect, \(\mathsf {rd}\,es, \mathsf {alloc}, pool, (pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep){{\bf `}}\mathsf {any}\) and subtracts the boundary \(\mathsf {rd}\,pool, (pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep){{\bf `}}\mathsf {any}\) and \(\mathsf {alloc}\) , which results in the effect \(\mathsf {rd}\,es, ((pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep)\backslash (pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep)){{\bf `}}\mathsf {any}\) , which trivially simplifies to \(\mathsf {rd}\,es, \varnothing {{\bf `}}\mathsf {any}\) and then to \(\mathsf {rd}\,es\) .

What about agreements for a postcondition? In general, a command may write preexisting locations and allocate new ones. In this case the only preexisting locations that are writable are the variables es and \(\mathsf {alloc}\) , so the postcondition includes \(\mathbb {A}es\) . (In general, to handle writable heap locations the general definition of \({ {locEq}}\) uses snapshots of the relevant expressions in write effects; for details see Section 8.1.) To handle fresh locations, \({ {locEq}}\) uses the snapshot \(s_{\mathsf {alloc}}\) in the way described in Section 3.5: the fresh references are \(\mathsf {alloc}\backslash s_{\mathsf {alloc}}\) so the fresh locations are \((\mathsf {alloc}\backslash s_{\mathsf {alloc}}){{\bf `}}\mathsf {any}\) . Again, effect subtraction is used to exclude \(\mathsf {alloc}\) and the boundary. The resulting agreement is \(\mathbb {A}((\mathsf {alloc}\backslash s_{\mathsf {alloc}}) \backslash (pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep)){{\bf `}}\mathsf {any}\) .

In summary, the local equivalence spec that we get from Equation (17) for MST isIf one simply wants to know that the new and old versions of the program are the same, aside from encapsulated state, then this is enough. By construction, the \({ {locEq}}\) spec requires agreement on what the program can read and ensures agreement on its results.

In this particular case, to obtain a more explicit postcondition that refers to the list constructed, we can do as follows. First, strengthen the unary postcondition from \(\mathsf {true}\) to something like \(es.head\in es.nds \wedge es.nds{{\bf `}}next\subseteq es.nds \wedge (\lbrace es\rbrace \mathbin {\mbox{$\cup $}}es.nds)\subseteq (\mathsf {alloc}\backslash s_{\mathsf {alloc}})\) , which expresses the closure of nds and the freshness of the list (see Section 4.4). The relational spec Equation (18) then changes to have these conditions in place of \(\mathsf {true}\) . Then using the rule of consequence and reasoning about sets, we get \(\mathbb {A}es.nds{{\bf `}}next\) and \(\mathbb {A}es.nds{{\bf `}}val\) much like in the \(\texttt {tabulate}\) example.

For item (ii), as expected since Hoare’72, the coupling relation \(\mathcal {M}_{uf}\) conjoins a relational formula that connects the two implementations, together with the two private invariants. In particular, \(\mathcal {M}_{uf}\) is \({\langle \! [} I_{qf} {\langle \! ]} \wedge {[\! \rangle } I_{qu} {]\! \rangle } \wedge \ldots\) , where \(I_{qf}\) is the invariant discussed in Section 3.5, and \(I_{qu}\) is the private invariant of the quick-union implementation. The two implementations have similar internal data structure, in the sense that both use an array to represent an up-pointing tree, but quick-find and quick-union manipulate the tree quite differently. To specify the connection between the two data structures, the third conjunct of \(\mathcal {M}_{uf}\) is this formula:This says the two pools are in agreement, and for corresponding elements u in the pool, the abstract partition \(u.part\) on the left side is an equivalent partition to the one on the right. This means they have the same blocks. This coupling uses a common idiom. The coupling relation is defined using a mathematical abstraction: the two data structures are related if they have the same abstraction. This idiom is especially suitable if the two data structures are very different. By contrast, in our two implementations of \(\texttt {PQ}\) , we consider two similar pointer structures, and for their coupling, we use agreement formulas to describe fine-grained correspondence between the two pointer structures; see Example 4.3.

To show that \(\mathcal {M}_{uf}\) is framed by the boundary, the technique is essentially the same as for unary framing of an invariant (Section 3.5). The difference is that here we consider a pair of states that satisfy \(\mathcal {M}_{uf}\) , and a second pair where the two left (respectively, right) states agree on locations within the boundary, to show the second pair satisfies \(\mathcal {M}_{uf}\) . Given a suitable representation of states, as in our prototype, the implication is easily checked by SMT solvers.

The last part of item (ii) is that \(\mathcal {M}_{uf}\) is implied by the precondition of the client spec, in this case (17). To be precise, it is an implication at the level of relations: \(\mathbb {B} (numVertices(g) \gt 0 \wedge pool = \varnothing) \Rightarrow \mathcal {M}_{uf}\) . It holds owing to \(pool=\varnothing\) .

For item (iii), for each method, we verify the local equivalence spec derived from the method’s unary spec, with \(\mathcal {M}_{uf}\) conjoined to pre- and postcondition. For example, the frame condition of \(\texttt {union}\) is \([\mathsf {rw}\,(\lbrace \mathit {self}\rbrace \mathbin {\mbox{$\cup $}}\mathit {self}.rep){{\bf `}}\mathsf {any}]\) , and its parameters are \(\mathit {self},x,y\) . Based on this, \({ {locEq}}\) uses a precondition based on the agreement \(\mathbb {A}\mathit {self}\wedge \mathbb {A}x \wedge \mathbb {A}y \wedge \mathbb {A}(\lbrace \mathit {self}\rbrace \mathbin {\mbox{$\cup $}}\mathit {self}.rep){{\bf `}}\mathsf {any}\) . A snapshot variable s is used in precondition \(\mathbb {B} s = \lbrace \mathit {self}\rbrace \mathbin {\mbox{$\cup $}}\mathit {self}.rep\) so the postcondition can express agreement on writables by \(\mathbb {A}s{{\bf `}}\mathsf {any}\) , in addition to agreement on fresh locations as described for MST. Recall that \({ {locEq}}\) then subtracts locations within the boundary; it is not agreement that we want for those locations, but rather the connection expressed by \(\mathcal {M}_{uf}\) .

The implementations of \(\texttt {union}\) and \(\texttt {find}\) are fairly different. For quick-find, the union operation eagerly updates “parents” so find takes constant time. For quick-union, find has to traverse multiple parents to reach the representative element. To prove the relational judgments for the method bodies, we use biprograms that are not tightly woven. The corresponding implementations are not very similar and are not making external calls or doing allocation, so there is little motivation for close alignment the way there is for the \(\texttt {tabulate}\) example.

More details about the MST verification can be found in Section 9. For now, we review why relational modular linking—shown in Equation (3) and formalized in rule rMLink in Figure 31—is sound. In other words, why do (i)–(iii) suffice to prove equivalence of the linkages? Intuitively, the coupling is preserved by client steps owing to encapsulation, just like private invariants in the unary case. This is formalized by a relational version of the SOF rule, called rSOF. For that rule to be sound, the client needs to be aligned so that context calls can be sync’d (like the call to mf in the \(\texttt {tabulate}\) example) so a relational spec can be used—namely, a local equivalence spec conjoined with the coupling relation. So rule rSOF applies to the full alignment of some command, and its premise is that this fully aligned biprogram satisfies a local equivalence spec. This we obtain from the unary judgment of (i), by a rule that lifts a unary judgment to a relational one for the local equivalence derived from the unary spec (rule rLocEq in Figure 30). It relates the command to itself, expressing the dependency property of its read effect as a relational judgment.

Notations to conjoin couplings. To conclude this section, we define a metafunction that conjoins a relation to a relational spec; this is used to formulate rSOF and the modular linking rule. It is based on a similar metafunction, , which applies to a unary spec and a unary invariant I:This lifts to an operation on unary contexts, written \(\Phi {\bigcirc\!\!\!\!\!\!\!\!{\wedge}} I\) , by mapping \({\bigcirc\!\!\!\!\!\!\!\!{\wedge}} I\) over the specs in \(\Phi\) .

For relation formula \(\mathcal {M}\) , the operation \({\bigcirc\!\!\!\!\!\!\!\!{\wedge}} \mathcal {M}\) conjoins \(\mathcal {M}\) to a relational spec. The operation only applies to relational specs in the standard form, meaning that \(\Diamond\) occurs only outermost on the postcondition, or not at all.

Note that \(\Phi {\bigcirc\!\!\!\!\!\!\!\!{\wedge}} \mathcal {M}\) is only defined if the specs in \(\Phi _2\) are in standard form, and then so is the result.

Assume given an infinite set \({ {Ref}}\) of references, disjoint from the integers, with distinguished element \({ {null}}\) . A \(\Gamma\) -state comprises a finite heap and a type-respecting assignment of values to the variables in \(\Gamma\) . We confine attention to contexts \(\Gamma\) that include the special variable \(\mathsf {alloc}\) . We write \(\sigma (x)\) to look up the value of x in state \(\sigma\) . In particular, \(\sigma (\mathsf {alloc})\) is the finite set of allocated references. Any reference \(o\in \sigma (\mathsf {alloc})\) has a class K, which we write as \({ {Type}}(o,\sigma)\) .

A location is either a variable x or a heap location \(o.f\) , where we write \(o.f\) for the pair \((o,f)\) of a non-null reference o and field name f. For any state \(\sigma\) , define the set of its locations byThe heap provides a type-respecting assignment of values to heap locations. We write \(\sigma (o.f)\) for the value of field f of allocated reference o. Type-respecting means that if \({ {Type}}(o,\sigma)\) is K and \(f:T\) is in \({ {Fields}}(K)\) then \(\sigma (o.f)\) is in \({[\![} \, T \,{]\!]} \sigma\) . We write \({[\![} \, T \,{]\!]} \sigma\) for the values of type T in state \(\sigma\) . In the case of a reference type K, define \({[\![} \, K \,{]\!]} \sigma\) byDefine \({[\![} \, \mathsf {rgn} \,{]\!]} \sigma\) to be \(\mathbb {P}(\sigma (\mathsf {alloc}) \mathbin {\mbox{$\cup $}}\lbrace { {null}}\rbrace)\) . We write \({[\![} \, \Gamma \,{]\!]}\) for the set of \(\Gamma\) -states.

The transition semantics of a command typed in \(\Gamma\) may introduce additional variables for local blocks, so it is convenient to define \({ {Vars}}(\sigma)\) to be the variables of the state. We write \([\sigma \mathord {+} x\mathord {:}\, v]\) to extend the state with additional variable x with value v, and \([\sigma \, |\, x\mathord {:}\, v]\) to override the value of x that is already in \({ {Vars}}(\sigma)\) . We write \(\sigma \mathbin {\!\upharpoonright \!}x\) to remove x from the domain of \(\sigma\) .

We write \(\sigma (F)\) for the value of expression F. The semantics of program expressions E and region expressions G is in Figure 21. (To be very precise, the semantics of expressions is defined on a typing \(\Gamma \vdash F:T\) , such that \(\sigma (F)\) is in \({[\![} \, T \,{]\!]} \sigma\) .) The syntax is designed to avoid undefinedness. We are not formalizing arithmetic operators that can fail, there are no dangling pointers, and program expressions E do not depend on the heap. Region expressions can depend on the heap, in the case of images \(G{{\bf `}}f\) , and they are defined in any state. If \(f\mathord {:}K\) for some K, then \(\sigma (G{{\bf `}}f)\) is the set of values of the f fields of objects in \(\sigma (G)\) . If \(f\mathord {:}\mathsf {int}\) , then \(\sigma (G{{\bf `}}f)\) is empty. Finally, for \(f\mathord {:}\mathsf {rgn}\) , \(\sigma (G{{\bf `}}f)\) is the union of the regions \(\sigma (o.f)\) for o in \(\sigma (G)\) .

Transitions relate configurations of the form \(\langle C,\: \sigma ,\: \mu \rangle\) . The environment \(\mu\) maps method names to commands. The empty environment is written \(\_\) . In a configuration, the command C may include the pseudo-commands: \(\mathsf {ecall}(m)\) ends the code of a call to method m, \(\mathsf {evar}(x)\) ends the scope of a local variable, and \(\mathsf {elet}(\overline{m})\) ends the scope of some methods \(\overline{m}\) (arising from simultaneous binding \(\mathsf {let}~\overline{m} \mathbin {=}\overline{B}~\mathsf {in}~C\) ). The pseudo-commands do not occur in source programs. The code of a configuration thus takes a form that represents the execution stack for environment calls:So the leftmost command \(C_n\) is on top of the stack and \(m_n\) is the leftmost environment call. We write \({ {Active}}(C)\) for the active command (which one might call the redex), i.e., the unique sub-command that gets rewritten by the applicable transition rule.²⁷ For example, \({ {Active}}(x:=0;y:=1)\) is \(x:=0\) .

To formalize the semantics of encapsulation, we need to refer to the module of the active command: it must stay outside the boundary of every module except its own. So, we define the top module \({ {topm}}(C,M)\) to be N where \(N={ {mdl}}(m_n)\) and \(m_n\) is the leftmost environment call (see above), or M if C has no \(\mathsf {ecall}\) (i.e., \(n=0\) ). This is used in Definition 5.10, where the argument M is from the judgment under consideration. In Definition 5.10, we also write \(N\in (\Phi ,\mu)\) , for hypothesis context \(\Phi\) and method environment \(\mu\) , to mean there is \(m\in { {dom}}\,(\Phi)\mathbin {\mbox{$\cup $}}{ {dom}}\,(\mu)\) with \({ {mdl}}(m)=N\) .

For an empty method context, the transition relation is standard (Figure 34). For non-empty contexts the transition relation depends on a pre-model, which is defined in terms of the semantics of specs, to which we proceed.

Satisfaction of formula P in state \(\sigma\) is written \(\sigma \models P\) . The semantics of formulas is standard and two-valued. The points-to relation \(x.f=E\) is defined by \(\sigma \models x.f=E \mbox{ iff } \sigma (x)\ne { {null}}\mbox{ and } \sigma (\sigma (x).f)=\sigma (E)\) . The type predicate is defined by \(\sigma \models \mathsf {type}(G,\overline{K})\) iff \({ {Type}}(o,\sigma)\in \overline{K}\) for all \(o \in \sigma (G)\) . Quantifiers for reference types range over allocated (thus non-null) references: \(\sigma \models \forall x:K .\:P\) iff \([\sigma \mathord {+} x\mathord {:}\, o]\models P\) for all \(o\in \sigma (\mathsf {alloc})\) with \({ {Type}}(o,\sigma)=K\) .

In contexts where we consider a precondition P and suitable state \(\sigma\) , we adopt the hat convention of writing \(\hat{\sigma }\) for the extension of \(\sigma\) uniquely determined by \(\sigma\) and P as in Lemma 5.1.

For an effect \(\varepsilon\) in a given state \(\sigma\) , its read effects designate a set \({ {rlocs}}(\sigma ,\varepsilon)\) of locations. Specifically, it is the set of l-values of the left-expressions in its read effects:Define the same way but for the l-values in write effects. Note that for an effect of the form \(\mathsf {rd}\,G{{\bf `}}f\) the definition of \({ {rlocs}}\) uses the r-value \(\sigma (G)\) (Figure 21) where G may itself involve images. These functions are used in the key lemma about effect subtraction (see Equation (7)).

For use in the semantics of write effects, define the locations of \(\sigma\) that have been changed in \(\tau\) asThis captures the variables still in scope that have been changed, together with changed heap locations.²⁸ Say \(\tau\) can succeed \(\sigma\) , written , provided \(\sigma (\mathsf {alloc})\subseteq \tau (\mathsf {alloc})\) and \({ {Type}}(o, \sigma) = { {Type}}(o, \tau)\) for all \(o\in \sigma (\mathsf {alloc})\) . Say \(\varepsilon\) allows change from \(\sigma\) to \(\tau\) , in symbols , iff \(\sigma \hookrightarrow \tau\) and \({ {wrttn}}(\sigma ,\tau)\subseteq { {wlocs}}(\sigma ,\varepsilon)\) . The locations of \(\tau\) not present in \(\sigma\) are designated by \({ {freshL}}(\sigma ,\tau)\) . Define \({ {freshRefs}}(\sigma ,\tau) \mathrel {\,\hat{=}\,}\tau (\mathsf {alloc})\backslash \sigma (\mathsf {alloc})\) and

Read effects and refperms. Read effects constrain the locations on which the outcome of a computation can depend. Dependency is expressed by considering two initial states that agree on the values in the locations deemed readable, though the states may differ on the values in other locations. Agreement between a pair of states needs to take into account variation in allocation, as the relevant pointer structure in the two states may be isomorphic but involve differently chosen references. Such variation must also be taken into account in relation formulas, as in Example 4.3. For use with both read effects and relation formulas, agreements are formalized using refperms, as mentioned in Section 2.3.

Let \(\pi\) range over partial bijections on \({ {Ref}}\backslash \lbrace { {null}}\rbrace\) , i.e., injective partial functions. Write \(\pi (p)=p^{\prime }\) to express that \(\pi\) is defined on p and has value \(p^{\prime }\) . A refperm from \(\sigma\) to \(\sigma ^{\prime }\) is a partial bijection \(\pi\) such that \(dom(\pi)\subseteq \sigma (\mathsf {alloc})\) , \({ {rng}}\,(\pi)\subseteq \sigma ^{\prime }(\mathsf {alloc})\) , and \(\pi (p)=p^{\prime }\) implies \({ {Type}}(p,\sigma)={ {Type}}(p^{\prime },\sigma ^{\prime })\) . Define \(p\stackrel{\pi }{\sim }p^{\prime }\) to mean \(\pi (p)=p^{\prime }\) or \(p={ {null}}=p^{\prime }\) . Extend \(\stackrel{\pi }{\sim }\) to a relation on integers by \(i\stackrel{\pi }{\sim }j\) iff \(i=j\) . For reference sets \(X,Y\) , define \(X\stackrel{\pi }{\sim }Y\) to mean that \(\pi \mathbin {\mbox{$\cup $}}\lbrace ({ {null}},{ {null}})\rbrace\) restricts to a total bijection between X and Y. The image of \(\pi\) on location set W is written \(\pi (W)\) and defined for variables and heap locations by two conditions: \(x\in \pi (W)\) iff \(x \in W\) , and \(o.f\in \pi (W)\) iff \((\pi ^{-1}(o)).f \in W\) . In other words: variables map to themselves, and a heap location \(p.f\) is transformed by applying \(\pi\) to the reference p.

Next, we define notations for agreement between states. Agreement is formalized in terms of a condition that applies to two states together with a refperm and a subset W of the locations of \(\sigma\) . The location agreement \({ {Lagree}}(\sigma ,\sigma ^{\prime },\pi ,W)\) holds just if W is a set of locations of \(\sigma\) and for each of these locations, the contents in \(\sigma\) is the same as the contents of the location that corresponds according to \(\pi\) . Of course, “same as” is modulo \(\pi\) , for reference values.

This is defined for any \(W\subseteq { {locations}}(\sigma)\) . Agreement is monotonic in the refperm, in the sense that

Often we use \({ {Agree}}(\sigma ,\tau ,\varepsilon)\) where \(\sigma \hookrightarrow \tau\) , in which case \(\sigma (\mathsf {alloc})\mathbin {\mbox{$\cap $}}\tau (\mathsf {alloc})=\sigma (\mathsf {alloc})\) .

Agreement on location sets enjoys a kind of symmetry:By contrast, Definition 5.4 of agreement on read effects is left-skewed, in the sense that it refers to the locations denoted by effects interpreted in the left state. The asymmetry makes working with agreement somewhat delicate. For example, agreement on \(\mathsf {rd}\,G{{\bf `}}f\) (modulo \(\pi\) ) implies that \(\sigma (G)\subseteq { {dom}}\,(\pi)\) (by Definition 5.3), but it does not imply \(\sigma (G)\stackrel{\pi }{\sim }\sigma ^{\prime }(G)\) . At a higher level there will be symmetry, for reasons explained in due course.

The transition relation depends on a pre-model \(\varphi\) , defined below, and is written \(\mathrel {\overset{{\varphi }}{ {{\longmapsto }}}}\) . The pre-model provides semantics for context calls and represents denotations of method bodies. Transitions act on configurations where the environment \(\mu\) has procedures distinct²⁹ from those of \(\varphi\) .

Note that item (ii) involves extensions of \(\pi\) , whereas the relations \(\stackrel{\pi }{\sim }\) and \(\stackrel{\pi }{\approx }\) involve only \(\pi\) itself.

We say pre-models are quasi-deterministic, because from a given initial state, these three outcomes are mutually exclusive: fault, non-empty set of states, empty set. Moreover, instantiating \(\sigma ^{\prime }:=\sigma\) and setting \(\pi\) to the identity on \(\sigma (\mathsf {alloc})\) in the condition (state determinacy) yields that all results from a given initial state are isomorphic.³¹

The transition relation is defined in Figure 22. A trace via pre-model \(\varphi\) is a non-empty finite sequence of configurations that are consecutive for the transition relation \(\mathrel {\overset{{\varphi }}{ {{\longmapsto }}}}\) . For example, this sequence is a trace (for any \(\varphi\) ):Recall that we identify \((\mathsf {skip};C)\) with C (Figure 6). By definition, a trace does not contain \(&#x021AF;\) .

For syntactic substitution, we use the notation \({P}^{x}_{F}\) . Substitution notations are mainly used with spec-only variables. In addition, for clarity, we also use substitution notation for values, even references—although the syntax does not include reference literals.

A context model, or \(\Phi\) -model when we refer to a specific context \(\Phi\) , is a pre-model that satisfies its specs.

Condition (a) says \(\varphi (m)\) faults just on states outside the precondition of m, (b) says the postcondition holds and write effect is respected, (c) is a technical condition we call boundary monotonicity, and (d) is the dependency condition of the read effect.

The snapshot values \(\overline{v}\) in (a) and (b) are uniquely determined by \(\sigma\) (Lemma 5.1). So (a) can be rephrased: \(&#x021AF; \in \varphi (m)(\sigma)\) iff \(\sigma \not\models {R}^{\overline{s}}_{\overline{v}}\) where \(\overline{v}\) are the values uniquely determined by R in \(\sigma\) . Similarly for (b), which treats spec-only variables as being quantified over the pre- and postcondition.

Finally, we can give the semantics of correctness judgments, which embodies encapsulation for dynamic boundaries. In the definition to follow, we write to abbreviate \(\delta ,\mathsf {rd}\,\mathsf {alloc}\) . Apropos Definition 5.9(d), note that \(\lbrace \mathsf {alloc}\rbrace = { {rlocs}}(\sigma ,\mathsf {rd}\,\mathsf {alloc}) = { {rlocs}}(\sigma ,{ \bullet }^\oplus)\) .

The conditions for a valid correctness judgment include that there are no faulting executions, terminated executions satisfy the postcondition and write effect, and boundary monotonicity. These conditions are like (a)–(c) above for context model. The absence of fault means more than no null dereference; it means there are no method calls outside the method’s precondition—because otherwise the call would fault, by condition (a) for context models. An additional condition for correctness is that the read effects of the judgment should subsume the read effects in the specs of methods in context calls; this is called r-safety. Finally, the Encap condition says that each step reads and writes outside the boundaries of any module the step is not within. The Encap condition is formulated using the read effects of the judgments and implies the expected end-to-end read effect as will be explained later. Reading is meant in the extensional sense of a two-run dependency property, similar to condition (d) for context model.

The Encap condition applies to every reachable step, and refers to the initial state, so we use the following schema to designate identifiers for the elements of a step reached from command C and state \(\sigma\) :The step is taken by the active command of B, from state \(\tau\) to state \(\upsilon\) . For such a step, we need to refer to the locations encapsulated by all modules except the current module, M, of the correctness judgment. To this end, the collective boundary is an effect \(\delta\) defined by cases:

In addition to the terms introduced above to refer to parts of the definition, we also use the following derived notions: A trace from \(\langle C,\: \sigma ,\: \_\rangle\) respects \((\Phi ,M,\varphi ,\varepsilon ,\sigma)\) just if each step of the trace does, and it is r-safe for \((\Phi ,\varepsilon ,\sigma)\) just if each configuration is. A step is called r-safe if its starting configuration is r-safe.

While w-respect can be defined one module at a time, this is not the case for r-respect, because dependency properties do not compose in a simple way.³³ The absence of dependency needs to be expressed in terms of the collective boundary \(\delta\) with which a given step must not interfere. As with w-respect, this depends on whether the step is a context call. If not, then the current module’s boundary is exempt (see condition \(N\ne { {topm}}(B,M)\) in Equation (23)). If so, then the step is exempt from the boundary of the callee’s module together with modules into which its implemenation may call (second condition in Equation (23)). Dependency is expressed as usual by an implication from initial agreement Equation (24) on reads to final agreement Equation (25) on writes—subtracting the encapsulated locations. The read effects in \(\varepsilon\) are interpreted in the pre-state \(\sigma\) , as are the write effects (which cover the written locations according to the condition labelled Write). The collective boundary \(\delta\) is interpreted at intermediate states.

In case the module boundaries are all empty, in Definition 5.10, two parts of the Encap condition become vacuous, namely, w-respect and boundary monotonicity. And r-respect reduces to the property that the dependency of each step is within the readable locations of the given frame condition. This implies an end-to-end read effect condition given in the following lemma.³⁴ The lemma is used to prove soundness of the linking rule; in that proof we derive a pre-model from the denotation of the method body, and the lemma is used to show it is a context model.

The subeffect judgment, written , says that in states satisfying P, the readable or writable locations designated by \(\varepsilon\) are contained in those designated by \(\eta\) . It is defined as follows:

The framing judgment for formulas, written , can loosely be understood to say the read effects in \(\eta\) cover the footprint of Q. It is used in the frame rule and also second-order frame rule, where we need framing of the module invariant by the dynamic boundary. To be precise, the judgment says of states \(\sigma\) and \(\tau\) that if \(\sigma\) satisfies \(P\wedge Q\) and \(\tau\) agrees with \(\sigma\) on the contents of locations designated by the read effects of \(\eta\) , then \(\tau\) satisfies Q. Here \(\eta\) is interpreted in state \(\sigma\) , which only matters if its effect expressions mention mutable variables. The judgment is defined as follows:For example, we have \(x\in r \models \mathsf {rd}\,x,\mathsf {rd}\,r{{\bf `}}f \mathrel {\mathsf {frm}}x.f=0\) . The \({ {ftpt}}\) function, defined in Figure 10, provides framing for atomic formulas. The basic lemmas about \({ {ftpt}}\) are that \(\models { {ftpt}}(P)\mathrel {\mathsf {frm}}P\) , for atomic P, andThe framing judgment is used, in the Frame rule, in combination with a separator formula (Figure 11). A key property of separators is that a formula obtained as \(\eta \mathbin {\cdot {{\bf /}}.}\varepsilon\) holds in \(\sigma\) iff \({ {rlocs}}(\sigma ,\eta)\mathbin {\mbox{$\cap $}}{ {wlocs}}(\sigma ,\varepsilon)=\varnothing\) . From this it follows that

Separator formulas are also used in the notion of immunity, which amounts to framing for frame conditions. Immunity is only needed for the sequence and loop rules, which we relegate to the Appendix as there is no interesting change from RLI. Framing and immunity are about preserving the value of an expression or formula from one control point to a later one. For preservation of agreements, framed reads (Definition 3.1) are crucial; e.g., in proving the lockstep alignment Lemma 8.9.

Selected proof rules are in Figure 23. They are to be instantiated only with wf premises and conclusions. In the rest of the section, we comment briefly about some rules and derive the modular linking rule. Then Section 6.3 discusses how the rules work together to enforce encapsulation.

The proof rules for assignment, like FieldUpd and Alloc, are “small axioms” [76] that have empty context, are in the default module, and have precise frame conditions. The Conseq rule can be used to subsume a frame condition like \(\mathsf {wr}\,\lbrace x\rbrace {{\bf `}}f\) by a more general one like \(\mathsf {wr}\,r{{\bf `}}f\) , given precondition \(x\in r\) and using subeffect judgment \(x\in r \models \mathsf {wr}\,\lbrace x\rbrace {{\bf `}}f \le \mathsf {wr}\,r{{\bf `}}f\) . Rule Alloc can be used with the Frame rule to express freshness in several ways.³⁵ These and the method call rule have the minimum needed hypothesis context. Extending the context is done by rules discussed in Section 6.3.

The gist of the second-order frame rule, SOF, is to conjoin a formula not only to the spec in the conclusion, like rule Frame, but also conjoin it to the specs in the hypothesis context. The rule distils a property of program semantics; its practical role is to derive the modular linking rule.

In rule SOF, the conditions \(N\in \Theta\) and \(N\ne M\) ensure that the command C respects the encapsulation of \({ {bnd}}(N)\) , in accord with the semantic condition Encap of Definition 5.10. Together with the framing judgment \(\models { {bnd}}(N)\mathrel {\mathsf {frm}}I\) , this ensures that C does not falsify I. The condition C binds no N-method means C contains no let-binding of a method m with \({ {mdl}}(m)=N\) . This and the condition \(\forall m\in \Phi .\:{ {mdl}}(m)\not\preceq N\) ensure that all of N’s method specs are in \(\Theta\) and have the invariant added simultaneously. Such conditions are the price we pay for not cluttering the logic with explicit syntax and judgments for a module calculus. Rule Link has analogous conditions.

In rule Link, \(\mathsf {let}~\overline{m} \mathbin {=}\overline{B}~\mathsf {in}~C\) means the simultaneous linking of \(m_i\) with \(B_i\) for i in some range. This version of Link supports simultaneous linking of multiple methods that may be defined in different modules. Note that \(\Theta\) is in the hypotheses for \(B_i\) , because some methods in \(\Theta\) may call others in \(\Theta\) , and for recursion. Condition \(\forall N\in \Phi ,L\in \Theta .\:N\not\preceq L\) precludes dependency of the ambient modules on the ones being linked. Condition \(\forall N,L .\: N\in \Theta \wedge N\prec L \Rightarrow L\in (\Phi ,\Theta)\) expresses import closure, which is needed to ensure that all relevant boundaries are considered in the Encap condition of the premises.

Recall the modular linking rule (2) sketched in Section 2.1. It can now be made precise as follows:

In Section 2.1, we mention requirements for soundness of Equation (2), in vague terms that can now be made precise. Requirement (E1) is to delimit some internal locations, which is expressed as a dynamic boundary \({ {bnd}}(M)\) . Requirement (E2) is that the module invariant I depends only on encapsulated locations, which we express by a framing judgment \(\models { {bnd}}(M)\mathrel {\mathsf {frm}}I\) . Requirement (E3) says the client stays outside boundaries, a part of the meaning of the correctness judgment for C; more on this in Section 6.3. Finally, (E4) requires that the invariant holds initially; we simply require that I follows from the main program’s precondition ( \(P\Rightarrow I\) ). Rule MLink is derived in Figure 24. The side conditions \(\models { {bnd}}(M) \mathrel {\mathsf {frm}} I\) , and \(P \Rightarrow I\) are the responsibility of the module developer. The idea is that precondition P expresses initial conditions for the linked program, e.g., that globals have default values (null for class types, \(\varnothing\) for \(\mathsf {rgn}\) ). In our examples, the invariant quantifies over elements of the global variable pool and holds when pool is empty. For a more sophisticated language, we would have module initialization code to establish the module invariant.

The proof rules for commands must enforce requirement (E3), i.e., a command respects the boundaries of modules in context other than the current module. In part, this is done by what we call context introduction rules. One may expect a weakening rule that allows additional specs to be added to the context, and indeed there is such a rule (CtxIntroIn1) for the case that the method’s module is already in context. If the method’s module is not already in context, then adding its spec actually strengthens the property expressed by the judgment, namely, respect of the added module’s boundary. For this, we have a rule CtxIntro that extends the context by adding a spec for method m and has side conditions (using separator formulas generated by \(\mathbin {\cdot {{\bf /}}.}\) ) that ensure both the read and write effects of atomic command A are separate from the boundary of m’s module. Two other variations are needed to handle method calls and adding a spec for the current module; these are relegated to the Appendix. (A more elegant treatment may be possible using an explicit calculus of modules and their correctness, but that would have its own intricacies.)

As an example, consider this code that acts on variables \(\texttt {s: Stack}\) and \(\texttt {c,d: Cell}\) .

Using variable \(r:\mathsf {rgn}\) and idiomatic precondition \(d\in r \wedge {r}{\#}{(pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep)}\) , this code has frame condition \(\mathsf {rw}\,d,r,\mathsf {alloc}, r{{\bf `}}val\) . (Here, we use the spec idiom depicted in Figure 3.) The small axiom for the store command \(d.val:=0\) says it reads d and writes \(d.val\) . To add the Stack module to this command’s context, rule CtxIntro requires the precondition to imply a separator, which when simplified is \({ \lbrace d\rbrace }{\#}{ pool } \wedge { \lbrace d\rbrace }{\#}{ pool{{\bf `}}rep }\) . This says d is neither in pool nor in any rep unless d is null.

There is also a rule to change the current module from the default module used in, e.g., rules Call, FieldUpd, and Alloc. In a proof these and the context introduction rules are used at the “leaves” of the proof, i.e., for atomic commands, to introduce the intended modules. This organization is the same as used previously in RLII. However, here the notion of encapsulation is stronger. To enforce that reads do not transgress boundaries (r-respect in Definition 5.10), the proof rules for If and While also have side conditions to ensure the conditional expressions are separate from boundaries. For test expression E, the condition is \((\mathord {+} N\in \Phi ,N\ne M .\:{ {bnd}}(N)) \mathbin {\cdot {{\bf /}}.}{ {r2w}}({ {ftpt}}(E))\) . This separator formula simplifies to true or false depending on whether any variable in E occurs in any of the boundaries of modules N in scope other than the current module M. Although the details are different from RLII, the general idea is the same, so we relegate most of these rules to the Appendix (see Figure 35 and Remark 8). Relevant examples can be found in Section 8 of RLII.

Refperms and agreement, the basis for semantics of read effects, are also used for semantics of agreement formulas. For relation formulas, satisfaction \(\sigma |\sigma ^{\prime }\models _\pi \mathcal {P}\) says state \(\sigma\) relates to \(\sigma ^{\prime }\) according to \(\mathcal {P}\) and refperm \(\pi\) (see Figure 25). The propositional connectives have classical semantics. Formula \(\mathcal {P}\) is called valid if \(\models \mathcal {P}\) .

Recall that semantic agreement ( \({ {Lagree}},{ {Agree}}\) ) is skewed in the sense that region expressions are evaluated in the left state, as noted following Equation (22). The semantics of \(\mathbb {A}G{{\bf `}}f\) uses agreement via refperm \(\pi\) and agreement via \(\pi ^{-1}\) for the swapped pair of states. As a result, \(\sigma |\sigma ^{\prime }\models _\pi \mathbb {A}G{{\bf `}}f\) implies not only \(\sigma (G)\subseteq dom(\pi)\) but also \(\sigma ^{\prime }(G)\subseteq rng(\pi)\) . However, \(\mathbb {A}G{{\bf `}}f\) does not imply \(G\mathrel {\ddot{=}}G\) in general. So the form \(G\mathrel {\ddot{=}}G\wedge \mathbb {A}G{{\bf `}}f\) is often used, e.g., formula (11); in particular, it appears in the agreements from a read framed effect.

The formulas \(\mathbb {A}G{{\bf `}}f\) and \(G{{\bf `}}f\mathrel {\ddot{=}}G{{\bf `}}f\) have different meaning and in general are incomparable. In case \(f:\mathsf {int}\) , the region \(G{{\bf `}}f\) is empty in which case \(\mathbb {A}G{{\bf `}}f\) implies \(G{{\bf `}}f\mathrel {\ddot{=}}G{{\bf `}}f\) trivially. Using a diagram like in Figure 17, Figure 26 shows two states and a refperm such that \(\mathbb {A}\lbrace x\rbrace {{\bf `}}f\) holds (noting that \((q,q^{\prime })\in \pi\) and \((r,r^{\prime })\in \pi\) ). But \(\lbrace x\rbrace {{\bf `}}f\mathrel {\ddot{=}}\lbrace x\rbrace {{\bf `}}f\) does not; we have \(\sigma (\lbrace x\rbrace {{\bf `}}f)=\lbrace q\rbrace\) and \(\sigma ^{\prime }(\lbrace x\rbrace {{\bf `}}f)=\lbrace r^{\prime }\rbrace\) but \((q,r^{\prime })\notin \pi\) . Also \(\lbrace x\rbrace \mathrel {\ddot{=}}\lbrace x\rbrace\) is false, because \((o,p^{\prime })\notin \pi\) .

Here are some valid schemas: \(\mathcal {P}\Rightarrow \Diamond \mathcal {P}\) , \(\Diamond \Diamond \mathcal {P}\Rightarrow \Diamond \mathcal {P}\) , and \(\Diamond (\mathcal {P}\wedge \mathcal {Q}) \Rightarrow \Diamond \mathcal {P}\wedge \Diamond \mathcal {Q}\) . Another validity is \((\mathsf {alloc}\mathrel {\ddot{=}}\mathsf {alloc}) \wedge \Diamond \mathcal {P}\Rightarrow \mathcal {P}\) , in which \(\mathsf {alloc}\mathrel {\ddot{=}}\mathsf {alloc}\) says the refperm is a total bijection on allocated references. The strong condition \(\mathsf {alloc}\mathrel {\ddot{=}}\mathsf {alloc}\) is not local, and is not a useful requirement for most purposes.

Validity of \(\mathcal {P}\Rightarrow \mathord {{\Box }}\mathcal {P}\) is equivalent to \(\mathcal {P}\) being refperm monotonic, i.e., not falsified by extension of the refperm. Agreement formulas are refperm monotonic, as a consequence of Equation (21). A key fact isValidity of \(\Diamond \mathcal {P}\Rightarrow \mathcal {P}\) expresses that \(\mathcal {P}\) is refperm-independent, i.e., \(\sigma |\sigma ^{\prime }\models _\pi \mathcal {P}\) iff \(\sigma |\sigma ^{\prime }\models _\rho \mathcal {P}\) , for all \(\sigma ,\sigma ^{\prime },\pi ,\rho\) . If \(\mathcal {P}\) contains no agreement formula, then it is refperm-independent (even if \(\Diamond\) occurs in \(\mathcal {P}\) ). For such formulas the condition in Equation (30) can be strengthened:

Syntactic projection is weakening: \(\mathcal {P}\Rightarrow {\langle \! [} P {\langle \! ]} \wedge {[\! \rangle } \text{P}^{\prime } {]\! \rangle }\) where P is \(\mathop {\mathcal{P}} \limits^{\leftharpoonup}\) and \(P^{\prime }\) is \(\mathop {\mathcal{P}} \limits^{\rightharpoonup}\) . The implication is strict, in general, because projection discards agreements (Figure 15). Syntactic projection is not \(\Rightarrow\) -monotonic: for boolean variable x, the formula \(x\mathrel {\ddot{=}}x \wedge {[\! \rangle } x\gt 0 {]\! \rangle } \Rightarrow {\langle \! [} x\gt 0 {\langle \! ]}\) is valid, but \(\mathop {{x\mathrel {\ddot{=}}x \wedge {[\! \rangle } x\gt 0 {]\! \rangle } }}\limits^{\leftharpoonup\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!} \equiv true\wedge true\) and \(\mathop {{ {\langle \! [} x\gt 0 {\langle \! ]} }}\limits^{\leftharpoonup\!-\!-\!-\!-\!-\!-\!-\!-} \equiv x\gt 0\) . The example also shows that agreements can have unary consequences. As another example, this is valid: \(\Diamond (x\mathrel {\ddot{=}}x^{\prime } \wedge x\mathrel {\ddot{=}}y^{\prime }) \Rightarrow {[\! \rangle } x^{\prime }=y^{\prime } {]\! \rangle }\) . The antecedent holds if the refperm relates the value of x to both the values of \(x^{\prime }\) and \(y^{\prime }\) , or can be extended to do so. Neither is possible if the value of \(x^{\prime }\) is different from the value of \(y^{\prime }\) .

The framing judgment generalizes the unary version (27).

For example, \(G\mathrel {\ddot{=}}G \models \eta |\eta \mathrel {\mathsf {frm}}\mathbb {A}G{{\bf `}}f\) where \(\eta\) is \({ {ftpt}}(G),\mathsf {rd}\,G{{\bf `}}f\) (Lemma C.2). Apropos relations of the form \(\mathcal {R}\mathrel {\,\hat{=}\,}G\mathrel {\ddot{=}}G \wedge \mathbb {A}G{{\bf `}}f\) , we have \(\models \delta |\delta \mathrel {\mathsf {frm}}\mathcal {R}\) where \(\delta\) is \({ {ftpt}}(G),\mathsf {rd}\,G{{\bf `}}f\) . If \(P\models \eta \mathrel {\mathsf {frm}}Q\) , then \({\langle \! [} P {\langle \! ]} \models \eta |{ \bullet }\mathrel {\mathsf {frm}} {\langle \! [} Q {\langle \! ]}\) (and same on the right). Also, \(\models { {ftpt}}(F) | { {ftpt}}(F^{\prime })\mathrel {\mathsf {frm}}F\mathrel {\ddot{=}}F^{\prime }\) , which can be shown using the footprint agreement lemma (28).

The subeffect judgment is also a direct generalization of the unary version: the inclusions of Equation (26) hold on both sides, for \(\sigma ,\sigma ^{\prime },\pi\) with \(\sigma |\sigma ^{\prime }\models _\pi \mathcal {P}\) .

A relational pre-model involves two unary pre-models (Definition 5.7) together with a function on state pairs as appropriate for the denotation of a biprogram. This function is subject to similar conditions as for unary pre-models, and must also be compatible with its two unary pre-models.

We do not require \(&#x021AF; \in \varphi _2(m)(\sigma |\sigma ^{\prime })\) to imply \(&#x021AF; \in \varphi _0(m)(\sigma)\) or \(&#x021AF; \in \varphi _1(m)(\sigma ^{\prime })\) . The bi-model denoted by a biprogram may fault due to relational precondition, or alignment conditions, even though the underlying commands do not fault.

In a relational pre-model, the bi-model outcome sets are convex in this sense:This is a consequence of unary compatibility, relational compatibility, and fault determinacy. But it is not a consequence of the three conditions imposed on bi-models alone.

Biprograms are given transition semantics by relation on configurations, defined in Figures 27 and 28 for any (relational) pre-model \(\varphi\) . Configurations have the form \(\langle CC,\: \sigma |\sigma ^{\prime },\: \mu |\mu ^{\prime }\rangle\) , which represents an aligned pair of unary configurations. These have projections \(\mathop {{\langle CC,\: \sigma |\sigma ^{\prime },\: \mu |\mu ^{\prime }\rangle }}\limits^{\leftharpoonup\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!-\!\!} \mathrel {\,\hat{=}\,}\langle \mathop {CC} \limits^{\leftharpoonup\!\!-\!\!-\!\!-\!\!-\!\!-},\: \sigma ,\: \mu \rangle\) and \(\mathop {\langle CC,\: \sigma |\sigma ^{\prime },\: \mu |\mu ^{\prime }\rangle }\limits^{\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!-\!\rightharpoonup} \mathrel {\,\hat{=}\,}\langle \mathop {CC} \limits^{-\!-\!\rightharpoonup},\: \sigma ^{\prime },\: \mu ^{\prime }\rangle\) . Environments are unchanged from unary semantics: \(\mu\) and \(\mu ^{\prime }\) map procedure names to commands, not biprograms.³⁶ The rules are designed to ensure quasi-determinacy (see Lemma C.8).

The bi-com \((C|C^{\prime })\) represents a pair of programs for which the only alignment of interest is the initial states and the final states (if any). Its steps are dovetailed, unless one side has terminated, so that divergence on one side cannot prevent progress on the other side. It make direct use of the unary transition relation. The exact order of dovetailing does not matter; what matters is that one-sided divergence is not possible. Here are the details of the specific formulation we have chosen. The bi-com \((C|C^{\prime })\) takes a step on the left (rule bComL in Figure 27), leaving the right side unchanged. It transitions to the r-bi-com form , which does not occur in source programs, and which takes a right step (bComR). In configurations, identifier CC ranges over biprograms that may include endmarkers from the unary semantics and also the r-bi-com.³⁷ Rule bComR0 is needed to handle biprograms of the form \((\mathsf {skip}|D)\) . The rules ensure that \((\mathsf {skip} |^{\!\triangleright } D)\) never occurs for \(D&#x2262; \mathsf {skip}\) , and we identify \((\mathsf {skip} |^{\!\triangleright } \mathsf {skip})\equiv \lfloor \mathsf {skip} \rfloor\) .

Rules bSeq and bSeqX simply close the transitions under command sequencing. Recall that we identify some biprograms, e.g., \((\mathsf {skip}|\mathsf {skip}) \equiv \lfloor \mathsf {skip} \rfloor\) , to avoid the need for bureaucratic transitions (see Figure 6). A trace T via \(\varphi\) is a finite sequence of configurations that is consecutive under \(\mathrel {\overset{{\varphi }}{{&#x27FE; }}}\) . The projection lemma (Lemma 7.8) confirms that T gives rise to unary trace U on the left via \(\mathrel {\overset{{\varphi _0}}{ {{\longmapsto }}}}\) and V on the right via \(\mathrel {\overset{{\varphi _1}}{ {{\longmapsto }}}}\) .

The sync atomic command \(\lfloor A \rfloor\) steps A by unary transition on both sides, unless A is a context call in which case the context bi-model is used. Endmarkers are considered to be atomic commands, e.g., \(\lfloor \mathsf {elet}(m) \rfloor\) transitions via rule bSync and removes m from the environment on both sides.

A bi-if, \(\mathsf {if}\ {E\mbox{$|$}E^{\prime }}\ \mathsf {then}\ {CC}\ \mathsf {else}\ {DD}\) , faults from initial states that do not agree on the tests \(E,E^{\prime }\) , which we call an alignment fault (rule biIfX). A bi-while, \(\mathsf {while}\ {E\mbox{$|$}E^{\prime }} \cdot {\mathcal {P}\mbox{$|$}\mathcal {P}^{\prime }}\ \mathsf {do}\ {CC}\) , executes the left part of the body, \(\mathop {CC} \limits^{\leftharpoonup}\) , if E and the left alignment guard \(\mathcal {P}\) both hold, and mutatis mutandis for the right. If neither alignment guard holds, then the loop faults unless the tests \(E,E^{\prime }\) agree (bWhX).

The transition relation \(\mathrel {\overset{{\varphi }}{{&#x27FE; }}}\) uses the unary models \(\varphi _0\) and \(\varphi _1\) for method calls in the bi-com form, e.g., \((m()|\mathsf {skip})\) goes via \(\varphi _0\) according to bComL. A sync’d call \(\lfloor m() \rfloor\) in the body of a loop that has non-false left or right alignment guards may give rise to steps where the active biprogram has the form \((m();C|D)\) or \((\mathsf {skip}|m();C)\) (rules bWhL, bWhR). The active biprogram, like the active command in a unary configuration, is the unique sub-biprogram that gets rewritten by the applicable transition rule. As with unary programs, we define \({ {Active}}(CC)\) to be the unique BB such that \(CC\equiv BB;DD\) for some DD and BB is not a sequence; it is what gets rewritten by the applicable transition rule.

Projecting from a biprogram trace does not simply mean mapping the syntactic projections over the trace, because that would result in stuttering steps that do not arise in the unary semantics (where stuttering only happens for context calls and only if the model returns an empty set). In the preceding diagrams, some unary configurations correspond with more than one biprogram configuration; one may say the unary program is idling while a step is taken on the other side.

The alignment of biprogram traces with unary ones is formalized as follows. Here, we treat a trace T as a map defined on an initial segment of the naturals, so \({ {dom}}\,(T)\) is the set \(\lbrace 0,\ldots ,\) \(len(T)-1\rbrace\) .

The dashed lines in Figure 29 represent the l and r index mappings of a schedule. For Example 7.6, left side of the figure, the mapping is \(r(0)=0\) , \(r(1)=0\) , \(r(2)=1\) , and so on.

The following result makes precise that every biprogram trace represents a pair of unary traces. It is phrased carefully to take into account the possibility of stuttering transitions at the unary level.

Owing to careful design of Definitions 5.9, 5.10, and 7.4, the following notions are mostly about relational aspects. Relational context models are pre-models that satisfy some specs. They play the same role in the semantics of relational judgments as unary context models play in unary correctness.

A direct consequence of Definition 7.9, together with unary compatibility of pre-models and condition (c) of Definition 5.9, is that for all N with \({ {mdl}}(m)\preceq N\) , letting \(\delta \mathrel {\,\hat{=}\,}{ {bnd}}(N)\) , we haveand there is also a direct consequence of condition (d) of Definition 5.9.

The projections of Lemma 7.8 are used in the following definition of relational correctness.

The values of spec-only variables are uniquely determined by the pre-states, just like in unary specs. In virtue of the universal quantification over refperms \(\pi\) , for a spec in standard form \(\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {Q}\) , the judgment says for any \(\pi\) that supports the agreements in \(\mathcal {P}\) there exists an extension \(\rho \supseteq \pi\) that supports the agreements in \(\mathcal {Q}\) .

The following result confirms that the relational judgment is about unary executions. In particular, a judgment about a bi-com \((C|C^{\prime })\) implies the expected property relating executions of C and \(C^{\prime }\) . The proof uses the embedding Lemma C.9, which says a biprogram’s traces cover all the executions of its unary projections, unless it faults.

In Section 2.1, we introduced the notion of local equivalence. There is a relational proof rule, rLocEq, which lifts a unary judgment to a relational one. The unary read effect, which has an extensional semantics that is relational (Definition 5.10) gets lifted to an explicit relational property, a local equivalence relating a command to itself. As basis for the proof rule, we now formalize a construction, \({ {locEq}}\) , that applies to a unary spec and makes a relational spec—like the spec (9) in Example 4.3, and others in Section 4.6—that expresses equivalence in terms of the given frame condition and takes into account encapsulation boundaries.

Both unary and relational proof rules have conditions to enforce encapsulation with respect to the boundaries of modules in scope. For unary this is discussed in Section 6.3. The semantic condition Encap, in Definition 5.10, refers to a collective boundary. This is an effect formed as a union of the relevant boundaries, for example in the expression \((\mathord {+} N\in \Phi ,N\ne M .\:{ {bnd}}(N))\) where M is the current module and \(\Phi\) is the hypothesis context. For brevity, several relational proof rules are expressed using \(\delta\) to name the collective boundary; in particular, rule rLocEq, which introduces the \({ {locEq}}\) spec we now define.

Given a boundary \(\delta\) and unary spec \(P\leadsto Q\:[\varepsilon ]\) , the desired pre-relation expresses agreement on the readable locations. Absent a boundary, this can be written \(\mathbb {A}\varepsilon\) , taking advantage of our abbreviations, which say that \(\mathbb {A}\varepsilon\) abbreviates \(\mathbb {A}{ {rds}}(\varepsilon)\) , which in turn abbreviates a conjunction of agreement formulas (Figure 14). But, we should avoid requiring agreement on variable \(\mathsf {alloc}\) , as we want to allow entirely different data structures within boundaries. The requisite agreement can be expressed, using effect subtraction, as \(\mathbb {A}(\varepsilon \backslash \delta ^\oplus)\) , where \(\delta\) is the collective boundary of the modules to be respected. Note that \(\delta ^\oplus\) abbreviates \(\delta ,\mathsf {rd}\,\mathsf {alloc}\) (as in Definition 5.9).

A first guess for the post-relation would use agreement on the writable locations, but that cannot be written as \(\mathbb {A}{ {w2r}}(\varepsilon)\) , because any state-dependent region expressions in write effects of \(\varepsilon\) should be interpreted in the pre-state. This is why the concluding agreements in the definition of r-respect are expressed in terms of the fresh and written locations. So this is what we need to express in a spec. The solution is to use snapshot variables. If we use fresh variable \(s_{\mathsf {alloc}}\) in precondition \(s_{\mathsf {alloc}}=\mathsf {alloc}\) , then the fresh references can be described in post-states as \(\mathsf {alloc}\backslash s_{\mathsf {alloc}}\) and agreement on fresh locations can be expressed as \(\mathbb {A}(\mathsf {alloc}\backslash s_{\mathsf {alloc}}){{\bf `}}\mathsf {any}\) . For written (pre-existing) locations, we can obtain the requisite agreements in terms of initial snapshots of the locations deemed writable by \(\varepsilon\) . For an example, see Equation (18) in Section 4.6.

For each \(\mathsf {wr}\,G{{\bf `}}f\) in \(\varepsilon\) , we add a snapshot equation \(s_{G,f} = G\) to the precondition, or rather \(\mathbb {B} (s_{G,f} = G)\) . The desired post-relation is then \(\mathbb {A}s_{G,f}{{\bf `}}f\) . Please note that \(s_{G,f}\) is just a fresh identifier, written in a way to keep track of its use in connection with \(G{{\bf `}}f\) . The snapshots and agreements are given by functions \({ {snap}}\) and \({ {Asnap}}\) defined next. The following definitions make use of effects like \(\mathsf {rd}\,s_{G,f}{{\bf `}}f\) , in which spec-only variables occur. These are used to define agreement formulas used in postconditions—they are not used in frame conditions, where spec-only variables are disallowed.

Notice that \({ {Asnap}}\) omits \(\mathsf {alloc}\) and uses the snapshot variables introduced by \({ {snap}}\) .³⁸ Notice also that in the case \({ {Asnap}}(\mathsf {wr}\,G{{\bf `}}\mathsf {any})\) a single snapshot variable \(s_{G,\mathsf {any}}\) is used, but the image expression in \(G{{\bf `}}\mathsf {any}\) gets expanded to the constituent fields ( \(f, g, \dots\) ).

The following result confirms that \({ {Asnap}}\) serves the purpose of designating the writable locations from the perspective of the post-state. It uses semantic notions from Sections 5.1 and 5.2.

The following definition of \({ {locEq}}\) uses effect subtraction to avoid asserting agreement inside the given boundary, in both pre and post. For example, if \(\varepsilon\) includes \(\mathsf {wr}\,x,\mathsf {wr}\,G{{\bf `}}f\) , then we convert to read effects and use the snapshot variable: \(\mathsf {rd}\,x,\mathsf {rd}\,s_{G,f}{{\bf `}}f\) . Then \((\mathsf {rd}\,x,\mathsf {rd}\,s_{G,f}{{\bf `}}f)\backslash \delta\) will remove x if \(\mathsf {rd}\,x\) is in \(\delta\) , and result in \(\mathsf {rd}\,(s_{G,f}\backslash H){{\bf `}}f\) if \(\mathsf {rd}\,H{{\bf `}}f\) is in \(\delta\) .

If \(P\leadsto Q\:[\varepsilon ]\) and \(\delta\) are wf in \(\Gamma\) , then \({ {locEq}}_\delta (P\leadsto Q\:[\varepsilon ])\) is wf in \(\Gamma |\Gamma\) and has the same spec-only variables on both sides.

Recall from Section 6.3 the Stack client with precondition \(P \mathrel {\,\hat{=}\,}c\in r\wedge {r}{\#}{(pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep)}\) and frame \(\varepsilon \mathrel {\,\hat{=}\,}\mathsf {rw}\,c,r,\mathsf {alloc}, r{{\bf `}}val\) , where the boundary \(\delta\) is \(\mathsf {rd}\,pool, pool{{\bf `}}\mathsf {any}, pool{{\bf `}}rep{{\bf `}}\mathsf {any}\) . For the precondition, the reads are \(\mathsf {rd}\,c,\mathsf {rd}\,r,\mathsf {rd}\,\mathsf {alloc},\mathsf {rd}\,r{{\bf `}}val\) . Subtracting \(\delta ^\oplus\) leaves the variables \(c,r\) and is more interesting for \(r{{\bf `}}val\) . Expanding abbreviation \(\mathsf {any}\) and discarding empty regions, we are left with \(\mathsf {rd}\, (r\backslash (pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep)){{\bf `}}val\) . So the precondition \(\mathbb {A}\varepsilon ^\leftarrow _\delta\) is \(\mathbb {A}c \wedge \mathbb {A}r \wedge \mathbb {A}(r\backslash (pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep)){{\bf `}}val\) . (In conjunction with \(\mathbb {B} P\) , the formula \(\mathbb {A}(r\backslash (pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep)){{\bf `}}val\) is equivalent to \(\mathbb {A}r {{\bf `}}val\) .) There is a snapshot variable in precondition \(s_{r,val} = r\) , due to \(\mathsf {wr}\,r{{\bf `}}val\) . It is used in this conjunct of the \({ {Asnap}}\) part of the postcondition: \(\mathbb {A}(s_{r,val}\backslash (pool\mathbin {\mbox{$\cup $}}pool{{\bf `}}rep)){{\bf `}}val\) .

Selected proof rules are in Figure 30. For relational judgments, the validity conditions (Definition 7.10) have been carefully formulated to leverage the unary ones (Definition 5.10). This obviates the need for rules like CtxIntro at the relational level. Rule rCall, for aligned calls using a relational spec, relies on unary premises to enforce the requisite encapsulation conditions. The relational rules for bi-if and bi-while have separator conditions to enforce encapsulation, taken straight from their unary rules (e.g., If in Figure 23). The relational rules for bi-while and sequence include an immunity condition for framing of their effects, again taken straight from the unary rules.

The linking rule, rLink, relates a client command C to itself using relations that imply its executions can be aligned lockstep. It can be instantiated with local equivalence specs but also with more general specs that include hidden invariants and coupling on encapsulated state. To allow this generality in a sound way, rule rLink uses the following notion.

For example, we have \({ {locEq}}_\delta (spec){\bigcirc\!\!\!\!\!\!\!\!{\wedge}} \mathcal {M}\Rrightarrow { {locEq}}_\delta (spec)\) for any \(\delta ,spec,\mathcal {M}\) .

In rLink, side conditions constrain module imports, exactly as in unary Link, as part of the enforcement of encapsulation. As with Link, some of the conditions merely express module structure. The soundness proof for rLink goes by induction on biprogram traces, similar to the soundness proof for unary Link; the relational hypothesis can be used, because the relevant context calls are aligned (see Appendices B.10 and D.10).

Rule rEmb lifts unary judgments to a relational one. It applies to arbitrary commands. For example, it can be applied to the sumpub program of Equation (4), to prove the judgment about \((sumpub|sumpub)\) by lifting a unary spec as described in Section 4.5. It is also needed to obtain relational judgments about assignments, and it enables the use of unary specs in one-sided method calls.

For allocation, there needs to be a way to indicate when a pair of allocations are meant to be aligned; this is the purpose of rAlloc. Using rConj, rEmb, the unary rule Alloc, and the frame rules, one can add postconditions like \(\mathbb {A}\lbrace x\rbrace {{\bf `}}f\) and freshness of x. (Detailed derivations for freshness can be found in RLIII (Section 7.1)). Like rCall, rule rAlloc does not have the minimal hypothesis context but rather allows an arbitrary one; this is needed, because we do not have context introduction rules at the relational level. To enforce encapsulation, rAlloc has a side condition that simply says neither x nor \(\mathsf {alloc}\) occur in the boundaries of any models other than the current one.

Rule rLocEq has a side condition about the unary judgment’s frame condition: the writes must be subsumed by the reads (subeffect judgment \(P\models { {w2r}}(\varepsilon)\le { {rds}}(\varepsilon)\) ). This ensures that the precondition of the relational conclusion has agreement for writable locations. The requirement that C is let-free is needed in accord with Lemma 8.9.

Rule rSOF follows the pattern of the unary SOF in its use of \({\bigcirc\!\!\!\!\!\!\!\!{\wedge}} \mathcal {M}\) from Definition 4.7. It can only be instantiated with specs in standard form, so that \({\bigcirc\!\!\!\!\!\!\!\!{\wedge}} \mathcal {M}\) is defined. It requires refperm monotonicity of the coupling, i.e., \(\mathcal {N}\Rightarrow \mathord {{\Box }}\mathcal {N}\) ; more on this in Section 8.3.

Figure 31 presents the relational modular linking rule, rMLink, and its derivation. (Here specialized to a single method, i.e., \({ {dom}}\,(\Phi)=\lbrace m\rbrace\) , for clarity). The side conditions are \(P\models { {w2r}}(\varepsilon)\le { {rds}}(\varepsilon)\) (for rLocEq); \(\models \delta | \delta \mathrel {\mathsf {frm}} \mathcal {M}\) and \(\mathcal {M}\Rightarrow \mathord {{\Box }}\mathcal {M}\) (for rSOF); \({ {dom}}\,(\Phi)=\lbrace m\rbrace\) (for rLink); and \(pre({ {locEq}}_\delta (P\leadsto Q\:[\varepsilon ])) \Rightarrow \mathcal {M}\) (for rConseq, to drop \(\wedge \mathcal {M}\) from the precondition; of course \(\wedge \mathcal {M}\) is also dropped from postcondition). For rWeave, we use the fact that \((\mathsf {let}~m \mathbin {=}B~\mathsf {in}~C \mid \mathsf {let}~m \mathbin {=}B^{\prime }~\mathsf {in}~C) \looparrowright ^* \mathsf {let}~m \mathbin {=}(B|B^{\prime })~\mathsf {in}~ \lfloor\!\!\lfloor C \rfloor\!\!\rfloor\) . Vertical elipses in the derivation indicate that, in addition to the expected relational premise for B and \(B^{\prime }\) , unary premises are required: \(\Phi {\bigcirc\!\!\!\!\!\!\!\!{\wedge}} \mathop{\mathcal {M}}\limits^{\leftharpoonup} \vdash _M B : \Phi (m){\bigcirc\!\!\!\!\!\!\!\!{\wedge}} \mathop{\mathcal {M}}\limits^{\leftharpoonup}\) and \(\Phi {\bigcirc\!\!\!\!\!\!\!\!{\wedge}} \mathop{\mathcal {M}}\limits^{\rightharpoonup} \vdash _M B^{\prime } : \Phi (m){\bigcirc\!\!\!\!\!\!\!\!{\wedge}} \mathop{\mathcal {M}}\limits^{\rightharpoonup}\) . These are required by rLink, for technical reasons explained in its proof (Section D.10).

The implication \(pre({ {locEq}}_\delta (P\leadsto Q\:[\varepsilon ])) \Rightarrow \mathcal {M}\) refers to the precondition of local equivalence. Typically, the implication is valid, because P includes initial conditions that imply \(\mathcal {M}\) just as in the case of unary modular linking and module invariant. This is the responsibility of the module developer, who defines \(\mathcal {M}\) , shows its framing by the boundary, and shows refperm monotonicity of \(\mathcal {M}\) .

For modular linking and most other purposes, we are concerned with specs in the standard form, i.e., either \(\mathcal {R}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {S}\:[\eta ]\) or \(\mathcal {R}\mathrel {{\approx\!\!\!\! \gt }}\mathcal {S}\:[\eta ]\) where \(\mathcal {R}\) and \(\mathcal {S}\) are \(\Diamond\) -free. In this section, we consider the rules that give rise to other forms, and related notions concerning formulas with \(\Diamond\) . It is possible to reformulate the logic to consider only standard form specs. We choose the present formulation, because some proof rules can be simpler and more orthogonal.

For reasoning about sequential composition one wants to combine judgments for specs \(\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {Q}\) and \(\mathcal {Q}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {R}\) into a judgment for \(\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {R}\) (omitting frame for clarity). It is easy to derive a rule for specs of this form, from the more basic rule for sequence together rules rPoss and rConseq. From \(\mathcal {Q}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {R}\) , we get \(\Diamond \mathcal {Q}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \Diamond \mathcal {R}\) by rPoss. Then, we get \(\Diamond \mathcal {Q}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {R}\) by rConseq, because \(\Diamond \Diamond \mathcal {R}\iff \Diamond \mathcal {R}\) is valid. From \(\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {Q}\) and \(\Diamond \mathcal {Q}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {R}\) we get \(\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {R}\) by the sequence rule.

Similarly, one can derive a relational rule for loops, with premises in standard form and relational invariant \(\mathcal {Q}\) that is \(\Diamond\) -free. In accord with the loop rule sketched as Equation (16), we elide frame conditions, context, and side conditions for immunity and encapsulation. The derived rule looks like this:

Given the premises, three applications of rPoss yields \(CC: \Diamond (\mathcal {Q}\wedge \lnot \mathcal {P}\wedge \lnot \mathcal {P}^{\prime }\wedge {\langle \! [} E {\langle \! ]} \wedge {[\! \rangle } E^{\prime } {]\! \rangle })\mathrel {{\approx\!\!\!\! \gt }}\Diamond \Diamond \mathcal {Q}\) , \((\mathop {CC} \limits^{\leftharpoonup}|\mathsf {skip}) : \Diamond (\mathcal {Q}\wedge \mathcal {P}\wedge {\langle \! [} E {\langle \! ]})\mathrel {{\approx\!\!\!\! \gt }}\Diamond \Diamond \mathcal {Q}\) , and \((\mathsf {skip}|\mathop {CC} \limits^{\rightharpoonup}) : \Diamond (\mathcal {Q}\wedge \mathcal {P}^{\prime }\wedge {[\! \rangle } E^{\prime } {]\! \rangle })\mathrel {{\approx\!\!\!\! \gt }}\Diamond \Diamond \mathcal {Q}\) . But \(\Diamond \Diamond \mathcal {Q}\) is equivalent to \(\Diamond \mathcal {Q}\) . Furthermore, \({\langle \! [} E {\langle \! ]}\) and \({[\! \rangle } E^{\prime } {]\! \rangle }\) are agreement-free and thus refperm independent. Also \(\mathcal {P},\mathcal {P}^{\prime }\) are refperm independent, because they are agreement free by the wellformedness condition mentioned at the end of Section 3.1. So, using property (31), the precondition of the second judgment, \(\Diamond (\mathcal {Q}\wedge \mathcal {P}\wedge {\langle \! [} E {\langle \! ]})\) is equivalent to one where \(\Diamond\) is applied only to \(\mathcal {Q}\) , i.e., \(\Diamond \mathcal {Q}\wedge \mathcal {P}\wedge {\langle \! [} E {\langle \! ]}\) . Similarly for the other two preconditions. So by rConseq, we get

With these, we instantiate the rule (16) with \(\Diamond \mathcal {Q}\) for \(\mathcal {Q}\) , which yields \(\mathsf {while}\ {E\mbox{$|$}E^{\prime }} \cdot {\mathcal {P}\mbox{$|$}\mathcal {P}^{\prime }}\ \mathsf {do}\ {CC} : \Diamond \mathcal {Q}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {Q}\wedge {\langle \! [} \lnot E {\langle \! ]} \wedge {[\! \rangle } \lnot E^{\prime } {]\! \rangle }\) . Finally, the implication \(\mathcal {Q}\Rightarrow \Diamond \mathcal {Q}\) is valid, and we can distribute refperm independent formulas under \(\Diamond\) ; so using rConseq, we obtain the conclusion of Equation (32).

For a bi-while with false alignment guards, there is a derived rule with a single premise \(\vdash CC: \mathcal {Q}\wedge {\langle \! [} E {\langle \! ]} \wedge {[\! \rangle } E^{\prime } {]\! \rangle } \mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {Q}\) . It can be derived, using rule rEmpPre.

Refperm monotonicity. Given a judgment \(\Phi \vdash ^{}_{}CC:\: \mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {Q}\:[\varepsilon |\varepsilon ^{\prime }]\) , rule rFrame yields \(\Phi \vdash ^{}_{}CC:\: \mathcal {P}\wedge \mathcal {R}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {Q}\wedge \mathcal {R}\:[\varepsilon |\varepsilon ^{\prime }]\) , which is not in the standard form. But suppose \(\mathcal {R}\) is refperm monotonic, i.e., \(\mathcal {R}\Rightarrow \mathord {{\Box }}\mathcal {R}\) is valid. Then by Equation (30), we have \(\Diamond \mathcal {Q}\wedge \mathcal {R}\Rightarrow \Diamond (\mathcal {Q}\wedge \mathcal {R})\) . So using rConseq we get this derived frame rule:

Refperm monotonicity is also a side condition for the coupling relation in rule rSOF. In that rule, moving the coupling relation under \(\Diamond\) is done by the \({\bigcirc\!\!\!\!\!\!\!\!{\wedge}}\) operation (Definition 4.7).

Agreement formulas are refperm monotonic, as are refperm independent formulas. But negation does not preserve refperm monotonicity, and in particular a formula of the form \(\mathbb {A}x \Rightarrow \mathcal {R}\) is not refperm monotonic even if \(\mathcal {R}\) is. Such implications are used in our example couplings. In particular, implication is used in the following idiomatic pattern:The second conjunct can be written in sugared form as \(\forall x\mathord {:}K \in G\mbox{$|$}x\mathord {:}K\in G^{\prime } .\:\mathbb {A}x \Rightarrow \mathcal {R}\) .

The coupling \(\mathcal {M}_{uf}\) in Section 4.6 is refperm monotonic. The embedded invariants \({\langle \! [} I_{qf} {\langle \! ]}\) and \({[\! \rangle } I_{qu} {]\! \rangle }\) are refperm monotonic, by (i) in the lemma, as is the consequent \(eqPartition({\langle \! [} u.part {\langle \! ]} , {[\! \rangle } u.part {]\! \rangle })\) in the relation (19). So refperm monotonicity of \(\mathcal {M}_{uf}\) follows using (ii) and (iii).

The coupling \(\mathcal {M}_{PQ}\) in Example 4.3 is refperm monotonic. To see why, first note that Equation (33) is equivalent to \(G/K\mathrel {\ddot{=}}G^{\prime }/K \wedge (\forall x\mathord {:}K \in G \mbox{$|$}x\mathord {:}K\in G^{\prime } .\:\mathbb {A}x \Rightarrow \mathcal {R})\) , because a quantified variable of type K ranges over allocated (non-null) references of type K. So inside the quantification, \(x\in G\) is equivalent to \(x\in G/K\) . The relevant subformula of \(\mathcal {M}_{PQ}\) is \(q.rep/\texttt {Pnode} \mathrel {\ddot{=}}q.rep/\texttt {Pnode}\) . Now, we distill the following pattern from \(\mathcal {M}_{PQ}\) , in which we assume \(f:\mathsf {rgn}\) and assume both \(\mathcal {Q}\) and \(\mathcal {R}\) are refperm monotonic:By (iii) in the lemma, the subformula \(\lbrace x\rbrace {{\bf `}}f \mathrel {\ddot{=}}\lbrace x\rbrace {{\bf `}}f \wedge (\forall y\mathord {:}L \in x.f \mbox{$|$}y\mathord {:}L \in x.f .\: \mathbb {A}y \Rightarrow \mathcal {R})\) is refperm monotonic. Then by (ii), we extend that to the conjunction with \(\mathcal {Q}\) . Then by (iii), the displayed formula is refperm monotonic. Note that this relies on agreement of the region values, \(\lbrace x\rbrace {{\bf `}}f \mathrel {\ddot{=}}\lbrace x\rbrace {{\bf `}}f\) , not pairwise agreement \(\mathbb {A}\lbrace x\rbrace {{\bf `}}f\) on field values.

This discussion provides guidelines for writing specs, but checking refperm monotonicity can be automated. Validity of \(\mathcal {R}\Rightarrow \mathord {{\Box }}\mathcal {R}\) only involves universal quantification. Unfolding semantic definitions, it says: for all \(\pi ,\rho ,\sigma ,\sigma ^{\prime }\) , if \(\sigma |\sigma ^{\prime }\models _\pi \mathcal {R}\) and \(\rho \supseteq \pi\) then \(\sigma |\sigma ^{\prime }\models _\rho \mathcal {R}\) . A straightforward encoding of this in our prototype suffices to show refperm monotonicity of the example couplings.

Agreement compatibility. The last rule for which \(\Diamond\) is an issue is rConj. With premises of the form \(\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {Q}_0\) and \(\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {Q}_1\) it yields \(\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\Diamond \mathcal {Q}_0\wedge \Diamond \mathcal {Q}_1\) . To obtain the standard form \(\mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\Diamond (\mathcal {Q}_0\wedge \mathcal {Q}_1)\) one can use rConseq but only if \(\mathcal {Q}_0\) and \(\mathcal {Q}_1\) are agreement compatible, which means this implication is valid:An easy case is where \(\mathcal {Q}_0\) or \(\mathcal {Q}_1\) is refperm independent, in which case agreement compatibility holds by Equation (31). Formulas that depend on the refperm involve agreements, and for these, we do not have an easy characterization of agreement compatibility.

In the prototype, \(\Diamond\) is not explicit in specs. A current refperm is witnessed in ghost state, so even when using conjunctive splitting, we effectively get \(\Diamond (\mathcal {Q}_0\wedge \mathcal {Q}_1)\) as desired. So agreement compatibility is not an issue in the tool. Morever our case studies show that agreement compatibility is achievable in practical examples where it is needed. Please note that nontrivial formulas of the form (34) are not amenable to validity checking by SMT, owing to the existential quantifier that underlies \(\Diamond\) in the consequent.³⁹

We end this section with some examples regarding agreement compatibility. But it is not needed later so it is safe to skip now to Section 8.4.

As a first example, consider the agreements \(\mathbb {A}(G/\texttt {List}){{\bf `}}head\) and \(\mathbb {A}(G/\texttt {Cell}){{\bf `}}val\) , where class \(\texttt {List}\) has field \(head:\texttt {Node}\) and class \(\texttt {Cell}\) has field \(val:\mathsf {int}\) . The truth value of \(\mathbb {A}(G/\texttt {List}){{\bf `}}head\) depends only on references of type \(\texttt {List}\) and \(\texttt {Node}\) . The truth value of \(\mathbb {A}(G/\texttt {Cell}){{\bf `}}val\) depends only on references of type \(\texttt {Cell}\) . Refperms respect types, so extensions of a refperm to witness \(\Diamond \mathbb {A}(G/\texttt {List}){{\bf `}}head\) and \(\Diamond \mathbb {A}(G/\texttt {Cell}){{\bf `}}val\) can be combined to witness \(\Diamond (\mathbb {A}(G/\texttt {List}){{\bf `}}head \wedge \mathbb {A}(G/\texttt {Cell}){{\bf `}}val)\) . Such considerations also apply in a case like \(\mathbb {B} \mathsf {type}(G,\texttt {List})\wedge \mathbb {A}G{{\bf `}}head\) and \(\mathbb {B} \mathsf {type}(H,\texttt {Cell})\wedge \mathbb {A}H{{\bf `}}val\) .

Agreement compatibility of \(\mathcal {Q}_0\) and \(\mathcal {Q}_1\) may fail even if both formulas are \(\mathcal {Q}\) and \(\mathcal {R}\) are refperm monotonic. For example, the formula \(\Diamond (x\mathrel {\ddot{=}}y) \wedge \Diamond (x\mathrel {\ddot{=}}z\wedge {[\! \rangle } z\ne y {]\! \rangle })\) is satisfiable but \(\Diamond (x\mathrel {\ddot{=}}y \wedge x\mathrel {\ddot{=}}z\wedge {[\! \rangle } z\ne y {]\! \rangle })\) is not. This example may give the impression that disequalities are the culprit but they are not. Consider these two formulas: \(\Diamond (x\mathrel {\ddot{=}}x^{\prime } \wedge y\mathrel {\ddot{=}}y^{\prime })\) and \(\Diamond (x\mathrel {\ddot{=}}y^{\prime } \wedge y\mathrel {\ddot{=}}x^{\prime })\) (for distinct variables \(x,x^{\prime },y,y^{\prime }\) ). Both are satisfiable. In fact their combination, \(\Diamond (x\mathrel {\ddot{=}}x^{\prime } \wedge y\mathrel {\ddot{=}}y^{\prime } \wedge x\mathrel {\ddot{=}}y^{\prime } \wedge y\mathrel {\ddot{=}}x^{\prime })\) , is also satisfiable: it can hold when \({\langle \! [} x=y {\langle \! ]} \wedge {[\! \rangle } x^{\prime }=y^{\prime } {]\! \rangle }\) . But the agreement-compatibility implication is not valid. Consider \(\sigma ,\sigma ^{\prime },\pi\) where \(x,y,x^{\prime },y^{\prime }\) have four distinct values, none of which are in the domain or range of \(\pi\) . Then both \(\Diamond (x\mathrel {\ddot{=}}x^{\prime } \wedge y\mathrel {\ddot{=}}y^{\prime })\) and \(\Diamond (x\mathrel {\ddot{=}}y^{\prime } \wedge y\mathrel {\ddot{=}}x^{\prime })\) are true but \(\Diamond (x\mathrel {\ddot{=}}x^{\prime } \wedge y\mathrel {\ddot{=}}y^{\prime } \wedge x\mathrel {\ddot{=}}y^{\prime } \wedge y\mathrel {\ddot{=}}x^{\prime })\) is false.

One might guess \(\mathbb {A}G{{\bf `}}f\) is agreement compatible with \(\mathbb {A}H{{\bf `}}g\) where \(f,g\) are distinct field names. But consider \(\mathbb {A}\lbrace x\rbrace {{\bf `}}f\) and \(\mathbb {A}\lbrace x\rbrace {{\bf `}}g\) for distinct fields \(f,g\) of some reference type. Suppose \(\sigma |\sigma ^{\prime }\models _\pi x\mathrel {\ddot{=}}x\) , so \(\pi (\sigma (x))=\sigma ^{\prime }(x)\) . Suppose \(\sigma (x.f)\) and \(\sigma (x.g)\) are non-null values not in \({ {dom}}\,(\pi)\) , and likewise \(\sigma ^{\prime }(x.f)\) and \(\sigma ^{\prime }(x.g)\) are non-null values not in \({ {rng}}\,(\pi)\) . Then, we have \(\sigma |\sigma ^{\prime }\models _\pi \Diamond \mathbb {A}\lbrace x\rbrace {{\bf `}}f \wedge \Diamond \mathbb {A}\lbrace x\rbrace {{\bf `}}g\) , because \(\pi\) can be extended to link \(\sigma (x.f)\) with \(\sigma ^{\prime }(x.f)\) and mut. mut. for g. However, if \(\sigma (x.f) = \sigma (x.g)\) and \(\sigma ^{\prime }(x.f) \ne \sigma ^{\prime }(x.g)\) then there is no single extension of \(\pi\) that satisfies \(\mathbb {A}\lbrace x\rbrace {{\bf `}}f \wedge \mathbb {A}\lbrace x\rbrace {{\bf `}}g\) .

Region disjointness \({G}{\#}{H}\) does not entail agreement compatiblity of \(\mathbb {A}G{{\bf `}}f\) with \(\mathbb {A}H{{\bf `}}f\) . Consider \(\mathbb {A}\lbrace x\rbrace {{\bf `}}f\) and \(\mathbb {A}\lbrace y\rbrace {{\bf `}}g\) . Suppose \(\sigma |\sigma ^{\prime }\models _\pi x\mathrel {\ddot{=}}x \wedge y\mathrel {\ddot{=}}y \wedge \mathbb {B} (x\ne y)\) . Similar to the preceding example, if \(\sigma (x.f)=\sigma (y.g)\) and \(\sigma ^{\prime }(x.f)\ne \sigma ^{\prime }(y.g)\) and none of the field values are in \(\pi\) , then we have \(\sigma |\sigma ^{\prime }\models _\pi \Diamond \mathbb {A}\lbrace x\rbrace {{\bf `}}f \wedge \Diamond \mathbb {A}\lbrace y\rbrace {{\bf `}}g\) but again there is no extension of \(\pi\) that satisfies \(\mathbb {A}\lbrace x\rbrace {{\bf `}}f \wedge \mathbb {A}\lbrace y\rbrace {{\bf `}}g\) .

The lockstep alignment lemma brings together the semantics of encapsulation in the unary logic (Definition 5.10), in which dependency is expressed in terms of two runs under a single unary context model, with the biprogram semantics, which involves two possibly different unary context models as needed for linking with two module implementations. The lemma says that, from states that agree on what may be read, a fully-aligned biprogram remains fully aligned through its execution, and maintains agreements sufficient to establish the postcondition of local equivalence—for any of its traces that satisfy the r-safe and respect conditions of Definition 5.10. In light of trace projection (Lemma 7.8), it says a pair of unary executions can be aligned lockstep, with strong agreements asserted at each aligned pair of configurations. The result does not rely on validity of a judgment—rather, we use this result to prove soundness of rules rLocEq, rSOF, and rLink.

A number of subtleties in the unary semantics of encapsulation, in the biprogram semantics, and in the definition of \({ {locEq}}\) are all motivated by difficulties in obtaining a result that is sufficiently strong to support the soundness proofs for the three rules from which the modular relational linking rule is derived (rLocEq, rSOF, and rLink).

In other words, the Lemma says that if we have fully aligned code, unary encapsulation (iv), initial agreement (ii), and relational specs that imply the local equivalence spec (but may be strengthened to include hidden invariants and coupling) (i), then the code remains fully aligned at every step, and agreements outside encapsulated state are preserved. Condition (v) can be strengthened to say \(\mu\) and \(\mu ^{\prime }\) are empty, which holds owing to the assumption that C is let-free. We keep this formulation, because it suffices and shows what we expect for the extensions discussed in Section 8.5.

The lemma is proved by induction on steps, maintaining (v)–(vii), using several technical lemmas for preservation of agreement (in Appendix Section D.2).

Lemma 8.9 resembles Lemma 5.11 but has significant differences. Lemma 8.9 is for client code outside boundaries, in a setting where there are different implementations of methods. Lemma 5.11 is for code potentially inside boundaries, but relating two runs of exactly the same program. In the proofs of both results, r-safety helps ensure that the small-step dependency embodied by r-respect implies an end-to-end dependency condition.

The unary and relational linking rules allow simultaneous linking of multiple modules, for example linking MST with the \(\texttt {PQ}\) and \(\texttt {Graph}\) modules. In RLII (Section 9), a modular linking rule is derived for simultaneous linking of two modules with mutually recursive methods, each respecting the other’s boundary. That can be done with both the unary and relational rules in this article: the judgments for correctness of the bodies are extended with the other module’s invariant or coupling (using SOF or rSOF) and then linked (using Link or rLink). In RLII and the unary logic in this article, it is also possible for linking to be nested (shown by examples in Sections 2.4 and 8.4 of RLII). However, there is a limitation of the relational rules with nested use of bi-let.

To set the stage, we carry out the derivation of modular linking as in Figure 24 but with a second module in context, to which we then apply modular linking. Methods of \(\Phi\) may be used in both the client C and the implementation B. The implementation of \(\Phi\) has its own internal state with invariant J:

We would like the relational analog of this derivation, so that with coupling \(\mathcal {M}\) for module M and coupling \(\mathcal {N}\) for N one could obtain the judgmentFollowing the pattern of the derivation above, one would like to apply rSOF for \(\mathcal {N}\) to the judgment \({ {LocEq}}_\delta (\Phi)\vdash _{{ \bullet }} \mathsf {let}~m \mathbin {=}(B|B^{\prime })~\mathsf {in}~\lfloor\!\!\lfloor C \rfloor\!\!\rfloor : { {locEq}}_\delta (P\mathord {\leadsto }Q\:[\varepsilon ]) {\bigcirc\!\!\!\!\!\!\!\!{\wedge}} \mathcal {M}\) , where \(\delta ={ {bnd}}(M),{ {bnd}}(N)\) . However, the current rSOF and rLink are only for fully aligned client code, and the “client” body \(\mathsf {let}~m \mathbin {=}(B|B^{\prime })~\mathsf {in}~\lfloor\!\!\lfloor C \rfloor\!\!\rfloor\) of the outer let is not in that form. Soundness of rSOF hinges on the calls being sync’d—but in the program \(\mathsf {let}~m \mathbin {=}(B|B^{\prime })~\mathsf {in}~\lfloor\!\!\lfloor C \rfloor\!\!\rfloor\) , calls to n (the method of \(\Phi\) ) from B or \(B^{\prime }\) are not sync’d, because \(m()\) steps to \((B|B^{\prime })\) , which has no sync’d calls. The restriction of bi-let to separate unary commands simplifies the technical development considerably. But, we would like to generalize the bi-let form to allow \(\mathsf {let}~m \mathbin {=}BB~\mathsf {in}~CC\) where BB is sufficiently woven that all its calls are sync’d, and CC is a nest of such bi-lets enclosing a fully aligned client. This requires Lemma 8.9 to be generalized to account for such biprogram computations. The Lemma relies on agreements derived from unary Encap, but this is no longer sufficient to handle computations with sub-computations that are not fully aligned. The premises of rSOF and rLink entail that such computations can make sync’d calls, but this fact is not retained in the semantics of relational judgments. Details of our solution are beyond the scope of this article.

An important feature of relational logic that is introduced in Banerjee et al. [11] (long version) is unconditional rewrites. These are correctness-preserving transformations of control structure in commands that enable the use of the bi-if and bi-while forms for programs with differing control structure. An example is the equivalence \(\mathsf {while}\ {E}\ \mathsf {do}\ {C} \mathrel {\cong }\mathsf {while}\ {E}\ \mathsf {do}\ {(C; \mathsf {while}\ {E\wedge E0}\ \mathsf {do}\ {C})}\) . Banerjee et al. use this and another loop unrolling equivalence to prove correctness of a loop tiling optimization. In that proof the loop iterations are aligned lockstep, i.e., rule rWhile and a bi-while with false alignment guards.

In the cited work, it suffices to define \(\mathrel {\cong }\) as a safety-preserving trace equivalence. These sorts of transformations do not alter the series of states reached and which atomic commands are executed. From the same initial state and environment, the computations proceed almost in step-by-step correspondence, the exceptions being different manipulation of the control state in some cases, which leaves the (data) state and method environment unchanged. As a result, correctness is preserved in the sense that if \(C\mathrel {\cong }D\) then \(\Phi \models ^{}_{}C:\: P\leadsto Q\:[\varepsilon ]\) implies \(\Phi \models ^{}_{}D:\: P\leadsto Q\:[\varepsilon ]\) . Moreover, \(\Phi \models ^{}_{}(C|C^{\prime }):\: \mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\mathcal {Q}\:[\varepsilon |\varepsilon ^{\prime }]\) implies \(\Phi \models ^{}_{}(D|C^{\prime }):\: \mathcal {P}\mathrel {{\approx\!\!\!\! \gt }}\mathcal {Q}\:[\varepsilon |\varepsilon ^{\prime }]\) (and the same on the right side). However, to cater for the stronger conditions of valid unary and relational judgments in the present work (Definitions 5.10 and 7.10), a stronger notion is needed, because those conditions refer to the control.

As an example, suppose we have a valid correctness judgment \(\Phi \vdash _M \mathsf {while}\ {E}\ \mathsf {do}\ {C}: P\leadsto Q\:[\varepsilon ]\) and consider the form \(\mathsf {while}\ {E}\ \mathsf {do}\ {(C; \mathsf {while}\ {E\wedge E0}\ \mathsf {do}\ {C})}\) . If E0 reads some variable that is encapsulated by a module, different from M, in \(\Phi\) , then it may violate the Encap condition of Definition 5.10 and invalidate the judgment \(\Phi \vdash _M \mathsf {while}\ {E}\ \mathsf {do}\ {(C; \mathsf {while}\ {E\wedge E0}\ \mathsf {do}\ {C})} : P\leadsto Q\:[\varepsilon ]\) . For the equivalences considered here, which involve rearranging control structure, branch conditions turn out to be the main complication. Details of our formalization of \(\mathrel {\cong }\) and its rules are beyond the scope of this article.

Bao et al. [15] introduce a unified fine-grained region logic with both separating conjunction and explicit read/write effects, subsuming a fragment of separation logic. To enable effective use of SMT solvers, Piskac et al. [80, 81] encode separation logic style specifications using explicit regions. Several works implement implicit dynamic frames [67, 90], which combines the succinctness of separation logic with the automation of SMT. For recent work on decidable fragments of separation logic, see Echenim et al. [38]. Using an extension of FOL with recursive definitions, the logic of Murali et al. [68] has an expression form for the footprint of a formula, akin to our \({ {ftpt}}\) operator but usable in formulas, avoiding the need for a separate framing judgment; this can encode a fragment of separation logic but effectiveness for automation has not been thoroughly evaluated.

The most closely related works are the RL articles. The image notation, introduced in RLI [14], was inspired by the use of field images to express relations in the information flow logic of Amtoft et al. [3]. In RLI this style of dynamic framing was shown to facilitate local reasoning about global invariants, and this was extended to dynamic boundaries and hiding of invariants in RLII [9].

In RLIII [12], pure methods are formalized with end-to-end read effects. The end-to-end semantics of read effects is also used in the preliminary work [11], from which we take biprograms, weaving, and bi-while alignment guards. But, we change the semantics of bi-com \((C|C^{\prime })\) to eliminate one-sided divergences and to allow models to diverge (see rules uCall0 in Figure 22 and bCall0 in Figure 27). This validates a better weaving rule (no termination conditions) and a stronger adequacy theorem (Theorem 7.11). We drop their semantics of read effects, which is inadequate for our purposes (and is subsumed by r-respects in Definition 5.10), but use quasi-determinacy and agreement-preservation results from RLIII. Neither RLIII nor [11] addresses information hiding or encapsulation. Our semantics of encapsulation (Definition 5.10) is a major extension of that in RLII, from which we take the minimalist formalization of modules; but we change the semantics to use context models (from RLIII where models are called interpretations) and add r-respects, and so on. We adapt unary rules from RLII but use the term modular linking for what they call mismatch. The case studies in RLIII are implemented using Why3 with an encoding of heaps and frame conditions similar to the one used by WhyRel.

Francez [43, 74] articulated the product principle reducing relational verification to the inductive assertion method and introduced a number of proof rules. Benton [25] introduced the term Relational Hoare Logic and brought to light applications including compiler optimizations. Yang [100] introduced relational separation logic, motivated by data abstraction although the logic does not formalize that as such. Beringer [27] extends Benton’s logic with heap (still not procedures), and provides proof rules for non-lockstep loops, on which our rWhile is based; a similar rule appears in Barthe et al. [22]. There has been a lot of work on relational logics and verification techniques [24], e.g., applications in security and privacy [21, 70, 83] and merges of software versions [94]. A shallow embedding of relational Hoare logic in \(F^\star\) is used to interactively prove refinements between union-find implementations [47]. Aguirre et al. [1] develop a logic based on relational refinement types, for terminating higher order functional programs, and provide an extensive discussion of work on relational logics.

Automated relational verification based on product programs is implemented in several works that address effective alignment of control flow points and the inference of alignment points and relational assertions and procedure summaries [16, 17, 18, 34, 40, 55, 99, 101, 102]. One line of work, centered around the SymDiff verifier [50, 56, 57], proves properties of program differences using relational procedure summaries. Godlin and Strichmann [46] prove soundness of proof rules for equivalence checking taking into account similar and differing calls. Eilers et al. [39] implement a novel product construction for procedure-modular verification of k-safety properties of a program, maximizing use of relational specs for procedure calls. (We follow O’Hearn et al. [77] in using “modular” to imply also information hiding.) Girka et al. [45] explore forms of alignment automata. Shemer et al. [89] provide for flexible alignments and infer state-dependent alignment conditions, as do Unno et al. [97]. The latter works rely on constraint solving techniques, which are not yet applicable to the heap. For the heap the state of the art for finding alignments is syntactic matching heuristics.

For \(\forall \exists\) properties, product constructions appear in some recent works [5, 17, 35, 59, 97]. Pioneering work by Rinard and Marinov [85, 86] introduces a logic of \(\forall \exists\) simulations for correct compilation, for programs represented as control flow graphs.

Sousa and Dillig’s Cartesian Hoare Logic [93] (a generalization of Benton’s logic) can be used to reason about k-safety properties such as secure information flow (2-safety) and transitivity (3-safety). They also develop an algorithm, based on an implicit product construction, for automatically proving k-safety properties; The corresponding tool, Descartes, has been used in the verification of several user-defined relational operators in Java programs. For more efficient relational verification, Pick et al. [79] introduce a new algorithm atop Descartes, which automatically detects opportunities for alignment (the synchrony phase) and detects opportunities for pruning subtasks by exploiting symmetries in program structure and relational specs.

None of the above works address hiding, and many do not fully handle the heap [58]. Our work is complementary, providing a foundation for verified toolchains implementing these algorithmic techniques. The use of rWhile with alignment guards, together with the disjunction rule to split cases and unconditional rewriting (Section 8.6), enables our logic to express a wide range of state-dependent alignments.

It is difficult to account for encapsulation in semantics of languages with dynamically allocated mutable state and especially with higher order features. Crary’s tour de force proves parametricity for a large fragment of ML but excluding reference types [36]. Semantic studies of the problem [2, 7] have been connected with unary [10] and relational logics [37]. The latter relies on intensional atomic propositions about steps in the transition semantics. In this sense it is very different from standard (Hoare-style) program logics.

Birkedal and Yang [30] show client code proved correct using the SOF rule of separation logic is relationally parametric, using a semantics that does not validate the rule of conjunction, which plays a key role in automated verification. That rule is an issue in some other models as well, e.g., Iris (in part owing to its treatment of ghost updates as logical operators).

Thamsborg et al. [96] also lift separation logic to a relational interpretation, but instead of second-order framing, address abstract predicates. Their goal is to give a relational interpretation of proofs. They uncover and solve a surprising problem: due to the nature of entailment in separation logic, not all uses of the rule of consequence lift to relations. Our logic does not directly lift proofs but does lift judgments from unary to relational (the rEmb and rLocEq rules). In general, most works on representation independence, including work on encapsulation of mutable objects, are essentially semantic developments [7, 10]; general categorical models of Reynolds’ relational parametricity [84], which validate his abstraction theorem and identity extension lemma have been developed and are under active study by Johann et al. [92].

The state of the art for data abstraction in separation logics is abstract predicates, which are satisfactory in many specs where some abstraction of ADT state is of interest to clients, but less attractive for composing libraries such as runtime resource management with no client-relevant state. Such logics have been implemented in interactive provers [29, 53, 71]. These are unary logics with concurrency; they do not feature second-order framing but they have been used to verify challenging concurrent programs. As shown by the recent extension of VST with Verified Software Units [28], higher order logics with impredicative quantification facilitate expressive interface specifications for modular reasoning about heap-based programs.

ReLoC [44], based on Iris [53], is a relational logic for conditional contextual refinement of higher order concurrent programs. Iris and the works in the preceding paragraph do support hiding in the sense of abstraction: through existential quantification and abstract predicates, and in Iris through the invariant-box modality and the associated “masks.” With respect to our context and goals, we find such machinery to be overkill. Like O’Hearn et al. [77], we only need invariants in the sense of conditions that hold when control enters or exits the module—not conditions that hold at every step. There is a considerable gap between this work and the properties/techniques for which automation has been developed; moreover their step-indexed semantics does not support termination reasoning or transitive composition of relations (which needs relative termination [50]); our logic is easily adapted to both.

Maillard et al. [65] provide a general framework for relational program logics that can be instantiated for different computational effects represented by monads. The paper does not address encapsulation, except insofar as the system is based on dependent-type theory.

Lemma 5.2 (Subtraction) \({ {rlocs}}(\sigma , \varepsilon \backslash \eta) = { {rlocs}}(\sigma , \varepsilon) \backslash { {rlocs}}(\sigma ,\eta)\)

and the same for \({ {wlocs}}\) .

Lemma 5.6 Suppose \(\sigma \stackrel{\pi }{\approx }\sigma ^{\prime }\) . Then \(\sigma (F) \stackrel{\pi }{\sim } \sigma ^{\prime }(F)\) , and \(\sigma \models P\) iff \(\sigma ^{\prime }\models P\) .

The definition of r-respect is formulated (in Definition 5.10) in a way to make evident that client steps are independent from locations within the boundary. But r-respect can be simplified, as follows, when used in conjunction with w-respects.

The following notion is used to streamline the statement of some technical results. It is used with states \(\sigma ,\tau ,\tau ^{\prime },\upsilon ,\upsilon ^{\prime }\) , where \(\sigma\) is an initial state from which \(\tau\) and then later \(\upsilon\) is reached, and in a parallel execution \(\tau ^{\prime }\) reaches \(\upsilon ^{\prime }\) . Moreover, \(\delta\) is a dynamic boundary. We write \(\delta ^\oplus\) to abbreviate \(\delta ,\mathsf {rd}\,\mathsf {alloc}\) .

Like Definition 5.4, this definition is left-skewed, both because \(\varepsilon\) is interpreted in the left state \(\sigma\) and because the fresh and written locations are determined by the left transition \(\sigma\) to \(\tau\) . This is tamed in case \(\varepsilon\) has framed reads (Lemma A.1).

Allowed dependence gives an alternate way to express part of the Encap condition in Definition 5.10. For a step \(\langle B,\: \tau ,\: \mu \rangle \mathrel {\overset{{\varphi }}{ {{\longmapsto }}}} \langle D,\: \upsilon ,\: \nu \rangle\) that r-respects \(\delta\) for \((\varphi ,\varepsilon ,\sigma)\) and \({ {Active}}(B)\) is not a call, and alternate step (24), the condition implies \(\tau ,\tau ^{\prime }\overset{\pi }{\mathord {\Rightarrow }}\upsilon ,\upsilon ^{\prime } \models ^{\sigma }_{\delta } \varepsilon\) in the notation of Definition A.2.

A critical but non-obvious consequence of framed reads is that for a pair of states \(\sigma ,\sigma ^{\prime }\) that are in ‘symmetric’ agreement and transition to a pair \(\tau ,\tau ^{\prime }\) forming an allowed dependence, the transitions preserve agreement on any set of locations whatsoever. The formal statement is somewhat intricate; it generalizes RLIII Lemma 6.12.

Proof. From Definition 5.3 and Equation (35), we know that \(\rho\) and \(\rho ^{\prime }\) are total on \({ {freshL}}(\tau ,\upsilon)\backslash { {rlocs}}(\upsilon ,\delta)\) and \({ {freshL}}(\tau ^{\prime },\upsilon ^{\prime })\backslash { {rlocs}}(\upsilon ^{\prime },\delta),\) respectively. Since \(\rho\) and \(\rho ^{\prime }\) are bijections, from Equation (36), we have equal cardinalities: \(|{ {freshL}}(\tau ,\upsilon)\backslash { {rlocs}}(\upsilon ,\delta)| = |{ {freshL}}(\tau ^{\prime },\upsilon ^{\prime })\backslash { {rlocs}}(\upsilon ^{\prime },\delta)|\) . So, we get \(\rho ({ {freshL}}(\tau ,\upsilon)\backslash { {rlocs}}(\upsilon ,\delta)) ={ {freshL}}(\tau ^{\prime },\upsilon ^{\prime })\backslash { {rlocs}}(\upsilon ^{\prime },\delta)\) . Now from Equation (35) using the symmetry lemma Equation (22) for \({ {Lagree}}\) , we getSo, we have \({ {Lagree}}(\upsilon ^{\prime },\upsilon ,\rho ^{-1},{ {freshL}}(\tau ^{\prime },\upsilon ^{\prime })\backslash { {rlocs}}(\upsilon ^{\prime },\delta))\) . However, we have \({ {wrttn}}(\tau ^{\prime },\upsilon ^{\prime })\subseteq { {locations}}(\tau ^{\prime })\) , and we have \(\rho ^{\prime }|_{{ {locations}}(\tau ^{\prime })}=\pi ^{-1}|_{{ {locations}}(\tau ^{\prime })}=\rho ^{-1}|_{{ {locations}}(\tau ^{\prime })}\) , using vertical bar for domain restriction. So, from Equation (35), we getwhich we can write as \({ {Lagree}}(\upsilon ^{\prime },\upsilon ,\rho ^{-1},{ {wrttn}}(\tau ^{\prime },\upsilon ^{\prime })\backslash { {rlocs}}(\upsilon ^{\prime },\delta ^\oplus))\) . Thus, we get