A separation logic for effect handlers

Abstract

User-defined effects and effect handlers are advertised and advocated as a relatively easy-to-understand and modular approach to delimited control. They offer the ability of suspending and resuming a computation and allow information to be transmitted both ways between the computation, which requests a certain service, and the handler, which provides this service. Yet, a key question remains, to this day, largely unanswered: how does one modularly specify and verify programs in the presence of both user-defined effect handlers and primitive effects, such as heap-allocated mutable state? We answer this question by presenting a Separation Logic with built-in support for effect handlers, both shallow and deep. The specification of a program fragment includes a protocol that describes the effects that the program may perform as well as the replies that it can expect to receive. The logic allows local reasoning via a frame rule and a bind rule. It is based on Iris and inherits all of its advanced features, including support for higher-order functions, user-defined ghost state, and invariants. We illustrate its power via several case studies, including (1) a generic formulation of control inversion, which turns a producer that ``pushes'' elements towards a consumer into a producer from which one can ``pull'' elements on demand, and (2) a simple system for cooperative concurrency, where several threads execute concurrently, can spawn new threads, and communicate via promises.

Applying formal verification to microkernel IPC at meta

“…• Prior Research: non-blocking algorithms had previously been verified in Iris [13,29]. • Corroboration: Iris is not only used by its inventors but also by other research teams (e.g., [2,8,20]) and by at least one company, Bedrock Systems. • Community: Iris has a responsive support community.…”

Verifying an Effect-Handler-Based Define-By-Run Reverse-Mode AD Library

“…This means that a computation that suspends itself once can be resumed more than once. This use of continuations is powerful, but requires care: it breaks the property that "a block of code, once entered, is exited at most once", and thereby compromises the frame rule [dVP21a], one of the most fundamental reasoning rules of Separation Logic. Both Multicore OCaml and our reasoning rules 3 that a continuation be invoked at most once.…”

“…In this section, we use the mathematical definitions of the previous section ( §4) in combination with Hazel [dVP21a], an extension of Separation Logic with support for effect handlers, described in previous work by the same authors. Hazel allows writing a formal specification of the library that was presented earlier ( §3).…”

“…A small set of features, including first-class functions, references, effect handlers and one-shot continuations, suffices. In previous work [dVP21a], we have defined such a calculus, dubbed HH (for "heaps and handlers"), and have endowed it with a small-step operational semantics. We do not recall the syntax or operational semantics of HH , whose details are not relevant here.…”

“…We transcribe Wang and Rompf's simple implementation of RMAD in HH , a core λ-calculus equipped with effect handlers. Then, using Iris [JKJ + 18], a powerful evolution of Separation Logic, which in previous work [dVP21a] we have extended with support for effect handlers, we express a specification for an automatic differentiation algorithm and we verify that this code is correct with respect to this specification. Our proof is machine-checked and is available online [dVP21b].…”