Session Coalgebras: A Coalgebraic View on Session Types and Communication Protocols

Compositional methods are central to the development and verification of software systems. They allow breaking down large systems into smaller components, while enabling reasoning about the behaviour of the composed system. For concurrent and communicating systems, compositional techniques based on behavioural type systems have received much attention. By abstracting communication protocols as types, these type systems can statically check that programs interact with channels according to a certain protocol, whether the intended messages are exchanged in a certain order. In this paper, we put on our coalgebraic spectacles to investigate session types, a widely studied class of behavioural type systems. We provide a syntax-free description of session-based concurrency as states of coalgebras. As a result, we rediscover type equivalence, duality, and subtyping relations in terms of canonical coinductive presentations. In turn, this coinductive presentation makes it possible to elegantly derive a decidable type system with subtyping for \documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$\pi $$\end{document}π-calculus processes, in which the states of a coalgebra will serve as channel protocols. Going full circle, we exhibit a coalgebra structure on an existing session type system, and show that the relations and type system resulting from our coalgebraic perspective agree with the existing ones.


Introduction
Communication protocols enable interactions between humans and computers alike, yet different scientific communities rely on different descriptions of protocols: one community may use textual descriptions, another uses diagrams, and yet another may use types. There is then a mismatch, which is fruitful and hindering at the same time. Fruitful, because different views on protocols lead to different insights and technologies. But hindering, because exactly those insights and technologies cannot be easily exchanged. With this paper, we wish to provide a view of protocols that opens up new links between communities and that, at the same time, contributes new insights into the nature of communication protocols.
What would such a view of communication protocols be? Software systems typically consist of concurrent, interacting processes that pass messages over channels. Protocols are then a description of the possible exchanges on channels, without ever referring to the exact structure of the processes that use the channels. Since we may, for example, expect to get an answer only after sending a question, it is clear that such exchanges have to happen in an appropriate order. Therefore, protocols have to be a state-based abstraction of communication behaviour on channels. Because coalgebras provide an abstraction of general state-based behaviour, our proposed view of communication protocols becomes: model the states of a protocol as states of a coalgebra and let the coalgebra govern the exchanges that may happen at each state of the protocol.
The above view of protocols allows us to model protocols as coalgebras. However, protocols are usually not studied for the sake of their description but to achieve certain goals: ensuring correct composition of processes, comparing communication behaviour, or refining and abstracting protocols. Session types [19,20] are an approach to communication correctness for processes that pass messages along channels. The idea is simple: describe a protocol as a syntactic object (a type), and use a type system to statically verify that processes adhere to the protocol. This syntactic approach allows the automatic and efficient verification of many correctness properties. However, the syntactic approach depends on choosing one particular representation of protocols and one particular representation of processes. We show in this paper that our coalgebraic view of protocols can guarantee correct process composition, and allows us to reason about key notions in the world of session types, type equivalence, duality and subtyping, while being completely independent of protocol and process representations.
Our coalgebraic view is best understood by following the distillation process of ideas on a concrete session type system by Vasconcelos [37]. Consider the session type S = ?int. !bool. end, which specifies the protocol on one endpoint of a channel that receives an integer, then outputs a Boolean, and finally terminates the interaction. Note that the protocol S specifies three different states: an input state, an output state, and a final state. Moreover, we note that S specifies only how the channel is seen from one endpoint; the other endpoint needs to use the channel with the dual protocol !int. ?bool. end. Thus, session type systems ensure that the states of S are enabled only in the specified order and that the two channel endpoints implement dual protocols.
A state-based reading of session types is intuitive and is already present in programming concepts such as typestates [15,32,33], theories of behavioural contracts [4,6,7,13], and connections between session types and communicating automata [10,25]. The novelty and insight of the coalgebraic view is that 1. it describes the state-based behaviour of protocols underlying session types, supporting unrestricted types and delegation, without adhering to any specific syntax or target programming model; 2. it offers a general framework in which key notions such as type equivalence, duality, and subtyping arise as instances of well-known coinductive constructions; and 3. it allows us to derive type systems for specific process languages, like the π-calculus. Session Coalgebras at Work How does this coalgebraic view of protocols work for general session types? Consider a "mathematical server" that offers three operations to clients: integer multiplication, Boolean negation and quitting. The following session type T specifies a protocol to communicate with this server.
mul : ?int. ?int. !int. X neg : ?bool. !bool. X quit : end T is a recursive protocol, as indicated by "μX. ", which can be repeated. A client can choose, as indicated by &, between the three operations (mul, neg, and quit) and the protocol then continues with the corresponding actions. For instance, after choosing mul, the server requests two integers and, once received, promises to send an integer over the channel. We can see states of the protocol T emerging, and it remains to provide a coalgebraic view on the actions of the protocol to obtain what we will call session coalgebras.  Fig. 1 depicts a session coalgebra that describes protocol T . It consists of states q 0 , . . . , q 6 , each representing a different state of T , and transitions between these states to model the evolution of T . Meaning is given to the different states and transitions through the labels on the states and transitions. The state labels, written in purple at top-left of the state name, indicate the branching type of that state. Depending on the branching type, the labels of the transitions bear different meanings. For instance, q 0 is labelled with "&", which indicates that this state initiates an external choice. The labels on the three outgoing transitions for q 0 (mul, neg, quit) correspond then to the possible kinds of message for selecting one of the branches. Continuing, states q 1 , . . . , q 5 are labelled with a request for data (label ?) or the sending of data (label !), and the outgoing transition labels indicate the type of the exchanged values (e.g., bool). Finally, state q 6 decrees the end of the protocol. Note that the cyclic character of T occurs as transitions back to q 0 ; there is no need for an explicit operator to capture recursion. A session coalgebra models the view on one channel endpoint, but to correctly execute a protocol we also need to consider the dual session coalgebra that models the other endpoint's view. In our example, the dual of Fig. 1 is given by the diagram in Fig. 2, which concerns states s 0 , . . . , s 6 . More precisely, the states q i and s i are pairwise dual in the following sense. The external choice of q 0 becomes an internal choice for s 0 , expressed through the label ⊕, with exactly the same labels on the transitions leaving s 0 . This means that whenever the server's protocol is in state q 0 and the client's protocol in state s 0 , then the client can choose to send one of the three signals to the server, thereby forcing the server protocol to advance to the corresponding state. All other states turn from sending states into receiving states and vice versa. We will see that this duality relation between states of session coalgebras has a natural coinductive description that can be obtained with the same techniques as bisimilarity. The duality relation for T will give us then the full picture of the intended protocol.
Suppose a client who would only want to use multiplication once but could also handle real numbers as inputs. Such a client had to follow the protocol given by the session coalgebra in Fig. 3, with states r 0 , . . . , r 5 . In theories of session types, the protocol of Fig. 2 would be a subtype of this one (cf. [17,16]). Concretely, this new client can also follow the subtype protocol, and can thus communicate with a server following the protocol of Fig. 1. For session coalgebras, we recover the same notion of subtyping by using specific simulation relations that allow us to prove that the behaviour of r 0 can be simulated by s 0 . Together, simulations and duality provide the foundation of typical session type systems.
We have used thus far session types and coalgebras for protocols with simple control and with exchanges of simple data values. In contrast, rich session type systems can regulate session delegation, the dynamic allocation and exchange of channels by processes. Imagine a process that creates a channel, which should adhere to some protocol T . From an abstract perspective, the process holds both endpoints of the new channel, and has to send one of them to the process it wishes to communicate with. To ensure statically that the receiving process respects the protocol of this new channel, we need to announce this communication as a transmission of the session type T (via an existing channel) and use T to verify the receiving process. Session delegation adds expressiveness and flexibility, but may cause problems in the characterisation of a correct notion of duality [18]. Remarkably, our coalgebraic view of session types makes this characterisation completely natural.
As an example, consider the type T = μX. ?X. X, which models a channel endpoint that infinitely often receives channel ends of its own type T . To obtain the dual of T , we may naïvely try to replace the receive with a send, which results in the type μX. !X. X. The problem is that the two channel endpoints would not agree on the type they are sending or receiving, as any dual type of T needs to send messages of type T . Thus, the correct dual of T would be the type U = μX. !T. X. Both T and U specify the transmission of non-basic types, either the recursion variable X or T , in contrast to the mathematical server that merely stipulated the transmission of basic data values (integers or Booleans).
In our session coalgebras for the mathematical server it sufficed to have simple data types and branching labels on transitions. However, to represent T and U we will need another mechanism to express session delegation. We observe that a transmission in session types consists of the transmitted data and the session type that the protocol must continue with afterwards. Thus, a transition out of a transmitting state in a session coalgebra encompasses both a data transition and a continuation transition. In diagrams of session coalgebras, we indicate the data transition by a coloured arrow and an arrow connecting the data to the continuation transition. Using the combined transitions, Fig. 4 redraws the multiplication part of the mathematical server in Fig. 1. This way, the transition q 1 int q 2 has been replaced by both a data transition into a new state q and a continuation transition into q 2 . Moreover, q has been declared as a data state that expects an integer to be exchanged (label int).
Having added these transitions to our toolbox, we can present the two types T and U as session coalgebras. The diagram in Fig. 5 shows such a session coalgebra, in which we name the states suggestively T and U . Using this presentation as session coalgebras, it is now straightforward to coinductively prove that the states T and U are dual: 1. the states have opposite actions; 2. their data transitions point to equal types; and 3. their continuations are dual by coinduction. Clearly, the last step needs some justification but it will turn out that we can appeal to a standard definition of coinduction in terms of greatest fixed points. This demonstrates that our coalgebraic view on session types makes the definition of duality truly natural and straightforward.
Up to here, we have discussed session types and coalgebras that are linear, i.e., they enforce that protocols complete exactly once. In many situations, one also needs unrestricted types, which enable sharing of channels between processes that access these channels concurrently. This is the case of a process that offers a service for other processes, for instance a web server. Session delegation allows us to create dynamically channels and check their protocols, but the shared channel for initiating a session [17] has to offer its protocol to an arbitrary number of clients. Unrestricted types enable us to specify these kind of service offers.
As an example, consider a process that provides a channel for communicating integers to anyone asking, like a town hall official handing out citizen numbers. The type U = μX. un !int. X represents the corresponding protocol, where "un" qualifies the type !int. X as unrestricted. This allows the process holding the end of a channel with type U to transmit an integer to any process that is connected to the shared channel, without any restriction on their number. It is now surprisingly simple to express U in our coalgebraic view: we introduce a new state label "un" (unrestricted), which expresses that states reachable from this state can be used arbitrarily as protocols across different processes connecting to a channel that follow the protocol given by those states. The following diagram shows a session coalgebra with a state that corresponds to the type U .
Contributions and Related Work. In this paper, we introduce the notion of session coalgebra, which justifies the state-based behaviour of session types from a coalgebraic perspective. This perspective is novel, although specific state-based description of protocols have been considered before [4,6,7,9,10,13,15,25,32,33]. Using coalgebra as a unifying framework for session types has two advantages: 1. session coalgebras can be defined and studied independently from specific syntactic formulations, while keeping the operational behaviour of session types; and 2. we can uncover the innate coinductive nature of key notions in session types, such as duality, subtyping, and type equivalence through standard coalgebraic techniques. In particular, although communicating automata can also provide syntax-independent characterisations of session types [10,11], such characterisations do not support delegation, an expressive feature which is cleanly justified in our coalgebraic approach. Coinduction already has been exploited in the definition of type equivalence [35], subtyping [17,16] and, especially, duality for systems with recursive types [3,18,24]. Unlike ours, these previous definitions are language-dependent, as they are tailored to specific process languages and/or syntactic variants of the type discipline. Session coalgebras enable thus the generalisation of insights and technologies from specific languages to any protocol specification that fits under the umbrella of state-based sessions.
To enable the verification of processes against protocols described by session coalgebras, we also contribute a type system for π-calculus processes, in which channel types are given by states of an arbitrary session coalgebra. Our type system revisits the one by Vasconcelos [37] from our coalgebraic perspective, while extending it with subtyping. Moreover, we provide a type checking algorithm for that system, provided that the underlying session coalgebra fulfils two intuitive conditions. In doing so, we show how a specific type syntax can be equipped with a session coalgebra structure and how the two decidability conditions are reflected in the type system. This is in contrast to starting with a specific type syntax and then employing category theoretical ideas [36], where coinductive session types are encoded in a session type system with parametric polymorphism [5]. Instead, we show how a session type system can be derived in general from coalgebras.
Organisation Throughout the remaining paper we will turn the sketched ideas into a coalgebraic framework. We introduce in Sec. 2 a concrete session type syntax that we will use as illustration of our framework. In Sec. 3, we will define session coalgebras as coalgebras for an appropriate functor and show that the type system from Sec. 2 can be equipped with a coalgebraic structure. The promised coinductive view on type equivalence, duality, subtyping, etc. will be provided in Sec. 4. Moreover, we will show that these notions are decidable under certain conditions that hold for any reasonable session type syntax, including the one from Sec. 2. Up to that point, the session coalgebras only had intrinsic meaning and were not associated to any process representation. Section 5 sets forth a type system for π-calculus, in which channels are assigned states of a session coalgebra as types. The resulting type system features subtyping and algorithmic type checking, presented in Sec. 6. Some final thoughts are gathered in Sec. 7. An extended version, available online, collects additional material [22].

Session Types
To motivate the development of session coalgebras, we recall in this section the concrete syntax of an existing session type system by Vasconcelos [37]. After building up our intuition, we introduce session coalgebras in Sec. 3 to show they can represent this concrete type system. The types of the system that we will be using are generated by the grammar in Fig. 6, relative to a set of basic data types D and a countable set of type variables Var. This grammar has three syntactic categories: pretypes p, qualifiers q, and session types T . A pretype p is simply a communication action: send (!), receive (?), external choice (&), and internal choice (⊕) indexed by a finite sets I of labels, followed by one or multiple session types. The simplest session types are basic data types in D and the completed, or terminated, protocol represented by end. A pretype and qualifier also form a session type, written as q p. The "lin" qualifier enforces that the communication action p has to be carried out exactly once, while the "un" qualifier allows arbitrary use of p. Finally, we can form recursive session types with the the fixed point operator μ and the use of type variables. We use the usual notion of α-equivalence, (capture-avoiding) substitution, and free and bound types variables for session types.
The grammar allows arbitrary recursive types. We let Type be the set of all T in which recursive types are contractive and closed, which means that they contain no substrings of the form μX 1 .μX 2 . . . μX n .X i and no free type variables.
To lighten up notation, we will usually omit the qualifier lin and assume every type to finalise with end. With these conventions, we write, e.g., ?int. instead of lin ?int. end and un ?int. for a single unrestricted read.
We assume there is some decidable subtyping preorder ≤ D over the basic types. A type is a subtype of another if the subtype can be used anywhere where the supertype was accepted. In examples, we use the basic types int, real and bool, and we assume that int is a subtype of real, as usual.
An important notion is the unfolding of a session type, which we define next:

Definition 1 (Unfolding). The unfolding of a recursive type μX.T is defined recursively unfold (μX.T ) = unfold (T [μX.T /X])
For all other T in Type, unfold is the identity: unfold (T ) = T .
Because we assume that types are contractive, unfold (T ) terminates for all T . Also, because all types are required to be closed, unfold (T ) can never be a variable X. Any such variable would have to be bound somewhere before use, meaning it would have been substituted. Furthermore, unfolding a closed type always yields another closed type, as each removed binder always causes a substitution of the bound variable.

Session Coalgebra
Here we will discuss session coalgebras, the main contribution of this paper. The idea is that session coalgebras will be coalgebras for a specific functor F , which will capture the state labels and the various kinds of transitions that we discussed in Sec. 1. An important feature of coalgebras in general, and session coalgebras in particular, is that the states can be given by an arbitrary set. We will leverage this to define a session coalgebra on the set of types Type introduced in Sec. 2. Before coming to the definition, let us briefly recall some minimal notions of category theory. We will not require a lot of category theoretical terminology; in fact, we will only use the category Set of sets and functions. Moreover, we will be dealing with functors F : Set → Set on the category Set. Such a functor allows us to map a set X to a set F (X), and functions f : To be meaningful, a functor must preserve identity and compositions. That is, F maps the identity function id X : X → X on X to the identity on F (X): F (id X ) = id F (X) ; and, given functions f : A central notion is that of the coalgebras for a functor F . A coalgebra is given by a pair (X, c) of a set X and a function c : X → F (X). For simplicity, we often leave out X and refer to c as the coalgebra. The general idea is that the set X is the set of states and that c assigns to every state its one-step behaviour. In the case of session coalgebras this will be the state labels and outgoing transitions. Given two coalgebras c : X → F (X) and d : Coalgebras and their homomorphisms form a category, with the same identity maps and composition as in Set.
We will have to analyse subsets of coalgebras that are closed under transitions. Given a coalgebra c : Note that in this case c(Y ) ⊆ F (Y ) and thus d is the restriction of c to Y . Hence, we also refer to Y as subcoalgebra. The subcoalgebra generated by x ∈ X in c, denoted by x c , is the least subset of X that contains x and is a subcoalgebra of c. Intuitively, it is the set of x and all states that are reachable from x.
Coming to the concrete case of session coalgebras, we now construct a functor that allows us to capture the state labels and the different kinds of transitions. Keeping in mind that states of a session coalgebra correspond to states of a protocol, we need to be able to label the states with enabled operations. ). The operation of a state describes the action it represents: com marks the transmission (sending or receiving) of a value; branch marks an (internal or external) choice; end marks the completed protocol; bsc marks a basic data type; and un marks an unrestricted type. States that transmit data (labelled with com) or allow for choice (labelled with branch) also have a polarity, which can be either in (a receiving action or external choice) or out (a sending action or internal choice). We let O be the set of all operations O = {com, branch, end, bsc, un} and P the set of polarities P = {in, out}.

Definition 2 (Operations and Polarities
Note that pairs in {com, branch} × P directly correspond to the actions of a session type: ? = (com, in), ! = (com, out), & = (branch, in) and ⊕ = (branch, out). We will be using these markers to abbreviate the pairs. Now that we have the possible operations of a protocol, we need to define the transitions that may follow each operation. Recall that the transition at a choice state has to be labelled with messages that resolve that choice. We therefore assume to be given a set L of possible choice labels. The variable l will be used to refer to an element of L. P + <ℵ0 (L) is the set of all finite, non-empty, subsets of L. Variables L, L 1 , L 2 , . . . refer to these finite, non-empty subsets of L.
Our goal is to define a polynomial functor [14] that captures the states labels and transitions. This requires some further formal language. First, we let * and d be some fixed, distinct, objects. Second, given sets X and Y , we denote by X Y the set of all (total) functions from Y to X. Finally, given a family of sets {X i } i∈I indexed by some set I, their coproduct is the set i∈I We are now ready to define session coalgebras:

Definition 3 (Session Coalgebras). Let A and B be sets defined as follows,
where we recall that D is the set of all basic data types.
Let us unfold this definition. Given a session coalgebra c : X → F (X) and a state x ∈ X, we find in c(x) ∈ F (X) the information of x encoded as a tuple (a, f ) with a ∈ A and f : B a → X. From a, we get directly the operation, and the polarity for com states, the type of values communicated for bsc states or the message labels of branch states. The function f encodes the transitions out of x. The domain of f is exactly the set of labels that have a transition, and is dependent on the kind of state declared by a.
It is convenient to partition the domain of the transition map f into data and continuations. Notice how only com states have data transitions, for other states, all transitions are continuations. As usual, we write dom(f ) for the domain of f .

Alternative Presentation of Session Coalgebras
Session coalgebras (X, c) are rather complex. We show how to build up c as the combination of two simpler functions, denoted σ and δ, so that c(x) = (σ(x), δ(x)) with σ : X → A and δ(x) : B σ(x) → X. Observe that every state gets an operation in O assigned, thus we may assume that there is a map op : X → O. Depending on the operation given by op(x), the label on x will then have different other ingredients that are captured in the following proposition.
To formulate the proposition, we need some notation. Suppose f : X → I is a map and i ∈ I. We define the fibre We specified δ a as a family of transition functions to preserve each specific signature. We can define a single global transition function as δ(x) = δ σ(x) (x). This is how the coalgebra finally becomes c(x) = (σ(x), δ(x)). As long as the provided maps fit their signatures, this derived function will conform to c : X → F (X).
The procedure also works backwards: given any session coalgebra, we can derive functions op(x), pol(x), etc. from c(x). We will often use op(x), σ(x), and δ(x) to refer to those specific parts of an arbitrary session coalgebra.

Coalgebra of Session Types
In Sec. 1, we informally explained how session types can be represented as states of a session coalgebra. We will now justify this claim by showing that session types are, in fact, states of a specific session coalgebra (Type, c Type ).
We define the functions op, pol, δ, and la (see Prop. 1) on Type. Using Prop. 1, we can then derive c Type : Type → F (Type). Let us begin with the linear types. Recall that contractivity ensures that unfold always terminates. As our types are closed, all recursion variables are substituted during the unfolding of their binder. Consequently, we do not need to define c on these variables. Also note that this definition results in an equi-recursive interpretation of recursive types. Session types can also be unrestricted, and consist of a pretype p with a qualifier un. Session coalgebras have un states to mark unrestricted types; the continuation describes what the actual interaction is. Thus, we define op(un p) = un and δ(un p)( * ) = lin p.

Remark 1 (Alternative Syntaxes and their Functors).
The unrestricted session types that we have adopted are fairly standard, but they are not the only ones in the literature. Most notably, Gay and Hole [17] defined a type [T 1 , . . . , T n ] that allows infinite reading and writing. To allow for such behaviour in session coalgebra, we can change B un to a set of two elements, such a { * 1 , * 2 }. Like internal choice, the two transitions describe an option of which behaviour to follow, but without sending synchronisation signals. One transition could go to a read, and the other to a write, both recursively continuing as the original type [T 1 , . . . , T n ].
It is possible, although not entirely trivial, to change the further definitions appropriately and get a decidable type checking algorithm encompassing both the syntax presented in this work, and Gay and Hole's syntax. We choose not to, so to keep the presentation simpler.

Type Equivalence, Duality and Subtyping
Up to here, we have represented session types as session coalgebras, but we have not yet given a precise semantics to them. As a first step, we will define three relations on states: bisimulation, duality, and simulation. Bisimulation is also called behavioural equivalence for types; we will show that bisimilar types are indeed equivalent. Duality specifies complementary types: it tells us which types can form a correct interaction. Simulation will provide a notion of subtyping: it tells us when a type can be used where another type was expected. Besides relations on session coalgebras, we also introduce the parallelizability of states that allows us to rule out certain troubling unrestricted types. Finally, we will obtain conditions on coalgebras to ensure the decidability of the three relations and therefore the type system that we derive in Sec. 5.
In the following, we will denote by Rel X the poset P(X × X) of all relations on X ordered by inclusion. Recall that a post-fixpoint of a monotone map g : Rel X → Rel X is a relation R ∈ Rel X with R ⊆ g(R). Note that Rel X is a complete lattice and that therefore any monotone map has a greatest post-fixpoint by the Knaster-Tarski Theorem [34]. We will define bisimulation, simulation, and duality as the greatest (post-)fixpoint of monotone functions, which we will therefore call coinductive definitions. This definition turns out to be intuitively what we would expect and the interaction of infinite behaviour with other type features is automatically correct. The coinductive definitions also give us immediately proof techniques for equivalence, duality and subtyping: to show that two states are, say, dual we only have to establish a relation that contains both states and show that the relation is a post-fixpoint. This technique can then be improved in various ways [30] and we will show that it is decidable for reasonable session coalgebras.

Bisimulation
Two states of a coalgebra are said to be bisimilar if they exhibit equivalent behaviour. We abstract away from the precise structure of a coalgebra and only consider its observable behaviour. Two states are bisimilar if their labels are equal and if the states at the end of matching transitions are again bisimilar. There is one exception to the equality of labels: basic types can be related via their pre-order, which does not have to coincide with equality.

Definition 5.
We define the function f ∼ : Rel X → Rel F (X) as It can be easily checked that, both, c * and f ∼ are monotone maps and thus also their composition. Thus, the greatest fixpoint in the following definition exists.

Definition 6. A relation R is called a bisimulation if it is a post-fixpoint of
We call the greatest fixpoint bisimilarity and denote it by ∼.

Duality
Duality describes exactly opposite types in terms of their polarity. That is, the dual of input is output and the dual of output is input: in = out and out = in. We can extend this to tuples a in A, see Def. 3, with the exception of basic types because they do not describe channels: The next step is to compare transitions. Continuations of dom C (f ) need to be dual. The data types that are sent or received need to be equivalent, hence transitions of dom D (f ) need to go to bisimilar states. We capture this idea with the monotone map f ⊥ : Rel X → Rel F (X) defined as follows.

Definition 7. A relation R is called a duality relation if it is a post-fixpoint of c * • f ⊥ . We call the greatest fixpoint duality and denote it by ⊥.
It is useful to have a function mapping any x ∈ X to their dual x, as long as duality is defined on x. However, even if duality is defined on x, the dual state might not be in X. Thus, we define the dual closure of X as the set X ⊥ = X ∪{x | σ(x) is defined}, where x is understood to be an arbitrary state not in X and distinct from y for any states y ∈ X with x = y. For any of the original states, c ⊥ (x) = c(x), but for the new states we define σ ⊥ (x) = σ(x) and Thus, the dual closure is a coalgebra such that x ⊥ x for any x. Notice that taking a dual twice always yields a bisimilar type, so we can define the duality function as an involution, x = x, rather than adding more variables. Clearly, the dual closure of a finite set is finite.

Proposition 2.
x ⊥ x for every state x such that x is defined.

Parallelizability
Unlike a linear endpoint, a channel endpoint with an unrestricted type may be shared between different parallel processes; each of them uses it independently, without informing the others. Furthermore, there is no way to coordinate which process receives which message. If the unrestricted endpoint sends a message, it could be read by a process that just started using the channel, or by a process that is almost done using the channel, or by a process that is anywhere in between.
In practice, this means an unrestricted channel can only perform one kind of communication action. However, session coalgebras allow us to define arbitrarily complex unrestricted types. For example, μX. un ?int. un ?bool. X is an element of Type, but we know that sending both int and bool over the same unrestricted channel causes problems. a coalgebra (X, c), some subset Y ⊆ X is parallelizable, written par(Y ), if for every x and y in Y one of the following holds: x ∼ y, σ(x) = un, or σ(y) = un.

Definition 8. Given
We know that un states do not represent communications; any other states, though, have to represent the same kind of action. We make this slightly stronger by requiring they are pairwise bisimilar.
Often we are interested in the parallelizability only of a specific state. Recall that x c denotes the subcoalgebra generated by x ∈ X in c.

Simulation and Subtyping
Intuitively, a coalgebra simulates another if the behaviour of the latter "is contained in" the former. Subtyping, originally defined on session types by Gay and Hole [17], is a notion of substitutability of types [16]. We will define our notion of simulation such that it coincides with subtyping, just like bisimulation provides a notion of type equivalence [17].
Consider a process that expects a channel of type T = ?real. The process reads a value, and expects it to be a real number and treat it as such. We defined int as a subtype of real, so the process can operate correctly if it receives an integer instead; that is, ?int is a subtype of T . Now consider a process that expects a channel of type !int, on which it can send any integer. In this case we cannot restrict the channel to a subtype: as all integers are valid where real numbers are expected, we can generalise the channel type to !real. Now, in the input case the session types are related (in the subtyping relation) in the same order as the data types; this is called covariance. For output, the order is reversed; this is called contravariance. The same idea holds for labelled choices: the subtype of an external choice can have a subset of choices, while the subtype of an internal choice can add more options. For all types, it holds that states reached through transitions are covariant, i.e., if T is a subtype of U , continuations of T must be subtypes of continuations (of the same label) of U . The monotone map h in Fig. 7 captures these ideas formally.

Definition 10. A relation R is called a simulation if it is a post-fixpoint of
We call the greatest fixpoint similarity and denote it by .

Figure 8. Simulation for two mathematical server clients (indicated by dotted arrows)
Let us illustrate similarity by means of an example.

Example 1.
Recall the two client protocols for our mathematical server in Figs. 2 and 3. We can now prove our claim that the latter can also connect to the server because it is a supertype of the client protocol in Fig. 2. To do that, we have to establish a simulation relation between the states of both client protocols. In Fig. 8, we display a part of both session coalgebras side-by-side and indicate with dotted arrows the pairs that have to be related by a simulation relation to show that these states are similar, that is, related by . It should be noted that we simulate states from the second coalgebra by that of the first, that is, we show s k r k for the shown states. There is one exception to this, namely q int q real .
The following proposition records some properties of and tight connections between the relations that we introduced.

Proposition 3. Bisimilarity ∼ is an equivalence relation, duality ⊥ is symmetric, and similarity
is a preorder. Moreover, for all states x, y, and z of a session coalgebra, we have that 1. x ∼ y iff x y and y x; 2. x ⊥ y and x ⊥ z implies y ∼ z; and 3. x ⊥ y and y ∼ z implies x ⊥ z .

Decidability
In a practical type checker, we need an algorithm to decide the relations defined above. In this subsection we show an algorithm that computes the answer in finite time for a certain class of types.
This restriction is not problematic for types, as the following lemma shows. Lemma 1. The coalgebra of types (Type, c Type ) is finitely generated.
To determine whether two states x and y are bisimilar, we need to determine if there exists a bisimulation R with x R y. We start with the simplest relation R = {(x, y)}, and ask if this is a bisimulation.
First, we check that for all (u, w) ∈ R, σ(u) = σ(w), or in the case of bsc states that da(u) ≤ D da(w) and da(w) ≤ D da(u). If σ(u) = σ(w) for any pair in R we know that no superset of R is a bisimulation, and the algorithm rejects.
Second, we check the matching transitions. For every (u, w) ∈ R and α ∈ dom(δ(u)) we check whether (δ(u)(α), δ(w)(α)) ∈ R. If we encounter a missing pair, we add it to R and ask whether this new relation is a bisimulation, i.e., return to the first step. If all destinations for matching transitions are present in R, then R is, by construction, a bisimulation containing (x, y). Hence, x ∼ y.
This algorithm tries to construct the smallest possible bisimulation containing (x, y), by only adding strictly necessary pairs. If the algorithm rejects, there is no such bisimulation; hence, x ∼ y. Additionally, the algorithm only examines pairs in x c × y c . If there are finitely many of such pairs, the algorithm will terminate in finite time The above described algorithm can be suitably adapted to similarity and duality, which gives us the following result.

Typing Rules
Session types are meant to discipline the behaviour of the channels of an interacting process, so as to ensure that prescribed protocols are executed as intended. Up to here, we have focused on session types (i.e., their representation as session coalgebras and coinductively-defined relations on them) without committing to a specific syntax for processes. This choice is on purpose: our goal is to provide a truly syntax-independent justification for session types. In this section, we introduce a syntactic notion of processes and rely on session coalgebras to define the typing rules for a session type system. P, Q ::= x y .P output y on channel x | x(y).P bind input from channel x to variable y | x {l i : Pi}i∈I offer choices l1, l2, . . . | x l.P make choice l | P | Q composition | !P replication | 0 finished process | (νxy)P channel creation Figure 9. Process syntax

A Session π-calculus
The π-calculus is a formal model of interactive computation in which processes exchange messages along channels (or names) [26,31]. As such, it is an abstract framework in which key features such as name mobility, (message-passing) concurrency, non-determinism, synchronous communication, and infinite behaviour have rigorous syntactic representations and precise operational meaning. We consider a session π-calculus based on [37,17], i.e., a variant of the π-calculus whose operators are tailored to the protocols expressed by session types. We assume base sets of variables (x, y, z, . . .) and values (v, v , . . .), which can be variables or the Boolean constants (true and false). There is also a set of labels L, ranged over by l, l , . . .. The syntax of processes (P, Q, . . .) is given by the grammar in Fig. 9. We discuss the salient aspects of the syntax. A process x y .P denotes the output of channel y along channel x, which precedes the execution of P . Dually, a process x(y).P denotes the input of a value v along channel x, which precedes the execution of process P [v/y], i.e., the process P in which all free occurrences of y have been substituted by v. Processes x {l i : P i } i∈I and x l.P implement a labelled choice mechanism. Given a finite index set I, process x {l i : P i } i∈I , known as branching, denotes an external choice: the reception of a label l j (with j ∈ I) along channel x precedes the execution of the continuation P j . Process x l.P , known as selection, denotes an internal choice; it is meant to interact with a complementary branching. Given processes P and Q, process P | Q denotes their parallel composition, which enables their simultaneous execution. The process !P , the replication of P , denotes the composition of infinite copies of P running in parallel, i.e., P | P | · · · . Process 0 denotes inaction. Finally, process (νxy)P is arguably the main difference with respect to usual presentations of the π-calculus, and denotes a restriction operator that declares x and y as covariables, i.e., as complementary endpoints of the same channel, with scope P .
The operational semantics for processes is defined as a reduction relation denoted −→, by relying on a notion of structural congruence on processes, denoted ≡. Figure 10 defines these two notions. Intuitively, two processes are structurally congruent if they are identical in behaviour, but not necessarily in structure. It is the smallest congruence relation satisfying the axioms in Fig. 10 (bottom). We say a process P reduces to Q, written P −→ Q, when there is a single execution step yielding Q from P . We comment on the rules in Fig. 10 (top). r-com formalizes

Structural congruence
Parallel composition: (νxy)(νvw)P ≡ (νvw)(νxy)P (νxy)0 ≡ 0 (νxy)P ≡ (νyx)P (νxy)(P | Q) ≡ ((νxy)P ) | Q if x and y not free in Q Figure 10. Reduction semantics the exchange a value over a channel formed by two covariables. Similarly, r-sync formalises the synchronisation between a branching and a selection that realises the labelled choice. Rules r-res and r-par are contextual rules, which allow reduction to proceed under restriction and parallel composition. Finally, Rule r-cong says that reduction is closed under structurally congruence: we can use ≡ to promote interactions that match the structure of the rules above.

Typing Rules
Based on the above, variables P, Q will refer to processes, x, y, z will range over channels and T, U, V are states of some fixed, but arbitrary, session coalgebra (X, c). Variables are associated with these states in a context Γ , as described by Γ ::= ∅ | Γ, x : T . A context is an unordered, finite set of pairs, that may have at most one pair (x, T ) for each variable x. A context is thus isomorphic to a (partial) function from a finite set of variables to their types. We use Γ to denote this isomorphic function as well: The domain of a context is defined accordingly. We know 'un' types are unrestricted, but they are not the only ones. A context Γ may be split into two parts Γ 1 and Γ 2 , such that the linear types are strictly divided between Γ 1 and Γ 2 , but unrestricted types can be copied. Context split is a ternary relation, defined by the axioms in Fig. 11. We may write Γ 1 • Γ 2 to refer to a context Γ for which Γ = Γ 1 • Γ 2 is in the context split relation. Such a context is not necessarily defined for any given contexts; we implicitly assume its existence when writing Γ 1 • Γ 2 . Notice that the use of Γ, x : T in the third rule of Fig. 11 carries the assumption that x not in Γ . Otherwise, Γ, x : T would have two pairs with x, which is not allowed.
The type system is defined by the rules in Fig. 12. A process P is well-formed, under a context Γ , if there is some inference tree whose root is Γ P and whose nodes are all valid instantiations of these type rules. As T-Inact is the only rule that does not depend on the correctness of another process, it forms the leaves of such trees. For well-formed processes, the type system guarantees that: -If the process terminates, then all linear sessions were completed.
-If a process reads a value from a channel, the value has the type specified by the channel's session type. If a process receives a label, it is one of the labels specified by the channel's session type.
We discuss the typing rules, which can be conveniently read keeping in mind the notations introduced in Def. 3 and Prop. 1. T-Inact ensures that all linear channels in the context are interacted with until the type becomes unrestricted. If our context contains a variable x of type ?int, then the process is required to read an int from it. Thus, x : ?int. 0. In contrast, process x(z).0 is well-formed for the same context, using T-Inact and T-In: x : end, z : int 0 x : ?int x(z).0 T-Res creates a channel by binding together two covariables x and y, of dual type. T-Par causes unrestricted channels to be copied and linear channels to get split between composite processes, ensuring the latter occur in only a single process. Recall that replication !P is an infinite composition of a single process P , hence, a replicated process can only use unrestricted channels. Together, T-Par and T-Res allow us to introduce new covariables, with new types, and distribute them. But, only unrestricted types may be copied. Notice that a process does not specify which types to give the newly bound variables.
Each action on a channel has its own rule: T-In handles input, binding the channel x to the continuation type and y to some supertype of the received type. T-Out handles output, which requires the sent variable to have a subtype of whatever type the channel expects to send. T-Branch handles external choice, where the process needs to offer at least all choices the type describes, coupled with processes that are correctly typed under the respective continuation types.
T-Sel only checks whether the single label that was chosen by the process was a valid option, and if the rest of the process is correct under the continuation type. These rules are only specified for linear states; T-Unpack allows a un state to be used as if it was the underlying type, as long as it is parallelizable (Def. 8).
We can actually create structures with un that do not have a syntactical equivalent. For example, let T end be a state with σ(T end ) = un and δ(T end )( * ) = T end . Just like regular end, T end allows no interactions on the channel, but it does not cause a "un" type to be unparallelizable.  The diagram in Fig. 13 describes a parallelizable unrestricted state T such that each copy of a channel in state T can only do a single receive. However, because it is unrestricted, we can still copy the channel across threads and read a value per copy. We can even read infinitely many values through replication.
x : T x(y 1 ).x(y 2 ).x(y 3 ).0 Such a type might be interesting in combination with session delegation. A linear session could be established by receiving a channel from an unrestricted channel. By using a structure like T , each thread is guaranteed to establish at most one private session, but there can be many of such sessions in parallel threads. In Sec. 4, we defined simulation through the intuition of subtyping as substitutability in one direction. We see that substitution is indeed allowed for simulated types. Theorem 2. The following, more common, rule is admissible from the rules in Fig. 12.
Γ, x : T P U T Γ, x : U P That is, we could add the rule as an axiom, without changing the set of typable processes. As a corollary, bisimulation of states implies the states are equivalent with respect to the type system.

Corollary 2.
For all bisimilar types T ∼ U , contexts Γ and processes P , it holds that Γ, x : T P if and only if Γ, x : U P .

Algorithmic Type Checking
The type rules describe what well-formed processes look like, but do not directly allow us to decide whether an arbitrary process is well-formed or not. This is because, beforehand, we do not know: 1. Which type to introduce in reading (T-In) or scope restriction (T-Res), or 2. How to split the context in composite processes (T-Par).
Rather than trying to infer the introduced types, we augment the language of processes with type annotations: P ::= . . . | (νxy : T ) P | x(y : T ).P We only need to annotate one type for scope restrictions, as we can create the other with the duality function. Other productions are kept unchanged.
When checking a process P | Q, we pass along the entire context to P , keeping track of all linear variables used, and remove those from the context given to Q. To do this we add an output to the algorithm: in an execution Γ 1 P ; Γ 2 , output Γ 2 is the subset of Γ 1 containing only those variables of the input which had unrestricted types or were not used in P . We say subset because we want these variables, if present, to have the same type in Γ 2 as in Γ 1 . Figure 15 lists the algorithmic versions of the type rules. A-Par, for example, checks parallel processes as described. By construction, Γ 2 is one part of the context split required to instantiate T-Par. The linear variables of the other part is exactly those which are present in Γ 1 but not in Γ 2 . This change in A-Par requires adjusting the other rules. Firstly, we need the algorithm to accept even when we do not fully complete all sessions of Γ 1 in P . We do this by unconditionally accepting the terminated process. Note that acceptance of the algorithm now only implies well-formedness if the returned context is unrestricted.
Secondly, the algorithm needs to remove linear variables from the output as we use them. We do not, however, want to remove any variable that has a linear type, as that would allow us to accept processes which do not complete all linear sessions. Thus, we introduce the context difference operator ÷ in Fig. 14. Γ ÷ {x} is the context of all variable/type pairs in Γ minus a potential pair including x, but is only defined if (x, T ) ∈ Γ implies that T is unrestricted.
We elaborate on A-Branch; the algorithm is called once for every branch, yielding a context Γ l each time. Excluding x, each branch must use the exact same set of linear variables. Thus, we require that all these contexts are equal up to a potential (x, U l ) pair. Specifically, there is some Γ 2 such that Γ 2 = Γ l ÷ {x} for any l ∈ L 2 , this Γ 2 is the output context.
To motivate this, consider a type T = &{a : T un , b : end}, where T un is some unrestricted type distinct from end, and some process P = x {a : 0, b : 0}. Let Γ be some unrestricted context, 0 is well-formed for both Γ, x : T un and Γ, x : end; the algorithm agrees. The resulting contexts are not equal. P is well-formed for Γ , so we have to allow x to have different types in the output of different branches in a complete algorithm. A-In, A-Out, and A-Sel do not have multiple branches to check, but the ideas are similar. When introducing a new variable, either through a read or scope restriction, the new variable is also removed from the output. A-Unpack only unpacks unrestricted types. We want those to have the same type in the input as in the output, so we remove the variable and add a pair with the original type.
Take, for example, the process x : ?int, y : ?int x(z 1 ).0 | y(z 2 ).0 The variables are split correctly, and both split contexts are unrestricted when the process is completed, thus it is well-formed. If, on the other hand, the left process did not complete the linear session, then the context difference would not have been defined. Take one such process: x : ?int.?int, y : ?int x(z 1 ).0 | y(z 2 ).0 We succeed in checking the terminated process of the left part.
x : ?int, y : ?int 0 ; (x : ?int, y : ?int) But x has a linear type in the output. (x : ?int, y : ?int) ÷ {x} is undefined, so the algorithm rejects this input entirely. The process was indeed not well-formed, and no further parallel processes could fix it; the rejection is expected. For each process and context there is at most one applicable algorithmic rule: which one is directed by the process syntax and unrestrictedness of a channel being interacted with.
Under the same assumptions as before (i.e., the session coalgebra describing the types is finitely generated), this induced type checking algorithm is decidable, sound, and complete with respect to the type rules defined in Sec. 5.

Theorem 3 (Decidability).
The type checking algorithm terminates in finite time for every input, assuming a finitely generated session coalgebra.
Having defined algorithmic typechecking, we can go back to the language that we used to define our typing rules by erasing type annotations in input and restriction operators. Let erase(·) denote a function on processes defined as erase((νxy : T ).Q) = (νxy).erase(Q) erase(x(y : T ).Q) = x(y).erase (Q) and as an homomorphism on the remaining process constructs. We have: Theorem 4 (Correctness). For any context Γ and annotated process P , Γ 1 erase(P ) iff Γ 1 P ; Γ 2 and un(Γ 2 ).

Concluding Remarks
We have developed a new, language-independent foundation for session types by relying on coalgebras. We introduced session coalgebras, which elegantly capture all communication structures of session types, both linear and unrestricted, without committing to a specific syntactic formulation for processes and types. Session coalgebras allow us to rediscover language-independent coinductive definitions for duality, subtyping, and type equivalence. A key idea is to assimilate channel types to the states of a session coalgebra; we demonstrated this insight by deriving a session type system for the π-calculus, which revisits and extends that by Vasconcelos [37], unlocking decidability results and algorithmic type checking.
Interesting strands for future work include extending our coalgebraic toolbox so as to give a language-independent justification to advanced session type systems, such as context-free session types [35] and multiparty session types [21]. Another line concerns extending our coalgebraic view to include language-dependent issues and properties that require a global analysis on session behaviours. Salient examples are liveness properties such as (dead)lock-freedom and progress: advanced type systems [23,29,28,8] typically couple (session) types with advanced mechanisms (such as priority-based annotations and strict partial orders), which provide a global insight to rule out the circular dependencies between sessions that are at the heart of stuck processes. Lastly, the whole area of coalgebra now becomes available to explore session types. One possible direction is to make use of final coalgebras and modal logic, which would allow us to analyse the behaviour of session coalgebras. This would be particularly powerful in combination with composition operations for session coalgebras to break down protocols and type checking. Another direction is to use session coalgebras to verify other coalgebras that take on the role of the syntactic π-calculus [12,27] and thereby allowing also for the exploration of other semantics like manifest sharing [1,2] without resorting to a specific syntax.
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.