Formalising a Turing-Complete Choreographic Language in Coq
FFormalising a Turing-Complete Choreographic Language in Coq
LUÍS CRUZ-FILIPE,
University of Southern Denmark, Denmark
FABRIZIO MONTESI,
University of Southern Denmark, Denmark
MARCO PERESSOTTI,
University of Southern Denmark, Denmark
Theory of choreographic languages typically includes a number of complex results that are proved by structural induction. The highnumber of cases and the subtle details in some of them lead to long reviewing processes, and occasionally to errors being found inpublished proofs. In this work, we take a published proof of Turing completeness of a choreographic language and formalise it inCoq. Our development includes formalising the choreographic language and its basic properties, Kleene’s theory of partial recursivefunctions, the encoding of these functions as choreographies, and proving this encoding correct.With this effort, we show that theorem proving can be a very useful tool in the field of choreographic languages: besides theadded degree of confidence that we get from a mechanised proof, the formalisation process led us to a significant simplification of theunderlying theory. Our results offer a foundation for the future formal development of choreographic languages.CCS Concepts: •
Theory of computation → Process calculi ; Recursive functions ; Logic and verification ;Additional Key Words and Phrases: Choreographic Programming, Formalisation, Turing Completeness
Background.
In the setting of concurrent and distributed systems, choreographic languages are used to defineinteraction protocols that communicating processes should abide to [18, 28, 31]. These languages are akin to the“Alice and Bob” notation found in security protocols, and inherit the key idea of making movement of data manifestin programs [27]. This is usually obtained through a linguistic primitive that looks 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 developingmethodologies based on choreographies, yielding results in program verification, monitoring, and program synthesis [2,17]. For example, in multiparty session types , types are choreographies used for checking statically that a system ofprocesses implements protocols correctly [16]. Further, in choreographic programming , choreographic languages areelevated to full-fledged programming languages [25], which can express how data should be pre- and post-processed byprocesses (encryption, validation, anonimisation, etc.). Choreographic programming languages showed promise in anumber of contexts, including parallel algorithms [7], cyber-physical systems [14, 22, 23], self-adaptive systems [11],system integration [13], information flow [20], and the implementation of security protocols [14]. The Problem.
Proofs in the field of choreographic languages are extremely technical. They have to cover many cases,and they typically involve translations from/to other languages that come with their own structures and semantics. Thelevel of complexity makes peer-reviewing challenging. For example, it has recently been discovered that a significantnumber (at least 5) of key results published in peer-reviewed articles on multiparty session types actually do not hold,and that their statements require modification [29].
Authors’ addresses: Luís Cruz-Filipe, University of Southern Denmark, Campusvej 55, Odense, 5230, Denmark, [email protected]; Fabrizio Montesi,University of Southern Denmark, Campusvej 55, Odense, 5230, Denmark, [email protected]; Marco Peressotti, University of Southern Denmark,Campusvej 55, Odense, 5230, Denmark, [email protected]. a r X i v : . [ c s . L O ] F e b Luís Cruz-Filipe, Fabrizio Montesi, and Marco Peressotti
This Article.
The aim of this article is to show that computer-aided verification – in particular, interactive theoremproving – can be successfully applied to the study of choreographies and to provide solid foundations for futuredevelopments.Before presenting our scientific contributions, it is interesting to look at the story behind this article, as it tells usthat interactive theorem proving is not just a tool to check what we already know.Our development started in late 2018. Our starting point was the theory of Core Choreographies (CC), a minimalisticlanguage that we previously proposed for the study of choreographic programming [8]. CC is designed to include onlythe essential features of choreographic languages and minimal computational capabilities at processes (computing thesuccessor of a natural number and deciding equality of two natural numbers). Nevertheless, it is expressive enoughto be Turing complete, which is proven by developing a provably-correct translation of Kleene’s partial recursivefunctions [19] into choreographies that implement the source functions by means of communication [8].At the TYPES conference in 2019, we gave an informal progress report on the formalisation of CC using the Coqtheorem prover [9]. Our effort revealed soon a crux of unparsimonious complexity in the theory: a set of term-rewritingrules for a precongruence relation used in the semantics of the language for (i) expanding procedure calls with thebodies of their respective procedures and (ii) reshuffling independent communications in choreographies to representcorrectly concurrent execution. This relation is closed under context and transitivity, and it can always be involved inthe derivation of reductions, which led to tedious induction on the derivation of these term rewritings in almost allcases of proofs that had to do with the semantics of choreographies. In addition to being time consuming, formalisingthis aspect makes the theory presented in [8] much more complicated (we discuss this in Section 2.4).At the time, the second author had been teaching a few editions of a course that includes theory of choreographies.Interestingly, the same technical aspects that made the formalisation of CC much more intricate than its original theorywere all found to be subtly complicated by students. Motivated by this observation and our early efforts in formalising [8],the teacher developed a revisited theory of CC for his course material that dispenses with the problematic notions andshows that they are actually unnecessary [26]. The choreography theory in [26] is the one that we deal with in this article.Thus, besides the scientific contributions that we are going to present, this article also shows that theorem provingcan be used to do research: the insights that we got by doing this formalisation led to changes in the original theory.We are going to prove that this did not come at the cost of expressive power, by formalising that the same translation ofKleene’s partial recursive functions from [8] still works as-is for the theory in [26]. Furthermore, while formalising thetheory we realised that some assumptions in some results were actually not necessary, which yielded stronger results.
Contributions.
This article presents the first formalised theory of a full-fledged choreographic language, including itssyntax and semantics, and the main properties of determinism, confluence, and deadlock-freedom by design. This theoryis formalised in Coq, using its module system to make it parametric. Furthermore, we formalise Kleene’s theory of partialrecursive functions (which, to the best of our knowledge, has not been done before). We then show that the choreographiclanguage is Turing complete, by encoding these functions as choreographies and proving this encoding sound.The full development can be downloaded at [10].
Structure.
We assume the reader to be familiar with Coq. In Section 2, we present the syntax and semantics of ourchoreographic language, based on its formalisation in Coq, and establish the main theoretical properties of this language.Section 3 presents the theory and formalisation of Kleene’s partial recursive functions, and Section 4 describes theirencoding as choreographies and the proof of Turing completeness of the choreographic language. We discuss therelevance of our results and future work in Section 5.ormalising a Turing-Complete Choreographic Language in Coq 3
In this section, we introduce the choreographic language of Core Choreographies (CC), together with the correspondingformalisation.A choreography specifies a protocol involving different participants (processes) that can communicate amongthemselves and possess local computational capabilities. Each process also has storage, which is accessible throughvariables. There are two kinds of communications: value communications, where the sender process locally evaluates anexpression and sends the result to the receiver process, who stores it in one of its variables; and label selection, wherethe sender selects one among some alternative behaviours (tagged by labels) offered by the receiver. A choreography canalso define (recursive) procedures, which can be invoked by their name anywhere. The formal syntax of choreographiesis given in Section 2.2.
We define the type of choreographies as a parametric Coq
Module , taking eight parameters: the types of process identifiers(processes for short)
Pid , local variables
Var (used to access the processes’ storage), values
Val , expressions
Expr , Booleanexpressions
BExpr , procedure names
RecVar (from recursion variables ), and the evaluation functions mapping expressionsto values and Boolean expressions to Booleans.The first six parameters are datatypes that are equipped with a decidable equality. Due to difficulties with usingthe definitions in Coq’s standard libraries, we reimplemented this as a
Module Type DecType , and defined a functor
DecidableType providing the usual lemmas to simplify function definitions by case analysis on equality of two objects.Evaluation requires a local state , mapping process variables to actual values. We model states as functors, taking
Var and
Val as parameters and returning a
Module containing this function type together with an operator to update thestate (by changing the value assigned to one variable) and lemmas characterising this operator. For the semantics ofchoreographies, we also need global states , which take
Pid as an additional parameter and map each process to a localstate. This type is again enriched with operations to update a global state and their properties.An evaluation function is a function mapping expressions to values, given a local state. Evaluation must be compatiblewith extensional equality on states.
Module Type Eval ( Expression Vars Input Output : DecType ). Parameter eval : Expression . t → ( Vars . t → Input . t ) → Output . t . Parameter eval_wd : ∀ f f ' , ( ∀ x , f x = f ' x ) → ∀ e , eval e f = eval e f ' . End Eval . This module is instantiated twice in the choregraphy type: with arguments
Expr , Var , Val and
Val , evaluating expressionsto values, and with arguments
BExpr , Var , Val and bool , evaluating Boolean expressions to Booleans.
We present the Coq definition of the type of choreographies, and afterwards briefly explain each constructor and itspretty-printing.
Inductive Label : Type :=| left : Label
Luís Cruz-Filipe, Fabrizio Montesi, and Marco Peressotti | right : Label . Inductive Eta : Type :=|
Com : Pid → Expr → Pid → Var → Eta | Sel : Pid → Pid → Label → Eta . Inductive Choreography : Type :=|
Interaction : Eta → Choreography → Choreography | Cond : Pid → BExpr → Choreography → Choreography → Choreography | Call : RecVar → Choreography | RT_Call : RecVar → ( list Pid ) → Choreography → Choreography | End : Choreography . Definition DefSet := RecVar → ( list Pid ) ∗ Choreography . Record Program : Type :={
Procedures : DefSet ; Main : Choreography }. Constructor
Interaction builds a choreography that starts with a communication (
Eta ), which can be either a valuecommunication (
Com ) or a label selection (
Sel ). These choreographies are written as p e −→ q $ x ;; C or p −→ q [ l ];; C , re-spectively. Label selections were inherited by choreographies from linear logic and behavioural types: they are used tocommunicate a choice made by the sender to the receiver. In minimalistic theories of choreographies and behaviouraltypes, it is common to restrict the set of labels that can be communicated ( Label ) to two elements, generically called left and right [4, 8]. These labels are typically used to propagate information about the local evaluation of a conditionalexpression, which generates two possible execution branches.A choreography that starts by locally evaluating an expression is built using
Cond , written
If p ?? b Then C1 Else C2 ,while invoking procedure X is built as Call X . A procedure may involve several processes; the auxiliary term
RT_Call X ps C represents a procedure that has already started executing, but the processes in ps have not yet entered it – the term C isobtained from the actions of procedure that have been executed (see the semantics below). End denotes the terminatedchoreography.A
DefSet (set of procedure definitions) is a mapping assigning to each
RecVar a list of processes and a choreography;intuitively, the list of processes contains the processes that are used the procedure. A
Program is a pair containing a setof procedure definitions and the choreography to be executed at the start.Terms built using
RT_Call are meant to be runtime terms, generated while executing a choreography; therefore,programs written by programmers should not contain such terms. We call such a choreography initial , and define itinductively in the natural way.
Well-Formedness.
There are a number of well-formedness requirements on choreographies. Some of these come frompractical motivations and are typically explicitly required, while others are more technical and not always writtendown in other articles. We summarise these conditions.ormalising a Turing-Complete Choreographic Language in Coq 5A choreography is well-formed if its processes do not self-communicate: the two arguments of type
Pid to Com and
Sel in all its subterms are always distinct. Furthermore, the list of process names in the argument of
RT_Call is neverempty. These conditions are defined separately by recursion in the natural way.For a program P to be well-formed, there are more requirements on procedure definitions and the annotations ofthe runtime terms. First, both Main P and all choreographies in
Procedures P must be well-formed, and furthermorethe latter must all be initial choreographies. In
Main P , all runtime terms must be consistently annotated: the set ps in RT_Call X ps C should only contain processes that occur in the definition of X (as specified in Procedures P ).Second, a program must be finitely specifiable. Instead of requiring the type
RecVar to be finite, which wouldsignificantly complicate the formalisation, we require that there exist Xs : list RecVar such that every procedure in Xs , aswell as Main P , only calls procedures in Xs . Hence, it becomes irrelevant what the remaining procedure definitions are.Well-formedness is thus parameterised on Xs . Definition Program_WF ( Xs : list RecVar ) ( P : Program ) :
Prop := Choreography_WF ( Main P ) ∧ within_Xs Xs ( Main P ) ∧ consistent ( Vars P ) (
Main P ) ∧∀ X , In X Xs → Choreography_WF ( Procs P X ) ∧ initial ( Procs P X ) ∧ ( Vars P X ) ≠ nil ∧ within_Xs Xs ( Procs P X ). The third and last condition is that the set of procedure definitions in a program must be well-annotated: if
Procedures P X =( ps , C ) , then the set of processes used in C must be included in ps . The set of processes used in C is in turnrecursively defined using the information in Procedures P , so computing an annotation is not straightforward. For thisreason, it can be convenient in practice to over-annotate a program – which is why well-annotation only requires a setinclusion.
Definition well_ann ( P : Program ) :
Prop := ∀ X , set_incl _ ( CCC_pn ( Procs P X ) (
Vars P )) (
Vars P X ). Definition CCP_WF ( P : Program ) := well_ann P ∧ ∃ Xs , Program_WF Xs P . While
Program_WF is decidable, well_ann and
CCP_WF (for CC program) are not, due to the quantifications in theirdefinitions. This motivates defining
Program_WF separately.Formalising well-formedness requires some auxiliary definitions (the sets of processes and procedure names used ina choreography) and several inductive definitions. Most of them are straightforward, if sometimes cumbersome; thecomplexity of the final definition can make proofs of well-formedness quickly grow in size and number of cases, so weprovide a number of inversion results such as the following to make subsequent proofs easier.
Lemma CCP_WF_eta : ∀ Defs C eta , CCP_WF ( Build_Program Defs ( eta ;; C )) → CCP_WF ( Build_Program Defs C ). The semantics of CC is defined by means of labelled transition systems, in several layers. At the lowest layer, we definethe transitions that a choreography can make (
CCC_To ), parameterised on a set of procedure definitions; then we packthese 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. Thislayered approach makes proofs about transitions cleaner, since the different levels of induction are separated. Luís Cruz-Filipe, Fabrizio Montesi, and Marco Peressotti
Transition Labels.
We have two types of transition labels. The first one is a simple inductive type with constructorscorresponding to the possible actions a choreography can take: value communications, label selections, local conditional,or local procedure call. This type is called
RichLabel : rich labels are not present in the informal theory [26], butthey are needed to obtain strong enough induction hypotheses in proofs of results about CC that we will need inSection 4 for Turing completeness. The labels in the informal theory correspond to observable actions; they areformalised as
TransitionLabel , and they forget the internal details of actions. The two types are connected by a function forget : RichLabel → TransitionLabel . Inductive RichLabel : Type :=|
R_Com ( p : Pid ) ( v : Value ) ( q : Pid ) ( x : Var ) :
RichLabel | R_Sel ( p : Pid ) ( q : Pid ) ( l : Label ) :
RichLabel | R_Cond ( p : Pid ) :
RichLabel | R_Call ( X : RecVar ) ( p : Pid ) :
RichLabel . Inductive TransitionLabel : Type :=|
L_Com ( p : Pid ) ( v : Value ) ( q : Pid ) :
TransitionLabel | L_Sel ( p : Pid ) ( q : Pid ) ( l : Label ) :
TransitionLabel | L_Tau ( p : Pid ) :
TransitionLabel . Transition Relations.
CCC_To is defined inductively by a total of 11 clauses, corresponding to the 11 rules in theinformal presentation. We include some of them below, with some proof terms omitted.
Inductive CCC_To ( Defs : DefSet ) :
Choreography → State → RichLabel → Choreography → State → Prop :=|
C_Com p e q x C s s ' : let v := ( eval_on_state e s p ) ineq_state_ext s ' ( update s q x v ) → CCC_To Defs ( p e −→ q $ x ;; C ) s ( R_Com p v q x ) C s '| C_Delay_Eta eta C C ' s s ' t : disjoint_eta_rl eta t → CCC_To Defs C s t C ' s ' → CCC_To Defs ( eta ;; C ) s t ( eta ;; C ' ) s '| C_Call_Start p X s s ' : eq_state_ext s s ' → set_size _ ( fst ( Defs X )) > 1 → In p ( fst ( Defs X )) → CCC_To Defs ( Call X ) s ( R_Call X p )( RT_Call X ( set_remove _ p ( fst ( Defs X ))) ( snd ( Defs X ))) s '| C_Call_Enter p ps X C s s ' : eq_state_ext s s ' → set_size _ ps > 1 → In p ps → CCC_To Defs ( RT_Call X ps C ) s ( R_Call X p )( RT_Call X ( set_remove _ p ps ) C ) s ' ormalising a Turing-Complete Choreographic Language in Coq 7 | C_Call_Finish p ps X C s s ' : eq_state_ext s s ' → set_size _ ps = 1 → In p ps → CCC_To Defs ( RT_Call X ps C ) s ( R_Call X p ) C s ' .
The first constructor defines a transition for a value communication, with the state being updated with the valuereceived at the receiver. Since states are functions, we do not want to require that the resulting state be update s q x v –the state obtained directly from s by updating the value at q ’s variable x with v – but only that it be extensionally equalto it (the values of variables at all processes are the same). (The stronger requirement would break, e.g., confluence,since updating two different variables in a different order does not yield the same state.)The original informal theory allows for out-of-order execution of independent interactions [8, 26], a well-establishedfeature of choreographic languages [6, 16]. For example, given a choreography that consists of two independentcommunications such as p e −→ q $ x ;; r e ' −→ s $ y ;; End (“ p communicates e to q and r communicates e ' to s ”) where p , q , r ,and s are distinct processes, we should be able to observe the first and the second value communication in whicheverorder. Out-of-order execution is modelled by three rules, of which the second constructor shown is an example. Here,a choreography is allowed to reduce under a prefix eta if its label does not share any processes with eta . This side-condition is checked by disjoint_eta_rl eta t ; several auxiliary predicates named disjoint_type1_type2 are defined tosimplify writing these conditions.Procedure calls are managed by four rules, of which the main three are shown. A procedure call is expanded whenthe first process involved in it enters it (rule C_Call_Start ). The remaining processes and the procedure’s definitionare 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 , not shown).When the last process enters the procedure, the runtime term is consumed (rule
C_Call_Finish ). The missing ruleaddresses the edge case when a procedure only uses one process.In order to prove results about transitions, it is often useful to infer the resulting choreography and state. Theconstructors of
CCC_To cannot be used for this purpose, since the resulting state is not uniquely determined. Therefore,we prove a number of lemmas stating restricted forms of transitions that are useful for forward reasoning.
Lemma C_Com ' : ∀ Defs p e q x C s , let v := ( eval_on_state e s p ) inCCC_To Defs ( p e −→ q $ x ;; C ) s ( R_Com p v q x ) C ( update s q x v ). Afterwards, we formalise the transition relations as defined in [26].
Definition Configuration : Type := Program ∗ State . Inductive CCP_To : Configuration → TransitionLabel → Configuration → Prop :=|
CCP_To_intro Defs C s t C ' s ' : CCC_To Defs C s t C ' s ' → CCP_To ( Build_Program Defs C , s ) ( forget t ) ( Build_Program Defs C ', s ' ). Inductive CCP_ToStar : Configuration → list TransitionLabel → Configuration → Prop :=|
CCT_Refl c : CCP_ToStar c nil c | CCT_Step c1 t c2 l c3 : CCP_To c1 t c2 → CCP_ToStar c2 l c3 → CCP_ToStar c1 ( t :: l ) c3 . We also define the suggestive notations c —[ tl ] −→ c ' for CCP_To c tl c ' and c —[ ts ] −→ ∗ c ' for CCP_To_Star c ts c ' . Luís Cruz-Filipe, Fabrizio Montesi, and Marco Peressotti The challenging – and interesting – part of formalising CC is establishing the basic properties of the language, whichare essential for more advanced results and typically not proven in detail in publications. We discuss some of the issuesencountered, as these were the driving force behind the changes relative to [8].The first key property of choreographies is that they are deadlock-free by design: any choreography that is notterminated can reduce. Since the only terminated choreography in CC is
End , this property also implies that anychoreography either eventually reaches the terminated choreography
End or runs infinitely. These properties dependon the basic result that transitions preserve well-formedness.
Lemma CCC_ToStar_CCP_WF : ∀ P s l P ' s ' , CCP_WF P → ( P , s ) —[ l ] −→ ∗ ( P ', s ') → CCP_WF P '. Theorem progress : ∀ P , Main P ≠ End → CCP_WF P → ∀ s , ∃ tl c ', ( P , s ) —[ tl ] −→ c '. Theorem deadlock_freedom : ∀ P , CCP_WF P →∀ s ts c ' , ( P , s ) —[ ts ] −→ ∗ c ' → { Main ( fst c ') = End } + { ∃ tl c '' , c ' —[ tl ] −→ c ''}. This is the first place where we benefit from the change in both the syntax and semantics of choreographies from [8]to [26], which removes idiosyncrasies that required clarifications in the reviewing process of [8]. In the language of [8],procedures are defined inside choreographies by means of a def 𝑋 = 𝐶 𝑋 in 𝐶 constructor in choreographies. This makesthe definition of terminated choreography much more complicated, since End could occur inside some of these terms.Furthermore, procedure calls were expanded by structural precongruence, so that a choreography as def 𝑋 = End in 𝑋 would also be terminated. Separating procedure definitions from the main choreography in a program and promotingprocedure calls to transitions makes stating and proving progress much simpler. The direct syntactic characterisation oftermination also has advantages, since it is intuitive and easily verifiable.The second key property is confluence, which is an essential ingredient of the proof of Turing completeness below:if a choreography has two different transition paths, then these paths either end at the same configuration, or bothresulting configurations can reach the same one. This is proved by first showing the diamond property for choreographytransitions, then lifting it to one-step transitions, and finally applying induction. Lemma diamond_Chor : ∀ Defs C s tl1 tl2 C1 C2 s1 s2 , CCC_To Defs C s tl1 C1 s1 → CCC_To Defs C s tl2 C2 s2 → tl1 ≠ tl2 → ∃ C ' s ' , CCC_To Defs C1 s1 tl2 C ' s ' ∧ CCC_To Defs C2 s2 tl1 C ' s ' . Lemma diamond_1 : ∀ c tl1 tl2 c1 c2 , c —[ tl1 ] −→ c1 → c —[ tl2 ] −→ c2 → tl1 ≠ tl2 → ∃ c ', c1 —[ tl2 ] −→ c ' ∧ c2 —[ tl1 ] −→ c '. Lemma diamond_4 : ∀ P s tl1 tl2 P1 s1 P2 s2 ,( P , s ) —[ tl1 ] −→ ∗ ( P1 , s1 ) → ( P , s ) —[ tl2 ] −→ ∗ ( P2 , s2 ) → ( ∃ P ' tl1 ' tl2 ' s1 ' s2 ' , ( P1 , s1 ) —[ tl1 ' ] −→ ∗ ( P ', s1 ') ∧ ( P2 , s2 ) —[ tl2 ' ] −→ ∗ ( P ', s2 ') ∧ eq_state_ext s1 ' s2 '). As an important consequence, we get that any two executions of a choreography that end in a terminated choreo-graphy must yield the same state.ormalising a Turing-Complete Choreographic Language in Coq 9
Lemma termination_unique : ∀ c tl1 c1 tl2 c2 , c —[ tl1 ] −→ ∗ c1 → c —[ tl2 ] −→ ∗ c2 → Main ( fst c1 ) = End → Main ( fst c2 ) = End → eq_state_ext ( snd c1 ) ( snd c2 ). The complexity of the proof of confluence was the determining factor for deciding to start our work from thevariation of the choreographic language presented in [26] instead of that in [8]. The current proof of confluence takesabout 300 lines of Coq code, including a total of 11 lemmas. This is in stark contrast with the previous attempt, whichalready included over 30 lemmas with extremely long proofs. The reason for this complexity lay, again, in both inlinedprocedure definitions and structural precongruence. Inlined procedure definitions forced us to deal with all the usualproblems regarding bound variables and renaming; structural precongruence introduced an absurd level of complexitybecause it allowed choreographies to be rewritten arbitrarily.To understand this issue, consider again the choreography p e −→ q $ x ;; r e ' −→ s $ y ;; End . As we have previouslydiscussed, this choreography can execute first either the communication between p and q or the one between r and s . Inour framework, the first transition is modelled by rule C_Com , while the second is obtained by applying rule
Delay_Com followed by
C_Com . In a framework with reductions and structural precongruence, instead, the second transition ismodelled by first rewriting the choreography as r e ' −→ s $ y ;; p e −→ q $ x ;; End and then applying rule
C_Com [8]. The setof legal rewritings is formally defined by the structural precongruence relation ⪯ , and there is a rule in the semanticsallowing 𝐶 to reduce to 𝐶 whenever 𝐶 ⪯ 𝐶 ′ , 𝐶 ′ ⪯ 𝐶 , and 𝐶 ′ reduces to 𝐶 . Thus, the proof of confluence also needsto take into account all the possible ways into which choreographies may be rewritten in a reduction. In a proof ofconfluence, where there are two reductions, there are four possible places where choreographies are rewritten; given thehigh number of rules defining structural precongruence, this led to an explosion of the number of cases. Furthermore,induction hypotheses typically were not strong enough, and we were forced to resort to complicated auxiliary notionssuch as explicitly measuring the size of the derivation of transitions, and proving that transitions could be normalised.This process led to a seemingly ever-growing number of auxiliary lemmas that needed to be proved, and after severalmonths of work with little progress it became evident that the problem lay in the formalism.With the current definitions, the theory of CC is formalised in two files. The first file, which defines the preliminaries,contains 40 definitions, 58 lemmas and around 700 lines of code. The second file, which defines CC-specific results,contains 48 definitions, 106 lemmas, 2 theorems and around 2100 lines of code. In order to formalise Turing completeness of our choreographic language, we need a model of computation. In [8], themodel chosen was Kleene’s partial recursive functions [19], and the proof proceeds by showing that these can all beimplemented as a choreography, for a suitable definition of implementation. This proof structure closely follows that ofthe original proof of computational completeness for Turing machines [30].In this section, we describe our formalisation of partial recursive functions, and the main challenges and designoptions that it involved. Following standard pratice, we routinely use lambda notation for denoting these functions.
The class of partial recursive functions is defined inductively as the smallest class containing the constant unary zerofunction 𝑍 = 𝜆𝑥.
0, the unary successor function 𝑆 = 𝜆𝑥.𝑥 + 𝑛 -ary projection functions 𝑃 𝑚𝑘 = 𝜆𝑥 . . . 𝑥 𝑚 .𝑥 𝑘 (base functions), and closed under the operations of composition, primitive recursion, and minimisation. All functionshave an arity (natural number); the arity of 𝑍 and 𝑆 is 1, and the arity of 𝑃 𝑚𝑘 is 𝑚 . Given a function 𝑔 of arity 𝑚 and0 Luís Cruz-Filipe, Fabrizio Montesi, and Marco Peressotti 𝑚 functions 𝑓 , . . . , 𝑓 𝑚 of arity 𝑘 , then the composition 𝐶 ( 𝑔, (cid:174) 𝑓 ) has arity 𝑘 ; if 𝑔 has arity 𝑘 and ℎ has arity 𝑘 +
2, thenfunction 𝑅 ( 𝑔, ℎ ) defined by primitive recursion from 𝑔 and ℎ has arity 𝑘 +
1; and if ℎ has arity 𝑘 +
1, then its minimisation 𝑀 ( ℎ ) has arity 𝑘 .We formalise this class as a dependent inductive type PRFunction taking the arity of the function as a parameter. Inorder to ensure the correct number of arguments in composition, we require 𝑓 , . . . , 𝑓 𝑚 to be given as a vector of length 𝑚 . Inductive PRFunction : nat → Set :=|
Zero : PRFunction Successor : PRFunction Projection : ∀ { m k : nat }, k < m → PRFunction m | Composition : ∀ { k m : nat } ( g : PRFunction m ) ( fs : t ( PRFunction k ) m ), PRFunction k | Recursion : ∀ { k : nat } ( g : PRFunction k ) ( h : PRFunction (2+ k )), PRFunction (1+ k )| Minimization : ∀ { k : nat } ( h : PRFunction (1+ k )), PRFunction k . Note the required proof term on the constructor for projections. The parameter k is one unit lower than the parameter 𝑘 in the mathematical definition, since Coq’s natural numbers start at 0 – this choice simplifies the development. A partial recursive function of arity 𝑚 is meant to denote a partial function of type N 𝑚 → N . The denotation of 𝑍 , 𝑆 and 𝑃 𝑚𝑘 was already given above; the remaining operators are interpreted as follows, where we write (cid:174) 𝑥 for 𝑥 , . . . , 𝑥 𝑘 . 𝐶 ( 𝑔, (cid:174) 𝑓 )( (cid:174) 𝑥 ) = 𝑔 ( 𝑓 ( (cid:174) 𝑥 ) , . . . , 𝑓 𝑚 ( (cid:174) 𝑥 )) 𝑅 ( 𝑔, ℎ )( , (cid:174) 𝑥 ) = 𝑔 ( (cid:174) 𝑥 ) 𝑅 ( 𝑔, ℎ )( 𝑛 + , (cid:174) 𝑥 ) = ℎ ( 𝑛, 𝑅 ( 𝑔, ℎ )( 𝑛, (cid:174) 𝑥 ) , (cid:174) 𝑥 ) 𝑀 ( ℎ )( (cid:174) 𝑥 ) = 𝑛 if ℎ ( (cid:174) 𝑥, 𝑛 ) = ℎ ( (cid:174) 𝑥, 𝑖 ) > ≤ 𝑖 < 𝑛 Minimization can lead to partiality, since there may be no 𝑛 satisfying the conditions given in its definition. Thispartiality propagates, since any value depending on an undefined value is also undefined. Kleene’s original work doesnot completely specify this mechanism: for example, if 𝑓 is a unary function that is undefined everywhere, should 𝐶 ( 𝑍, 𝑓 ) be also everywhere undefined, or constantly zero? It is generally assumed that a function is undefined wheneverany of its arguments is undefined, even in the case where those arguments are not used for computing the result; wetake this approach in this work.Since Coq does not allow for defining partial functions, we take an operational approach to the semantics of partialrecursive functions, and interactively define the bounded evaluation of an 𝑚 -ary function 𝑓 on a vector of length 𝑚 in 𝑛 steps, which has type option nat . This construction proceeds in three steps. First, we deal with minimisation by defining Fixpoint find_zero_from { k } ( h : t ( option nat ) (1+ k ) → option nat )( ns : t ( option nat ) k ) ( init : nat ) ( steps : nat ) : option nat := match steps with | O ⇒ None | S m ⇒ match h ( shiftin ( Some init ) ns ) with | None ⇒ None ormalising a Turing-Complete Choreographic Language in Coq 11 | Some O ⇒ Some init | Some ( S _ ) ⇒ find_zero_from h ns ( S init ) m end end . which tries to find the smallest zero of h starting at init using a bound of steps steps for the first value, steps −1 for thenext value, etc. (The type t T n is the type of vectors containing exactly n elements of type T .) With this, we recursivelydefine the evaluation function Fixpoint eval_opt { m } ( f : PRFunction m ) : ∀ ( steps : nat ) ( ns : t ( option nat ) m ), option nat . Given the complexity of
PRFunction , this function is defined interactively. Finally, we define
Definition eval { m } ( f : PRFunction m ) ( steps : nat ) ( ns : t nat m ) : option nat := eval_opt f steps ( map Some ns ) as our intended evaluation function.Evaluation starts by checking that all arguments are defined. If this is the case, then the base functions always returntheir value; composition and recursion call the functions that they depend upon with the same number of steps; andminimisation initiates a search from 0 with the bounds explained above.In order to ensure that the interactive definitions are correct, we prove a number of lemmas stating that the definingequations for each class of functions hold. For example, for recursion we have the following three lemmas. Lemma Recursion_correct_base : ∀ k ( g : PRFunction k ) ( h : PRFunction (2+ k )) ( ns : t nat (1+ k )), ∀ steps , hd ns = 0 → eval ( Recursion g h ) steps ns = eval g steps ( tl ns ). Lemma Recursion_correct_step : ∀ k ( g : PRFunction k ) ( h : PRFunction (2+ k )) ( ns : t nat (1+ k )), ∀ steps x y , hd ns = S x → ( eval ( Recursion g h ) steps ( x :: tl ns )) = Some y → eval ( Recursion g h ) steps ns = eval h steps ( x :: y :: tl ns ). Lemma Recursion_correct_step ' : ∀ k ( g : PRFunction k ) ( h : PRFunction (2+ k )) ( ns : t nat (1+ k )), ∀ steps x , hd ns = S x → ( eval ( Recursion g h ) steps ( x :: tl ns )) = None → eval ( Recursion g h ) steps ns = None . These results rely on a number of auxiliary results, notably about the function find_zero_from . For further proof of correctness, we chose some functions that typically are used as examples in textbooks on thetopic – addition, multiplication, sign – and some relations – greater than, smaller than, equals – and showed that theusual definitions are correct. For example, sum is defined as 𝑅 ( 𝑃 , 𝐶 ( 𝑆, 𝑃 )) (this is also used as an example in [8]). Ourformalisation defines PR_add as Recursion ( Projection aux11 ) (
Composition Successor [ Projection aux23 ]) , and includes Lemma add_correct : ∀ m n steps , eval PR_add steps [ m ; n ] = Some ( m + n ). (The parameters 𝑚 and 𝑘 are implicit in the constructor for projections; the proof terms are named to correspond to theinformal usage, so that aux11 :0<1 . Thus 𝑃 is represented by @ Projection aux11 .)2 Luís Cruz-Filipe, Fabrizio Montesi, and Marco Peressotti
The next step is to show that the value by eval is unique and stable (augmenting the number of steps can only changeit from
None to Some n , and not conversely).This is the first place where we have to do induction over
PRFunction . The induction principle automatically generatedby Coq from the type definition is not strong enough for our purposes: the constructor for composition includes elementsof type
PRFunction inside a vector argument, and these functions are not available on inductive proofs. We use a standardtechnique to overcome this limitation: we assign a depth to every element of
PRFunction (corresponding to the depth ofits abstract syntax tree), and prove results by induction over the depth of functions. In particular, this allows us to provethe following general induction principle.
Theorem PRFunction_induction : ∀ ( P : ∀ ( n : nat ) ( f : PRFunction n ), Prop ), P _ Zero → P _ Successor → ( ∀ i j ( Hp : i < j ), P _ ( Projection Hp )) → ( ∀ m k g fs , ( ∀ H , P m fs [@ H ]) → P k g → P _ ( Composition g fs )) → ( ∀ k g h , P _ g → P _ h → P (1+ k ) ( Recursion g h )) → ( ∀ k h , P _ h → P k ( Minimization h )) →∀ n f , P n f . (The notation v [@ H ] denotes the 𝑘 -th element of vector v , where H is a proof that 𝑘 is smaller than the length of v .)Using this principle (and sometimes directly induction over depth), we can prove all mentioned properties ofevaluation. We then define convergence and divergence in the natural way. Definition converges { k } ( f : PRFunction k ) ns y := ∃ steps , eval f steps ns = Some y . Definition diverges { k } ( f : PRFunction k ) ns := ∀ steps , eval f steps ns = None . Lemma converges_inj : ∀ { k } f ns y y ' , converges ( k := k ) f ns y → converges f ns y ' → y = y '. Lemma converges_diverges : ∀ { k } f ns , ( diverges ( k := k ) f ns ↔ ∀ y , ~ converges f ns y ). Finally, we prove a number of results for establishing convergence of each class of functions. These results are usedlater, when proving Turing completeness of choreographies. For example, for recursion we have:
Lemma Recursion_converges_base : ∀ k g h ns y , converges g ( tl ns ) y → converges (@ Recursion k g h ) (0:: tl ns ) y . Lemma Recursion_converges_step : ∀ k g h ns x y z , converges (@ Recursion k g h ) ( x :: ns ) y → converges h ( x :: y :: ns ) z → converges ( Recursion g h ) (
S x :: ns ) z . Conversely, if recursion converges, then all intermediate computations must also converge.
Lemma converges_Recursion_base : ∀ { m } ( g : PRFunction m ) h ns y , converges ( Recursion g h ) ns y → hd ns = 0 → converges g ( tl ns ) y . Lemma converges_Recursion_step : ∀ { m } ( g : PRFunction m ) h ns x y , converges ( Recursion g h ) ns y → hd ns = ( S x ) →∃ z , converges ( Recursion g h ) ( x :: tl ns ) z ∧ converges h ( x :: z :: tl ns ) y . ormalising a Turing-Complete Choreographic Language in Coq 13 Lemma converges_Recursion_full : ∀ { m } ( g : PRFunction m ) h ns y , converges ( Recursion g h ) ns y →∀ x , x ≤ hd ns → ∃ z , converges ( Recursion g h ) ( x :: tl ns ) z . For completeness, the formalisation also includes corresponding results for divergence; these are currently unused.This part of the development contains 22 definitions and 84 lemmas, with a total of 1388 lines of code. (This excludessome results on basic data structures that we could not find in the standard library.)
We are now ready to show that the choreographic language is Turing complete, in the sense that every partial recursivefunction can be implemented as a choreography (for a suitable definition of implementation). The construction isvery similar to that in [8]: a significant part of the formalisation amounted to transcribing all the relevant definitionsto Coq syntax. This contributes to confirming that the simplifications introduced in [26] and the additional notionsand properties (rich labels, well-formedness, etc.) introduced by our formalisation are mostly internal and aimed atsimplifying metatheoretical reasoning on choreographies.
The first step is to instantiate the parameters in the definition of CC with the right types. Process identifiers, valuesand procedure names are natural numbers. Each process contains two variables; we use Bool for this type, and aliasits elements to xx and yy for clarity. Expressions are an inductive type with three elements: this (evaluating to theprocess’s value at xx ), zero (evaluating to ) and succ_this (evaluating to the successor of the value at xx ). Booleanexpressions are a singleton type with one element compare , which evaluates to true exactly when the process’s twovariables store the same element.We restrict the syntax of choreographies to mimic the operators from the original development in [8], where processesonly had one storage variable. Thus, incoming value communications are always stored at variable xx . However, in thatcalculus the conditional compared the value stored in two processes. We model this as a communication whose result isstored at yy , followed by a call to compare . We define these operations as macros. Definition Send p e q := p e −→ q $ xx . Definition IfEq p q C1 C2 := q this −→ p $ yy ;; If p ? compare Then C1 Else C2 . The most complex step of the formalisation is formalising the encoding of partial recursive functions as choreographies.This is naturally a recursive construction, but there are some challenges. First, non-base functions need to storeintermediate computation results in auxiliary processes; second, recursion and minimisation use procedure definitionsto implement loops. The strategy in [8] was to use auxiliary processes sequentially: since we can statically determinehow many processes are needed from the definition of the function to encode, we can always determine the first unusedprocess. The language used therein did not have the problem with recursion variables, but the same technique apply.The key definition is the following: a choreography 𝐶 implements function 𝑓 : N 𝑚 → N with input processes 𝑝 , . . . , 𝑝 𝑚 and output process 𝑞 iff: for any state 𝑠 where 𝑝 , . . . , 𝑝 𝑚 contain the values 𝑛 , . . . , 𝑛 𝑚 in their variable xx ,(i) if 𝑓 ( 𝑛 , . . . , 𝑛 𝑚 ) = 𝑛 , then all executions of 𝐶 from 𝑠 terminate, and do so in a state where 𝑞 stores 𝑛 in its variable xx ;4 Luís Cruz-Filipe, Fabrizio Montesi, and Marco Peressottiand (ii) if 𝑓 ( 𝑛 , . . . , 𝑛 𝑚 ) is undefined, then execution of 𝐶 from 𝑠 never terminates. This is captured in the followingCoq definition. Definition implements ( P : Program ) { n } ( f : PRFunction n ) ( ps : t Pid n ) ( q : Pid ) := ∀ ( xs : t nat n ) ( s : State ), ( ∀ Hi , s ( ps [@ Hi ]) xx = xs [@ Hi ]) → ( ∀ y , converges f xs y ↔ ∃ s ' ts P ' , ( P , s ) —[ ts ] −→ ∗ ( P ', s ') ∧ s ' q xx = y ∧ Main P ' =
End ) ∧ ( diverges f xs ↔ ∀ s ' ts P ' , ( P , s ) —[ ts ] −→ ∗ ( P ', s ') → Main P ' ≠ End ). The idea is that we recursively define the set of procedure definitions needed to encode 𝑓 : N 𝑚 → N , taking asparameters not only the processes 𝑝 , . . . , 𝑝 𝑚 and 𝑞 , but also the indices of the first unused process and the first unusedprocedure. The encoding of 𝑓 is a program whose set of procedure definitions is obtained by instantiating the lasttwo values to max ( 𝑝 , . . . , 𝑝 𝑚 , 𝑞 ) + Call . Furthermore, theencoding is done in such a way that the choreography terminates by calling the first unused procedure (which bydefault is defined as the terminated choreography). This makes it easy to ensure that procedure calls compose nicely inthe recursive steps of the construction.We start by defining two auxiliary functions Pi and Gamma , which given a function in
PRFunction return the numberof processes and procedures needed to encode it, respectively. (Function Pi is exactly the function Π from [8].) Noresults about these functions are needed – their definition suffices to prove all needed results, namely that no process(resp. procedure) higher than Pi f (resp.
Gamma f ) is used when encoding f .Ironically, the most challenging part of the definition is composition. The base cases are directly encoded by suitablyadapting the definitions from [8], as well as those of recursion and minimisation. However, the definition of compositionneeds to be recursive (due to the variable number of argument functions), and working with vectors adds a layer ofcomplexity. As such, a number of auxiliary functions were defined to deal with composition, defining a choreographythat encodes a vector of functions all with the same inputs and returning outputs in consecutive processes.The recursive definition of encoding Encoding_rec is again written interactively, and afterwards a number of lemmasprove that it behaves as expected, e.g.:
Lemma Zero_Procs : ∀ d Hd ps q n X , Encoding_rec Zero d Hd ps q n X X = Send ( hd ps ) zero q ;; Call ( S X ). Lemma Recursion_Procs_g : ∀ k ( g : PRFunction k ) h d ( Hd : depth ( Recursion g h ) <
S d ) ps q n , ∀ X Y , X ≤ Y < X + Gamma g → let Hg := (...) inEncoding_rec ( Recursion g h ) _ Hd ps q n X Y = Encoding_rec _ _ Hg ( tl ps ) n ( n +3) X Y . where we omit the definition of the proof term Hg .Finally, we prove that encoding always returns a well-formed choreography. This is implicit in [8], but it is an essentialproperty that should hold. For convenience, each condition of well-formedness is proved separately, capitalising on thefact that the encoding returns an initial choreography. The proof follows the recursive structure of the definition of Encoding_rec , and is relatively automatic once the relevant splitting in cases is done.
Lemma Encoding_WF : ∀ { n } ( f : PRFunction n ) ps q , ~ In q ps → CCP_WF ( Encoding f ps q ). ormalising a Turing-Complete Choreographic Language in Coq 15 Soundness of the encoding – the property that the encoding of 𝑓 implements 𝑓 – is proven by analysing the executionpath obtained by always reducing the first action in the choreography, and invoking confluence. We split the proof intoa number of lemmas, stating the obvious reductions from each procedure definition to the procedure call at its end. Wegive some examples of these results. Lemma Zero_reduce : ∀ Defs ( ps : t Pid q X s , ∃ t , ( Build_Program Defs ( Send ( hd ps ) zero q ;; Call X ), s )—[ t ] −→ ( Build_Program Defs ( Call X ), update s q xx Lemma Recursion_reduce_0 : ∀ Defs X n s , ∃ t , ( Build_Program Defs ( Send ( n + 2) zero ( S n );;
Call X ), s )—[ t ] −→ ( Build_Program Defs ( Call X ), update s ( S n ) xx Lemma Recursion_reduce_1_true : ∀ m Defs X Y n ( ps : t Pid ( S m )) q s , s ( S n ) xx = s ( hd ps ) xx → ∃ t s ', ( Build_Program Defs ( IfEq ( S n ) ( hd ps ) (
Send n this q ;; Call X ) (
Call Y )), s )—[ t ] −→ ∗ ( Build_Program Defs ( Call X ), s ') ∧ s ' q xx = s n xx ∧ ∀ p , p ≠ q → s ' p xx = s p xx . Lemma Recursion_reduce_1_false : ∀ m Defs X Y n ( ps : t Pid ( S m )) q s , s ( S n ) xx ≠ s ( hd ps ) xx → ∃ t , ( Build_Program Defs ( IfEq ( S n ) ( hd ps ) (
Send n this q ;; Call X ) (
Call Y )), s )—[ t ] −→ ∗ ( Build_Program Defs ( Call Y ), update s ( S n ) yy ( s ( hd ps ) xx )). We briefly explain the lemmas about recursion. Encoding 𝑅 ( 𝑔, ℎ ) uses three auxiliary procedures. The first one initializesthe recursion by placing a zero on the first auxiliary process (Lemma Recursion_reduce_0 ), and calls the first procedure inthe encoding of 𝑔 . The second one, placed immediately after the procedures used for encoding 𝑔 , checks whether the valuein the auxiliary process is the value where we want to stop, and in this case places the result in the return process (Lemma Recursion_reduce_1_true ). Otherwise, it calls the first procedure in the encoding of ℎ (Lemma Recursion_reduce_1_true ).(This explanation assumes the values of X and Y to be instantiated in the right way, but the lemmas do not depend onthis.) The third procedure, invoked when ℎ terminates, increases the value of the auxiliary process controlling the loop(Lemma Recursion_reduce_2 , omitted). All these lemmas also include characterisations of the resulting state that areneeded for applying the induction hypothesis in the main proof.Using these results, we can prove by induction that, if 𝑠 is a state where 𝑛 , . . . , 𝑛 𝑚 are stored in the appropriateprocesses, (i) if 𝑓 ( 𝑛 , . . . , 𝑛 𝑘 ) converges, then there is some execution path of the encoding of 𝑓 from 𝑠 that terminateswith the expected result; (ii) using confluence, all execution paths from 𝑠 must terminate in the same state; and (iii) thatif 𝑓 ( 𝑛 , . . . , 𝑛 𝑘 ) diverges, then no execution of the encoding of 𝑓 from 𝑠 terminates. These three results are combinedin a single theorem, stating that the default encoding of 𝑓 (where 𝑛 , . . . , 𝑛 𝑚 are stored in processes 1 , . . . , 𝑚 , and theresult is returned in process 0) is sound. Theorem encoding_sound : ∀ n ( f : PRFunction n ), implements ( Encoding ' f ) f ( vec_1_to_n n ) 0. This part of the development contains 28 definitions and 65 lemmas, with a total of 2352 lines of code.6 Luís Cruz-Filipe, Fabrizio Montesi, and Marco Peressotti
We presented a formalisation of a choreographic language and proved it Turing complete. To the best of our knowledge,this is the first time that such a task has been achieved – the only comparable work in progress consists of a preliminarypresentation on a certified compiler from choreographies to CakeML [15], which however does not deal with the majorchallenge of recursion (the choreography language used therein is simplistic and can only express finite behaviour) [21].Moreover, we showed how formalising proofs unveiled subtle problems in definitions and can influence the developmentof the theory, making a case for a more systematic use of theorem provers in research in the field. The number ofchoreographic languages proposed in the literature is increasing rapidly, to include features of practical value suchas asynchronous communication, non-determinism, broadcast, dynamic network topologies, and more [2, 12, 17].Hopefully, our work can contribute a solid foundation for the development of these features. This recalls the situationfound in the field of process calculi, and indeed similar conclusions are drawn in an article that presents the formalisationof a higher-order process calculus in Coq [24].It is interesting that the proof of Turing completeness – both construction and proofs – still closely follows theoriginal theory [8], despite the significant changes to the lowest layers that we had to make. This suggests that themajor formalisation challenge currently lies in the foundational work. To the best of our knowledge, this is also the firsttime that Kleene’s theory of partial recursive functions has been formalised in Coq.Our formalisation includes some design options. The most significant one, in our opinion, is the restriction to onlytwo labels in selections. However, as is well known in the field of session types, this is not a serious restriction [4].Labels are typically used to communicate choices based on a conditional; more complex decisions are expressed asnested conditionals, and can be communicated by sending multiple label selections.Restricting the set of labels to two elements also has a strong impact on the formalisation of realisability [3, 5],which we do not discuss in this article. Choreography realisability deals with identifying sufficient conditions for achoreography to be implementable in a distributed setting, and generating an implementation in a process calculusautomatically. We are currently finishing formalising this construction, and this process heavily relies on the set of labelsbeing fixed. An important result is that any choreography can be amended into a realisable one, so that in particular ourTuring-completeness result immediately implies Turing-completeness of the process calculus used for implementations.We aimed at making our development reusable, so that it can readily be extended to more expressive choreographiclanguages. In the future, we plan to look at interesting extensions (such as those mentioned above) and explore howeasy it is to extend the current formalisation to those frameworks. We conjecture that this will prove much simplerthan the current effort, thanks to the structures established in this work.The full development can be downloaded at [10].
ACKNOWLEDGMENTS
This work was partially supported by Villum Fonden, grant no. 29518.
REFERENCES [1] Elvira Albert and Ivan Lanese (Eds.). 2016.
Formal Techniques for Distributed Objects, Components, and Systems - 36th IFIP WG 6.1 InternationalConference, FORTE 2016, Held as Part of the 11th International Federated Conference on Distributed Computing Techniques, DisCoTec 2016, Heraklion,Crete, Greece, June 6-9, 2016, Proceedings . Lecture Notes in Computer Science, Vol. 9688. Springer.[2] Davide Ancona, Viviana Bono, Mario Bravetti, Joana Campos, Giuseppe Castagna, Pierre-Malo Deniélou, Simon J. Gay, Nils Gesbert, Elena Giachino,Raymond Hu, Einar Broch Johnsen, Francisco Martins, Viviana Mascardi, Fabrizio Montesi, Rumyana Neykova, Nicholas Ng, Luca Padovani, Vasco T.Vasconcelos, and Nobuko Yoshida. 2016. Behavioral Types in Programming Languages.
Foundations and Trends in Programming Languages
3, 2–3 ormalising a Turing-Complete Choreographic Language in Coq 17 (2016), 95–230.[3] Samik Basu, Tevfik Bultan, and Meriem Ouederni. 2012. Deciding choreography realizability. In
Procs. POPL , John Field and Michael Hicks (Eds.).ACM, 191–202. https://doi.org/10.1145/2103656.2103680[4] Luís Caires and Frank Pfenning. 2010. Session Types as Intuitionistic Linear Propositions. In
Procs. CONCUR (Lecture Notes in Computer Science) ,Paul Gastin and François Laroussinie (Eds.), Vol. 6269. Springer, 222–236. https://doi.org/10.1007/978-3-642-15375-4_16[5] Marco Carbone, Kohei Honda, and Nobuko Yoshida. 2012. Structured Communication-Centered Programming for Web Services.
ACM Trans.Program. Lang. Syst.
34, 2 (2012), 8:1–8:78. https://doi.org/10.1145/2220365.2220367[6] Marco Carbone and Fabrizio Montesi. 2013. Deadlock-freedom-by-design: multiparty asynchronous global programming. In
Procs. POPL , RobertoGiacobazzi and Radhia Cousot (Eds.). ACM, 263–274. https://doi.org/10.1145/2429069.2429101[7] Luís Cruz-Filipe and Fabrizio Montesi. 2016. Choreographies in Practice, See [1], 114–123. https://doi.org/10.1007/978-3-319-39570-8_8[8] Luís Cruz-Filipe and Fabrizio Montesi. 2020. A core model for choreographic programming.
Theor. Comput. Sci.
802 (2020), 38–66. https://doi.org/10.1016/j.tcs.2019.07.005[9] Luís Cruz-Filipe, Fabrizio Montesi, and Marco Peressotti. 2019. Choreographies in Coq. In
TYPES 2019, Abstracts . Extended abstract.[10] Luís Cruz-Filipe, Fabrizio Montesi, and Marco Peressotti. 2021. A Formalisation of a Turing-Complete Choreographic Language in Coq. https://doi.org/10.5281/zenodo.4479102[11] Mila Dalla Preda, Maurizio Gabbrielli, Saverio Giallorenzo, Ivan Lanese, and Jacopo Mauro. 2017. Dynamic Choreographies: Theory And Implement-ation.
Log. Methods Comput. Sci.
13, 2 (2017). https://doi.org/10.23638/LMCS-13(2:1)2017[12] Simon J. Gay, Vasco T. Vasconcelos, Philip Wadler, and Nobuko Yoshida. 2017. Theory and Applications of Behavioural Types (Dagstuhl Seminar17051).
Dagstuhl Reports
7, 1 (2017), 158–189. https://doi.org/10.4230/DagRep.7.1.158[13] Saverio Giallorenzo, Ivan Lanese, and Daniel Russo. 2018. ChIP: A Choreographic Integration Process. In
Procs. OTM, part II (Lecture Notes inComputer Science) , Hervé Panetto, Christophe Debruyne, Henderik A. Proper, Claudio Agostino Ardagna, Dumitru Roman, and Robert Meersman(Eds.), Vol. 11230. Springer, 22–40. https://doi.org/10.1007/978-3-030-02671-4_2[14] Saverio Giallorenzo, Fabrizio Montesi, and Marco Peressotti. 2020. Choreographies as Objects.
CoRR abs/2005.09520 (2020). https://arxiv.org/abs/2005.09520[15] Alejandro Gomez-Londono and Johannes Aman Pohjola. 2018. Connecting Choreography Languages With Verified Stacks. In
Procs. of the NordicWorkshop on Programming Theory . 31–33. http://hdl.handle.net/102.100.100/86327?index=1[16] Kohei Honda, Nobuko Yoshida, and Marco Carbone. 2016. Multiparty Asynchronous Session Types.
J. ACM
63, 1 (2016), 9. https://doi.org/10.1145/2827695 Also: POPL, pages 273–284, 2008.[17] Hans Hüttel, Ivan Lanese, Vasco T. Vasconcelos, Luís Caires, Marco Carbone, Pierre-Malo Deniélou, Dimitris Mostrous, Luca Padovani, AntónioRavara, Emilio Tuosto, Hugo Torres Vieira, and Gianluigi Zavattaro. 2016. Foundations of Session Types and Behavioural Contracts.
ACM Comput.Surv.
49, 1 (2016), 3:1–3:36. https://doi.org/10.1145/2873052[18] Intl. Telecommunication Union. 1996. Recommendation Z.120: Message Sequence Chart.[19] Stephen Cole Kleene. 1952.
Introduction to Metamathematics . Vol. 1. North-Holland Publishing Co.[20] Alberto Lluch-Lafuente, Flemming Nielson, and Hanne Riis Nielson. 2015. Discretionary Information Flow Control for Interaction-OrientedSpecifications. In
Logic, Rewriting, and Concurrency (Lecture Notes in Computer Science) , Narciso Martí-Oliet, Peter Csaba Ölveczky, and Carolyn L.Talcott (Eds.), Vol. 9200. Springer, 427–450. https://doi.org/10.1007/978-3-319-23165-5_20[21] Alejandro Gómez Londoño. 2020. Choreographies and Cost Semantics for Reliable Communicating Systems.[22] Hugo A. López and Kai Heussen. 2017. Choreographing cyber-physical distributed control systems for the energy sector. In
Procs. SAC , AhmedSeffah, Birgit Penzenstadler, Carina Alves, and Xin Peng (Eds.). ACM, 437–443. https://doi.org/10.1145/3019612.3019656[23] Hugo A. López, Flemming Nielson, and Hanne Riis Nielson. 2016. Enforcing Availability in Failure-Aware Communicating Systems, See [1], 195–211.https://doi.org/10.1007/978-3-319-39570-8_13[24] Petar Maksimovic and Alan Schmitt. 2015. HOCore in Coq. In
Interactive Theorem Proving - 6th International Conference, ITP 2015, Nanjing, China,August 24-27, 2015, Proceedings (Lecture Notes in Computer Science) , Christian Urban and Xingyuan Zhang (Eds.), Vol. 9236. Springer, 278–293.https://doi.org/10.1007/978-3-319-22102-1_19[25] Fabrizio Montesi. 2013.
Choreographic Programming
Commun. ACM
Proc. ACM Program. Lang.