Do be do be do

Abstract

We explore the design and implementation of Frank, a strict functional programming language with a bidirectional effect type system designed from the ground up around a novel variant of Plotkin and Pretnar's effect handler abstraction.Effect handlers provide an abstraction for modular effectful programming: a handler acts as an interpreter for a collection of commands whose interfaces are statically tracked by the type system. However, Frank eliminates the need for an additional effect handling construct by generalising the basic mechanism of functional abstraction itself. A function is simply the special case of a Frank operator that interprets no commands. Moreover, Frank's operators can be multihandlers which simultaneously interpret commands from several sources at once, without disturbing the direct style of functional programming with values.Effect typing in Frank employs a novel form of effect polymorphism which avoid mentioning effect variables in source code. This is achieved by propagating an ambient ability inwards, rather than accumulating unions of potential effects outwards.We introduce Frank by example, and then give a formal account of the Frank type system and its semantics. We introduce Core Frank by elaborating Frank operators into functions, case expressions, and unary handlers, and then give a sound small-step operational semantics for Core Frank.Programming with effects and handlers is in its infancy. We contribute an exploration of future possibilities, particularly in combination with other forms of rich type system. Hillerström and Lindley [20-22] (Links [11]) and Leijen [30] (Koka [29]) have extended existing languages with effect handlers and algebraic effects. Both languages incorporate row-based effect type systems and attempt to elide some effect variables from source code, but neither eliminates effect variables to the extent that Frank does. Dolan et al. [12] built Multicore OCaml by extending OCaml with support for effect handlers and algebraic effects. Multicore OCaml does not include an effect type system.Whereas Frank is bidirectionally typed, all of these other languages use Hindley-Milner type inference. None of the other languages supports multihandlers and none of those with effect typing allow effect variables to be omitted to the degree that Frank does.Kammar et al.[25] describe a number of effect handler libraries for languages ranging from Racket, to SML, to OCaml, to Haskell. Apart from the Haskell library, their libraries have no effect typing support. The Haskell library takes advantage of type classes to simulate an effect type system not entirely dissimilar to that of Frank. As Haskell is lazy, the Haskell library cannot be used to write direct-style effectful programs-one must instead adopt a monadic style. Moreover, although there are a number of ways of almost simulating effect type systems in Haskell, none is without its flaws. Kiselyov and collaborators [26,27] have built another Haskell library for effect handlers, making different design choices.Brady's effe...

Doo bee doo bee doo

“…Currently, Frank supports a limited range of built-in top-level interfaces, but one can imagine adding many more and in particular connecting them to external APIs. We have revisited an example presented by Lindley et al (2017) but have been able to give a more constrained type to the parser process, preventing it from accessing Console commands by using an adaptor in the signature for input to mask this effect. No changes to the implementation were necessary.…”

“…Relation to Prior Work. This is an updated and extended version of a previous paper (Lindley et al, 2017). The primary new contributions in this paper are a direct semantics (previously the semantics was given by translation to a core language) and extensions to Frank with polymorphic commands and adaptors to support effect encapsulation and enable the rewiring of effect flow.…”

Signature restriction for polymorphic algebraic effects

“…Pretnar [2009, 2013] introduced effect handlers in order to represent the semantics of exception handling in an equational theory. The idea of separating an effect interface and its interpretation makes it possible to handle user-defined effects in a modular way and encourages the emergence of languages equipped with algebraic effect handlers, such as Eff [Bauer and Pretnar 2015], Koka [Leijen 2017], Frank [Lindley et al 2017], Multicore OCaml [Dolan et al 2017]. We also utilize the separation and restrict only effect interfaces in order to achieve type safety in polymorphic type assignment.…”

Faster coroutine pipelines: A reconstruction

“…Multihandlers. The Frank language (Lindley et al, 2017) is based on shallow handlers and supports a feature called multihandlers. These handlers operate on multiple inputs which have uninterpreted operations, much like pattern matching on multiple free structures.…”