2.1 Processes

We assume that there is a fixed set of process names et cetera. These processes can represent nodes in a distributed system, system processes, threads, or more. Process polymorphism allows us to refer to processes using type variables, which may go in or out of scope. Despite this, the set of physically-running processes remains the same.

We assume every process knows its identity. Thus, every process can choose what code to run on the basis of its identity. This assumption is reasonable for many practical settings, for instance it is common for nodes in distributed systems to know their identity. This capability is essential to our strategy for enabling process polymorphism.

2.2 Communication

We assume that processes communicate via synchronous message passing. Thus, if sends a message to , then does not continue until has received the message. Moreover, we assume that message passing is instantaneous and certain, so messages do not get lost.

Processes can receive two kinds of messages: values of local programmes (described below) and labels describing choices made during a computation. These are used to ensure that different processes stay in lock-step with each other.

2.3 Local programmes

We assume that processes run a local language described in Section 4. This is a functional language extended with communication features, similar to the language GV (Gay & Vasconcelos, Reference Gay and Vasconcelos2010; Wadler, Reference Wadler2012; Lindley & Morris, Reference Lindley and Morris2015). Even more related to our work is FST (System F with Session Types) Lindley & Morris (Reference Lindley, Morris, Gay and Ravara2017), an extension of GV with polymorphism. As it does not have our communication of distributed values, they can base their types on System F rather that System F $\omega$ .

Endpoint projection translates PolyChor $\lambda$ into this “Network Process” language. We have thus further extended GV with features required for our endpoint projection mechanism. For instance, in the local language described in Section 4 we provide an expression form, which allows a process to choose which code to run based on its identity. Despite these extensions, the language should feel familiar to any reader familiar with polymorphic $\lambda$ -calculi.

3.1 Typing

We now turn to the type system for PolyChor $\lambda$ . As before, our type system builds on that for Chor $\lambda$ . Here, we focus on the rules that are new in this work. Thus, we focus on rules related to polymorphism, and those that have had to change due to polymorphism.

Typing judgements for PolyChor $\lambda$ have the form , where $\Theta$ is the set of process names—either names in or type variables with kind —used in M or the type of M. The typing environment $\Gamma$ is a list associating variables and function names to their types and type variables and process names to their kinds. We sometimes refer to the pair $\Theta;\Gamma$ as a typing context.

Selected rules for our type system can be found in Figure 3. The full collection of rules are given in Appendix A. Again, many of the rules are inherited directly from Chor $\lambda$ (Cruz-Filipe et al., Reference Cruz-Filipe, Graversen, Lugovic, Montesi and Peressotti2022); we thus focus on the rules that have changed due to our additions. Many, if not most, of these rules are inspired by System F $\omega$ . However, the addition of the kind of processes and Without kinds—i.e., kinds of the form —also lead to some changes.

Fig. 3. Typing rules (Selected).

The rules give types to values of base types. Here, we have to ensure that the location of the term is a process. Intuitively, then, we want the location to have kind . However, it might be a Without kind—that is, it might be of the form . In this case, our subkinding system (which you can find details about in Section 3.2) still allows us to apply the rule.

We express function application and abstraction via the rules, respectively. The application rule is largely standard—the only addition is the addition of a set on the function type, as discussed earlier. The abstraction rule , on the other hand, is more complicated. First, it ensures that the argument type, , has kind . Then, it ensures that every element in the set decorating the arrow is a process name—i.e., that it has kind . Finally, it checks that, in an extended environment, the body of the function has the output type . As is usual, this extended environment gives a type to the argument. However, it restricts the available process names to those in the set and those mentioned in the types .

There are two ways that a type can mention a process: it can either name it directly, or it can name it via a type variable. Thus, in the rule we allow the free variables of to remain in the process context, computing them using the (standard) free-type-variable function where both bind X. However, we must also identify the involved processes in a type, which we write and compute as follows:

The involved processes of other types are defined homomorphically.

The communication primitives are typed with , respectively. A term behaves as M, where the process informs the process that the $\ell$ branch has been taken, as we saw earlier. Thus, the entire term has type if M does. Moreover, must be processes.

The rule types terms. So far we have been simplifying the type used in for readability. We have been using to denote the input type, but as it turns out to type correctly, we have to complicate things a little. Intuitively, a term represents communicating the parts of M on . Thus, we require that be a type transformer requiring a process. Moreover, cannot be mentioned in otherwise, not every part of the type of M on in our example above would transfer to . For this, we use the following notion of mentioned processes:

Again, with other types being defined homomorphically. The difference between involved and mentioned processes is subtle. If there is no polymorphism, they are the same, but when dealing with polymorphism with restriction they are opposites: involved processes includes every process not in the restriction (the variable could be instantiated as something involving those processes and thus they may be involved), while mentioned names includes the processes mentioned in the restriction. Mentioned names is used only when typing . If we have such a type-level function, , and two type values which are not and will not be instantiated to anything mentioned in then we can type as a function from . Since this is direct communication, no intermediaries are necessary and we can associate this arrow with the empty set .

It is worth noting at this point that the communication rule inspired our use of System F $\omega$ rather than plain System F, which lacks type-level computation. In Chor $\lambda$ and other previous choreographic languages, communicated values must be local to the sender. In PolyChor $\lambda$ , this would mean not allowing the communicated type to include type variables or processes other than the sender. Since we are introducing the idea of using communication as a means of delegation, we have slackened that restriction. This means that PolyChor $\lambda$ programmes can communicate larger choreographies whose type may involve other processes, and importantly other type variables. We see this in the delegation example Listing (1.5), where we have the communication . Adding in the required type annotation (which we had suppressed in the introduction), this becomes . Note that this still leaves us with a free type variable B, representing the unknown process that is telling to interact with! Since we cannot ban free type variables in communicated types, we must create a typing system that can handle them, and this requires type-level computation.

To see why this led us to type-level computation, consider the alternative. In Chor $\lambda$ and other choreographic works, we would have a type communication using process substitution instead of communication. The annotated programme would then be . When applied to a programme of appropriate type, the result would have type

Note that, because B is a type variable, it was ignored by the substitution. If B is later instantiated as , then we must substitute B with in the output type. Thus, we need some mechanism to delay this substitution; rather than use a mechanism like explicit substitutions, we instead reached for the standard tool of System F $\omega$ . The communication winds up instead being written as with X being instantiated as in the input type and in the output type. This seemed more elegant and less ad-hoc; moreover, it adds features which a real-world implementation of PolyChor $\lambda$ would want anyway. To ensure that B does not get instantiated incorrectly, we use our Without kinds. Rule requires that both are restricted on B, which, thanks to our restrictions being symmetric, means that B cannot be instantiated as either of them. The Without kinds here prevent nonsensical typings of where, in the type, part of the output does not get moved from the sender to the receiver. This can happen if a type variable present in the type of the communicated value is instantiated during execution before the communication takes place, but has not yet been instantiated when we type the choreography. Where it not for the restrictions imposed by Without kinds, we would allow the choreography

to be typed as , which implies that part of the function is still at after the communication is executed. This is not what will happen when actually executing the choreography, so the type is wrong. The Without kinds ensure that the choreography cannot be typed: the kind of B must be , and therefore, it cannot be instantiated as .

Returning now to the typing rules of Figure 3, we next have the rules, which type universal quantification. The rule is completely standard, while the others are 4 cases of what to do with a type abstraction. Each of these rules have a different definition for the typing context of M, depending on the kind of X. As is standard, we check if the body of the function has the right type when the parameter X has kind . But first, if X is a process as in , then we need to extend $\Theta$ with X. In addition, we must further manipulate the context in order to ensure that the types whose kinds are restricted on X correspond to the restriction on the kind of X.

First, the new type variable X may shadow a previously defined X. Thus, we need to remove X from any Without kinds already in the context. We do this using the following operation :

We define $+$ on other kinds homomorphically and extend this to contexts as usual:

Furthermore, in if X itself has a Without kind—that is, X’s kind tells us it cannot be any of the processes in —then we need to symmetrically add a restriction on X to every type in . Otherwise, we would not be able to use the roles in in any place where we cannot use X, even though we know X will not be instantiated with them. We do this with the operation , which we define as follows:

With these operations in place, we can now fully understand how to type the type abstractions. When is actually a Without kind, then we must handle both shadowing and symmetrical restrictions. However, when it is not a Without kind, we must only handle shadowing. We show an example where every possible complication

Example 1 (Typing complex type abstractions). Consider the following choreography, which takes a process A and sends an integer communication with A from :

That A has a Without kind and the fact that A is a process means that we will need to use Rule when typing M. In order to illustrate the necessity of shadowing, we will include an unnecessary process in our environment. Setting , we start with the following judgement:

We need to take into account both that A is a process and that it has a Without kind in order to make the choreography typeable. First, we shadow, obtaining the following:

so we get rid of any restrictions on previous variables called A. We then add the new symmetric restrictions necessary for typing the communication, as follows:

Continuing on, we can abbreviate . Finally, we add A to the environment and $\Theta$ (writing $\Theta' = \Theta \cup \{A\}$ ), giving:

where . Because of the restrictions in Rule , N would not be typable if we had not made sure to add the symmetric restrictions. We will furthermore see in Section 3.2 that adding A to the set process names is also necessary when kinding it with the kind.

On the other hand, although the rule looks bigger at first glance, it is much simpler to use Rule .

We can type this as

Since we have no shadowing, the only way we have to manipulate our environment when entering the type abstraction is to add to the environment, giving us

Rules are for cases of middling complexity. In Rule , we have to add the type variable to $\Theta$ , as in . However, since we have no restrictions, we do not need to consider symmetric conflict. In Rule , we do consider symmetric conflicts, but do not add to $\Theta$ (since we are not dealing with a process).

The final addition to our type system is the rule . This is another standard rule from System F $\omega$ ; it tells us that we are allowed to compute in types. More specifically, it tells us that we can replace a type with an equivalent type, using the following equivalence:

In addition to the rules in Figure 3 for typing choreographies, our type system needs one more rule for typing the definitions of our recursive functions. We also add an extra judgement of the form $\Theta; \Gamma \vdash D$ where $\Theta; \Gamma$ is a typing context as before, and D is a set of definitions for function variables—i.e., $D = \{f_1 = M_1, \ldots f_n = M_n\}$ . We write D(f) for the term associated with f in D. The only rule for this judgement is , which says that a set of definitions is well-formed if every variable in D is associated with a type in $\Gamma$ , and the body of f in D can be given be given type in the context $\emptyset; \Gamma$ . We require that the body of f can be typed with an empty set of roles because they are global predefined functions, and as such they should not be local to any one process.

3.2 Kinding

We finish our discussion of the static semantics of PolyChor $\lambda$ by looking at our kinding system. Our kinding system uses only one judgement, , which says that in the typing context $\Theta; \Gamma$ , the type has kind . You can find the rules of our kinding system in Figure 4. These are mostly directly inherited from System F $\omega$ . However, we must account for and Without kinds.

Fig. 4. Kinding rules.

For instance, the rules check that the type representing which process is storing the data indeed has the kind . Similarly, ensures that all of the types in the set of possible intermediaries are processes. The rule for type variables, , ensures that if a type variable X is assigned kind , then X must also be in $\Theta$ .

One of the biggest differences between our kinding system and that of System F $\omega$ , however, is the rule which tells us that our system enjoys subkinding. The subkinding rules come from the subset ordering on Without kinds. We also consider any kind equivalent to the same kind restricted on the empty set due to and .

The rules for subkinding are as follows:

We also find that types have the same kinds as their equivalent type values. Due to $\beta$ -expansion, a kindable type can be equivalent to an unkindable type, but not an unkindable type value.

This type shows both the input, output, and involved roles of the choreography.

3.3 Operational semantics

Finally, we consider the operational semantics of PolyChor $\lambda$ . In practice, the semantics of a choreographic language can be used to simulate a choreography and check if it specifies the expected collective behaviour. Its key role, however, is to prove properties about the projected local code. Specifically, we are going to prove that the projected code is compliant to the choreography (an operational correspondence result) and that as a result it is deadlock-free. The semantics of PolyChor $\lambda$ are mostly a standard call-by-value reduction semantics for a typed $\lambda$ calculus. However, the reduction semantics must also carry a set D of function definitions. Only a few rules are unusual or must be modified; those can be found in Figure 5. You can find the rest of the rules in Appendix B.

Fig. 5. Semantics of PolyChor $\lambda$ (selected rules).

The rules come from System F $\omega$ . The rule is similar to ordinary CBV $\beta$ reduction, but tells us how to reduce a type abstraction applied to a type value, but with the caveat that if we do not have a type value we must use type equivalence to get one before reducing. The rule tells us that we can reduce a type function applied to any argument.

The rule allows us to reduce function names by looking up their definition in the set D.

Finally, we have the rules for communication. The rule says that acts as a no-op, as we stated earlier. While this may seem redundant, such terms are vital for projection, as we will see in the next section. More importantly, the rule tells us how we represent communication at the choreography level: via substitution of roles. This also helps explain some of the restrictions in . Since we replace all mentions of with in V, we cannot allow other mentions of in the type transformer of V. Otherwise, there could be some mentions of P which should not be replaced during communication, which we do not model. Unlike when typing , when executing a communication we know (since we only consider choreographies without free variables) that any type variables in or V have already been instantiated and as such do we do not need to consider how to substitute variables which may later be instantiated to .

It may be surprising to learn that our semantics are simply call-by-value reduction semantics, especially for those readers familiar with choreographies. After all, choreographies are supposed to represent concurrent programmes, and so multiple redices should be available at any time. Indeed, previous works on choreographic programming (e.g., Carbone & Montesi, Reference Carbone and Montesi2013; Cruz-Filipe & Montesi, Reference Cruz-Filipe and Montesi2020; Hirsch & Garg, Reference Hirsch and Garg2022) provided a semantics with out-of-order execution, so that the operational semantics of the choreographies matched with all possible reductions in the concurrent interpretation. We use these simpler semantics, without out-of-order execution, instead. In exchange, our result in Section 5 will be weaker: we only promise that any value which the choreography can reduce to, so can the concurrent interpretation.

To see why we chose to obtain this weaker result, consider the choreography

Here we have a function f which needs to be instantiated with a distributed pair. is ready to feed its part of the argument into f and start computing the result, while and are still working on computing their part of the argument. There are two ways we could interpret PolyChor $\lambda$ concurrently: we can synchronise when all processes enter a function or we can allow to enter the function early. We take the second, more practical, route. However, this means it is not possible to reflect at least one evaluation order into the semantics of the choreography without banning distributed values or allowing us to somehow call a single value in multiple steps. This insight led to us adopting the weaker guarantee discussed above.

As is standard for call-by-value $\lambda$ -calculi, we are able to show that our type system is sound with respect to our operational semantics, as expressed in the following two theorems:

Theorem 3 (Type Preservation). Let M be a choreography and D a function mapping containing every function in M. If there exists a typing context $\Theta;\Gamma$ such that and $\Theta;\Gamma\vdash D$ , then for any M’ such that $M\rightarrow_{D} M'$ .

4.1 Projection

We can now define the endpoint projection (EPP) of choreographies. This describes a single process’s view of the choreography; the concurrent interpretation of a choreography is given by composing the projection to every process in parallel. Endpoint projection to a particular process is defined as a recursive function over typing derivations . For readability, however, we write it as a recursive function over the term M, and use the notation to refer to the types assigned to any term N in the implicit typing derivation. Similarly, we use to refer to the kind of a type in the implicit typing derivation. We write to denote the projection of the term M (implicitly a typing derivation for M, proving that it has some type) to the process .

Intuitively, projection translates a choreography term to its corresponding local behaviour. For example, a communication action projects to a send (for the sender), a receive (for the receiver), a substitution (for the other processes in the type of the value being communicated) or an empty process (for the remaining processes). However, this is more complicated for statements. For instance, consider the following choreography, which matches on a sum type which is either an integer on or a unit on . If it is an integer, then receives that integer from Alice and the choreography returns the integer now located at . Otherwise, the choreography returns the default value 42 also located at of which branch she has taken using terms.

Imagine projecting this to ’s point of view. He does not have any of the information in the sum, so he cannot participate in choosing which branch of the expression gets evaluated. Instead, he has to wait for to tell him which branch he is in. If we naïvely translate just the first branch of the case expression, waits for to send him the label Just and then waits for to send him an integer. Similarly, in the second branch waits for to send him the label Nothing before returning the default value 42. Somehow, we need to combine these so that waits for either label, and then takes the corresponding action.

We do this by merging ’s local programmes for each branch (Carbone et al., Reference Carbone, Honda and Yoshida2012; Honda et al., Reference Honda, Yoshida and Carbone2016; Cruz-Filipe & Montesi, Reference Cruz-Filipe and Montesi2020). Merging is a partial function which combines two compatible local programmes, combining choice statements. In other words, the key property of merging is:

Merging is defined homomorphically on other terms, though it is undefined on incompatible terms. Thus, for example, is undefined.

We can then use this to project the choreography above to as:

where represents a part of the choreography executed by .

Definition 2. The EPP of a choreography M for process is defined by the rules in Figures 9, 10 and 11.

Fig. 9. Projection of PolyChor $\lambda$ programmes.

Fig. 10. Projection of PolyChor $\lambda$ programmes (ctd.).

Fig. 11. Projection of PolyChor $\lambda$ types.

To project a network from a choreography, we therefore project the choreography for each process and combine the results in parallel: .

Intuitively, projecting a choreography to a process that is not involved in it returns a . More-complex choreographies, though, may involve processes that are not shown in their type. This explains the first clause for projecting an application: even if does not appear in the type of M, it may participate in interactions inside M. A similar observation applies to the projection of , where merging is also used.

Selections and communications follow the intuition given above, with one interesting detail: self-selections are ignored, and self-communications project to the identity function. This is different from many other choreography calculi, where self-communications are not allowed—we do not want to impose this in PolyChor $\lambda$ , since we have process polymorphism and therefore do not want to place unnecessary restrictions on which processes a choreography can be instantiated with.

Any process must prepare two behaviours for a process abstraction : one for when X is instantiated with itself, and one for when X is instantiated with another process. To do this, we use terms, which allow to use its knowledge of its identity to select which behaviour takes place. (This also holds when X has a Without kind, as long as the base kind is , is excluded from the type of X and does not participate in M then we simply project to .) However, type abstractions terms if is not a kind of processes, since cannot instantiate X.

When projecting an application, we may project both the function and its argument, either one but not the other, or neither. While it may seem simple—just project both sides, and get rid of any that come up—it turns out to be somewhat complicated. In order to ensure every process performs actions in the same order and avoid communication mismatches, we must project an abstraction for any process involved in the computation, even if they do not have the input (Cruz-Filipe et al., Reference Cruz-Filipe, Graversen, Lugovic, Montesi and Peressotti2023, Example 6). To see why this causes complications, consider . When M gets projected to , it becomes . However, applying M to an argument—say, —needs to lead to a function application on ! Thus, we project this to , allowing Q to instantiate its function. We use the type system to identify the cases where we need to keep and those where we should only project the function part of an (type) application.

Type applications work a bit differently. Since there is no chance of communication happening while computing a type, we can project only the body of a type abstraction without the actual abstraction to when we know the argument is not located at . In addition, we do not have a case for projecting only the argument, since the context surrounding a type abstraction will not expect a type.

In general, projecting a type yields at any process not used in that type. We use the restrictions on kinds to avoid projecting type variables and type abstractions when we know we do not need to and project all process names to themselves, but otherwise the projection of type constructs is similar to that of corresponding process terms.

Finally, to execute a projected choreography, we need to project the set of definitions of choreographic functions to a set of definitions of local functions. Since these functions are all parametrised over every involved process, this is as simple as projecting the definitions onto an arbitrarily chosen process name.

Note that function names always get projected everywhere. This means that if we have a function which does not terminate when applied to some value in any process, then it diverges when applied to that value in the choreography and in every other process.

Example 5. We will now show how to project the bookseller service example Equation (1.5). As in that example we use as syntactic sugar for for some as syntactic sugar for for some . We project for and get the following process:

Here we can see that if the buyer B turns out to be itself, then all the communications become identity functions, and the seller does not inform itself of its choice. Otherwise, we get a function which, after being instantiated with a buyer, also needs to be instantiated with two s representing values existing at B. It then waits for B to send a title, returns the price of this title, and waits for B to decide whether to buy or not. It might seem strange to have a function parametric on two values that are located at B and will therefore here be instantiated with s, but this example actually illustrates why when projecting we cannot in cases like this remove the first two $\lambda$ s from the process without causing a deadlock. Consider that is syntactic sugar for . Here we need to have the abstraction on y even though it gets instantiated as sends the result of . If instead we only had , then the first part of the application would not be a value, and would be waiting for B to choose between $\textsf{Buy}$ and $\textsf{Quit}$ while B has the abstraction on y and therefore considers the first part of the application a function which must wait to be instantiated. B therefore expects to receive the result of , and we get a deadlock in our system. This is why we never want to project a value to a non-value term and need to keep any abstractions guarding a part of the choreography involving .

7.1 Choreographies

Choreographies are inspired by the “Alice-and-Bob” notation for security protocols by Needham & Schroeder (Reference Needham and Schroeder1978), which included a term for expressing a communication from a participant to another. The same idea inspired later several graphical notations for modelling interactions among processes, including sequence diagrams and message sequence charts (International Telecommunication Union, 1996; Object Management Group, 2017).

A systematic introduction to theory of choreographic languages and their historical development can be found in Montesi (Reference Montesi2023). We recap and discuss relevant recent developments. The first sophisticated languages for expressing choreographies were invented to describe interactions between web services. The Web Services Choreography Description Language (WS-CDL) by The World Wide Web Consortium (W3C) (2004) is a choreographic language which describes the expected observable interactions between web services from a global point of view (Zongyan et al., Reference Zongyan, Xiangpeng, Chao and Hongli2007). Carbone et al. (Reference Carbone, Honda and Yoshida2012) later formalised endpoint projection for a theory of choreographies based on WS-CDL, and in particular introduced the merging operator (which we adjusted and extended to our setting). This inspired more work on choreographies and projection and eventually the birth of choreographic programming—where choreographies are programmes compiled to executable code—and the first choreographic programming language, Chor (Montesi, Reference Montesi2013). As choreographic programming languages became more complex, Cruz-Filipe & Montesi (Reference Cruz-Filipe and Montesi2020) developed a core calculus of choreographies (CC). Montesi (Reference Montesi2023) revisited and generalised CC in his text on foundations of choreographic languages. Cruz-Filipe et al. (Reference Cruz-Filipe, Montesi and Peressotti2021) then formalised this new version and its properties in the Coq theorem prover (The Coq Development Team, 2004). Later, Pohjola et al. (Reference Pohjola, Gómez-Londoño, Shaker and Norrish2022) developed a certified end-to-end compiler from another variation of CC to CakeML by using the HOL theorem prover.

One of the primary design goals of all of choreographic programming languages is deadlock-freedom by design (Carbone & Montesi, Reference Carbone and Montesi2013)—the operational correspondence between the choreography and the distributed network ensures deadlock-freedom for the network. PolyChor $\lambda$ achieves this goal. Montesi (Reference Montesi2023) discusses restrictions for a procedural imperative choreographic language in order to obtain a stronger liveness property (starvation-freedom). The idea is to prove that processes eventually get involved in transitions at the choreographic level and then leverage the correctness of endpoint projection to obtain the same result about choreography projections. This idea might work for PolyChor $\lambda$ as well, but whether and how the technical devices for starvation-freedom in Montesi (Reference Montesi2023) can be adapted to PolyChor $\lambda$ is not clear due to the different nature of our language (functional instead of imperative). Alternatively, one could adapt static analyses for lock-freedom—like that in Kobayashi (Reference Kobayashi2006)—to choreographies. We leave explorations of liveness properties other than deadlock-freedom in PolyChor $\lambda$ to future work.

The first choreographic language with limited process polymorphism was Procedural Choreographies (PC) (Reference Cruz-Filipe and MontesiCruz-Filipe & Montesi, 2017b ). In PC, a choreography comes with an environment of predefined procedures parametric on process names which may be called by the choreography. These procedures have a number of limitations compared to the process polymorphism of PolyChor $\lambda$ : they cannot contain any free processes, they cannot be partially instantiated, and they are lower-order—that is, they must be defined in the environment rather than as part of a larger choreography. These limitations allow the projection function to know how the procedure will be instantiated, whereas in PolyChor $\lambda$ we may need to compute the processes involved first. This has major implications for projection: in PC, it is easy to tell when projecting a procedure call which processes are involved and therefore need a local copy of the call. However, PolyChor $\lambda$ ’s full process polymorphism allows the function and process names to each be enclosed in a context. While this allows greater flexibility for programmers, it forces us to project a process-polymorphic functions to every process and let each process determine at runtime whether it is involved.

Recently, there has been a fair amount of interest in higher-order and functional programming for choreographies (Hirsch & Garg, Reference Hirsch and Garg2022; Cruz-Filipe et al., Reference Cruz-Filipe, Graversen, Lugovic, Montesi and Peressotti2022; Shen et al., Reference Shen, Kashiwa and Kuper2023; Giallorenzo et al., Reference Giallorenzo, Montesi and Peressotti2023). The first higher-order choreographic programming language, Choral (Giallorenzo et al., Reference Giallorenzo, Montesi and Peressotti2023) is an object-oriented choreographic language compiled to Java code. Thus, Choral choreographies can depend on other choreographies, allowing programmers to reuse code. Choral was also the first choreographic language to treat as a first-class function.

While Choral gave a practical implementation of higher-order choreographies, it did not establish their theoretical properties. Two different—but independently developed—works filled this gap, including Chor $\lambda$ , the basis of PolyChor $\lambda$ . Chor $\lambda$ is a functional choreographic calculus based on the $\lambda$ -calculus. In this work, we extended Chor $\lambda$ with type and process polymorphism and the ability to send non-local values such as choreographies. Chor $\lambda$ , and hence PolyChor $\lambda$ , provides a core language for higher-order choreographies, thus allowing us to establish their properties. Since the original Chor $\lambda$ has parametric procedures like PC and Choral, it lacks PolyChor $\lambda$ ’s property that a choreography diverging in one process must diverge in every process. This forces Chor $\lambda$ to have both a complex notion of out-of-order execution and a more lax correspondence between actions in the network and the choreography.

The other work establishing the theoretical properties of higher-order choreographic programming is Pirouette (Hirsch & Garg, Reference Hirsch and Garg2022), which is also a functional choreographic programming language based on simply-typed $\lambda$ calculus. Unlike Chor $\lambda$ (and thus PolyChor $\lambda$ ), Pirouette does not allow processes to send messages written in Pirouette. Instead, it takes inspiration from lower-order choreographic programming languages in which (the computations to produce) messages are written in their own separate language. Like other choreographic languages (Cruz-Filipe et al., Reference Cruz-Filipe, Montesi and Peressotti2021; Montesi, Reference Montesi2023), Pirouette’s design is parametrised by the language for writing messages. Thus, Pirouette can describe communication patterns between processes that draw from a large swath of languages for their local computations. Nevertheless, this design means that Pirouette fundamentally cannot allow programmes to send choreographic functions, unlike PolyChor $\lambda$ .

Moreover, unlike Chor $\lambda$ and PolyChor $\lambda$ , Pirouette forces every process to synchronise when applying a function. This allows Pirouette to establish a bisimulation relation with its network programming language, a result formalised in Coq. This result allows a traditional—and verified—proof of deadlock-freedom by construction. However, this constant synchronisation would be a bottleneck in real-world systems; PolyChor $\lambda$ ’s choice to obtain a weaker—but strong-enough—connection between the languages allows it to avoid this high cost.

7.2 Concurrent functional programming

Functional concurrent programming has a long history, starting with attempts to parallelise executions of functional programmes (Burton, Reference Burton1987). The first language for functional programming with communications on channels was Facile (Giacalone et al., Reference Giacalone, Mishra and Prasad1989) which, unlike later choreographic languages, had an abstraction over process IDs very similar to process polymorphism. A more recent work, which more closely resembles choreographic programming, is Links (Cooper et al., Reference Cooper, Lindley, Wadler and Yallop2006), with the RPC calculus (Cooper & Wadler, Reference Cooper and Wadler2009) as its core language. Links and the RPC calculus, like choreographies, allow a programmer to describe programmes where different parts of the computation takes place at different locations and then compile it to separate code for each location. Interestingly, though Links has explicit communication, in the RPC calculus the top level does not, and communications are created only when projecting a function located at a different process. Moreover, the RPC calculus does not feature multiple threads of computation; instead, on communication the single thread of computation moves to a new location while other locations block. The RPC calculus was later extended with location polymorphism, very similar to our and Facile’s process polymorphism (Choi et al., Reference Choi, Cheney, Fowler and Lindley2020). However, as the RPC calculus only deals with systems of 2 processes, a client and a server, they project a process abstraction as a pair and then the location as picking the correct part of this pair. This solution creates a simpler network language but is not suitable for a framework with an arbitrary number of participants such as PolyChor $\lambda$ . Moreover, the RPC calculus—like PolyChor $\lambda$ but unlike traditional choreographic languages—does not have out-of-order execution at the top level.

Session types were applied to a concurrent functional calculus with asynchronous communication by Gay & Vasconcelos (Reference Gay and Vasconcelos2010). Though initially this language did not guarantee deadlock-freedom, only runtime safety, later versions of GV (Wadler, Reference Wadler2012; Lindley & Morris, Reference Lindley and Morris2015) did. Jacobs et al. (Reference Jacobs, Balzer and Krebbers2022) extended GV with global types (Honda et al., Reference Honda, Yoshida and Carbone2016), which generalise session types to protocols with multiple participants. Similarly to choreographic programming, global types offer a global viewpoint on interactions. However, they are intended as specifications and thus cannot express computation. Global types are typically projected onto local types, which manually-written programmes can later be checked against. In choreographic programming, by contrast, choreographies are projected directly to programmes. Some works mix the approaches (e.g., Scalas et al., Reference Scalas, Dardha, Hu and Yoshida2017): given a global type, a compiler produces typestate-oriented libraries (Aldrich et al., Reference Aldrich, Sunshine, Saini and Sparks2009) that help the users with following the global type correctly (but not with performing the right computations at the right time).

Session types have also been used to study global higher-order programming outside of functional settings. Mostrous & Yoshida (Reference Mostrous and Yoshida2007) describe the challenges associated with obtaining subject reduction when sessions can pass other sessions between them. Based on this, Mostrous & Yoshida (Reference Mostrous and Yoshida2009) define the higher-order $\pi$ -Calculus with asynchronous sessions, a calculus combining elements of the $\pi$ -calculus and $\lambda$ -calculus.

Castellani et al. (Reference Castellani, Dezani-Ciancaglini, Giannini and Horne2020) propose a notion of session types with delegation. They write delegation by enclosing a part of the global type in brackets. During the execution of such a part, one process acts on another’s behalf by temporarily taking its name. This means that they do not need to inform other participants in the delegated computation that delegation is happening. However, nested delegations can cause deadlocks.

ML5 (Murphy VII et al., Reference Murphy VII, Crary and Harper2007; Licata & Harper, Reference Licata and Harper2010) is a functional concurrent programming language based on the semantics of modal logic. However, instead of the and terms of choreographic languages, they have a primitive get[w] M, which makes another process w evaluate M and return the result. Since M may include other gets, this construct gives ML5 something resembling PolyChor $\lambda$ ’s ability to send a full choreography. However, the result of evaluating this “choreography” must be at the receiver and then returned to the sender.

Multitier programming languages, like ScalaLoci (Weisenburger & Salvaneschi, Reference Weisenburger and Salvaneschi2020), offer another paradigm for describing global views of distributed systems. Like Choral, ScalaLoci is built on top of an existing object-oriented language: in this case, Scala. In ScalaLoci and other tierless languages, an object describes a whole system containing multiple processes and functions. Differently from choreographic programming, multitier programming does not allow for modelling the intended flow of communications. Rather, communication happens implicitly through remote function calls and the concrete protocol to be followed is largely left to be decided by a runtime middleware. For a more detailed comparison of choreographic and multitier languages, see the work of Giallorenzo et al. (Reference Giallorenzo, Montesi, Peressotti, Richter, Salvaneschi and Weisenburger2021).