Abstracting algebraic effects

Abstract

Proposed originally by Plotkin and Pretnar, algebraic effects and their handlers are a leading-edge approach to computational effects: exceptions, mutable state, nondeterminism, and such. Appreciated for their elegance and expressiveness, they are now progressing into mainstream functional programming languages. In this paper, we introduce and examine programming language constructs that back adoption of programming with algebraic effects on a larger scale in a modular fashion by providing mechanisms for abstraction. We propose two such mechanisms: existential effects (which hide the details of a particular effect from the user) and local effects (which guarantee that no code coming from the outside can interfere with a given effect). The main technical difficulty arises from the dynamic nature of coupling an effectful operation with the right handler during execution, but, as we show in this paper, a carefully designed type system can ensure that this will not break the abstraction. Our main contribution is a novel calculus for algebraic effects and handlers, called λ HEL , equipped with local and existential algebraic effects, in which the dynamic nature of handlers is kept in check by typed runtime coercions. As a proof of concept, we present an experimental programming language based on our calculus, which provides strong abstraction mechanisms via an ML-style module system.

Binders by day, labels by night: effect instances via lexically scoped handlers

“…There are three kinds in the calculus: types (T), effects (E), and signatures (S). In the core calculus, one does not declare effects (in contrast to, e.g., [Biernacki et al 2019]), and signatures play a role similar to type schemes in the HindleyśMilner type system: kept in the context, they describe the (possibly polymorphic) type of a particular instance, which is instantiated every time the operation is used. Note that there is no kind for instances: in the syntax and type system of the core calculus, instances exist only as variables coupling operations and handlers, and are never instantiated with anything else than other instance variables (this is no longer the case in the generative operational semantics in Section 5, which needs some additional syntactic elements).…”

“…This gives the programmer a lot of expressiveness, but it is not possible to track such instances using a type-and-effect system, since it is impossible to statically determine which instances will be handled and when. Biernacki et al [2019] introduced effect coercions, which are similar to the slightly more expressive adaptors proposed later by Convent et al [2019]. These two solutions boil down to recognising each use of an effect by its position in the row of effects, resulting in something akin to de Bruijn indices on the level of types, which is rather expressive and well-behaved on the theoretical side, but quite impractical in real life.…”

“…This way, the programmer is always aware of what can happen behind the scenes: whether a function is pure, does any I/O, throws a particular kind of exceptions ś and if all of them are always caught. Such systems can be quite complex, and allow for features like effect polymorphism [Leijen 2014], existential effects [Biernacki et al 2019] (useful for combining algebraic effects with built-in effects), or linearity [Leijen 2018] (useful for physical resource management).…”

“…The paper is accompanied by a surface-level language, based on the implementation by Biernacki et al [2019]. 1 Moreover, we formalise our calculus and meta results in Coq.…”

Effekt: Capability-passing style for type- and effect-safe, extensible effect handlers in Scala

“…Existing implementations of languages with effect handlers either completely lack a static effect system-this includes Multicore OCaml (Dolan et al, 2014), Eff (Bauer & Pretnar, 2015), embeddings of Eff in OCaml (Kiselyov & Sivaramakrishnan, 2016), and previous versions of Effekt (Brachthäuser & Schuster, 2017;Brachthäuser et al, 2018)-or they do not have sufficient support for effect polymorphism (Kammar et al, 2013;Inostroza & van der Storm, 2018). Languages and libraries with effect systems like Extensible Effects (Kiselyov et al, 2013), Koka (Leijen, 2017c), Links (Hillerström et al, 2017), Frank (Lindley et al, 2017), and Helium (Biernacki et al, 2019) require explicit lifting annotations to encapsulate effects in effectful higher-order functions, like the function mapM above. Without such manual liftings, the implementation detail of effects used within mapM would leak into its type signature.…”