Session types revisited

Dardha, Ornela; Giachino, Elena; Sangiorgi, Davide

doi:10.1016/j.ic.2017.06.002

Cited by 48 publications

(61 citation statements)

References 32 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The choose_left, choose_right, and offer_either functions let processes offer or make a binary choice. These are derived constructs [8,2]. They are implemented using only the functions in our library-new, send, recv, close, and cancel-and the sum type Either.…”

Section: Branching With Offer! and Choose!mentioning

confidence: 99%

Rusty Variation: Deadlock-free Sessions with Failure in Rust

Kokke

2019

Electron. Proc. Theor. Comput. Sci.

View full text Add to dashboard Cite

Rusty Variation (RV) is a library for session-typed communication in Rust which offers strong compile-time correctness guarantees. Programs written using RV are guaranteed to respect a specified protocol, and are guaranteed to be free from deadlocks and races. Rusty Variation Types, sessions, and dualityThere are three basic types which we use to describe session protocols-or session types: Send, Recv, and End. We refer to values of these types as session endpoints or, when referring to both endpoints, sessions. Session endpoints wrap primitive channels-see section 2.6. Any type built using these primitive types is a valid session type:Session types are public, but their member functions are not. Therefore, users cannot construct their own misbehaving sessions. The continuation of a session must itself be a session. This is enforced by the Session constraint. In addition to this "kinding" of session types, the Session trait also requires any session type to implement duality and session generation: pub trait Session { type Dual: Session; fn new() -> (Self, Self::Dual); } Duality works as expected: Send is dual to Recv-and vice versa-and End is selfdual. The constraint Session enforces that the dual of a session type is a session type, and that S::Dual::Dual is equal to S (involutivity).The new function generates a new session-typed channel and returns two dual channel endpoints. Unlike the rest of the functions discussed in this section, new is not part of the public interface-see section 2.7.Using these types, we can define the types of servers which offer squaring or negation as follows, where i32 is the type of 32-bit integers:type SqrSrv = Recv>; type NegSrv = Recv>;The client types are obtained by duality. Send, receive, close, and forkThe send and recv functions send and receive values in sessions. Sending is non-blocking, and never fails. Sending a value on a cancelled channel is equivalent to cancelling that value-see section 2.3. Receiving is blocking, and fails if the channel is cancelled.

show abstract

Section: Branching With Offer! and Choose!mentioning

confidence: 99%

Rusty Variation: Deadlock-free Sessions with Failure in Rust

Kokke

2019

Electron. Proc. Theor. Comput. Sci.

View full text Add to dashboard Cite

show abstract

“…Linearity inspired also the seminal theories of linear types for the π-calculus [11] and session types [10]. Even though the two theories do not have a direct correspondence with linear logic, the link is still strong enough that session types can be encoded into linear types [7].…”

Section: Related Workmentioning

confidence: 99%

Taking Linear Logic Apart

Kokke

Montesi

Peressotti

2019

Electron. Proc. Theor. Comput. Sci.

View full text Add to dashboard Cite

Process calculi based on logic, such as πDILL and CP, provide a foundation for deadlock-free concurrent programming. However, in previous work, there is a mismatch between the rules for constructing proofs and the term constructors of the π-calculus: the fundamental operator for parallel composition does not correspond to any rule of linear logic.Kokke et al. [12] introduced Hypersequent Classical Processes (HCP), which addresses this mismatch using hypersequents (collections of sequents) to register parallelism in the typing judgements. However, the step from CP to HCP is a big one. As of yet, HCP does not have reduction semantics, and the addition of delayed actions means that CP processes interpreted as HCP processes do not behave as they would in CP.We introduce HCP − , a variant of HCP with reduction semantics and without delayed actions. We prove progress, preservation, and termination, and show that HCP − supports the same communication protocols as CP.

show abstract

“…Later, linearity inspired also the seminal theories of linear types for the π -calculus (Kobayashi et al 1999) and session types (Honda et al 1998). Even though the two theories do not use exactly linear logic, the work by Dardha et al (2017) shows that the link is still strong enough that session types can be encoded into linear types.…”

Section: Related Workmentioning

confidence: 99%

Classical Higher-Order Processes

Montesi

2017

Formal Techniques for Distributed Objects, Components, and Systems

View full text Add to dashboard Cite

Classical Processes (CP) is a calculus where the proof theory of classical linear logic types communicating processes with mobile channels,à la π -calculus. Its construction builds on a recent propositions as types correspondence between session types and propositions in linear logic. Desirable properties such as type preservation under reductions and progress come for free from the metatheory of linear logic.We contribute to this research line by extending CP with code mobility. We generalise classical linear logic to capture higher-order (linear) reasoning on proofs, which yields a logical reconstruction of (a variant of) the Higher-Order π -calculus (HOπ ). e resulting calculus is called Classical Higher-Order Processes (CHOP). We explore the metatheory of CHOP, proving that its semantics enjoys type preservation and progress (terms do not get stuck). We also illustrate the expressivity of CHOP through examples, derivable syntax sugar, and an extension to multiparty sessions. Lastly, we de ne a translation from CHOP to CP, which encodes mobility of process code into reference passing.Outline of development and contributions. We develop the calculus of Classical Higher-Order Processes (CHOP), a strict generalisation of CP that captures process mobility (CP is a fragment of CHOP). CHOP extends linear logic to higher-order reasoning, by allowing proofs to have "holes": a proof may just assume a sequent to be provable and use it as a premise. Actual proofs that resolve these assumptions can then be provided separately, using a higher-order version of the cut rule. Providing a proof and assuming provability are respectively typed by two new kinds of types, [Γ] and Γ , where Γ is a typing context. e rules that we introduce for our new ingredients type the key primitives that elevate CP to a higher-order process calculus: send a process, receive a process, store a process in a variable, and run the process stored in a variable.Di erently from previous higher-order process calculi, CHOP treats process variables linearly (following the intuition that it is a higher-order linear logic): a process sent over a channel is guaranteed to be eventually used exactly once-the receiver may delegate this responsibility further on to another process. Higher-order types can be composed using the standard connectives of linear logic, so that we can apply the usual expressivity of linear logic propositions to this new se ing-e.g., multiple assumptions Γ ⊗ Γ or explicit weakening ? Γ .Our higher-order cuts (called chops) support type-preserving proof transformations that yield a semantics of communication and explicit substitutions (as originally developed by Abadi et al. (1991) for the λ-calculus) for higherorder processes. Our semantics suggests how the substitutions that should be performed at the receiver as a result of code mobility can be implemented e ciently. We show that the existing semantics for link terms in CP-which bridge two channels and enable behavioural polymorphism-becomes unsound in the higher-order se ing, and the...

show abstract

Session types revisited

Cited by 48 publications

References 32 publications

Rusty Variation: Deadlock-free Sessions with Failure in Rust

Rusty Variation: Deadlock-free Sessions with Failure in Rust

Taking Linear Logic Apart

Classical Higher-Order Processes

Contact Info

Product

Resources

About