Abstract
Session types statically guarantee that communication complies with a protocol. However, most accounts of session typing do not account for failure, which means they are of limited use in real applications---especially distributed applications---where failure is pervasive. We present the first formal integration of asynchronous session types with exception handling in a functional programming language. We define a core calculus which satisfies preservation and progress properties, is deadlock free, confluent, and terminating. We provide the first implementation of session types with exception handling for a fully-fledged functional programming language, by extending the Links web programming language; our implementation draws on existing work on effect handlers. We illustrate our approach through a running example of two-factor authentication, and a larger example of a session-based chat application where communication occurs over session-typed channels and disconnections are handled gracefully.
Highlights
With the growth of the internet and mobile devices, as well as the failure of Moore’s law, concurrency and distribution have become central to many applications
We present the first formal integration of asynchronous session types with exception handling in a functional programming language
We provide the first implementation of session types with exception handling for a fully-fledged functional programming language, by extending the Links web programming language; our implementation draws on existing work on effect handlers
Summary
With the growth of the internet and mobile devices, as well as the failure of Moore’s law, concurrency and distribution have become central to many applications. Writing correct concurrent and distributed code requires effective tools for reasoning about communication protocols. While data types provide an effective tool for reasoning about the shape of data communicated, protocols require us to reason about the order in which messages are transmitted. Session types [Honda 1993; Honda et al 1998] are types for protocols. They describe both the shape and order of messages. If a program type-checks according to its session type, it is statically guaranteed to comply with the corresponding protocol. TwoFactorServer ≜ ?(Username, Password).⊕{ Authenticated : ServerBody, Challenge : !ChallengeKey.?Response. ⊕{Authenticated : ServerBody, AccessDenied : End}, AccessDenied : End}. TwoFactorClient ≜ !(Username, Password).&{ Authenticated : ClientBody, Challenge : ?ChallengeKey.!Response. &{Authenticated : ClientBody, AccessDenied : End}, AccessDenied : End} TwoFactorClient ≜ !(Username, Password).&{ Authenticated : ClientBody, Challenge : ?ChallengeKey.!Response. &{Authenticated : ClientBody, AccessDenied : End}, AccessDenied : End}
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
