A Formal Theory of Choreographic Programming

Choreographic programming is a paradigm for writing coordination plans for distributed systems from a global point of view, from which correct-by-construction decentralised implementations can be generated automatically. Theory of choreographies typically includes a number of complex results that are proved by structural induction. The high number of cases and the subtle details in some of these proofs has led to important errors being found in published works. In this work, we formalise the theory of a choreographic programming language in Coq. Our development includes the basic properties of this language, a proof of its Turing completeness, a compilation procedure to a process language, and an operational characterisation of the correctness of this procedure. Our formalisation experience illustrates the benefits of using a theorem prover: we get both an additional degree of confidence from the mechanised proof, and a significant simplification of the underlying theory. Our results offer a foundation for the future formal development of choreographic languages.


Introduction
In the setting of concurrent and distributed systems, choreographic languages are used to define interaction protocols that communicating processes should abide to [21,25,37].These languages are akin to the "Alice and Bob" notation found in security protocols, and inherit the key idea of making data communication manifest in programs [34].This is usually obtained through a linguistic primitive like Alice.e → Bob.x, read "Alice communicates the result of evaluating expression e to Bob, which stores it in its local variable x".
In recent years, the communities of concurrency theory and programming languages have been prolific in developing methodologies based on choreographies, yielding results in program verification, monitoring, and program synthesis [2,24].For example, in multiparty session types, types are choreographies used for checking statically that a system of processes implements protocols correctly [23].Further, in choreographic programming, choreographic languages are elevated to full-fledged programming languages [32], which can express how data should be pre-and postprocessed by processes (encryption, validation, anonymisation, etc.).
Choreographic programming languages come with a procedure known as Endpoint Projection (EPP), which automatically synthesises executable code for each process described in a choreography, with the guarantee that executing these processes together implements the communications prescribed in the choreography [4,5].These languages showed promise in a number of contexts, including parallel algorithms [9], cyber-physical systems [20,29,30], self-adaptive systems [17], system integration [19], information flow [28], and the implementation of security protocols [20].
EPP involves three elements: the source choreographic language, the target process language, and the compiler.The interplay between these components, where a single instruction at the choreographic level might be implemented by multiple instructions in the target language, makes the theory of choreographic programming error-prone: for even simpler approaches, like abstract choreographies without computation, it has been recently discovered that a few key results published in peer-reviewed articles do not hold and their theories required adjustments [36], raising concerns about the soundness of these methods.
This article presents a formalisation of a core theory of choreographic programming in the theorem prover Coq, the process of developing this formalisation, the challenges encountered, and how tackling these challenges led to improvements of the original theory.
A note on the process.We argue that computer-aided verification can be successfully applied to the study of choreographies and to provide solid foundations for future developments.To substantiate this claim, we summarise the story behind this article, which illustrates how interactive theorem proving can do more than just checking what we already know.
Our starting point was the theory of Core Choreographies (CC), a minimalistic language that the first two authors previously proposed for the study of choreographic programming [12].CC includes only the essential features of choreographic languages and minimal computational capabilities at processes (computing the successor of a natural number and deciding equality of two natural numbers), yet it is expressive enough to be Turing complete.
We started formalising CC in Coq in late 2018.In mid-2019, we gave an informal progress report on the promising status of the formalisation at the TYPES conference [13].Unfortunately, we soon stumbled upon an unexpected source of complexity for the formalisation: a set of term-rewriting rules for a precongruence relation used in the semantics of the language for (i) expanding procedure calls and (ii) reshuffling independent communications to model concurrent execution.In addition to being time consuming, reasoning with precongruence systematically made the formalisation significantly more complicated than the development in [12] (for a more technical discussion, see Section 3.5).
At the time, the second author was responsible for a Master course on theory of choreography for students in Computer Science.It quickly became apparent that the technical aspects (including, but not only, structural precongruence) that complicated the formalisation of CC were also the most challenging for the students.This observation led that author to develop an alternative theory of CC for his course material that dispenses with these problematic notions without changing its essence [33].The formalisation in this article uses this revised choreography theory.
Thus, our work also shows that theorem proving can be used in research: the insights obtained while doing this formalisation led to changes in the original theory.We show that this did not come at the cost of expressive power: the original proof of Turing completeness from [12] still works for the theory in [33] without essential changes [15].Furthermore, formalising the theory also allowed us to identify unnecessary assumptions in some lemmas, yielding stronger results.
Publication history and contribution.As mentioned previously, a first informal progress report on this formalisation was presented at the TYPES conference in 2019 [13], following an approach that later turned to be unfeasible.The first formalisation of the choreographic language, including the proof of Turing completeness, was presented in [15], while the formalisation of EPP appeared originally in [14].The current presentation discusses an updated formalisation, which (i) no longer uses Coq's module system and (ii) differs significantly in the treatment of partial functions, which significantly simplifies the definition of EPP.We do not discuss the formalisation of the proof of Turing completeness, as this is essentially unchanged from [15].Instead, we place a stronger emphasis on the formalisation challenges compared to the works cited.
The big picture.This work is the first step towards a more ambitious goal: the development of a certified framework for choreographic programming.At a later stage, we plan on developing compilers that can translate the process implementations generated by EPP into executable code in different programming languages (see Fig. 1).This would yield end-to-end compilation from choreographies to actual executable code.
Our goal motivated two important design choices in the current work that are not present in [14,15].First, we want to extract a correct implementation of EPP from our formalisation; this required moving away from the usage of Coq's module system, as it does not support extraction.Second, we introduce the possibility of annotating terms in choreographies with data that may be needed for (secondstage) compilation to executable programming languages.Structure.A full understanding of the more technical details of our formalisation benefits from some background knowledge on choreographies.For convenience, Section 2 features a short introduction to the main intuitions and results of choreography theory, which can be skipped by readers familiar with the topic.Our choreographic language (syntax and semantics) is presented together with its Coq formalisation in Section 3, where it is also shown that it enjoys the usual properties of choreographic languages.Section 4 defines the target process language, together with its semantics.EPP is formalised in Section 5, and its soundness and completeness are discussed in Section 6.We review related formalisation efforts in Section 7, before concluding in Section 8.
The source code of our Coq development is available at [16].
2 Background: Choreographic Languages and Endpoint Projection In this section we describe the language of Simple Choreographies [33], which introduces the basic principles of choreographies and EPP.We include this material to make our development accessible to the reader not familiar with the topic, but it is not directly used in our development.

Simple Choreographies
Simple Choreographies can express finite sequences of communications between processes.Processes are identified by names (p, q, etc.).Choreographies, ranged over by C, are constructed according to the following grammar.
C ::= p → q; C | 0 A choreography p → q; C represents a communication from a process p to a process q with continuation C; 0 is the terminated choreography.We omit trailing 0s in examples.
Example 1 (Ring protocol [33]) The choreography below describes a ring protocol among three participants: Alice communicates to Bob; then Bob communicates to Carol; and finally Carol communicates back to Alice.

⊳
The semantics of Simple Choreographies is given as the labelled transition system induced by the rules displayed in Figure 2. Transition labels have the form p → q, allowing for observing the communications performed by a choreography.
Rule com models the execution of a communication at the beginning of a choreography.Rule delay, instead, allows for performing a transition within the continuation of a choreography, provided that the transition does not involve any of the processes in preceding instructions.This rule captures the fact that processes run independently of each other, and thus choreographic instructions can be executed out-of-order.The independence requirement is captured by the the side-condition {p, q} # {r, s}, where # relates disjoint sets.
Example 2 (Ring protocol, continued [33]) Let C be the choreography in (1).Then, by rule com, we have the following chain of transitions.
These communications cannot be executed out-of-order, because of the chain of causality between them: each instruction involves a process that needs to participate in a previous instruction.

⊳
Example 3 Consider now the choreography (inspired from the factory examples in [33]), which models a system where two "ordering" processes o 1 and o 2 independently communicate two respective orders to the servers s 1 and s 2 .
The following derivation shows that o 2 → s 2 can be executed first.

Simple Processes
Implementations of Simple Choreographies are modelled in a process language called Simple Processes [33].First, we define a grammar for writing process behaviours.
These actions are the local counterparts to the communication action in choreographies.A send action p! sends a message to a process p, and the dual receive action p? receives a message from a process p.The term 0 is the terminated process.
Processes are composed into networks (N, M , etc.), which are maps from process names to processes.We introduce some notation: 0 is the terminated network, where all process names are mapped to 0; p[P ] is the network where p is mapped to P and all other process names are mapped to 0; and N | M ("N parallel M ") is the union of N and M , assuming that their supports 1 are disjoint.Under extensional equality of functions, the set of networks equipped with parallel composition forms a partial commutative monoid with 0 as identity element: [33].

Example 4
The following network implements the choreography in (1).

⊳
The semantics of Simple Processes is given by the transition rules in Figure 3. Rule com synchronises processes with matching send and receive actions.Rule par allows for parallel execution.
Example 5 The transitions of the choreography in (1) coincide with those of the network in (3).Technically, the labelled transition systems generated by the choreography and the network are isomorphic, showing that the network is indeed a precise implementation of the choreography.

⊳
Example 6 Out-of-order execution for choreographies corresponds to parallelism at the level of networks.The following network implements the choreography in (2).
Using rule par and the monoidal structure of parallel composition, the network can start by executing either the communication between o 1 and s 1 or the one between o 2 and s 2 .

Endpoint projection
In general, writing correct implementations of protocols is hard, especially for more expressive choreographic languages as the one that we use later in this article.Endpoint projection (EPP) is a mechanical procedure for translating choreographies into networks by splitting choreographic terms into their local counterparts [4,5,12,23,33].The idea is that given a choreography C and a process p, we 1 The support of a network is the set of all processes not mapped to 0. first compute the process term C p that implements the actions that p should perform to implement its part in C.Then, EPP is defined as the parallel composition of all such terms.In the case of Simple Choreographies and Simple Processes, the process projection map C p is defined in a natural way by the recursive equations in Figure 4.In particular, a communication term p → q; C is projected to a send action and the projection of the continuation if we are projecting the sender (first case), a receive action and the projection of the continuation if we are projecting the receiver, or just the projection of the continuation if we are projecting a process that is not involved in the communication.
Given a choreography C, its EPP C is defined as the network C (p) = C p.This network is a correct implementation of C.
Theorem 1 (Correctness of EPP [33]) The following statements hold for every choreography C and transition label µ in the language of Simple Choreographies.

Taking Stock
Theorem 1 is used to prove other notable results given by the choreographic approach, such as deadlock-freedom.A deadlocked network is one that is not terminated but cannot make any transitions, typically because all processes are waiting for someone else.Even in a simplistic process language such as Simple Processes, we can write deadlocked networks, such as: Here, p and q are both waiting for each other, and therefore the network will never be able to proceed.
Since communication terms in choreographies specify simultaneously what sender and receiver processes are involved, choreographies cannot describe deadlocks, a property known as deadlock-freedom by design [5].As a consequence of Theorem 1, the networks generated by EPP can never become deadlocked.
The choreographic language that we consider in the rest of our article is more expressive than Simple Choreographies, as it includes features that are important for modelling realistic protocols.However, the general structure of the development follows the roadmap given in this section, albeit with a much higher level of complexity.

Core Choreographies
We introduce Core Choreographies (CC), the choreographic language that we work with, and its formalisation.At the end of this section, we discuss how the formalisation process guided the evolution of the language from its original presentation in [12] to its present form, which is closer to the style of [33].
In CC, processes can perform point-to-point communications and have storage.Communicated messages can be either values, which are computed by evaluating local expressions, or labels (tags, or constants) from a fixed set {left, right}.2Additionally, choreographies can include conditionals based on Boolean expressions and invoke recursive procedures.

Preliminaries
Choreographies are parameterised on a signature, which defines the types for process names (processes for short) pid, local variables var (used to access the processes' storage), values val, expressions expr, Boolean expressions bexpr, and procedure names recvar (from recursion variables).Signatures also include types for (user-defined) annotations ann (as discussed in Section 1).Since the types of expressions and values are parameters, signatures also need to specify the evaluation functions mapping expressions to values and Boolean expressions to Booleans.We fix a signature Sig and introduce abbreviations Pid := (pid Sig) and similarly for all other parameters for convenience.
The first seven parameters are datatypes equipped with a decidable equality.Since we are targetting extraction, which is not compatible with modules, we reimplemented DecType as a record type consisting of exactly these two components, and reproved the lemmas about decidable equality from the Coq standard library.We also show that the Cartesian product of two DecTypes can be made into a DecType, and we define a two-element decidable type Label whose elements are the two labels left and right.
Evaluation functions are again records.The first element is a function that takes an expression and a mapping from a process's variables to values, and returns a value (possibly of a different type as the one stored locally).The second element is a proof that the value returned by evaluation does not change if the mapping from variables to values is replaced by an extensionally equivalent one.
The type State := Pid → Var → Value models the memory state of the set of all processes. 3We define extensional equality on states, written [==], and prove that it is an equivalence relation.Furthermore, we define an operation s[[p, x ⇒ v]] for updating the state s with the assignment of value v to process p's variable x, and prove a number of useful rewriting lemmas.

Syntax
Choreographies are defined inductively by the following grammar.
Here, p, q: Pid are processes, e: Expr is an expression, x: Var is a variable, l: Label is a label, a: Ann is an annotation, b: BExpr is a Boolean expression, X: RecVar is a procedure name, and ps:list Pid is a list of processes.
The terms denoted η are called interactions; for many results, it is convenient that they form their own type.Term p#e −→ q$x is a value communication, where p communicates the result of evaluating e to q, which stores it in its local variable x.Term p −→ q[l] is a label selection, where p communicates label l to q.
Label selections are used in conjunction with conditionals.In a conditional If p ?? b Then C1 Else C2, the evolution of the choreography is determined by the outcome of evaluating the Boolean expression b at p. Other processes that need to know which branch was chosen (knowledge of choice [6]) can get this information through the reception of label left or right from p.
Interactions are paired with annotations (a), which are not used in this work.They are meant to include additional information that may be needed in subsequent processing steps, such as documentation or the second-stage compilation mentioned in Section 1.We omit annotations in all our examples.
Term Call X invokes the procedure named X.A procedure may involve several processes, and the semantics of CC allows each process to join the procedure only when needed.The runtime term RT_Call X ps C represents this intermediate situation: execution of procedure X has already evolved to C, but the processes in ps have not yet joined it.Runtime terms are not meant to be written by programmers: they are auxiliary terms generated by the semantics.
The grammar of choreographies is defined as the following inductive types.A set of procedure definitions, formalised as type DefSet, is a mapping assigning to each RecVar a list of processes and a choreography; intuitively, the list contains the processes that are used in the procedure.A Program is a pair containing a set of procedure definitions and the choreography to be executed at the start, also called the main choreography.We write Procedures P and Main P for, respectively, the set of procedure definitions and the main choreography in a program P (so Procedures and Main are simply aliases for the corresponding projections).Likewise, Vars P X and Procs P X denote the list of processes and the definition of a particular procedure X within P. Finally, Names D is the function mapping each variable X to the set of processes that it uses according to D: DefSet.
Example 8 (Distributed Authentication) The choreography C1 below describes a multiparty authentication scenario where an identity provider ip authenticates a client c to server s. (For convenience, we name some of the subterms in the choreography.) C1 starts with c communicating its credentials to ip, which stores them in x.Then, ip checks whether the received credentials are valid by evaluating the Boolean expression check x, and signals the result to s and c by selecting left when the credentials are valid (C1t) and right otherwise (C1e).In the first case, the server communicates a token to c, otherwise the choreography simply terminates.
The selections from ip to s and c address knowledge of choice, as previously described.
⊳ Well-formedness.There are a number of well-formedness requirements on choreographies, which can be grouped in three categories.
1. Intended use of choreographies.Interactions must have distinct processes (there are no self-communication), e.g., p#e −→ p$x is disallowed.2. Intended use of runtime terms.Procedure definitions may not contain runtime terms.Main P may include subterms RT_Call X ps C, but ps must be nonempty and include only process names that occur in Vars P X. 3. Design choices in the formalisation.The processes in Vars X include all processes that are used in Procs X.
Well-formedness is essential in the proof of correctness of EPP (Section 6).We start by formalising the different properties of choreographies separately: -initial C holds if C does not contain runtime terms (RT_Call); -no_self_comm C holds if C contains no self-communications; -no_empty_ann C holds if all runtime terms in C have nonempty lists of process names.
These properties are defined recursively over C in the natural way.Well-formedness of choreographies Choreography_WF is defined as the conjunction of the last two properties.
Well-formedness of programs also takes into account the additional requirements on the lists of processes annotating runtime terms.Specifically, in a program P, the choreography Main P must be consistently annotated with respect to Vars P: in any subterm RT_Call X ps C' in Main P, the list ps only contains processes appearing in Vars P X.This property is written as consistent (Vars P) (Main P), where predicate consistent: (RecVar → list Pid) → Choreography → Prop is defined inductively in the expected way.Also, the set of procedure definitions in P must be well-annotated: if Procedures P X=(ps,C), then the set of processes used in C must be a nonempty subset of ps. 5efinition well_ann (P:Program) (X:RecVar) : Prop := Vars P X = nil ∧ CCC_pn (Procs P X) The last definition uses function CCC_pn, which computes the set of processes occurring in a choreography, given the set of processes used in each procedure.It generalises to CCP_pn, which computes the set of processes occurring in a wellannotated program.
Using these ingredients, we define well-formedness of programs as follows.
Definition Program_WF (P:Program) : Since initial choreographies do not include runtime terms, this definition also implies that all procedure definitions are well-formed.
Example 9 Let Defs:DefSet map FileTransfer to the pair consisting of the process list c :: s :: nil and the following choreography.FileTransfer describes a file transfer protocol between a server s and a client c using Cyclic Redundancy Checks (crc) to detect errors from a noisy channel.
Assuming that Defs maps all other procedure definitions to End, the program P=(Defs,Call FileTransfer) satisfies Program_WF P.

⊳
Recall that our long-term future goal is to apply program extraction to this formalisation, and then use the result in tools.Many of the results that we show later only hold for well-formed programs, and any tool built on our theory should be able to validate that its input is well-formed.However, due to the quantification over all procedure names, well-formedness of programs is in general not decidable.In practice, though, choreographic programs only use a finite number of procedures; if these are known, well-formedness becomes decidable.
This observation motivates the definition of a recursive predicate used_procedures_C : Choreography → list RecVar → Prop such that used_procedures_C C Xs holds iff C only calls procedures in Xs (directly).This is generalised to programs by requiring that all procedures in Xs also satisfy the same property, and additionally that all procedures not in Xs be defined as End.
Definition used_procedures The requirement Vars P X = nil for procedures not in Xs is included to ensure wellformedness.From this, we can prove decidability of well-formedness.
Applying this lemma in extracted code requires knowing a suitable set Xs.While we cannot automatically verify that this set satisfies used_procedures P Xs, it is very reasonable to trust that a correct one has been provided: typically, the relevant procedures used in a program are written down explicitly, making it straightforward to list them.An alternative approach would be requiring the set of procedure names to be finite.This is closer in spirit to the pen-and-paper presentations of choreographic languages -even if procedure names are taken from an infinite set, only a finite number of them can be used in a concrete program [12].We chose the present approach for simplicity, as working with finite sets in Coq is notoriously cumbersome.

Semantics
The semantics of CC is defined by means of labelled transition systems, in three layers.At the lowest layer, we define the transitions that a choreography can make (CCC_To), parameterised on a set of procedure definitions; then we pack these transitions into the more usual presentation -as a labelled relation CCP_To on configurations (pairs program/state).Finally, we define multi-step transitions CCP_ToStar as the transitive and reflexive closure of the transition relation.This layered approach makes proofs about transitions cleaner, allowing us to separate the different levels of induction.
Transition labels.Each layer of the semantics has its type of transition labels.For the lower level, we define an inductive type RichLabel whose constructors reflect the possible actions a choreography can take: value communications, label selections, reducing a conditional, or locally joining a procedure call.
The second layer uses the type TransitionLabel of labels corresponding to the observable actions.The two types are connected by a function forget:RichLabel → TransitionLabel.Labels in the third layer are simply lists of TransitionLabels.Pen-and-paper presentations only include TransitionLabels, which capture what can be observed in transitions without revealing syntactic information about the choreography.However, in Coq, this information is needed to obtain induction hypotheses that are strong enough for our development, which is why we have introduced RichLabels.
The transition relations are defined inductively by the rules in Figures 5 to 7. For readability, we present them in a more standard rule notation -below, we   The rules defining CCC_To can be divided into three groups, which we describe in the following paragraphs.
Transition rules.Rules C_Com, C_Sel, C_Then and C_Else deal with execution of the first action in a choreography.
As an example, rule C_Sel corresponds to a constructor Including the requirement s [==] s' instead of simply writing s in the conclusion is essential for enabling transitions between different intensional representations of the same state, which occur in practice.In particular, confluence (discussed below) does not hold without this formulation.The corresponding more compact rules are proved as lemmas, e.g., Lemma C_Sel' : ≪p −→ q[l] @a;; C,s≫ −−[RL_Sel p q l,D] −→ ≪C,s≫.
These formulations can be useful in proofs that use existential tactics to infer a previously uninstantiated target of a transition.
Procedure calls.Rules C_Call_Local, C_Call_Start, C_Call_Enter and C_Call_Finish allow a process to enter a procedure call, with different cases according to whether other processes have already entered the procedure and/or whether there are any other processes that still have to join it.A procedure call is expanded when the first process joins it (rule C_Call_Start).The remaining processes and the procedure's definition are stored in a runtime term, from which we can observe transitions either by more processes entering the procedure (rule C_Call_Enter) or by out-of-order execution of internal transitions of the procedure (rule C_Delay_Call, discussed below).When the last process enters the procedure, the runtime term is consumed (rule C_Call_Finish).Rule C_Call_Local addresses the edge case of a procedure that only uses one process.
Out-of-order execution.Rules C_Delay_Eta, C_Delay_Cond and C_Delay_Call deal with out-of-order execution (cf.Example 3).These rules require that the processes involved in the transition do not appear in the first term in the choreography; these conditions are specified by auxiliary predicates defined straightforwardly.The state st is immaterial.

⊳
We prove a number of useful low-level properties about transitions.For example, we show that transitions are preserved by state equivalence.
This result generalises to CCP_To and CCP_ToStar.Likewise, we show that: the set of processes involved in a choreography cannot increase during execution; transitions preserve well-formedness and the set of procedure definitions; well-formed choreographies do not perform self-communications; and terminated choreographies cannot perform transitions.

Progress, Determinism, and Confluence
The challenging part of formalising CC is establishing the core properties of the language semantics, which are essential for more advanced results and not always proven in full detail in pen-and-paper publications.We discuss some of the issues encountered, as these were also the driving force behind the changes relative to [12].The first key property of choreographies is that they are deadlock-free by design: any choreography that is not terminated can execute.Since the only terminated choreography in CC is End, this property also implies that any choreography either eventually reaches the terminated choreography End or runs infinitely.The second property of our semantics is that it is deterministic, in the sense that transitions can be uniquely inferred from their label or the resulting state.These properties are essential for later results, and the need for them was the original motivation for introducing type RichLabel -the first group of results does not hold if TransitionLabels are used in the definition of CCC_To.
The third key property is confluence, which has some relevant implications for our calculus: if a choreography has two different transition paths, then these paths either end at the same configuration, or both resulting configurations can reach the same one.This is proved by first showing the diamond property for choreography transitions, then lifting it to one-step transitions, and finally applying induction to show it for multistep transitions.
As an important consequence, we get that any two executions of a choreography that end in a terminated choreography must finish in the same state.
Using these results, we can establish Turing completeness of CC, in the sense that all of Kleene's partial recursive functions [27] can be implemented as a choreography for a suitable notion of implementation.The structure of the proof closely follows that of [12], and has been described in [15]; the interested reader is referred to those works for details.

Discussion
Formalising the proof of confluence following [12] turned out to be a spiralling process: the pen-and-paper proof assumes some obvious properties, which were not proved; proving these required some additional lower-level lemmas; these in turn generated some even more specific lemmas; and so on.At some point, we realised that the auxiliary lemmas accumulated already accounted for 90% of the formalisation.Worse, these lemmas were extremely specific and detached from the contents of [12] -even though we were far from done.This led us to rethinking the design of CC, and eventually to adopting the language of [33].
In this section, we discuss the features of the original language that turned out to be problematic.These regarded the handling of procedure definitions (syntax) and the treatment of procedure calls and out-of-order execution (semantics).
Syntax.Procedures were initially defined by including a term def X=CX in C in the grammar defining choreographies.While this removed the need for a separate notion of program, it introduced several dimensions of complexity.Even the notion of terminated choreography was nontrivial, since End could occur arbitrarily deep inside some of these terms.This made it hard to ensure that the Coq definition was an adequate representation of the informal notion in [12], affecting all results regarding termination, progress, and deadlock-freedom.With the current syntax, terminated programs are exactly those whose for which Main P=End.
Additionally, the name X in def X=CX in C acts as a binder, which added all the usual problems of working with binders -in particular, having to deal with capture-avoiding substitutions and α-renaming.In the current language, procedure names are statically determined and fixed, so there is no need to rename them ever, and they can be treated as constants.This constructor also allowed for unintuitive choreographies, e.g., def X=CX in C where the choreography CX itself contains additional procedure definitions.
Pairing procedure definitions with choreographies in programs yields a cleaner theory, and the overhead of an additional layer is a very small price to pay for the simplicity gained.This approach had been proposed earlier [11], and the two formulations are argued to be equally expressive in [8].
Semantics.Instead of a labelled transition system, the semantics of [12] was a reduction semantics that used a structural precongruence relation to model outof-order execution and to unfold procedure definitions.
To understand this issue, consider again Example 3, which shows a choreography that has two possible initial transitions.In a framework with reductions and structural precongruence, the out-of-order transition is obtained by first rewriting the choreography as o 2 → s 2 ; o 1 → s 1 and then applying rule com.The set of legal rewritings is formally defined by the structural precongruence relation , and there is a rule in the semantics that closes the transition relation under it.
In any proofs about the semantics, an approach using structural precongruence needs to take into account all the possible ways into which choreographies may be rewritten in a reduction.Concretely, in the proof of confluence, where there are two reductions, there are four possible places where choreographies are rewritten; given the high number of rules defining structural precongruence, this led to an explosion of the number of cases.Furthermore, induction hypotheses typically were not strong enough, requiring us to resort to complicated auxiliary notions such as explicitly measuring the size of the derivation of transitions, and proving that rewritings could be normalised.This process led to a seemingly ever-growing number of auxiliary lemmas that needed to be proved, with no counterpart in the original reference [12], and after several months of work with little progress it became evident that the problem lay in the formalism.
Summary.The current proof of confluence takes about 300 lines of Coq code, including a total of 11 lemmas.This is in stark contrast with the previous attempt, which while still unfinished already included over 30 lemmas with extremely long proofs.
With the current definitions, the theory of CC is formalised in two files.The first file, which defines the preliminaries, contains 24 definitions, 60 lemmas and around 740 lines of code.The second file, defining the syntax and semantics of CC and proving properties about it (including all the ones described herein), contains 32 definitions, 126 lemmas, 2 theorems and around 2300 lines of code.

The process language
The second part of our formalisation concerns the process calculus that we use for implementing CC: Stateful Processes (SP).We follow the pen-and-paper design presented in [33].SP is used to define networks of processes running in parallel, each with its own behaviour, that can interact by direct messaging.

Syntax
The syntax of SP is structured in three layers: behaviours, which express the local actions performed by individual processes; networks, which combine processes in a system where they can interact; and programs, which pair a network with a set of procedure definitions (which all processes can call).As with CC, we assume an underlying signature.
The constructors for behaviours correspond to those for choreographies, but interactions are now split between the two different roles involved (sender and receiver).The type Behaviour is defined inductively from the grammar below.Conditionals, procedure calls, and the terminated behaviour are standard and similar to the corresponding constructs in CC.
A term p! e @! a represents a send action towards p, where e is the expression used to compute the value to be sent and a is an annotation.Dually, a term p?x @? a represents a receive action where a value received from p is stored in the local variable x (a is, again, an annotation).
A selection action p(+)l @+ a; B is similar to a send action (label l is sent to p).The dual action needs to offer a behaviour for l, but may also accept other labels.In pen-and-paper presentations, these branching terms are typically defined as partial functions from labels to behaviours.
Formalising this informal description is challenging.A natural choice would be to include a constructor Branching : Pid → (Label → option Behaviour) → Behaviour.However, this is problematic for defining EPP, which relies on a recursively defined function on pairs of behaviours called merging (cf.Section 5.1).Defining this function directly in Coq is unwieldy because of the complexity of writing the appropriate term of type Label → option Behaviour given the corresponding subterms from the arguments.
Using partial functions also seems like an overkill, considering that there are only two possible labels.Instead, we include a constructor Branching : Pid → option (Ann * Behaviour) → option (Ann * Behaviour) → Behaviour that registers explicitly the behaviours offered for each of the two possible labels, in order.This design choice avoids the aforementioned issues, at the cost of making our development harder to generalise to larger sets of labels in the future.
Because of the option types in Branching, the induction principles generated automatically for Behaviour are not strong enough (they do not include induction hypotheses over the Behaviours appearing within branching terms).To overcome this, we define an auxiliary function depth:Behaviour → nat measuring the depth of the AST corresponding to a Behaviour, use it to prove the expected general induction principle, and define a tactic BInduction B that applies it.
Networks.Networks are simply (total) functions from processes to behaviours.
We define extensional equality of networks N (==) N' in the expected way and show that it is an equivalence relation.We support the common notation for writing networks by including a function for constructing singleton networks p[ B] , a parallel composition operator N | N' , and a removal operator N \ p (recall the description in Section 2).
For simplicity, we do not require disjoint support in parallel composition: if both networks define a nonterminated behaviour for p, the result of (N | N' ) p and (N' | N) p is different.Although this may seem odd, it has the advantage of making parallel composition total.We show that parallel composition is commutative under the assumption that the two composed networks have disjoint supports.Our library includes a number of results to reason about the network operations, including very specific lemmas dealing with networks that appear in the rules defining the semantics of SP, e.g., that updating the behaviours of two distinct processes yields the same result independent of the order of the updates.
Programs and well-formedness.As before, a program is a pair consisting of a set of procedure definitions and a network.Well-formedness is significantly simpler than for choreographies.If B: Behaviour, then B is well-formed, Behaviour_WF B, as long as no process in B attempts to communicate with itself.N: Network is well-formed, Network_WF N, if all processes are mapped to well-formed behaviours.This is not decidable in general, but it is under the assumption that all processes outside a given set ps are mapped to End -an assumption that holds for all networks that can be written explicitly using parallel composition of singleton networks.
Well-formedness of programs does not make sense: well-formedness of a behaviour depends on who is executing it, but a procedure definition has no information about which processes will call it.N p = (q ! e @!a ; B) N q = (p ?x @? a'; B' )

Semantics
The semantics of SP is again defined by a labelled transition system.Transitions for communications match dual actions in two processes, while conditionals and procedure calls simply run locally.There are again three layers of definitions, which are shown in Figures 8 to 10 These definitions warrant similar observations as those for the semantics of CC.Transitions include premises on network equality and state equality, rather than requiring specific values.We include some lemmas stating the more restricted rules, both as a sanity check and because they can be useful to instantiate variables created by the use of existential tactics in proofs.
Lemma S_LSel' : N p = (q (+) left @+ a ; B) There are two rules for reducing selections, one for each label.This is a deviation for standard practice (where there is a single rule and a premise matching the label in both behaviours) stemming from our design choice of avoiding functions in branching terms.Having an extra rule generates additional cases in induction proofs, but this formulation effectively simplifies the formalisation by eliminating one layer of inversion.

Example 13
We illustrate the possible transitions of the network from Example 12.We abbreviate the behaviours of processes that do not change in a reduction to ... to make it clearer what parts of the network are changed.Furthermore, we omit trailing Ends in Behaviours.
The network starts by performing the transition where v1 and st2 are as in Example 10.If eval_on_state (check x) st2 ip=true, execution continues as where v2 and st3 are again as in Example 10.Otherwise, it continues as follows.
The labels in these reductions are exactly as in Example 10.

Determinism and confluence
As for CC, we prove a number of useful results about the semantics of SP.These can be roughly divided in two groups: results showing that reductions are stable under the extensional equalities on the different types involved, and properties on the actual transitions.While the results in the first category are not surprising, they are useful and show that the definitions make sense.While determinism and confluence are similar to the corresponding results to CC, they are not as interesting: for networks generated by EPP (which are the ones we are interested in), these results would follow by the same properties for choreographies.
The formalisation of SP consists of 25 definitions, 81 lemmas, 11 simple tactics, and approximately 1960 lines of Coq code.

Endpoint projection
As with the simple language from Section 2, the intuition for generating process implementations is that each choreographic action should be projected to the corresponding process action.The prototypical example is the value communication p#e −→ q$x @a, which should be projected to a send action q! e @!a for p, to a receive action p?x @?a for q, and skipped for any other processes.
In the presence of conditionals, this intuition is not enough.Projecting a conditional If p. b Then Ct Else Ce for any process other than p, say q, is nontrivial, because q has no way of knowing which branch should be executed.Therefore q's behaviour must combine the projections obtained for Ct and Ce.
This problem is commonly known as knowledge of choice, and one of the solutions relies on the usage of label selections [4,6].If q's behaviour should depend on the result of p's local evaluation, then the result of this evaluation should be communicated to q by means of a label selection.The two possible behaviours can then be combined in a branching term offering two different options.

Merge
A standard way of combining behaviours to solve the problem above is the merge operator [4]: a partial binary operator that returns a behaviour combining all possible executions of its arguments (if possible).In SP, two behaviours can be merged only if they are built from the same constructor with matching parameters.So if B1 can be merged with B2 to yield B, we can also merge p?x @? a; B1 with p?x @? a; B2 to obtain p?x @? a; B, but p?x @? a; B1 can never be merged with q?x @? a; B2 for p = q (different arguments) or with q! e @! a; B2 (different constructor).
The only exception is branching terms, where merge can combine offers on different labels.For example, merging p & Some (a,B) // None with p & None // Some (a',B' ) yields p & Some (a,B) // Some (a' , B' ).In this way, the prototypical choreographic conditional If p??b Then (p−→ q[left];; q.e −→ p;; End) Else (p−→ q[right];; End) can be projected for q as p & Some (p!e; End) // Some End.
The partiality of merge again poses a formalisation problem.Our original approach [14] defined an auxiliary type XBehaviour that extends the syntax of behaviours with a constructor XUndefined : XBehaviour.In this work, instead, we define a ternary relation merge : Behaviour → Behaviour → Behaviour → Prop. 6While this design requires two additional lemmas stating that this relation is functional and computable, it significantly simplified this part of the formalisation (both in size and complexity of the proofs).As an example, [14] reported a number of inversion results, e.g., if merging two behaviours yields a behaviour starting with a send action, then both arguments start with that same action.All these results can now be obtained directly by applying inversion on the relevant hypotheses.
The full definition of merge includes 22 clauses.Figure 11 lists all representative cases; the missing clauses deal with the remaining combinations of None / Some subterms in branching terms (see Section 5.5 for a discussion on the exponential dependency of the number of clauses on the number of labels).We also define the suggestive notation B1 [ V] B2 == B for merge B1 B2 B, which reminds us that merge is a partial function.
We show that merge is functional, decidable, and preserves well-formedness.
Decidability is formulated using the stronger existential quantifier so that we can also obtain the existential witness to use in further definitions.

Branching order
In the literature, the arguments of merge and its result, when defined, are in a relation known as the branching order [4,33].This is formalised as yet another inductive type, defined by the rules in Figure 12. 7 We call the relation more_branches, for which we define the infix notation The branching order is reflexive, transitive and antisymmetric.It is pointwise extended to networks by defining N (≫) N' := ∀ p, N p [ ≫] N' p where (≫) is infix notation for more_branches_N : Network → Network → Prop.This relation is again reflexive, transitive and antisymmetric (with respect to extensional equality).
More interestingly, adding branches to some behaviours in a network does not eliminate any transitions that the network can do.
(The quantification on D' makes this lemma easier to apply.) We can now justify the notation for merge: it is the partial join for the branching order, in the sense that if two behaviours have an upper bound, then they are mergeable and their merging is their least upper bound.
x @?a; B1 [V] p?x @?a; B2 == p?x @?a; B merge_Recv Another key result is that the branching order is stable under merging: As we will see, this result is essential for the cases of the EPP theorem dealing with conditionals.Lastly, we prove the algebraic properties of merge -idempotency, commutativity, and associativity -by exploiting the relationship between merge and the branching order.

Projection
We can now define the projection of a choreography for an individual process.Since this definition relies on merge for the case of the conditionals, it is also a partial function.We define it inductively as a relation The type of bproj also reveals a new feature of projection when compared to the simple language from Section 2: the signature for the target instance of SP is different than that of the source instance of CC.The reason for this lies in the presence of procedure definitions: each procedure yields several projected procedures, one for each process in the choreography. 8The type of procedure names in the target of projection is thus RecVar * Pid; this can be seen in the rule for projecting procedure calls, which is included with the remaining rules in Figure 13.
We show that bproj is functional and decidable, and that it returns well-formed behaviours for choreographies without self-communications.
@a ;; C | q]]== p?x @?a; B bproj_Recv From bproj we obtain several notions of projectability: relative to a process or a set of processes, and projectability of D: DefSet -which requires each procedure to be projectable relative to its set of used processes.A program is projectable if the main choreography is projectable for all its processes and the set of procedure definitions is projectable.
Finally, we want to compute projections, which are again partial functions.Since our ultimate goal is to extract a correct implementation of EPP, we need to take a different approach to partiality and define taking a proof term as additional argument (for which we prove proof irrelevance).These definitions are interactive, so we also state and prove lemmas showing that they yield the expected results as in pen-and-paper presentations [12,33].
Paving the way for the EPP theorem, we prove a number of inversion lemmas for EPP, which cannot be trivially obtained by applying inversion to a hypothesis.Lemma epp_C_Cond_Send_inv : epp_C D ps (If p ?? b Then C1 Else C2) HC r = q!e @!a B → ∃ B1 B2, epp_C D ps C1 HC1 r = q!e @!a B1 ∧ epp_C D ps C2 HC2 r = q!e @!a B2 ∧ B1 [V] B2 == B.

Strong projectability
The operational correspondence between choreographies and their projections, which is the topic of Section 6, states that a projectable choreography can make a transition iff its projection can make a corresponding transition.Generalising this result to multi-step transitions requires chaining applications of this correspondence.However, projectability is not preserved by transitions, due to how runtime terms are projected: RT_Call X ps C' is projected as Call (X, p) if p is in ps, and as the projection of C' otherwise.Our definition of projectability allows C' to be unprojectable for any process in ps, which would make the result of the latter transition unprojectable.This situation can never arise if one respects the intended usage of runtime terms: initially C' is the body of a procedure, and ps is the set of processes used in it.Afterwards ps only shrinks, while C' may change due to execution of actions that involve processes not in ps (which keeps C' projectable).This assumption is implicit in pen-and-paper presentations.We formalise it in the following definition of strong projectability.The last conjunct in the case of conditional is needed to guarantee that strong projectability implies projectability.The last conjunct in the case of runtime terms captures the notion that C' may differ from the original definition of procedure X, but the transitions in the reduction path did not involve processes that still have to execute the procedure call.
Projectability and strong projectability coincide for initial choreographies.Furthermore, we state and prove lemmas that show that str_proj D C r implies both projectable_B D C r and str_proj D C' r for any choreography C' that C can transition to.(This is the reason for including the last conjunct in the clause defining strong projectability of conditionals: without it, we still would not be able to prove that projectable_B D C' r.) Strong projectability for programs requires as expected that all choreographies in the program be strongly projectable.Furthermore, we also require the program to be well-formed.This assumption makes the definition simpler and more manageable, as all procedures will be initial and annotated with the right sets of processes.
Using these results, we can start relating the semantics of choreographies with the definition of EPP.For example, if C can execute a communication from p to q, then the behaviour of its projection for p starts by sending the corresponding expression to q, while q's behaviour starts by receiving a value from p. Lemma CCC_To_bproj_Com_q : An interesting corner case is what happens for processes not involved in the transition: they may lose some subbehaviours in branching terms due to some branches of conditionals disappearing from the choreography.
The first hypothesis states that the procedures in D are well-annotated.
As a consequence of these lemmas, we get that strong projectability is preserved by transitions.The hypotheses of the first lemma all hold if (D, C) is a strongly projectable program.

Discussion
Modelling of partial functions.The definition of merge very explicitly considers the 2 4 = 16 possible combinations of behaviours that can be offered when both arguments are branching terms.This clearly does not scale if the set of labels is larger, and it is the place where our design choice of fixing it to a two-element set is most critical.The same issue, but with a smaller impact, arises in the definition of more_branches, which includes 2 2 = 4 clauses related to branching terms, and in the definition of bproj, which includes one clause for each branching term.We do not think that this issue can be circumvented.Our original approach considered an unspecified type Label:DecType, and branching terms had type This definition quickly proved unusable in practice: the induction principles generated by Coq were too weak, and most datatypes related to the process calculus had an undecidable equality.Furthermore we ran into problems with definitions that required inspecting the behaviours associated to the labels because of the size restrictions in elimination combinators.
The first time we managed to have a working definition of merge was after fixing the set of labels to contain two elements.This was the approach presented in [14], where merge is formalised by first defining a total function Xmerge : XBehaviour → XBehaviour → XBehaviour (where XBehaviour is a type including XUndefined subterms with the obvious intended meaning), and then defining merge B1 B2 as Xmerge (inject B1) (inject B2), where inject is the trivial injection from Behaviour to XBehaviour.
Apart from the added complexity of having duplications of types and definitions throughout the formalisation, working with these functions is very cumbersome.The definition of Xmerge relies heavily on deciding equalities, so proofs of results about Xmerge necessarily had to perform the same eliminations.At the end of the day, the number of cases in proofs was in the same order of magnitude as in the current version -but they were generated in several verbose elimination steps, rather than directly from performing induction/inversion on a hypothesis.Furthermore, the old definition required us to consider a significant number of absurd cases (in some lemmas, around 90% of the total), whereas with the current definition these cases are simply not generated.The only added complexity we noticed while adapting the formalisation was that we occasionally needed to apply lemma merge_unique to infer that two behaviours are identical -but the size of this part of the formalisation was reduced by about 80% (from around 3150 lines down to 700 lines).
Taking all these aspects into account, we believe that the current design choices are the most suitable for our theory.
Projectability.The lemmas relating projectability to the low-level semantics of choreographies typically include several hypotheses, cf.lemma CCC_To_str_proj.For programs, we packaged these properties in a single definition (str_proj_P).For the lower-level lemmas, we decided against this because not all these properties are needed in all lemmas -some are only required in results involving procedure calls, others are important for conditionals, and communications require far fewer.By including only the necessary assumptions in each lemma, we obtain more robust results.
Strong projectability.The need for strong projectability was independently identified in the pen-and-paper presentation in [33].There, the projectability requirement on runtime terms was included in the notion of well-formedness for choreographies.While this option matches the intuition of "intended usage of runtime terms", it requires having defined projection.In our formalisation, we strive for modularity, and we opted for a design where the choreographic calculus is fully decoupled from the target language and the definition of projection.In this way, we allow for future extensions of our development with alternative definitions of EPP.
In the future, it would be interesting to investigate whether there is a syntactic characterisation of "intended usage of runtime terms" that is completely at the level of choreographies.Such a characterisation would yield the benefits of both approaches described above: it would give us a notion of well-formedness closer to intuition, while keeping it decoupled from EPP.
Summary.The definitions of branching order, merge and Endpoint Projection, together with the accompanying lemmas, are divided in three files totaling 14 definitions, 126 lemmas and 15 tactics to automate recurring types of goals.By far the largest bulk is the formalisation of EPP, at over 2200 lines of Coq code (with approximately 100 lemmas), while the branching order and merge require respectively 260 and 440 lines of Coq code (with a total of only 3 results that require longer proofs).

The EPP theorem
The operational correspondence between choreographies and their projections, in languages that include both conditionals and out-of-order execution, is not as straightforward as for the simple language in Section 2. In particular, branching terms in networks may linger for a bit longer compared to the choreographies that generated them.This requires referring to the branching order in the EPP theorem: (Recall that epp takes a proof of projectability as its last argument.)Completeness is not too hard to prove.As in [12,33], the result is proven by considering the possible transitions that Main P can make; there are four cases, and the results proved earlier about the shape of the projection of P suffice to establish the thesis without too much work.The whole proof is 250 lines long, and the generalisation to multi-step transitions requires an additional 40 lines.
The proof of soundness is known to be harder [4,12,32,33].A common strategy is to proceed by induction on the choreography, and then do case analysis on the possible network transition.The latter is either the first term in the choreography, and we can apply the matching choreography rule; or it is not, and we can apply a delay rule and invoke the induction hypothesis.
Each of these cases is challenging in itself, and they are therefore stated as separate lemmas on transitions.As an example, the transition lemma for communications reads and the corresponding proof script is around 320 lines long.There are five of these lemmas in total, of a similar level of complexity.Soundness also requires an additional lemma on procedure calls: which is needed to apply the corresponding transition lemma.
Chaining applications of EPP_Sound also requires that extending the projection of a choreography with extra branches does not add transitions.This result is lifted to SPP_To and SPP_ToStar.The latter generalisation requires applying EPP_Sound.It is then itself used to prove soundness of EPP for multi-step transitions.
The proof of the EPP theorem consists of an additional 2650 lines of Coq code, for only 14 lemmas.

Related work
The need for formalising concurrency theory is identified in [31], where the authors formalised a published article on a process calculus in Coq and discovered several major flaws in the proofs.The authors [. . .] feel that it is [the errors'] very presence in a peer-reviewed, state-ofthe-art paper that strongly underlines the need for a more precise formal treatment of proofs in this domain.[31,Section 6] Since then, there have been a number of formalisation efforts in this area.We discuss the ones closest to our work.
To the best of our knowledge, our original presentations [14,15] were the first formalisations of a choreographic language featuring the expected programming constructs that allow for infinite and branching concurrent behaviour.As we discussed, this article presents a substantial improvement of the original development.
More recently, there have been two additions to the family of fully-formalised choreographic programming languages.
Kalas is a certified compiler written in HOL from a choreographic language similar to ours to CakeML [35].It includes an asynchronous semantics, but the notion of EPP is more restrictive than ours: it is an ad-hoc definition that bypasses the need for the merge operator, but does not provide its full flexibility.In particular, processes evaluating conditionals must immediately send selections to the processes that need them, while CC is more faithful to the pen-and-paper literature on choreographies [4,5,23].
Pirouette is a functional choreographic programming language formalised in Coq [22].It supports asynchronous communication and higher-order functions, but at the cost of introducing hidden global synchronisations for all processes whenever a function is called.The semantics of CC is, instead, decentralised and all synchronisations are syntactically explicit.
Extending CC with asynchronous communication has also been studied [10], but since it was not part of the reference pen-and-paper work that we followed, we postponed its formalisation to future work.
Another line of research connected to choreographic programming is that of multiparty session types [23].These types are essentially choreographies without computation (e.g., communications only specify sender, receiver, and message type, but not how the message is computed or where it is stored), and are therefore simpler than CC.There are two available formalisations of multiparty session types [7,26].Both formalisations include a counterpart to the EPP theorem, but they are even more restrictive than Kalas in how they handle the projection of conditionals.

Conclusion
We presented a formalisation of a state-of-the-art article on theory of choreographic programming.The formalisation process unveiled subtle problems in definitions, making a case for a more systematic use of theorem provers to validate results in the field.Even more, it positively impacted the theory itself, showing that formalisation can be valuable tool also in the design phase of the research process.
Our formalisation was done in parallel with the pen-and-paper revision of CC carried out in [33].There are two interesting observations to make about this parallel development.First, many of the technical aspects that we discuss in this article were also independently discovered during the writing of [33].Second, the seemingly disparate goals of making the theory more intuitive to students and amenable to formalisation actually converged on the same solution, and sometimes resulted in useful exchanges of feedback.Taken together, these two observations strongly suggest that the current formulation of CC is the "right" one, and offers a suitable basis for future developments.
We have already started exploring extensions and applications of our formalisation.These include amendment (a procedure that injects appropriate selections to make a choreography projectable), a proof of starvation-freedom, alternative definitions of EPP, and applying program extraction to develop a certified toolchain from choreographies to executable code.
An important tool for future extensions is stronger automation for proofs about choreographies.Our development already includes a few simple tactics that deal with commonly-recurring goals, but it would be worthwhile to extend this library with more powerful tactics, e.g., to reason about multi-step transitions.Furthermore, for many proofs by structural induction, there are strong similarities among their different cases, and it would be interesting to try to automate proof strategies that can capitalise on this.
The appeal of choreographic programming largely depends on its promise of delivering correct implementations, by removing the possibility of human error through EPP.This promise has motivated a proliferation of choreographic programming languages, including features of practical value such as asynchronous communication, nondeterminism, broadcast, dynamic network topologies, and more [2,18,24,33].The theories of these languages are becoming more and more complex, thus increasing the likelihood of critical mistakes and making the case for more trustworthy developments.We hope that our work can contribute a solid foundation for the development of these features.

Figure 1
Figure 1 Two-stage compilation process from choreographies to executable code.

Figure 4
Figure 4 Process projection for Simple Choreographies.
exemplify how they correspond to constructors in the formalisation.We also introduce suggestive notations for all these relations: ≪C,s≫ −−[rl,D] −→ ≪C',s'≫ stands for (CCC_To D C s rl C' s' ) (this relation is parameterised on D: DefSet for dealing with procedure calls); c −−[tl] −→ c' stands for (CCP_To c tl c'), where c, c' : Configuration are pairs containing a Program and a State; and c −−[ts] −→ * c' stands for (CCP_ToStar c ts c').

Figure 11
Figure 11 Definition of the merge relation.

Figure 12
Figure 12 Definition of the branching order.

Figure 13
Figure 13  Rules for projecting a choreography for a given target process.The notations are the ones printed by Coq, but they are not parsable due to the the different signatures.