2.1 Interaction trees and monadic interpreters

Monadic interpreters have grown to be an attractive way to mechanize the semantics of a wide class of computational systems in dependent typed theory, such as the one found in many proof assistants, for which the host language is purely functional and total. In the Rocq ecosystem, interaction trees (Xia et al., Reference Xia, Zakowski, He, Hur, Malecha, Pierce and Zdancewic2019) provide a rich library for building and reasoning about such monadic interpreters. By building upon the free(r) monad (Kiselyov & Ishii, Reference Kiselyov and Ishii2015; Letan et al., Reference Letan, Régis-Gianas, Chifflier and Hiet2018), one can both design highly reusable components, as well as define modular models of programming languages more amenable to evolution. By modeling recursion coinductively, in the style of Capretta’s delay monad (Capretta, Reference Capretta2005; Altenkirch et al., Reference Altenkirch, Danielsson and Kraus2017), such interpreters can model non-total languages while retaining the ability to extract correct-by-construction, executable, reference interpreters. By generically lifting monadic implementations of effects into a monad homomorphism, complex interpreters can be built by stages, starting from an initial structure where all effects are free and incrementally introducing their implementation. Working in a proof assistant, these structures are well suited for reasoning about program equivalence and program refinement: each monadic structure comes with its own notion of refinement, and the layered infrastructure gives rise to increasingly richer equivalences (Yoon et al., Reference Yoon, Zakowski and Zdancewic2022), starting from the free monad, which comes with no associated algebra.

Interaction trees are coinductive data structures for representing (potentially divergent) computations that interact with an external environment through visible events. A definition of the ITree datatype is shown in Figure 1. The datatype takes as its first parameter a signature—described as a family of types —that specifies the set of interactions the computation may have with the environment. The constructor builds a node in the tree representing such an interaction, followed by a continuation indexed by the return type of the event. The second parameter, , is the result type, the type of values that the entire computation may return, if it halts. The constructor builds such a pure computation, represented as a leaf. Finally, the Step constructor models a non-observable step of computation, allowing the representation of silently diverging computations; it is also used for guarding corecursive definitions.Footnote ¹

Fig. 1. Interaction trees: definition.

We illustrate the ITrees approach by defining the semantics for a simple imperative programming language, imp. The language contains a skip construct, assignments, sequential composition, and loops—we assume a simple language of expressions, e.

Consider the following imp programs:

In the style of Xia et al. (Reference Xia, Zakowski, He, Hur, Malecha, Pierce and Zdancewic2019), one builds a semantics in two stages. First, commands are represented as monadic computations of type : commands do not return values, so the return type of the computation is the trivial type; interactions with the memory are (at first) left uninterpreted, as indicated by the event signature . This signature encodes two operations: yields a value, while yields only the acknowledgment that the operation took place, which we encode again using .

Indexing by the type in the continuation of events gives rise to non-unary branches in the tree representing these programs. For instance, the programs $p_1,p_2,p_3$ are, respectively, modeled at this stage by the trees shown in Figure 2. These diagrams omit the and constructors, as their presence is clear from the picture. For example, the second tree $p_2$ would be written as

Fig. 2. Example ITrees denoting the imp programs $p_1$ , $p_2$ , and $p_3$ .

The Step nodes in the first tree are the guards from Capretta’s monad: because the computation diverges silently, it is modeled as an infinite sequence of such guards. The equivalence used for computations in the ITree monad is a weak bisimulation, dubbed equivalence up-to taus (eutt), which ignores finite sequences of Step nodes. It is termination-sensitive: the silently diverging computation is not equivalent to any other ITree.

With ITrees, no assumption about the semantics of the uninterpreted memory events is made. Although one would expect $p_2$ and $p_3$ to be equivalent, their trees are not eutt. This missing algebraic equivalence is concretely recovered at the second stage of modeling: imp programs are given a semantics by interpreting the trees into the state monad, by handling the events. This yields computations in , or, unfolding the definition of where is the “empty” event signature. More precisely, an combinator applies the handler $h_{mem}$ to the and nodes of the trees, implementing their semantics in terms of the state monad. For $p_2$ and $p_3$ , assuming an initial state , the computations become:Footnote ²

One can show that $\texttt{m}\{x\gets0\}\{x\gets \texttt{m}(y)\}$ and $\texttt{m}\{x\gets \texttt{m}(y)\}$ are extensionally equal, and hence $p_2$ and $p_3$ are eutt after interpretation.

2.2 Nondeterminism

While the story above is clean and satisfying for stateful effects, nondeterminism is much more challenging. Suppose we extend imp with a branching operator br p or q whose semantics is to nondeterministically pick a branch to execute. This new feature is modeled very naturally using a boolean-indexed flip event, creating a binary branch in the tree. The new event signature, a sample use, and the corresponding tree are shown in Figure 3.

Fig. 3. A boolean event, an example of its use, and the corresponding CTree.

Naturally, as with memory events, flip does not come with its expected algebra: associativity, commutativity, and idempotence. We therefore seek to interpret flip into an executable monad in which we recover these necessary equations, and furthermore combine them with the state algebra in order to establish program equivalences such as

CTrees will form a suitable monad for modeling such nondeterministic effects. The core idea is to build an ITree-like coinductive data structure, with an additional kind of node to represent nondeterminism. The resulting definitions are very expressive. As foreseen, they form a proper monad, validating all monadic laws up-to coinductive structure equality, they allow us to establish desired imp equations such as , but they also scale to model ccs and cooperative multithreading.

Before getting to that, and to better motivate our definitions, let us further extend our toy language with a block construction that cannot reduce, and a print instruction that simply prints a dot. We will refer to this language as ImpBr.

Consider the program . Depending on the intended operational semantics associated with br, this program can have one of two behaviors: (1) either to always reactively print an infinite chain of dots or (2) to become nondeterministically either similarly reactive or completely unresponsive. The former corresponds in the literature to the same kind of choice that exists in ccs (Milner, Reference Milner1989). The latter can be though of as a form of internal choice, found natively as well in CSP, and encoded in ccs by guarding processes by an internal $\tau$ step. We shall emphasize this analogy in Section 4 when providing a model for ccs.

When working with (small-step) operational semantics, the distinction between these behaviors is immediately apparent in the reduction rule for br (we only show rules for the left branch here).

BrInternal specifies that br may simply reduce to the left branch, while BrDelayed specifies that br can reduce to any state reachable from the left branch. From an observational perspective, the former situation describes a system where, although we do not observe which branch has been taken, we do observe that a branch has been taken. On the contrary, the latter only progresses if one of the branches can progress, we thus directly observe the subsequent evolution of the chosen branch, but not the branching itself.

In order to design the right monadic structure allowing for enough flexibility to model either behavior, we think of imp programs as labeled transition systems. From this perspective, the imp program p may correspond to three distinct LTSs depending on the intended semantics, as shown in Figure 4.

Fig. 4. Three possible semantics for the program p, from an LTS perspective.

Figure 4(a) describes the case where picking a branch is an unknown external event, hence where taking a specific branch is an observable action with a dedicated label: this situation is naturally modeled by a node in the style of ITrees, that is

Figure 4(b) corresponds to BrInternal: both the stuck and the reactive states are reachable, but we do not observe the label of the transition. This transition exactly corresponds to the internal $\tau$ step of process algebra. This situation couldFootnote ³ be captured by introducing a new kind of node in our data structure, a ${Br_S}$ branch, that maps in our bisimulations defined in Section 5 to a nondeterministic internal step. For this semantics, we thus have Footnote ⁴

Figure 4(c) corresponds to BrDelayed, but raises the question: how do we build such a behavior? It could be the responsibility of the model, i.e., the function mapping imp’s syntax to the semantic domain, CTrees, to explicitly compute this LTS. Here, ${{[\![ p ]\!]}}$ would be an infinite sequence of , print nodes, containing no other node. But recall we seek to compute our models, typically by recursion on the syntax. But to build this LTS directly, the model for br p or q would then need to introspect the models for ${[\![ p ]\!]}$ and ${[\![ q ]\!]}$ to decide whether they can take a step, and hence whether it should introduce a branching node. In general, statically determining whether a given program is semantically equivalent to block is intractable: consider a computation that checks the convergence of the Collatz sequence on its input before performing an observable event for instance. The introspection required to directly compute this LTS is therefore hard (or impossible) to implement in general.

We thus extend CTrees with a third category of nodes, a Br node, which does not directly correspond to states of an LTS. Instead, Br nodes aggregate sub-trees such that the (inductively reachable) Br children of a Br node are “merged” in the LTS view of the CTree. This design choice means that, for the BrDelayed semantics, the model is again trivial to define: , but the definition of bisimilarity for CTrees ensures that the behavior of ${{[\![ p ]\!]}}$ is precisely the LTS in Figure 4(c).

3.1 Core definitions

We are now ready to define our core datatype, displayed in the upper part of Figure 5. The definition remains close to a coinductive implementation of the free monad, but hard-codes support for an additional effect: unobservable branching. The CTree datatype, much like an ITree, is parameterized by a signature of (external) events encoded as a family of types and a return type . Contrary to ITree, it is parameterized by a second family of types characterizing the allowed arities of branching. This parameter is an improvement in expressiveness over the first iteration of CTrees (Chappe et al., Reference Chappe, He, Henrio, Zakowski and Zdancewic2023), which only supported unlabeled finite choice; It will be useful in Section 7.2. We discuss in depth the differences between both implementations in Section 11.

Fig. 5. CTree structure definition .

CTrees are coinductive treesFootnote ⁵ with four main kinds of nodes: pure computations (), external events (), unary node with an implicitly associated $\tau$ step (Step), and delayed branching (Br). Nullary ( constructor) and unary (Guard constructor) delayed branching could be expressed as special cases of Br over an appropriate interface , but we provide specific constructors for them for convenience given their central role. The continuation following external events is indexed by the return type specified by the emitted event. Similarly, the continuation following delayed branching is indexed by the return type specified by the emitted branch. When using finite branching in examples, we assume a suitable branching interface that includes such finite indexed types, and we abusively write, for instance, for a computation branching on a finite type with two inhabitants, and $B_2$ the corresponding signature it draws from, rather than explicitly spelling out an event with a boolean signature and the continuation that branches on the boolean index: . We write nodes as “ ${\emptyset}$ ” in equations.

The remainder of Figure 5 displays (superficially simplified) definitions of the core combinators. In particular, step branching that materializes internal choice, denoted ${Br_S}$ and informally introduced in Section 2.2, is defined as the composition of Br and Step. The minimal computations respectively triggering an event , delaying a branch, or generating observable branching are defined as , and .

As expected, forms a monad for any interfaces and : the combinator simply lazily crawls the potentially infinite first tree and passes the value stored in any reachable leaf to the continuation. The combinator is central to encoding looping and recursive features: it takes as argument a body, , intended to be iterated, and is defined such that the computation returns either a new index over which to continue iterating or a final value; ties the recursive knot. Its definition is analogous to the one for ITrees, except that we need to ask ourselves how to guard the : if is a constant, pure, computation, unguarded corecursion would be ill-defined. ITrees insert a Step node between iterations for this purpose, treated weakly by the eutt equivalence built on the structure. Here, we instead use the Guard constructor, encoding a unary non-observable branch. A Step node would also be a valid choice, with different resulting semantics, this option will be further discussed in Section 7.4.

Convenience in building models comes at a cost: many CTrees represent the same LTS. Figure 6 illustrates this phenomenon by defining several CTrees implementing the stuck LTS and the silently spinning one. Indeed, the constructor is intended to canonically represent the stuck process. However, it can be mimicked via nullary branching: asks the environment a question without answer, while internally chooses among none. More convoluted, the stagnate and stagnate_nary trees are infinitely deep structures made of delayed branches; they yet never find in their structure a transition to take. In contrast, the and processes exhibit a different behavior, depicted in the LTS: they generate infinite traces of $\tau$ s.

Fig. 6. Concrete representations of stuck and spinning LTSs, where is a finite type with elements.

Section 5 will introduce the necessary notions of equivalence on CTrees, bisimilarity in particular, to formally express and prove the semantic equivalence between these various representations of stuck processes.

We define a representation by recursion on the syntax: ImpBr programs are computations that may diverge, draw from binary choices, and emit read and write events to the memory, or printing signals. Assuming that we have already defined similarly the representation for expressions :

Similarly to ITrees, is used for emitting events, monadic binds and returns for sequences and terminated programs, and the combinator is used to encode a suitable looping combinator.Footnote ⁶ Finally, the two unusual constructs for an Imp language, branches and stuck programs, directly map to two new primitive concepts in CTrees.

3.2 Interpretation

ITrees support interpretation: provided a handler implementing a signature of events into a suitable monad , the combinator provides an implementation of any computation into .Footnote ⁷ The only restriction imposed on the target monad is that it must support its own combinator, i.e., be iterative, so that divergence, modeled coinductively in the tree, can also be internalized in . For this implementation to be sensible and amenable to verification in practice, one must, however, check an additional property: should form a monad morphism—in particular, it should map eutt ITrees to equivalent monadic computations in .

Unsurprisingly, given their structure, CTrees enjoy their own combinator. Its definition, provided in Figure 7, is very close to its ITree counterpart. The interpreter relies on the target monad’s own to chain the implementations of the external events in the process. But additionally to being iterative, i.e., being able to internalize divergence, the target monad must also be able to internalize nondeterminism by providing a stuck state (), an observable tick (), and a nondeterministic branching (). CTrees and stateful CTrees are both valid target monads, we provide straightforward instances for them.

Fig. 7. Interpreter for CTrees (class constraints omitted) .

We shall see that handlers must satisfy some conditions for the induced interpretation to be well-behaved: we defer this discussion to Section 7 once all the necessary tools have been introduced.

Read and write events are implemented concretely over a domain of maps , while printing events are retriggered, and hence left uninterpreted. The final model is therefore $[\![ c ]\!] \triangleq$ .

3.3 A hint of introspection: Heads of computations

Br nodes prevent the need for introspection over trees when modeling something as generic as a delayed branching construct such as the one specified by BrDelayed. However, introspection becomes necessary to build a tree that depends on the reachable external actions of the sub-trees (i.e., the non-Br nodes immediately reachable from the root after a series of Br nodes). This is the case for many parallel operators, including the one of ccs that we model in Section 4. The set of reachable external actions is not computable in general, as we may have to first know if the computation to the left of a sequence terminates before knowing if the events contained in the continuation are reachable. We are, however, in luck, as we have at hand a semantic domain able to represent potentially divergent computations: CTrees themselves!

The combinator, described in Figure 8, builds a pure, potentially diverging computation only made of delayed choices, and whose leaves contain all reachable subtrees starting with an observable node. These “immediately” observable trees are captured in an datatype, which is used as the return type of the built computation. The combinator simply crawls the tree by reconstructing all delayed branches, until it reaches a subtree with any other node at its root; it then returns that subtree as the corresponding . The resulting tree could be more precisely typed at the empty event interface if need be.

Fig. 8. Lazily computing the set of reachable observable nodes .

As such, provides a constructive computation of the set of visible actions a CTree computation can draw. We demonstrate in the next section how it is used to build a model for ccs, but illustrate it first on an artificial example.

Example: ImpBr. Consider a program that may have three behaviors: printing, writing in memory then printing, or looping. Figure 9 represents on the left the LTS of : the looping behavior is not observable, as its model is stagnate—we revisit formally this representation in terms of LTS in Section 5. On the right, it shows the CTree : notice that detecting that stagnate will exhibit no observable behavior is not computable in general, the head therefore also exhibits a stagnating branch. The two other branches return respectively the printing and writing events. The dots in the Ret nodes stand for the continuations. In particular, the continuation for the wr x 1 event contains the subsequent print event.

Fig. 9. The LTS for program p (on the left) and its head CTree (on the right).

4.1 Syntax and operational semantics

The syntax and operational semantics of ccs are shown in Figure 10. The language assumes a set of names, or communication channels, ranged over by ${{\mathit{c}}}$ . For any name ${{\mathit{c}}},$ there is a co-name $\bar {{\mathit{c}}}$ satisfying $\bar {\bar {{\mathit{c}}}} = {{\mathit{c}}}$ . An action is represented by a label l; it is either a communication label ${{\mathit{c}}}$ or $\bar{{\mathit{c}}}$ , representing the sending/reception of a message on a channel, or the reserved action $\tau$ , which represents an internal action.

Fig. 10. Syntax for ccs and its operational semantics .

The standard operational semantics, shown in the figure, is expressed as a labeled transition system, where states are terms P and labels are actions l. The ccs operators are the following: 0 is the process with no behavior. A prefix process ${l . P}$ emits an action l and then becomes the process P. The choice operator ${{\mathit{P}}} + {{\mathit{Q}}}$ behaves either like the process ${{\mathit{P}}},$ or like the process ${{\mathit{Q}}}$ , in the same fashion as the BrDelayed semantics for br in Section 2.2. The parallel composition of two processes ${{\mathit{P}}}\parallel {{\mathit{Q}}}$ interleaves the behavior of the two processes, while allowing the two processes to communicate. If the process ${{\mathit{P}}}$ emits a name ${{\mathit{c}}}$ and the process ${{\mathit{Q}}}$ emits its co-name $\bar{{\mathit{c}}}$ , then the two processes can progress simultaneously and the parallel composition emits an internal action $\tau$ . Channel restriction $\nu {{\mathit{c}}} . {{\mathit{P}}}$ prevents the process ${{\mathit{P}}}$ from emitting an action ${{\mathit{c}}}$ or $\bar{{\mathit{c}}}$ : the operational rule states that any emission of another action is allowed. Finally the replicated process $! {{\mathit{P}}}$ behaves as an unbounded replication of the process ${{\mathit{P}}}$ . Operationally, $! {{\mathit{P}}}$ has the behavior of $P\parallel {! {{\mathit{P}}}}$ .

4.2 Model

We define a denotational model for ccs using as domain, written ${{\texttt{ccs}}}^{\#}$ in the following. As witnessed by this type, processes do not return any value, but may emit actions modeled as external events expecting for answer: . Because the semantics of CCS limits the possible different outcomes at each program point, its model can exhibit only binary, ternary, or quaternary branches, captured in . Specifically, a ternary branch is used to express the behaviour of the parallel operator where either the left sub-term or the right sub-term progresses, or a synchronisation between the two sub-terms happens. Quaternary branches are required for the semantics of the replication operator—we detail its model below. Naturally, nested operators will lead to nested branches.

Figure 11 defines the semantic operators associated with each construct of the language. They are written as over-lined versions of their syntactic counterparts, and defined over ${{\texttt{ccs}}}^{\#}$ .

Fig. 11. Denotational model for ccs using $\texttt{ccs}^{\#}$ as a domain .

The empty process is modeled as a stuck tree—we cannot observe it. Actions are directly defined as visible events, and thus the prefix triggers the action, and continues with the remaining of the process. As discussed in Section 2.2, the delayed branching node fits exactly with the semantics of the choice operator in ccs, only progressing if one of the composed terms progresses. Restriction raises a minor issue: the compositional definition implies that the CTree for the restricted term has already been produced when we encounter the restriction and, a priori, that tree might contain visible actions on the name being restricted. We enforce scoping by replacing those actions by a stuck tree, ${\emptyset}$ , effectively cutting these branches. This is done using the operator from CTrees, with $\texttt{h}_{\texttt{new}}$ , a handler that does the substitution.

Parallel composition is more intricate, as the operator requires significant introspection of the composed terms. The traditional operational semantics of ccs is not explicitly constructive: each of the three reduction rules depends on the existence of specific transitions in the sub-processes. We perform this necessary introspection, in a constructive way, defining the tree as an explicit cofixpoint, and using the head operator introduced in Section 3.3. While the operation head p precisely captures the desired set of actions that p may perform, computing this set could, in general, silently diverge. We therefore cannot bluntly initiate the computation by sequencing the heads of p and q, as divergence in the former may render inaccessible valid transitions in the latter.Footnote ⁸ Instead, we initiate the computation with a ternary delayed choice: the left (resp. middle) branch captures the behaviors starting with an interaction by p (resp. q), while the right branch captures the behaviors starting with a synchronisation between p and q. Essentially, the tree nondeterministically explores the set of applicable instances of the three operational rules for parallel composition. In particular, if the operational rule to step in the left (resp. right) process is non-applicable, the left (resp. middle) branch of the resulting tree silently diverges. The right branch silently diverges if neither process can step, but, in general, it also contains branches considering the interaction of incompatible actions; we cut these branches by inserting ${\emptyset}$ . In all cases, the operator continues corecursively, having progressed in either or both processes. Figure 12 shows the CTree resulting from $p \overline{\parallel} q$ .

Fig. 12. Depiction of the tree resulting from $p \overline{\parallel} q$ .

The last operator to consider is the replication $\overline{!} $ . In theory, it could be expressed in terms of parallel composition directly, as the cofix . Unfortunately, although it is sound, defining the $\overline{!} $ operator in this way is too involved for Rocq’s syntactic criterion on cofixes to recognize that the corecursive call is guarded under $ \overline{\parallel} $ . To circumvent this difficulty, we use an auxiliary operator, defined in Figure 13, and define the replication operator as $\overline{!} p \triangleq p\overline{\parallel!} p$ . The intuition behind this operator, $p\overline{\parallel!} q$ , is to capture the parallel composition of a process p with a replicated process $! q$ . By extending the domain of the function, we manage to recover a syntactically guarded cofix, therefore accepted by Rocq. The operator $p\overline{\parallel!} q$ nondeterministically explores the four kinds of interactions that such a process could exhibit: a step in p; the creation of a copy of q performing a step to q’, before being composed in parallel with p; the creation of a copy of q synchronizing with p; or the emission of two copies of q synchronizing one with another..

Fig. 13. Definition of the auxiliary operator $p\overline{\parallel!} $ .

Finally, we define the model ${{[\![ \cdot ]\!]}}: {{\texttt{ccs}}} \rightarrow {{{\texttt{ccs}}}^{\#}}$ by recursion on the syntax.

5.1 Coinductive equality for CTree

Rocq’s equality, , is not a good fit to express the structural equality of coinductive structures—even the eta-law for a coinductive data structure does not hold up-to . We therefore define, as is standard, a structural equalityFootnote ¹⁰ by coinduction (written ${\cong}$ in infix). The endofunction simply matches head constructors and behaves extensionally on continuations.

The equ relation raises no surprises: it is an equivalence relation, and is adequate to prove all eta-laws—for the CTree structure itself and for the cofixes we manipulate. Similarly, the usual monadic laws are established with respect to equ.

Of course, formal equational reasoning with respect to an equivalence relation other than comes at the usual cost: all constructions introduced over CTrees must be proved to respect equ (in Rocq parlance, they must be ), allowing us to work painlessly with setoid-based rewriting.Footnote ¹¹

Finally, we establish some enhanced coinduction principles for equ.

With these lemmas, one has the ability, in the middle of a proof by coinduction aiming to establish that two trees are , to invoke reflexivity, symmetry, transitivity, congruence for bind, and to rewrite previously established equations.

While ${{\texttt{equ}}}$ , as a structural equivalence, is very comfortable to work with, it naturally is much too stringent. To reason semantically about CTrees, we need a relation that remains termination sensitive, but allows for mismatch in the amount of branching nodes, that still imposes a tight correspondence over external events, but relaxes its requirement for nondeterministically branching nodes. We achieve this by drawing from standard approaches developed for process calculi.

5.2 Looking at CTrees under the lens of labeled transition systems

To build a notion of bisimilarity between CTree computations, we associate a labeled transition system to a CTree, as defined in Figure 15. This LTS exhibits three kinds of labels: a Footnote ¹² witnesses a stepping branch, an obs e x observes the encountered event together with the answer from the environment considered, and a val v is emitted when returning a value. Note that there is a significant mismatch between the structure of the tree and the induced LTS: each state of the LTS corresponds, in the CTree, to a node that is not immediately preceded by a Br node. Accordingly, the definition of the transition relation between states inductively iterates over delayed branches. On the contrary, stepping branches and visible nodes map immediately to a set of transitions, one for each outgoing edge; finally, a return node generates a single val transition, moving onto a stuck state, encoded as the ${\emptyset}$ constructor. These rules formalize the intuition we gave in Section 2.2 and that allowed us to derive the LTSs of Figure 4 from the corresponding ImpBr terms.

Fig. 15. Inductive characterization of the LTS induced by a CTree .

Defining the property of a tree to be stuck, that is: $t\not\rightarrow \ \triangleq \ \forall l u, \lnot (t \xrightarrow{l} u)$ , we can make the depictions of stuck processes from Figure 6 precise: ${\emptyset}$ itself and nullary nodes are stuck by construction, since stepping would require a branch, while stagnate_nary and stagnate are proven to be stuck by induction on the transition relation . It follows that ${\emptyset}$ , stagnate_nary and stagnate are semantically undistinguishable.

The stepping relation interacts slightly awkwardly with : indeed, although a unit for , the construct is not inert from the perspective of the LTS: it has one outgoing transition labeled with the return value. Non val transitions can therefore be propagated below the left-hand side of a , while a val transition in the prefix does not entail the existence of a transition in the . Figure 16 describes lemmas capturing this intuition, by distinguishing cases of a val v transition (trans_bind_r for backward reasoning and the second case of the conclusion of trans_bind_inv for forward reasoning about ) or another kind of transition (trans_bind_l and the first case of trans_bind_inv).

Fig. 16. Lemmas for transitions under bind .

5.3 Bisimilarity

Having settled on the data structure and its induced LTS, we are back on a well-traveled road: strong bisimilarity (referred simply as bisimilarity in the following) is defined in a completely standard way over the LTS view of CTrees.

and conversely

The bisimulation game is represented visually in Figure 17 . Solid lines represent universal hypotheses and dashed ones represent existential conclusions. Bisimilarity, written $t \sim u$ , is defined as the greatest fixpoint of sb: .

Fig. 17. The bisimulation game $\sim_\mathcal{R}$ .

All the traditional tools surrounding bisimilarity can be transferred to our setup. The rest of this subsection shows the proof rules and up-to principles that are proved valid for CTree bisimilarity.

5.3.1 Core equational theory

Bisimilarity forms an equivalence relation satisfying a collection of primitive laws for CTrees summed up in Figure 18. We use simple inference rules to represent an implication from the premises to the conclusion and double-lined rules to represent equivalences. Each rule is proved as a lemma with respect to the definitions above.

Fig. 18. Elementary equational theory for CTrees .

The first four rules recover some structural reasoning on the syntax of the trees from its semantic interpretation. These rules recover reasoning principles close to what eutt provides by construction for ITrees: leaves are bisimilar if they are equal, computations performing the same external interaction must remain point-wise bisimilar, and unary steps can be matched against one another. Delayed branches, potentially of distinct arity, can be matched one against another if both domains of indexes can be injected into the other to reestablish bisimilarity. This is only an implication and not an equivalence since the points of the continuation structurally immediately accessible do not correspond to accessible states in the LTS. By contrast, this same condition is necessary and sufficient for stepping branches, as their Step nodes induce additional $\tau$ transitions, thus new states in the LTS. Finally, bisimilarity is a congruence for .

Unlike ITrees, two CTrees can be strongly bisimilar despite different head constructors. The simplest example is that sbisim can ignore (finite numbers of) Guard nodes, making e.g. bisimilar to . Another example is that stuck processes behave as a unit for delayed branching nodes. The fact that Br and Guard nodes are treated weakly by strong bisimilarity can be slightly disconcerting, but our definition of strong bisimilarity is standard. Rather, this mismatch is due to the fact that we completely collapse Br nodes in the LTSs we build from CTrees. This choice has far-reaching consequences that Section 9 will further discuss.

We obtain the equational theory that we expect for nondeterministic effects. Delayed branching is associative, commutative, idempotent, and can be merged into delayed branching nodes of larger arity w.r.t. sbisim.Footnote ¹³ By contrast, stepping branches are only commutative, and almost idempotent, provided we introduce an additional Step. This Step cannot be ignored w.r.t. $\sim{}$ , but one can move to weak bisimilarity to this end: we discuss this setup in Section 10.3.

Finally, two stagnating processes are always bisimilar (neither process can step) while two stepping spins are bisimilar if and only if they are both nullary (neither one can step), or both non-nullary.

We omit the formal equations here, but we additionally prove that the combinator deserves its name: the Kleisli category of the monad is iterative w.r.t. strong bisimulation . Concretely, we prove that the four equations described in Section 4 of Xia et al. (Reference Xia, Zakowski, He, Hur, Malecha, Pierce and Zdancewic2019) hold true. The fact that they hold w.r.t. strong bisimulation is a direct consequence of the design choice taken in our definition of : recursion is guarded by a Guard. One could provide an alternate iterator guarding recursion by a Step and recover the iterative laws w.r.t. weak bisimulation, but we have not proved it and leave it as future work. We expand further on a handful of delicate points related to weak bisimilarity in Section 10.3.

Example: ImpBr. Naturally, this equational theory gets trivially lifted at the language level for ImpBr. More specifically, the equational theory over CTrees is lifted to the syntax through . Furthermore, anticipating on Section 7, the theory will be transported for free by interpretation, and hence hold on the full model $[\![ \cdot ]\!]$ as well, in which we can additionally reason about state, and in particular establish the equation $p_3 \equiv {{\texttt{br}}}\, p_2\, {{\texttt{or}}}\, p_3$ suggested in Section 2.2.

The acute reader may notice that in exchange for being able to work with strong bisimulation, we have mapped the silently looping program to stagnate, hence identifying it with stuck processes. Indeed, both of these programs have the same observable behavior (no observable transition). For an alternate model observing recursion, one would need to investigate the use of the alternate iterator mentioned above and work with weak bisimilarity.

5.3.2 Proof system for bisimulation proofs

As is usual, the laws in Figure 18, enriched with domain-specific equations, allow for deriving further equations purely equationally. But to ease the proof of these primitive laws, as well as new nontrivial equations requiring explicit bisimulation proofs, we provide proof rules that are valid during bisimulation proofs, derived from valid up-to principles.

We recall that given a bisimulation candidate $\mathcal{R}$ , we write for , i.e., the proof goal in which $\mathcal{R}$ is the bisimulation candidate, and this coinduction hypothesis is not yet accessible. We depict the main rules we use in Figure 19. From the standpoint of the proof scientist, these rules notably avoid the exponential explosion in the number of subgoals that would arise by playing each side the bisimulation game separately: for all CTree constructors, there is a reasoning rule with no binary split at each level of play. These rules essentially match up counterpart CTree constructors at the level of bisimilarity, but additionally make a distinction between two cases. In the first case, applying the rule soundly acts as playing the game. i.e., the premises refer to $\mathcal{R}$ , allowing to conclude using the coinduction hypothesis. In the second case, the premises still refer to $\sim_\mathcal{R}$ and the proof rule strip off delayed branches from the structure of our trees. In this second case, on either side of the bisimulation, the rule does not entail any step in the corresponding LTSs, but rather corresponds to recursive calls to its inductive constructor.

Fig. 19. Proof rules for coinductive proofs of sbisim .

Furthermore, we provide a rich set of valid up-to principles:

Lemma 3 (Enhanced coinduction for sbisim ). The functions , , , , and provide valid up-to principles for ${{{{\texttt{sbisim}}}}}$ .

In particular, the rewriting principle can be used with the equation ${{\texttt{Guard}}} \, t\sim t$ during bisimulation proofs, allowing for asymmetric stripping of guards.

We always strive to provide powerful up-to principles, but from a library user perspective $\sim_\mathcal{R}$ is still harder to work with than $\sim$ . All the results that are valid for $\sim_\mathcal{R}$ are also valid for $\sim$ , it is thus desirable to reason as much as possible at the $\sim$ level. Proofs involving, e.g., loops are by nature coinductive, but this layer of complexity can sometimes be abstracted away. Section 7 provides a few high-level proof principles for that purpose, in particular around the combinator.

We omit the details, but our library additionally provides a characterization of the traces of a CTree, defined as the set of colistsFootnote ¹⁴ of labels induced by the LTS of the tree. Trace-equivalence (written $\equiv_{{{\texttt{tr}}}}$ ) is hence defined as the extensional equality of these sets of traces. With this infrastructure, we prove the standard result that sbisim entails trace-equivalence .

5.4 Similarity

Similarity is a specific, well-studied, notion of refinement for LTSs. In particular, similarity entails behavior inclusion, making it a popular proof tool for verified compilation (a compiled program should be simulated by its corresponding source program), but also when reasoning about scheduling (a scheduler is correct when it shrinks the determinism induced in a process by the set of all valid schedulers).

There exists a variety of subtly distinct variants of similarity. We focus in this section on strong similarity, the relation defined as the greatest fixpoint of the left half-game of bisimulation as depicted on Figure 17.

Similarity, written $t \lesssim u$ , is defined as the greatest fixpoint of ss: .

The coinductive proof rules for simulation are depicted in Figure 20. The rules are similar to those for bisimulation (Figure 19), but more permissive. In particular, a stuck process is simulated by any CTree (ss_stuck). Furthermore, additional asymmetric reasoning principles are available over Br nodes. ss_br_l states that a Br node is simulated by a CTree u if and only if all its branches are simulated by u. Conversely, ss_br_r states that a CTree starting with a Br node simulates a CTree t if one of its branches simulates t. These powerful rules illustrate the semantic particularity of Br nodes: they are collapsed and thus completely invisible in the LTS. The composition of ss_br_l and ss_br_r gives ss_br, which is similar to the sbisim proof rule for Br, with the symmetric condition dropped.

Fig. 20. Rules for coinductive proofs of ssim, with their names in our Rocq library—rules with a double bar are equivalences .

For convenience, the proof rules are lifted to ssim-level, raising equations similar to the ones in Figure 18. We omit the details as the resulting rules can be trivially deduced from the $\lesssim_\mathcal{R}$ ones by replacing occurrences of both $\mathcal{R}$ and $\lesssim_\mathcal{R}$ by $\lesssim$ in Figure 20.

All the up-to principles valid for sbisim are also valid for ssim except of course for the symmetry principle.

5.5 Proof example

Let us pause to illustrate concretely over a minimalist toy example how one can conduct a proof of similarity by enhanced coinduction with our library. We consider here CTrees with a print event for printing a boolean value and binary Br branches.

Example CTrees and represent programs that repeatedly print booleans, with slightly different behaviors. alternates printing and , while each iteration of nondeterministically chooses a boolean and prints it. ’ has the same semantics as , but it is written in a different style: exclusively uses the CTree constructors while ’ uses higher-level and (through the ; ; syntax) operators. In the second case, there is an additional Guard node as Rocq needs a syntactic guard before co-recursive calls. Because of this Guard, and ’ are not coinductively equal, but this has no consequence on the underlying LTS: they are still in strong bisimulation. The LTS underlying and are represented in Figure 21.

Fig. 21. The LTS for (left) and / ’ (right).

It is clear that program simulates program . We establish this fact, $t \lesssim u$ , through the following detailed proof steps, which correspond exactly to the Rocq implementation . We write the current state of the proof goal to the right of the sequent, the coinduction hypothesis to its left, and the proof rule leading us there at the beginning of the line.

The proof proceeds by coinduction: taking the singleton pair (t, u) as the simulation candidate $\mathcal{R}$ ,Footnote ¹⁵ we prove that $\texttt{t} \mathrel\lesssim_{\mathcal{R}} \texttt{u}$ , i.e., the pair (t’, u’) obtained after a simulation step is still in $\mathcal{R}$ . After initializing the coinduction, we unfold one iteration of t and one iteration of u.Footnote ¹⁶ At this point, CTree constructors appear in the goal. In particular, the at the head of the left-hand side should be matched against another in order to progress. This can be achieved by choosing the outcome of the br on the right-hand side using ss_br_r. Then, the matching can be stripped using the ss_vis_id theorem. Notice that the relation in the goal is no longer $\mathrel\lesssim_{\mathcal{R}}$ but $\mathcal{R}$ , as consuming nodes performs a simulation step. But we want to perform one more simulation step to consume the second of the left CTree, so we strengthen the proof goal from $\mathcal{R}$ to $\mathrel\lesssim_{\mathcal{R}}$ again using the ss up-to ss principle through the step tactic. Then, the remaining on the left can be matched using the same method as the first one, finally reducing to the goal $\texttt{t} \mathrel{\mathcal{R}} \texttt{u}$ , which is precisely our coinduction hypothesis, concluding the proof.

This simple example emphasizes that our infrastructure is robust enough to formally conduct, in Rocq, a proof that closely mimics the detailed one we would write on paper.

For a similar pedagogical proof of bisimilarity of u and u’, illustrating the use of bisimulation up-to bisimilarity, we refer the interested reader to our development .

6.1 Equational theory

We provide a first validation of our model by proving that it satisfies the expected equational theory with respect to CTrees’s notion of strong bisimulation, enabling the usual algebraic reasoning advocated for process calculi. In particular, we prove that our definition for the replication is sane in that it validates equationally the expected definition: $\overline{!} p\sim \overline{!} p \overline{\parallel} p$ . We also prove an illustrative collection of expected equations satisfied by our operators :

To facilitate these proofs, we first prove sound up-to principles at the level of ccs for each constructor: strong bisimulation up-to $c\overline{.} [\cdot]$ , $[\cdot] \overline{+} [\cdot]$ , $[\cdot] \overline{\parallel} [\cdot],$ $\overline{!} [\cdot],$ and $\nu c\overline{.} [\cdot]$ are all valid principles, allowing us to rewrite sbisim under semantic contexts during bisimulation proofs. Additionally to these language-level up-to principles, we inherit the ones generically supported by sbisim (Lemma 3).

6.2 Equivalence with the operational strong bisimilarity

In addition to proving that we recover in our semantic domain the expected up-to principles and the right algebra, we furthermore show that the model is sound and complete with respect to strong bisimulation compared to its operational counterpart. We do so by first establishing an asymmetrical bisimulation between ccs and $\texttt{ccs}^{\#}$ , matching operational steps over the syntax to semantic steps in the CTree. We write $\bar l$ for the obvious translation of labels between both LTSs.

A relation $\mathcal{R}: rel({{\texttt{ccs}}},{{{\texttt{ccs}}}^{\#}})$ is a strong bisimulation if and only if, for any label l, ccs term P, and ${{\texttt{ccs}}}^{\#}$ tree q:

and conversely

Figure 22 depicts this bisimulation game graphically.

Fig. 22. The bisimulation game for ccs.

We derive from this result that the operational and semantic strong bisimulations define exactly the same relation over ccs:

This establishes CTrees as a fitting framework for reasoning about channel-based concurrency. We shall illustrate in Section 8 that they are flexible enough to model shared-memory-based concurrency as well.

7.1 Interpretation

Section 3.2 introduced CTree interpretation. With the tools developed in Section 5, we can now turn to theoretical results around the combinator. Perhaps a bit surprisingly, the requirement that defines a monad morphism unearths interesting subtleties. Let us consider the elementary case where the interface is implemented in terms of (possibly pure) uninterpreted computations, that is, when for some . The requirement becomes: But this result does not hold for an arbitrary h : intuitively, our definition for sbisim has implicitly assumed that implementations of external events may eliminate reachable states in the computation’s induced LTS—through pure implementations—but should not be allowed to introduce new ones.

The counter-example in Figure 23, where ${{\texttt{flip}}}$ is the binary event introduced in Section 2.2, fleshes out this intuition. Indeed, the two trees on the left are strongly bisimilar: each of them can emit the label by stepping to either the ${{{{\texttt{Ret}}} \, 0}}$ or ${{{{\texttt{Ret}}}\, 2}}$ node or emit the label ${{\texttt{obs}}}\, {{\texttt{flip}}} \, {{\mathit{true}}}$ by stepping to either the ${{{{\texttt{Ret}}} \, 1}}$ or ${{{{\texttt{Ret}}} \, 3}}$ node. However, they are strongly bisimilar because the induced LTS processes the question to the environment— ${{\texttt{flip}}}$ —and its answer— ${{\mathit{false}}}/{{\mathit{true}}}$ —in a single step, such that the computations never observe that they have had access to distinct continuations. However, if one were to introduce in the tree a Step node before the external events, for instance using the handler , a new state allowing for witnessing the distinct continuations would become available in the LTSs, leading to non-bisimilar interpreted trees as shown on the right in the figure. We hence prove that the desired property holds on a subclass of handlers.

Fig. 23. Two strongly bisimilar trees before interpretation (left), but not after (right).

• • a pure computation, i.e., $\forall l t', h e \xrightarrow{l} t' \implies \exists r, l = {{\texttt{val}}} \, r$ ,

• • or always performs exactly one step before returning, i.e., $\forall l t', h e \xrightarrow{l} t' \implies \exists r, t' = {{{{\texttt{Ret}}} \, r}}$ .

We say that is quasi-pure if it is point-wise quasi-pure.

We show that we recover monad morphisms when working with quasi-pure handlers:

• • If is quasi-pure, then

• • If is quasi-pure, then

The same is true for $\lesssim$ .

The stateful version is, in particular, sufficient to transport ImpBr equations established before interpretation—such as the theory of br $\_$ or $\_$ —through interpretation . More generally, we can reason after interpretation to establish equations relying both on the nondeterminism and state algebras, for instance to establish the equivalence mentioned in Section 2.2 . Bahr & Hutton (Reference Bahr and Hutton2023) have established that the restriction to quasi-pure handlers can be lifted by defining the LTS a bit differently (see Section 11). For the time being, we have decided against making this change in the CTrees library because it represents too much added complexity for little benefit.

The former theorem links CTrees before and after interpretation. It can also be interesting to compare alternative implementations of a handler for the same kind of event, e.g., different memory models for memory access events. In this case, we provide a theorem to lift a simulation result on handlers to a simulation result on interpreted CTrees.

• •

• •

This theorem is presented here in the homogeneous case for simplicity, but we provide it for heterogeneous simulations, thus the heavily parameterized Rocq statement of the mechanized theorem. Note that unlike Theorem 1, we do not need any assumption on the handlers or the trees.

7.2 Refinement

Interpretation provides a general theory for the implementation of external events. Importantly, CTrees also support an analogous facility for the implementation of its Br branches. In particular, one would typically use this process to shrink the set of accessible paths in a computation—and, notably, determinize it—hence leading to a new computation that refines by the original one. For this reason, we abusively refer to this process as the refinement of its Br branches, and capture sufficient conditions to ensure that it defines a computation simulated by the original one.

We provide, to this end, a new combinator, , defined in Figure 24. The definition is very similarFootnote ¹⁷ to , except that it takes as an argument a handler specifying how to implement branches rather than external events into a monad . The target monad must naturally still be iterative, able to provide a stuck state, and an observable tick, but must additionally explain how it can re-embed an uninterpreted event (mtrigger)—a device already used by Yoon et al. (Reference Yoon, Zakowski and Zdancewic2022).

Fig. 24. Refining CTrees (class constraints omitted) .

Similarly to , it can be desirable to write handlers that refine only part of the Br nodes. For instance, a CTree containing Br nodes for thread scheduling and other Br nodes for random number generation can be refined to schedule the threads in a round-robin way while not touching the Br nodes for random number generation. Note that this was not possible in the original CTrees library (Chappe et al., Reference Chappe, He, Henrio, Zakowski and Zdancewic2023) because there was no branching signature in the CTree type.

As hinted at by the combinator’s name, the source program should be able to simulate the refined program. Fixing to ctree F B, this is expressed as $\forall t, $ refine h $ t \lesssim t$ . However, one cannot hope to obtain such a result for an arbitrary h because it could implement branches with an observable computation that can’t be simulated by t. We hence prove this result for refinement handlers implementing branches in terms of finite pure CTrees : finite-height CTrees that do not contain any Step or node.

• •

• •

Note that the second statement introduces a heterogeneous simulation (see Section 10.2 ): the return types of the trees are not identical—the refined tree maintains an additional state that we ignore.

Unlike , is typically not a monad morphism. The CTrees are clearly bisimilar, but refining them by always choosing the left branch of Br nodes gives, respectively, ${{{{\texttt{Ret}}} \, 0}}$ and ${{{{\texttt{Ret}}} \, 1}}$ , which are not bisimilar. This highlights the major difference between and Br: nodes represent external events whose response from the environment has a strong semantic value, while Br nodes represent nondeterminism, with branches indistinguishable for ${{{{\texttt{sbisim}}}}}$ .

7.3 Extraction

The shallow nature of CTrees also offers testing opportunities. Xia et al. (Reference Xia, Zakowski, He, Hur, Malecha, Pierce and Zdancewic2019) describe how external events such as IO interactions can alternatively be implemented in OCaml and linked against at extraction. Similarly, we demonstrate on ImpBr how to execute a CTree by running an impure refinement implemented in OCaml by picking random branches along the execution.

In comparison with ITrees, the random execution of CTrees requires some care because of the locally angelic nondeterminism of Br nodes. Indeed, the nave approach of randomly choosing a branch when encountering a Br node is not semantically correct because of stuck branches: the semantics of ${{Br^2 {\emptyset} t}}$ should be the semantics of t. We provide a correct implementation run for the ImpBr example that backtracks when it encounters a stuck branch, as shown in Figure 25.

Fig. 25. A random interpreter and a collecting interpreter for ImpBr, implemented in OCaml.

This fixed version still chooses Br branches randomly, but if it subsequently reaches a stuck node (materialized by a false return value), it explores the other branch. Again on the ImpBr example, we can define a collecting interpreter collect (see Figure 25) that, given an ImpBr program, crawls its CTree to build the list of its possible return values.

We observe that these interpreters exhibit correct behavior on an example CTree . However, a limitation of the proposed implementations is that they may loop when given a program with an infinite chain of Guard or Br nodes (e.g., the stagnate CTree from Figure 6). If it reaches a stagnate, the random interpreter will loop on the Guard case and never terminate. As for the collecting interpreter, it will always loop as it always explores every branch of the CTree. For the random interpreter, performing a breadth-first search instead of a depth-first search would solve this limitation. But this is not an option for the collecting interpreter. Instead, the maximal exploration depth could be limited as a workaround.

7.4 ITree embedding

We have used CTrees directly as a domain to represent the syntax of ImpBr, as well as in the ccs case study (see Section 4). CTrees can, however, fulfil their promise sketched in Section 2 and be used as a domain to host the monadic implementation of external representations of nondeterministic events in an ITree.

To demonstrate this approach, we consider the family of events C and aim to define an operator taking an ITree computation modeling nondeterministic branching using these external events and implementing them as branches indexed similarly into a CTree. This operator, defined in Figure 26, is the composition of two transformations. First, we ITrees into CTrees by (ITree) interpretation. This injection rebuilds the original tree as a CTree, where (because of the Guard-based definition of on CTrees) $\texttt{Step}_{i}$ nodes have become nodes and an additional has been introduced in front of each external event. Second, we the external branching contained in a CTrees implementing a event, using the isomorphic stepping branch. The resulting embedding forms a monad morphism transporting eutt ITrees into sbisim CTrees:

Fig. 26. Implementing external branching events into the CTree monad .

The proof of this theorem highlights how $\texttt{Step}_{i}$ nodes in ITrees (adding a subscript to distinguish them from their CTree homonym) collapse two distinct concepts that nondeterminism forces us to unravel in CTrees. The eutt relation is defined as the greatest fixpoint of an inductive endofunction euttF. In particular, one can recursively and asymmetrically strip finite amounts of $\texttt{Step}_{i}$ —the corecursion is completely oblivious to these nodes in the structures. Corecursively, however, $\texttt{Step}_{i}$ nodes can be matched symmetrically—a construction that is useful in exactly one case, namely to relate the silently spinning computation, $\texttt{Step}_{i}^{\omega},$ to itself. From the CTrees perspective, it is therefore natural to think of recursing in euttF as corresponding to the inductive case in the definition of the LTS: in this sense, $\texttt{Step}_{i}$ nodes behave as Guard nodes. Semantically, however, restricting ourselves to the deterministic case, i.e., where a CTree contains no Br nodes other than Stuck and Guard, the process of substituting Guard nodes for ${Step }$ nodes lead to a strongly bisimilar computation.

Conversely, the corecursive case in ${\texttt{eutt}}$ corresponds to both LTSs taking a synchronous internal step: we are tempted to think of $\texttt{Step}_{i}^{\omega}$ as corresponding to ${{\texttt{Step}}}^{\omega}$ . However, here again, we have actually more lenience. Indeed, ITrees do not have a notion of stuck computation,Footnote ¹⁸ contrary to CTrees: it turns out that it is just as sound, in the sense of Lemma 8, to map $\texttt{Step}_{i}^{\omega}$ to ${{\texttt{Guard}}}^{\omega}$ , i.e., to Stuck.

In the embedding we present here, we have taken this latter choice: to see this, one needs to unfold a couple of definitions. The function relies on an that consumes ITrees and produce CTrees. The behavior of this , when faced with a $\texttt{Step}_{i}$ , is to consume it and recurse w.r.t. the notion of iteration provided by CTrees: as introduced in Figure 5, this recursion is guarded by Guard.

In the proof of Lemma 8, the choice of embedding $\texttt{Step}_{i}$ into Guard materializes by the fact that an induction on euttF leaves us disappointed in the symmetric $\texttt{Step}_{i}$ case: we have no applicable induction hypothesis, but expose in our embedding a ${{\texttt{Guard}}}$ , which does not allow us to progress in the bisimulation. We must resolve the situation by proving that being able to step in implies that is not $\texttt{Step}_{i}^{\omega}$ , i.e., that we can inductively reach a or a node .

Limitations: on guarding recursive calls using Guard. We have shown that CTrees equipped with as recursor and strong bisimulation as equivalence form an iterative monad. Furthermore, building interpretation atop this combinator gives rise to a monad morphism respecting eutt, hence is suitable for implementing nondeterministic effects represented as external in an ITree.

However, we stress that the underlying design choice in the definition of , guarding recursion using Guard, is not without consequences. It has strong benefits, mainly that a lot of reasoning can be performed against strong bisimulation. More specifically, this choice allows the user to reserve weak bisimulation for the purposes of ignoring domain-specific steps of computations that may be relevant both seen under a stepping or non-stepping lens—e.g., synchronizations in ccs—but it does not impose this behavior on recursive calls. However, it also leads to a coarse-grained treatment of silent divergence: in particular, the silently diverging ITree (an infinite chain of $\texttt{Step}_{i}$ ) is embedded into an infinite chain of Guard, which, we have seen, corresponds to a stuck LTS. For some applications—typically, modeling other means of being stuck and later interpreting them into a nullary branch—one could prefer to embed this tree into the infinite chain of Step to avoid equating both computations. While one could rely on manually introducing a Step in the body iterated upon when building the model, that approach is a bit cumbersome.

Instead, a valuable avenue would be to develop the theory accompanying the alternate iterator mentioned in Section 5.3 and guarding recursion using Step. Naturally, the corresponding monad would not be iterative with respect to strong bisimulation, but we conjecture that it would be against weak bisimulation. From this alternate iterator would arise an alternative embedding of ITrees into CTrees: we conjecture it would still respect eutt, but seen as a morphism into CTrees equipped with weak bisimulation. The development accompanying this paper does not yet support this alternate iterator, we leave its implementation for future work.

Currently, the user has the choice between (1) not observing recursion at all, but getting away with strong bisimulation in exchange, (2) manually inserting Step at recursive calls that they chose to observe. With support for this alternate iterator, the user would be given additional option to (3) systematically -observe recursion, at the cost of working with weak bisimulation everywhere.

8.1 Model

The model for ImpBr, described in Section 2, was defined in two stages: a representation into a nondeterministic CTree with interaction with memory, and then a stateful interpretation. We proceed this time in three stages: a representation into a deterministic CTree with concurrent interaction represented as external events, a scheduling pass introducing nondeterminism by interleaving all the valid executions, and finally a stateful interpretation.

Representation

First, we represent statements as computations of type . At this stage of representation, they are modeled as deterministic computations,Footnote ²⁰ as highlighted by the use of the empty interface for branches. The computation can however perform events from two additional signature, namely yielding and forking:

carries no additional information and acts purely as a signal to yield control, and Fork introduces a binary branch in the CTree, allowing us to store the asynchronous thread in one branch and the main thread that continues running in the other branch. These events are used to represent the corresponding statements:

The remaining of the representation is entirely standard. We write ${{[\![ p ]\!]}}$ the representation of p.

Interleaving

The model’s second pass makes explicit the nondeterminism implicitly induced by the events (extending the thread pool) and the events (nondeterministically picking a new active thread to schedule). At a high level, our goal is hence to write a function:

where allows arbitrary finite branching—at run time, we may pick an identifier out of the current pool set, i.e., out of an unbounded finite set.

This combinator, like in the case of parallel composition for ccs, cannot be simply defined via . We hence craft this function by co-recursion, but need to generalize it first to this end. Let us pose a couple of definitions:

We introduce an external event containing no information that we will use to keep track of points where a fork happened. We write as a shorthand for the datatype of represented threads, i.e., intermediate, deterministic, models of pieces of code that have not been scheduled yet. In contrast, we write for the second semantic domain we aim, the datatype of already scheduled (and therefore nondeterministic) computations.

Our updated goal is therefore to craft a cofixpoint:

where is the arity of the current set of threads left to interpret, and is the index of the thread currently under focus, if any. The result is a scheduled computation, i.e., a . Once we have this function, we shall define our second stage of interpretation by simply starting with the singleton thread pool:

Figure 27 defines the function formally.Footnote ²¹ We write $v_n$ for a vector of size n, and vector operations for removing the i-th element as $v[-i]$ , updating the i-th element to x as $v[i \mapsto x]$ , and adding an element x to the front as $x :: v$ (so x is the new 0-th element in the resulting vector). The traditional constructors of the option type are written respectively ${\lfloor \mbox{-} \rfloor}$ and ${\lfloor v \rfloor}$ . References to ${{\mathsf{schedule}}}$ in its body should be interpreted as corecursive calls—we abuse notations to lighten the presentation.

Fig. 27. The definition of ${\mathsf{schedule}}$ .

The first two cases cover the situation where no thread is active, i.e., the second argument is ${\lfloor \mbox{-} \rfloor}$ . If the thread pool is empty, the computation simply terminates. Otherwise, it picks a thread to be scheduled: a event is inserted, followed by a branching node of arity the cardinality of the thread pool, and sets the chosen thread active.

If there is an active thread, ${\lfloor i \rfloor}$ , the ${{\mathsf{schedule}}}$ makes progress in that thread, analyzing the corresponding tree in the pool. If the active thread has terminated, it is removed from the pool, and out of focus. Guard, Step, and memory event nodes are simply kept, the active thread updated, and scheduling continues without changing focus. A stuck thread blocks the whole computation. The remaining cases correspond to events and in particular concurrency events.Footnote ²² The nodes are substituted for an invisible Guard, and remove the current focus—the event is hence reintroduced right after in the focusing rule. The nodes are replaced by a simple unary marker, and corecursion occurs over the vector extended with the new thread, and the updated thread that stays under focus (note that this shifts the active thread from index i to $i+1$ ).

The acute reader may wonder why we keep and events in the datatype since they do not contain any data. And indeed, we follow this scheduling process by an interpretation phase simply removing these events. However, they offer an intermediate semantic domain at which less programs are equated, but where there are more contexts inside which program equivalence is preserved: intuitively, equivalent programs are known to yield at the exact same points. We illustrate on an example the distinction between both equivalences in Section 8.2; leveraging this intermediate model to strengthen the language’s equational theory is left for future work.

We write the resulting tree after clean up of the and events.

8.2 Equational theory

The model described in Section 8.1 allows us to derive some program equivalences at source-level w.r.t. weak bisimilarity of their models. For example, the following programs all just run c, though some of them first perform some “invisible” steps related to concurrency

:

We emphasize that these equations are not compositional, they only hold in the absence of additional concurrent threads, hence when Yield behaves as a noop. Indeed, when another thread is running, in the program in the middle Yield lets the other thread run first, whereas the right program immediately runs c and only lets the other thread run afterward. In contrast, we conjecture that the monadic equivalence between $\mathcal{S}{{[\![ \cdot ]\!]}}$ representations is a congruence, albeit we have not proved it formally at the moment. Indeed when scheduling events are observable, only programs that allow thread interleaving to occur at the same time can be considered equivalent.

Other equations, especially ones that make use of multiple threads in nontrivial ways, rely on the stability of ${{\mathsf{schedule}}}$ under sbisim:

The arity requirement is satisfied by all denotations of programs in this language. This condition greatly simplifies the proof by constraining the shape that the strongly bisimilar CTrees can take.

Lemma 9 allows us to permute the thread pool, which is useful in examples such as

:

This program spawns two asynchronous threads then yields control to one of the two. This equivalence captures the natural fact that it does not matter which thread is spawned first, since neither can run until both are spawned.

Furthermore, Lemma 9 allows us to validate some simple optimizations that do not directly involve reasoning about concurrency or memory, such as

:

Here, one of the spawned threads is a while loop, which we wish to unroll by one iteration. Crucially, the loop and its unrolled form are strongly bisimilar, so this equivalence follows from Lemma 9 just as in the previous example. Other optimizations that can be done before interpreting events, such as constant folding or dead code elimination, can be proven sound similarly.

Finally, equivalences involving memory operations are still valid as well

:

where $\equiv$ here refers to equivalence ( $\approx$ in this case) after interpreting both concurrency and memory events. This result follows from the result in Section 7.1, which allows us to transport equations made before interpreting state events into computations in the state monad after interpretation.

9.1 Alternative characterization of CTree similarity

Our definition of strong bisimilarity is based on a completely standard strong simulation game (see Definition 3), and we have established convenient proof rules and up-to principles over it. However, it is defined on an LTS that bears some distance to the CTrees data-structure itself: all the Br nodes are skipped/collapsed. An unfortunate consequence is that we cannot reason at the level of the simulation on these Br nodes, as they do not even appear in the LTS. In this section, we alternatively consider LTSs in which Br nodes generate a special $\epsilon$ transition, and define a fitting simulation game that “ignores” these $\epsilon$ transitions.

In the following, we refer to this new LTS as the $\epsilon$ -LTS, or explicit LTS, and to the original one as the implicit LTS. Figure 28 shows the definition of the $\epsilon$ -LTS: it is no longer inductive, each syntactic node in the CTree maps to transitions to its children in the LTS.Footnote ²³ For instance, Figure 29 depicts the explicit LTS for the example CTree from Section 5.5. We observe that given a CTree c, it admits an implicit transition $c \xrightarrow{l} c'$ if and only if it admits an explicit sequence of transitions $c \xrightarrow{\epsilon^{*} \cdot l} c',$ where $\xrightarrow{\epsilon^{*} \cdot l}$ is a shorthand for $\xrightarrow{\epsilon^{*}}\xrightarrow{l}$ .

Fig. 28. Inductive characterization of the alternative $\epsilon$ -LTS induced by a CTree. The Br and Guard cases differ from the original LTS.

Fig. 29. The LTS built from the CTree of Section 5.5, with explicit $\epsilon$ transitions.

Working over this $\epsilon$ -LTS, one must be careful about terminology: we seek to redefine strong similarity (meaning, strong w.r.t. $\tau$ transitions), but will treat $\epsilon$ transitions weakly in doing so. Figure 30 recalls the simulation game introduced in Section 5.4, but spelled out from the perspective of the $\epsilon$ -LTS. We write $t \xrightarrow{\epsilon} u$ for $\epsilon$ transitions and $t \xrightarrow{l} u$ for other transitions. This simply makes it explicit that the simulation challenge we have been considering may involve an arbitrary number of $\epsilon$ transitions before reaching an observable label, which is indicative of a flavor of a weak simulation game, defined as a strong simulation game over a flavor of a weak transition system. And as illustrated in the toy example proof above, the awkwardness in the game translates in the proof system: consider Figure 20, the proof rule for Br does not unlock the coinduction hypothesis.

Fig. 30. The simulation game and bisimulation half-game $\texttt{t} \mathrel\lesssim_{\mathcal{R}} \texttt{u}$ , in the $\epsilon$ -LTS.

We can now provide a definition of strong similarity of CTrees that is equivalent to , while avoiding its drawbacks: Figure 31 depicts the corresponding game.

Fig. 31. The two cases of the simulation game $\texttt{t} \mathrel\lesssim'_{\mathcal{R}} \texttt{u}$ .

Definition 6 (Simulation for CTrees on the explicit LTS ). The progress function ss’ for similarity over the explicit $\epsilon$ -LTS maps a relation $\mathcal{R}$ over CTrees to the relation such that $ss' \mathcal{R} t u$ (also noted $\texttt{t} \mathrel\lesssim'_{\mathcal{R}} \texttt{u}$ ) holds if and only if:

\begin{align*} \forall l t',\, l \neq \epsilon,\, t \xrightarrow{l} t' \implies& \exists u'. t' \mathcal{R} u' \land u \xrightarrow{\epsilon^{*} \cdot l} u' \\ \forall t', t \xrightarrow{\epsilon} t' \implies& \exists u'. t' \mathcal{R} u' \land u \xrightarrow{\epsilon^{*}} u'. \end{align*}

Similarity, written $\texttt{t} \mathrel{\lesssim'} \texttt{u}$ , is defined as the greatest fixpoint of ss’:

The key to the definition of this new game ’ is to distinguish apart $\epsilon$ -transitions as a special kind of challenge. While other transitions are handled as in the original definitions, $\epsilon$ transitions can be answered by any number of $\epsilon$ transitions, possibly 0.

Our definition is very close to the standard notion of weak simulation Sangiorgi (Reference Sangiorgi2012). The definition of CTree simulation on the explicit LTS has two subtle differences: it is weak with respect to $\epsilon$ transitions instead of $\tau$ , and the answer to the non-epsilon challenge is different. Usually, classical weak simulation involves $\xrightarrow{\epsilon^{*} \cdot l \cdot \epsilon^{*}}$ , but Definition 6 does not allow $\epsilon$ transitions after the l transition. This is to match the semantics of the original CTree transition relation (Figure 15), which inductively skips Br nodes until it reaches a productive node, and stops just after. This slight difference is of no consequence on the greatest fixpoint: ssim’ could equivalently be defined as the greatest fixpoint of either of these simulation games.

Crucially, we prove that both definitions of similarity coincide:

Theorem 3 (Equivalence of the two notions of similarity ).

\[ \forall t u,\, t \lesssim u \iff \texttt{t} \mathrel{\lesssim'} \texttt{u} \]

All the proof rules for ss are also proved valid on ss’, and more powerful rules are valid for Br and Guard nodes. But crucially, consuming a Guard node now unlocks the coinductive hypothesis, alleviating the need for a nested induction encountered when working with ss.

The up-to-bind and up-to-equ principles are valid for ss’. However, the up-to-sbisim principle that allows rewriting top-level strongly bisimilar terms is no longer valid. Indeed, rewriting using the theorem would allow introducing a guard node and coinductively removing it using ss’_guard_l. This echoes the classical result that weak (bi)simulation is not valid up-to weak (bi)simulation when presented as generated by the asymmetric game. Fortunately, it is still possible to strip Guard nodes using a dedicated up-to principle:

\[ {{\epsilon_{r}}^{up}} \mathcal{R} \triangleq \{(x, y) \mid \exists y',\,y \xrightarrow{\epsilon^{*}} y' \land x \mathcal{R} y'\}\]

This up-to principle is used to recover asymmetric Guard- and Br-stripping proof rules for the right-hand side of the simulation.

Another interesting new up-to principle is ss, the original strong simulation game. In fact, it is more than an up-to principle. At any point during the proof of a ssim’ simulation, we can perform a regular step instead of an ’ step. This is because an step always corresponds to one or more ’ steps. To state this fact formally, we have to leak the implementation details of our relations in terms of tower induction:

Lemma 11 (is a sub-chain of '

). Given $\mathcal{R} : C_{ss'},$ i.e., a chain for ss’, the following implication holds.

With our alternative characterization of CTree simulation, we can now revisit our motivating example from the header of this section and conclude via a coinductive proof

.

9.2 Alternative characterization of CTree bisimilarity

Naturally, we want a similar improvement for strong bisimilarity. However, while the solution in the case of similarity turned out to be a fairly standard recipe, bisimilarity calls for more inventiveness. Indeed, bisimulation games are usually defined as the intersection of a simulation game and its symmetrized version—that was the case for the bisimulation game in Section 5.3. However, this would not work for the game on the $\epsilon$ -LTS. Consider the CTrees in Figure 32. They are bisimilar since they have the same available transitions, (val i) for $i \in \{0,1,2,3\}$ , to the empty state. But a nave symmetrization of $\lesssim'$ (by intersecting two half games) would require an $\epsilon$ challenge to be matched by exactly one $\epsilon$ transition (as it would essentially amount to defining a standard weak bisimulation w.r.t. $\epsilon$ ), which is not possible in the example. No matter which branch of the left CTree is taken, there is no branch in the right CTree that is bisimilar with the intermediate node. Hence, this definition would be too strong.

Fig. 32. Two bisimilar CTrees that motivate the definition of intertwined bisimilarity.

Rather, we define bisimulation over the $\epsilon$ -LTS as two mutually coinductive relations: intuitively, one for the left half-game and another one for the right half-game. The intersection of the greatest fixpoints of these relations gives the bisimulation relation. We dub this notion intertwined bisimilarity, to emphasize that it is an intersection of two interdependent simulation relations. This construction is reminiscent of coupled simulations (Parrow & Sjödin, Reference Parrow and Sjödin1994; Sangiorgi, Reference Sangiorgi2012), which is defined as a pair of simulations and a coupling relation between them, though the principles are not comparable. To our knowledge, mutual coinduction has been used before as a key proof device in the context of applicative bisimilarity (Levy, Reference Levy2006), but never in an actual definition of bisimulation.

To define formally intertwined bisimilarity, we define the pair of games we consider by indexing them by a boolean, encoding which half we are currently participating in. While the games encountered so far were monotone functions over binary CTree relations, $\mathrel{\sim'_\square}$ is a monotone function over ternary bool * ctree * ctree relations $\mathcal{R}$ . In the following, we note $\mathcal{R}_l$ for the left simulation $\mathcal{R}\ \texttt{true}$ , $\mathcal{R}_r$ for the right simulation $\mathcal{R}\ \texttt{false}$ , and $\mathcal{R}_{lr}$ for the intersection of $\mathcal{R}_l$ and $\mathcal{R}_r$ .

• • (also noted $\sim'_{\mathcal{R}_l}$ ) holds if and only if:

  \begin{align*} \forall l t',\, l \neq \epsilon,\, t \xrightarrow{l} t' \implies& \exists u'. t' \mathcal{R}_{lr} u' \land u \xrightarrow{\epsilon^{*} \cdot l} u' \\ \forall t', t \xrightarrow{\epsilon} t' \implies& \exists u'. t' \mathcal{R}_l u' \land u \xrightarrow{\epsilon^{*}} u' \end{align*}

• • (also noted $\sim'_{\mathcal{R}_r}$ ) holds if and only if:

  \begin{align*} \forall l u',\, l \neq \epsilon,\, u \xrightarrow{l} u' \implies& \exists t'. t' \mathcal{R}_{lr} u' \land t \xrightarrow{\epsilon^{*} \cdot l} t' \\ \forall u', u \xrightarrow{\epsilon} u' \implies& \exists t'. t' \mathcal{R}_r u' \land t \xrightarrow{\epsilon^{*}} t' \end{align*}

The bisimulation relation $\texttt{t} \mathrel{\sim'} \texttt{u}$ is defined as

. The “ $\forall \texttt{side}$ ” is critical as it requires a CTree pair to be both in $\mathcal{R}_l$ and $\mathcal{R}_r$ to be considered bisimilar.

This definition is similar to the one of $\lesssim'_\mathcal{R}$ (Definition 6), but the $\epsilon$ case in the bisimulation left (resp. right) half-game has a weaker conclusion: it only leads to the left (resp. right) half-relation. When the head of a CTree is an $\epsilon$ node, both the left and right half games need to be played (possibly several times) to get back to $\mathcal{R}_l \cap \mathcal{R}_r$ .

Intuitively, $t \sim'_{\mathcal{R}_l} u$ means that u can simulate one step of t (possibly skipping $\epsilon$ transitions before reaching the matching transition), and the resulting t’ and u’ are bisimilar (in $\sim'_{\mathcal{R}_{lr}}$ ). In case t admits an $\epsilon$ transition, the u side can answer with any number of $\epsilon$ transitions, or no transition at all. Symmetrically, $t \sim'_{\mathcal{R}_r} u$ means that t can simulate one step of u (possibly skipping $\epsilon$ transitions before reaching the matching transition), and the resulting t’ and u’ are bisimilar (in $\sim'_{\mathcal{R}_{lr}}$ ). The name intertwined bisimulation comes from the fact that $\mathcal{R}_l$ and $\mathcal{R}_r$ can go separate ways when encountering $\epsilon$ transitions, but converge back together when there is another transition.

For readers familiar with ITrees (Xia et al., Reference Xia, Zakowski, He, Hur, Malecha, Pierce and Zdancewic2019), our boolean parameter may evoke a proof device that was used in the definition of , a coinductive relation parameterized by two booleans. However, the point of the booleans in was to factor out four similar definitions of simulation and bisimulation (eutt, etc.). In this context, the booleans were outside the greatest fixpoint, while our boolean is not fixed, it is part of the coinduction domain and does evolve during a coinductive proof. Freely stuttering simulation Cho et al. (Reference Cho, Song, Lee, Gäher and Dreyer2023) is another case of an extension of a coinductive domain in an ITree-adjacent setting that will be discussed in Section 11.

The main proof rules for intertwined bisimulation are shown in Figure 34.Footnote ²⁴ The ones related to Guard and Br are more powerful than the sb rules, and the other ones (greyed out) are equivalent.

Fig. 33. The four cases of the intertwined bisimulation game $\texttt{t} \mathrel{\sim'_{\mathcal{R}_{lr}}} \texttt{u}$ . Note that the left and right half-games are symmetric, with $\mathcal{R}_l$ and $\mathcal{R}_r$ swapped.

Fig. 34. Proof rules for coinductive proofs of $\sim'$ .

As usual, various up-to principles are valid, but this time $\mathcal{R}$ is not a binary but a ternary relation (because of the additional boolean). For each of the up-to principles proved for ${\lesssim'}$ in Lemma 10, we proved the validity of a ternary counterpart for ${\sim'}$ .

Lemma 12 (Enhanced coinduction for ${\sim'}$ ). The up-to reflexivity

, up-to equ

, up-to bind

, up-to ss

and up-to epsilon

principles are valid for $\sim'$ . A new up-to negated symmetry

principle is also valid

.

The up-to negated symmetry principle is a ternary variant of the standard up-to symmetry principle. It swaps two CTree operands of a relation and negates its boolean, because after swapping the operands, $\mathcal{R}_l$ and $\mathcal{R}_r$ become inverted.

Again, a major result on this alternative characterization of bisimilarity is its equivalence with the bisimilarity previously presented in Section 5.3. Interestingly, the theorem statement can be split into a result on the left and right halves of $\sim'$ .

We have presented alternative characterizations of similarity and bisimilarity in the homogeneous case, but as with most definitions of Section 5, we implemented them in Rocq with support for heterogeneous relations (see Section 10.2). In fact, in the homogeneous case, the bisimulation game of Figure 33 degenerates to a simpler game (Figure 35) that does not rely on mutual coinduction, nor a ternary relation with a boolean. This simpler game stems from the observation that an homogeneous $\mathcal{R}$ verifies $\mathcal{R} b t u \iff \mathcal{R} \neg b u t$ .

Fig. 35. The two cases of the homogeneous alternative bisimulation game $t \sim'_\mathcal{R} u$ . $\mathcal{R}^\circ$ represents the converse of $\mathcal{R}$ .

10.1 Complete similarity

Section 5.4 introduced strong similarity, a standard notion of program refinement. This section studies complete similarity, a slightly more complex notion of similarity that behaves better in presence of stuck LTSs.

A well-known limitation of similarity is its deadlock-insensitivity: it directly follows from the definition of the simulation game that a stuck LTS is simulated by any LTS, and we have indeed a corresponding proof rule in Figure 20.

In many applications, when stating that a program or process p refines a non-stuck process q, we mean to prove that p exhibit a nonempty subset of the behaviors of q, which strong similarity therefore fails to capture. Several notions of similarity tackle this limitation (see for instance Chapter 6 of Sangiorgi, Reference Sangiorgi2012). This section is dedicated to complete similarity, an intuitive answer to this problem. Concretely, a complete simulation game is defined like a simulation game, with the additional constraint that if either LTS is stuck, the other one should be too. Figure 36 depicts graphically the following complete simulation game. In these rules, we write $t\rightarrow$ for $\exists l t', t \xrightarrow{l} t'$ , i.e., t is not stuck.

Fig. 36. The complete simulation game $\lesssim^C_\mathcal{R}$ .

Definition 8 (Complete simulation for CTrees

). The progress function css for complete similarity maps a relation $\mathcal{R}$ over CTrees to the relation such that $css R t u$ (also noted $t \lesssim^C_\mathcal{R} u$ ) holds if and only if

Complete similarity, written $t \lesssim^C u$ , is defined as the greatest fixpoint of css: .

Fig. 37. Proof rules for coinductive proofs of cssim .

The coinductive proof rules for complete simulation are depicted in Figure 37. The proof rules are basically the same as with ssim, with conditions to ensure that a CTree does not become stuck after taking a step. Note, however, that in cases where a node is matched against the exact same node, no additional condition is enforced. Cases that are identical to the rules for ssim are grayed out in the figure.

The up-to principles that are valid for ssim are also valid for cssim, except the up-to bind principle. We define a more restrictive up-to principle for complete similarity that requires the continuation not to be stuck.

10.2 Heterogeneous (bi)similarity

Throughout this paper, we have defined various relations for comparing programs which essentially match transitions with identical labels—with the exception of weak bisimilarity that we have briefly mentioned, and come back to in Section 10.3. From the perspective of program verification, this is insufficient: val v labels may carry in the memory configuration of our language, and we may need to express nontrivial relational invariants between such configuration, rather than enforcing equality.

The ITree library has had this notion since its inception, parameterizing their equivalence, eutt, by an arbitrary relation on leaves. When dealing with some more advanced reasoning, one may even wish to relate distinct external events. This led Silver et al. (Reference Silver, He, Cecchetti, Hirsch and Zdancewic2023) to introduce over ITrees the relation in order to express security invariants—Michelland et al. (Reference Michelland, Zakowski and Gonnord2024) have also made crucial use of this facility to relate concrete and abstract events to prove the soundness of abstract interpreters.

Although we have omitted for conciseness these details through our presentation, our library supports a similar generalization for all the relations we have introduced. In our setting, we recover immediately the full generality of by parameterizing the relations by an arbitrary relation $\mathcal{L}$ on labels. As an example, we reproduce below our definition of strong bisimilarity, and the other ones are generalized the same way.

and conversely

Bisimilarity w.r.t. $\mathcal{L}$ , written $t \sim_{\mathcal{L}} u$ , is defined as the greatest fixpoint of .

Many of the proof rules, up-to principles, and theorems (in particular, Theorem 2) introduced in the previous sections are generalized to this setting and can be used seamlessly in presence of such a heterogeneous relation on labels. The most interesting rule to extend is the rule. In terms of usefulness first, it becomes a very general cut rule allowing for the introduction of an intermediate relational invariant on the values returned by the first parts of the computations. In terms of statement second, where we must be careful to introduce the necessary machinery to allow for this update to the ${{\texttt{val}}} \cdot$ of the relation, while maintaining a consistent view on the other labels.

A class of $\mathcal{L}$ relations is of particular interest: relations between labels that lift a relation $\mathcal{V}$ of type between return values . Such a relation $\uparrow\mathcal{V}$ of type coincides with equality for ${{\texttt{obs}}}$ and ${{\texttt{tau}}}$ labels and relies on the $\mathcal{V}$ relation for comparing ${{\texttt{val}}}$ labels of possibly heterogeneous types. This is useful for comparing CTrees that are semantically related but typed differently.

10.3 Weak bisimilarity

Weak bisimilarity is a bisimilarity relation that ignores silent steps (called $\tau$ steps). It is an equivalence relation where programs are considered equivalent if they differ only in their number of finite $\tau$ steps. Weak bisimilarity, written $s \approx t$ , is derived from the definition of the weak transition . We will not detail our formal definition of weak bisimulation: it is based on the standard asymmetric game (see for instance Chapter 4 of Sangiorgi, Reference Sangiorgi2012).

We first define the traditional weak transition on the LTS that can perform tau transitions before or after the l transition (and possibly no transition at all if $l=\tau$ ). This part of the theory is so standard that we can directly reuse parts of the development for ccs that Pous developed to illustrate the companion (Pous, Reference Pous2024b). Weak bisimilarity enjoys additional equations compared to sbisim (see Figure 18): Step nodes can be ignored, and ${Br_S}$ is therefore properly idempotent. Crucially, however, it is still not associative.

Our library currently offers restricted support for weak bisimilarity. This situation stems in part by needs: existing applications of CTrees, including the examples in Sections 4 and 8, but also the artifact of Chappe et al. (Reference Chappe, Henrio and Zakowski2025c) have so far only leveraged strong bisimilarity. While in the case of ccs it is naturally only a matter of having not pushed the development of the case study further, the two other examples are more interesting: by using Guard in corecursive definitions and careful definitions of the models, strong bisimilarity appears to be sufficient to recover a satisfying equivalence. This is partly explained by the fact that Br nodes exhibit a form of weak behavior w.r.t. strong bisimilarity. Section 9.1 will expand on this perspective.

But our limited support for weak bisimilarity also comes from interesting technical challenges. As is well known in the field of process algebra (Milner, Reference Milner1989, p.152), weak bisimilarity can be unwieldy. Specifically, it is not a congruence for the $+$ operator of ccs (see Section 4) and of the $\pi$ -calculus, of which the CTree Br nodes can be seen as a direct generalization. This has several consequences in the CTree setting. First, unlike strong bisimilarity, weak bisimilarity is not a congruence for Br: we cannot define a general proof rule on the same model. Furthermore, the up-to bind principle is not verified in the general case either, as it would, with well-chosen CTrees, imply the former result.

Example 1 (Counter-example to the $\approx$ up-to bind principle). Consider the CTree t and the continuations k and k’ below. We have

; yet, we do not have $t >\!\!>\!\!= k \approx t >\!\!>\!\!= k'$ .

Below are depicted the LTSs for $t >\!\!>\!\!= k$ (on the left) and $t >\!\!>\!\!= k'$ (on the right). On the right, the gray state corresponds to the first Step of . It has no equivalent on the left, which explains why there is no bisimulation between these LTSs.

This limitation of weak bisimilarity is commonly circumvented in process algebra by requiring processes to be guarded:Footnote ²⁵ the operands of the ccs $+$ operator should begin with a deterministic transition. In a CTree setting, if we restrict ourselves to $\tau$ -guarded parallel composition, it means that each branch of a Br should begin with a ${{\texttt{Step}}}$ , which is precisely the definition of ${{Br_S}}$

. Similarly, we proved that an up-to bind principle that requires continuations to begin with ${{\texttt{Step}}}$ is valid

.

This principle is however not completely satisfying: we can note that the hypothesis involves the plain relation $\mathcal{R}$ (rather than $\approx_\mathcal{R}$ ) and strips the leading Step nodes. Transferred to an enhanced principle, this would translate to a bind-rule for Step-guarded continuations that does not unlock the coinduction hypothesis. We leave the definition of a more comfortable proof principle to future work.

Comparison with Works adjacent to ITrees