UPDATE AS OF 6/12/2017: I have moved this list to the ABCD Website, where it will be maintained from now on. As ever, please get in touch with tool updates, and I will update it on that site.

Introduction

Session types are a type discipline for communication-centric programming, where programs can be checked to see if they conform to protocols.

There has been a large emphasis on session type implementations recently (indeed, there was a fun event called CoCo:PoPS last year dedicated solely to implementations!), allowing session types to be used in many different programming languages.

This post hopes to serve as a small introduction to session types and how they can be used in programming languages, and to provide a list of implementations and resources for session types in many programming languages. I restrict the scope of the list to language-specific implementations as opposed to more general tools.

A brief introduction to session types in programming languages

Session types have their roots in process calculi, in particular typed π-calculi. Session types can be thought of as “types for protocols”, essentially extending the notion of the data type that we know and love to communicating systems. The idea behind session types is that we describe communication protocols as a type, and these can be checked either statically (at compile-time) or dynamically (at runtime).

In Go, we have typed channels: we can have a channel of type chan int for example, where any process with access to the channel endpoint can send or receive values of type int. Sending a value of type string along a such a channel, for example, gives us a type error, so we get a degree of type safety just from that.

Session types add more structure to these channel types: for example, we can describe a (very) simplified version of the SMTP protocol as follows:

SMTPClient = ⊕ {
  EHLO: !Domain.!FromAddress.!ToAddress.!Message.SMTPClient
  QUIT: end
}

Here, the ⊕ symbol states that the client can choose between two branches: EHLO, or QUIT. In the case of EHLO, the client sends (!) the domain, the address a message should be sent from, the address a message should be sent to, and the message, and the protocol repeats. In the case of QUIT, the protocol is over.

The session type for the server is the dual type – whereas before we were making a selection, now we’re offering a choice (&). Whereas before we were sending a message, now we’re receiving one (?).

SMTPServer = & {
  EHLO: ?Domain.?FromAddress.?ToAddress.?Message.SMTPServer
  QUIT: end
}

(There’s also a good amount of work on subtyping, too, which allows—for example—an “offer” type to have more branches than the corresponding “choice” type)

Implementing the client of this, we could write the following (written in the Links programming language):

sig smtpClient : (SMTPClient, FromAddress, ToAddress, Message) ~> ()
fun smtpClient(c, from, to, msg) {
  var c1 = select EHLO c;
  var c2 = send(getDomain(from), c1);
  var c3 = send(from, c2);
  var c4 = send(to, c3);
  var c5 = send(message, c4)
  var c6 = select QUIT c5;
  close c6
}

The smtpClient function takes a channel with session type SMTPClient, along with the various parameters as its arguments. Sending a value results in a new channel endpoint being bound upon each send (and an equivalent receive would return a pair of the received value and an endpoint). This technique was (I believe) first described by Simon Gay and Vasco Vasconcelos in this paper.

Now, the obvious question you may be asking here is “surely we could use each of those endpoints again, or have multiple copies of the endpoints?” – and yes, naiively this would result in a loss of all guarantees session types would give us! In order for session typing in programming languages to make sense, we need linearity, wherein each session endpoint must be used exactly once. This is, I would say, the largest barrier to implementation.

Multiparty Session Types

Multiparty Session Types extend the theory of binary session types to encompass interactions containing more than two participants.

The main idea behind multiparty session types is to describe the interactions between participants in a top-down manner as a global type. These global types can then be “projected” into local types, which describe the interaction from the point of view of a particular participant. Communication can then be checked against these local types either statically (generally by a compiler plugin) or dynamically (via runtime monitoring).

The “hello world” of MPSTs is the “two-buyer protocol”, which is intended to be a simplification of a financial protocol. Essentially, two buyers (“Buyer1” and “Buyer2”) wish to purchase a book from a book seller (“Seller”), negotiating the cost between them.

The protocol proceeds as:

  1. Buyer1 sends the title of the book to the seller.
  2. The seller sends the price to buyer 1 and buyer 2.
  3. Buyer 1 sends Buyer 2 the amount that Buyer 2 should pay.
  4. Buyer 2 can choose to:
    • Accept the offer, at which point it sends a delivery address to the seller and receives a delivery date.
    • Reject the offer, and await another offer from buyer 1.
    • End the protocol.

Scribble is a protocol description language based on the theory of multiparty session types, and is used by many of the tools described below. The Scribble specification for the two-buyer protocol is:

global protocol TwoBuyer(role Buyer1, role Buyer2, role Seller) {
  title(String) from Buyer1 to Seller;
  price(Currency) from Seller to Buyer1, Buyer2;
  rec loop {
    share(Currency) from Buyer1 to Buyer2;
    choice at Buyer2 {
      accept() from Buyer2 to Buyer1;
      deliveryAddress(String) from Buyer2 to Seller;
      deliveryDate(Date) from Seller to Buyer2;
    } or {
      reject() from Buyer2 to Buyer1;
      continue loop;
    } or {
      quit() from Buyer2 to Buyer1, Seller;
    }
  }
}

Interactions are of the form label(Types) from FromRole to RecipientRole1, RecipientRole2 ... RecipientRoleN;. rec and continue provide recursive protocols.

The corresponding local type for Buyer2 would be:

local protocol TwoBuyer at Buyer2(role Buyer1, role Buyer2, role Seller) {
  price(Currency) from Seller;
  rec loop {
    share(Currency) from Buyer1;
    choice at Buyer2 {
      accept() to Buyer1;
      deliveryAddress(String) to Seller;
      deliveryDate(Date) from Seller;
    } or {
      reject() to Buyer1;
      continue loop;
    } or {
      quit() to Buyer1, Seller;
    }
  }
}

Note that the local type does not contain any interactions that Buyer2 is not involved in.

Categorising language-based implementations of session types

Binary vs. Multiparty

Are sessions between two participants (generally implemented as a typed channel with dual endpoints), or multiple?

Primitive vs. Library vs. External

What form do the session types take?

  • Primitive: Session types are implemented as language primitives, or as part of a compiler plugin
  • Library: Session types are provided using a library
  • External: A tool checking session types as a static analysis pass, or providing functionality that is not necessarily verifying conformance to a protocol.

Static vs. Dynamic vs. Hybrid Verification

When and how is conformance to the session types checked?

  • Static: Conformance to session types is fully checked at compile time. Any error (be it sending the wrong message, not completing a session, or duplicating an endpoint) will be reported before a program compiles.
  • Dynamic: Conformance to session types is checked at runtime. Session types are compiled into communicating finite-state machines, and messages are verified against these CFSMs. These approaches are very flexible, extending session types to dynamically-checked languages, and allowing things like assertions on data.
  • Hybrid: Sending messages in the right order is checkeed statically. Linearity is checkeed dynamically. This is a promising approach, with drop-in libraries available to be used in general-purpose languages today!

Programming Languages with Native Session Types

ATS

(Static, Binary)

ATS is a programming language that aims to combine specification and implementation in a single language. ATS has many features, such as dependent and linear types, which allows the development of verified software. Recent work has integrated session-typed channels with ATS.

Resources

(Static, Binary)

Links is a programming language designed at the University of Edinburgh for developing “tierless” web applications. A recent extension of Links adds support for binary session types as language primitives.

Session types are checked fully statically, using an extension of the type system to support linear types. The repository contains a selection of examples.

Resources

MOOL

(Static, Object-based)

(Description from the MOOL website)

Mool is a mini object-oriented language in a Java-like style with support for concurrency, that allows programmers to specify class usage protocols as types. The specification formalizes (1) the available methods, (2) the tests clients must perform on the values returned by methods, and (3) the existence of aliasing and concurrency restrictions, all of which depend on the object’s state. Linear and shared objects are handled as a single category, allowing linear objects to evolve into shared ones. The Mool type system verifies that methods are called only when available, and by a single client if so specified in the usage type. Mool builds upon previous works on (Modular) Session Types and Linear Type Systems.

Resources

SePi

(Static, Binary)

(Description from the SePi website)

SePi is a concurrent, message-passing programming language based on the pi-calculus. The language features synchronous, bi-directional channel-based communication. Programs use primitives to send and receive messages as well as offer and select choices. Channel interactions are statically verified against session types describing the kind and order of messages exchanged, as well as the number of processes that may share a channel. In order to facilitate a more precise control of program properties, SePi includes assume and assert primitives at the process level and refinements at the type level. Refinements are treated linearly, allowing a finer, resource-oriented use of predicates: each assumption made supports exactly one an assertion.

Resources

SILL

(Static, Binary)

A programming language based on the intuitionistic linear logic view of session types.

Resources

Mainstream Languages with Implementations of Session Types

C

Multiparty Session C

(Static, Multiparty)

A statically-checked implementation of multiparty session types in C. Session communication happens using a runtime library, and type-checking is done via a clang plugin.

Resources

Erlang

monitored-session-erlang

(Dynamic, Multiparty, Actor-based)

An framework for monitoring Erlang/OTP applications by dynamically verifying communication against multiparty session types. Erlang actors can take part in multiple roles in multiple instances of multiple protocols.

The tool is inspired by the Session Actor framework of Neykova & Yoshida.

Resources

Go

DinGo Hunter

(External tool)

A static analyser for Go programs, which can statically detect deadlocks. The tool works by extracting CFSMs from Go programs, and attempting to synthesise a global graph. Should this fail, then there is a deadlock.

Resources

Gong

(External tool)

A more recent static analyser for Go, building on a minimal core calculus for Go called MiGo. MiGo types can be extracted from Go programs using another tool called GoInfer.

Given MiGo types obtained from GoInfer, Gong will check liveness and safety of communications.

Resources

Haskell

effect-sessions

(Static, Binary)

An implementation of session types in Concurrent Haskell, through the observation that session types can be encoded using an effect system (and vice versa).

Resources

simple-sessions

(Static, Binary)

A library implementation of Haskell session types, using parameterised monads and a channel stack.

Resources

sessions

(Static, Binary)

An alternative embedding of session types in Haskell.

Resources

GVInHS

(Static, Binary)

An embedding of session types in Haskell which (by virtue of a finally-tagless encoding) allows channels to be treated as first-class. Builds on Polakow’s embedding of a Linear Lambda-Calculus in Haskell.

Resources

Java

CO2 Middleware

(Dynamic, Binary, Timed)

Middleware for Java applications, based on the theory of timed session types. Supports dynamic monitoring of conformance to timing constraints.

Resources

(Eventful) Session Java

(Static, Binary, supports event-driven programming)

A frontend and runtime library for Java, supporting binary session types. The tool also supports event-driven programming.

Resources

Mungo / StMungo

(External, Multiparty)

Mungo is a tool which checks Java programs for conformance to typestate specifications, providing typestate inference. StMungo is a tool which translates Scribble protocols into typestate specifications.

Resources

Scribble Endpoint Generation

(Hybrid, Multiparty)

A tool which can generate endpoint APIs from Scribble protocols. The generated Java stubs allow message ordering to be checked statically, with linearity checked dynamically.

Resources

OCaml

FuSe

(Hybrid, Binary)

A very lightweight implementation of binary session types in OCaml, verifying message ordering statically and linearity violations dynamically.

Resources

Python

SPY

(Dynamic, Multiparty)

An implementation of multiparty session types in Python, using runtime monitoring.

Resources

Session Actor

(Dynamic, Multiparty, Actor-based)

A conceptual framework and Python implementation for extending session types to the actor model of programming. Each actor may be involved in multiple roles in multiple sessions. Communication is checked dynamically via compilation of Scribble protocols into CFSMs.

Resources

Rust

session-types

(Static, Binary)

An implementation of binary session types in Mozilla’s Rust language, making use of Rust’s affine typing system.

Resources
  • Session Types for Rust by Thomas Bracht Laumann Jespersen, Philip Munksgaard, and Ken Friis Larsen. In proceedings of WGP’15.

Scala

lchannels

(Hybrid, Binary)

An implementation of binary session types in Scala. The library uses the continuation-passing approach of Kobayashi, and Dardha et al. Message ordering is checked statically, and linearity is checked dynamically.

Resources