Abstract
Session types describe patterns of interaction on communicating channels. Traditional session types include a form of choice whereby servers offer a collection of options, of which each client picks exactly one. This sort of choice constitutes a particular case of separated choice: offering on one side, selecting on the other. We introduce mixed choices in the context of session types and argue that they increase the flexibility of program development at the same time that they reduce the number of synchronisation primitives to exactly one. We present a type system incorporating subtyping and prove preservation and absence of runtime errors for well-typed processes. We further show that classical (conventional) sessions can be faithfully and tightly embedded in mixed choices. Finally, we discuss algorithmic type checking and a runtime system built on top of a conventional (choice-less) message-passing architecture.
Highlights
Session types provide for describing series of continuous interactions on communication channels [16,19,43,45,49]
When used in type systems for programming languages, session type systems statically verify that programs follow protocols, and that they do not engage in communication mismatches
We introduce mixed sessions: session types with mixed choice
Summary
Session types provide for describing series of continuous interactions on communication channels [16,19,43,45,49]. Using mixed sessions one can invert the direction of the more selection and write the type of the channel (again as seen from the side of the consumer) as. The classical session primitive operations: selection and branching (that is, internal and external choice) and communication (output and input) become one only: mixed session. – enjoys preservation and absence of runtime errors for typable processes, and – provides for embedding classical sessions in a tight type and operational correspondence. The rest of the paper is organised as follows: the section shows mixed sessions in action; Section 3 introduces the technical development of the language, and Section 4 proves the main results (preservation and absence of runtime errors for typable processes).
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have