Effects as sessions, sessions as effects

Abstract

Effect and session type systems are two expressive behavioural type systems. The former is usually developed in the context of the lambda-calculus and its variants, the latter for the pi-calculus. In this paper we explore their relative expressive power. Firstly, we give an embedding from PCF, augmented with a parameterised effect system, into a session-typed pi-calculus (session calculus), showing that session types are powerful enough to express effects. Secondly, we give a reverse embedding, from the session calculus back into PCF, by instantiating PCF with concurrency primitives and its effect system with a session-like effect algebra; effect systems are powerful enough to express sessions. The embedding of session types into an effect system is leveraged to give a new implementation of session types in Haskell, via an effect system encoding. The correctness of this implementation follows from the second embedding result. We also discuss various extensions to our embeddings.

On the relative expressiveness of higher-order session processes

“…Our results show that the calculus in [27] is not only expressed but also reasoned in HO via precise encodings (with a limited form of arrow types: C → and C ). The work [30] studies two encodings: from PCF with an effect system into a session-typed π -calculus, and its reverse. The reverse encoding is used to implement session channel passing in Concurrent Haskell.…”

Value-Dependent Session Design in a Dependently Typed Language

“…EDSL EDSLs have been realised for: Haskell [36,30,35]; Go [25]; and Rust [22]. These approaches follow our approach, however, the host language chosen is not as expressive in describing global session description and thus do not allow for reasoning on message descriptions.…”

Session-ocaml: A Session-Based Library with Polarities and Lenses

“…Lines 2-7 define a type and a function for logical operations over boolean values. The function logic_server (lines [8][9][10][11][12][13][14] describes the body of the server. An expression branch~left:(s, cont 1 )~right:(s, cont 2 ) offers a choice between labels left and right to the peer, 4 and it continues to cont 1 when label left is selected, or to cont 2 when right is selected.…”

“…It receives a branch label first using one of the two slot specifiers. 8 Then, according to the received label, branch assigns the continuation session to the slot, and invokes the continuation function. We need distinct slot specifiers for different continuations because the pre-types in the two continuations can be different from each other, and a slot specifier assigning to the slot cannot have two different types in the third parameter.…”

“…Linearity of session channels, however, is a major obstacle to adopt the session type disciplines in mainstream programming languages, as it requires special syntax extensions for session communications [7], or it depends on specific language features, such as type-level functions in Haskell [5,8,9,4], or affine types in Rust [10]. In [6,[11][12][13], the check for linearity falls back to run-time and dynamic checking.…”