Report from Dagstuhl Seminar 18172 ...While traditionally fully abstract compilation and ﬂexible linking have been thought to be at odds, I’ll present a novel idea called Linking

Report from Dagstuhl Seminar 18172

Algebraic Effect Handlers go MainstreamEdited bySivaramakrishnan Krishnamoorthy Chandrasekaran1 Daan Leijen2Matija Pretnar3 and Tom Schrijvers4

1 University of Cambridge GB sk826clcamacuk2 Microsoft Research ndash Redmond US daanmicrosoftcom3 University of Ljubljana SI matijapretnarfmfuni-ljsi4 KU Leuven BE tomschrijverscskuleuvenbe

AbstractLanguages like C C++ or JavaScript support complex control flow statements like exceptionhandling iterators (yield) and even asynchrony (asyncawait) through special extensions Forexceptions the runtime needs to be extended with exception handling stack frames For iteratorsand asynchrony the situation is more involved as the compiler needs to turn regular code intostack restoring state machines Furthermore these features need to interact as expected egfinally blocks must not be forgotten in the state machines for iterators And all of this workneeds to be done again for the next control flow abstraction that comes along

Or we can use algebraic effect handlers This single mechanism generalizes all the controlflow abstractions listed above and more composes freely has simple operational semantics andcan be efficiently compiled since there is just one mechanism that needs to be supported wellHandlers allow programmers to keep the code in direct-style which is easy to reason about andempower library writers to implement various high-level abstractions without special extensions

The idea of algebraic effects handlers has already been experimented with in the form ofsmall research languages and libraries in several mainstream languages including OCaml HaskellClojure and Scala The next step and the aim of this seminar is to seriously consider adoptionby mainstream languages including both functional languages such as OCaml or Haskell as wellas languages like JavaScript and the JVM and NET ecosystems

Seminar April 22ndash27 2018 ndash httpwwwdagstuhlde181722012 ACM Subject Classification Software and its engineering rarr Control structures Software

and its engineering rarr Formal methods Software and its engineering rarr SemanticsKeywords and phrases algebraic effect handlers implementation techniques programming ab-

stractions programming languagesDigital Object Identifier 104230DagRep84104Edited in cooperation with Jonathan Immanuel Brachthaumluser

Except where otherwise noted content of this report is licensedunder a Creative Commons BY 30 Unported license

Algebraic Effect Handlers go Mainstream Dagstuhl Reports Vol 8 Issue 04 pp 104ndash125Editors Sivaramakrishnan Krishnamoorthy Chandrasekaran Daan Leijen Matija Pretnar and Tom Schrijvers

Dagstuhl ReportsSchloss Dagstuhl ndash Leibniz-Zentrum fuumlr Informatik Dagstuhl Publishing Germany

KC Sivaramakrishnan Daan Leijen Matija Pretnar and Tom Schrijvers 105

1 Executive Summary

Sivaramakrishnan Krishnamoorthy Chandrasekaran (University of Cambridge GB)Daan Leijen (Microsoft Research ndash Redmond US)Matija Pretnar (University of Ljubljana SI)Tom Schrijvers (KU Leuven BE)

License Creative Commons BY 30 Unported licensecopy Sivaramakrishnan Krishnamoorthy Chandrasekaran Daan Leijen Matija Pretnar andTom Schrijvers

Algebraic effects and their handlers have been steadily gaining attention as a programminglanguage feature for composably expressing user-defined computational effects Algebraiceffect handlers generalise many control-flow abstractions such as exception handling iteratorsasyncawait or backtracking and in turn allow them to be expressed as libraries ratherthan implementing them as primitives as many language implementations do While severalprototype languages that incorporate effect handlers exist they have not yet been adoptedinto mainstream languages This Dagstuhl Seminar 18172 ldquoAlgebraic Effect Handlers GoMainstreardquo touched upon various topics that hinder adoption into mainstream languagesTo this end the participants in this seminar included a healthy mix of academics who studyalgebraic effects and handlers and developers of mainstream languages such as HaskellOCaml Scala WebAssembly and Hack

This seminar follows the earlier wildly successful Dagstuhl Seminar 16112 ldquoFrom Theoryto Practice of Algebraic Effects and Handlersrdquo which was dedicated to addressing fundamentalissues in the theory and practice of algebraic effect handlers We adopted a similar structurefor this seminar We had talks each day in the morning scheduled a few days ahead Thefolks from the industry were invited to present their perspectives on some of the challengesthat could potentially be address with the help of effect handlers The afternoons wereleft free for working in self-organised groups and show-and-tell sessions with results fromthe previous days We also had impromptu lectures on the origins of algebraic effects andhandlers which were quite well received and one of the highlights of the seminar

Between the lectures and working-in-groups the afternoons were rather full Hence afew participants offered after-dinner ldquocheesy talksrdquo just after the cheese was served in theevening The participants were treated to entertaining talks over delightful cheese and finewine We encourage the organisers to leave part of the day unplanned and go with what theparticipants feel like doing on that day The serendipitous success are what makes DagstuhlSeminars special

We are delighted with the outcome of the seminar There were interesting discussionsaround the problem of encapsulation and leaking of effects in certain higher order use caseswith several promising solutions discussed It was identified that the problem of encapsulationand leaking effect names is analogous to the name binding in lambda calculus Anothergroup made significant progress in extending WebAssembly with support for effect handlersThe proposal builds on top of support for exceptions in WebAssembly During the seminarweek the syntax extensions and operational semantics were worked out with work begun onthe reference implementation During the seminar Andrej Bauer pointed out that severalprototype implementations that incorporate effect handlers exist each with their own syntaxand semantics This makes it difficult to translate ideas across different research groupsHence Andrej proposed and initiated effects and handlers rosetta stone ndash a repository ofexamples demonstrating programming with effects and handlers in various programminglanguages This repository is hosted on GitHub and has had several contributions duringand after the seminar

106 18172 ndash Algebraic Effect Handlers go Mainstream

In conclusion the seminar inspired discussions and brought to light the challenges inincorporating effect handlers in mainstream languages During the previous seminar (16112)the discussions were centered around whether it was even possible to incorporate effecthandlers into mainstream languages During this seminar the discussions were mainly on theergonomics of effect handlers in mainstream languages This is a testament to the success ofthe Dagstuhl Seminars in fostering cutting edge research

2 Contents

Executive SummarySivaramakrishnan Krishnamoorthy Chandrasekaran Daan Leijen Matija Pretnarand Tom Schrijvers 105

Overview of Talks

Linking Types for Multi-Language SoftwareAmal Ahmed 109

Idealised AlgolRobert Atkey 109

What is algebraic about algebraic effects and handlersAndrej Bauer 110

Event Correlation with Algebraic EffectsOliver Bracevac 110

Effect Handlers for the MassesJonathan Immanuel Brachthaumluser 111

Combining Algebraic TheoriesJeremy Gibbons 111

HandlersJs A Comparative Study of Implementation Strategies for Effect Handlerson the WebDaniel Hillerstroumlm 113

First Class Dynamic Effect Handlers and Deep Finally HandlingDaan Leijen 113

Encapsulating effectsSam Lindley 114

Experiences with structuring effectful code in HaskellAndres Loumlh 119

Make Equations Great AgainMatija Pretnar 119

Quirky handlersMatija Pretnar and Žiga Lukšič 119

What is coalgebraic about algebraic effects and handlersMatija Pretnar 120

Effect Handlers for WebAssembly (Show and Tell)Andreas Rossberg 120

Neither Web Nor AssemblyAndreas Rossberg 121

Efficient Compilation of Algebraic Effects and HandlersTom Schrijvers 121

Algebraic effects ndash specification and refinementWouter Swierstra 122

Adding an effect system to OCamlLeo White 122

Multi-Stage Programming with Algebraic EffectsJeremy Yallop 122

Working groups

Denotational Semantics for Dynamically Generated EffectsRobert Atkey 123

Reasoning with EffectsJeremy Gibbons 124

Participants 125

3 Overview of Talks

31 Linking Types for Multi-Language SoftwareAmal Ahmed (Northeastern University ndash Boston US

License Creative Commons BY 30 Unported licensecopy Amal Ahmed

Main reference Daniel Patterson Amal Ahmed ldquoLinking Types for Multi-Language Software Have Your Cakeand Eat It Toordquo in Proc of the 2nd Summit on Advances in Programming Languages SNAPL2017 May 7-10 2017 Asilomar CA USA LIPIcs Vol 71 pp 121ndash1215 Schloss Dagstuhl ndashLeibniz-Zentrum fuer Informatik 2017

URL httpsdoiorg104230LIPIcsSNAPL201712

In the last few years my group at Northeastern has focused on verifying compositionalcompiler correctness for todayrsquos world of multi-language software Such compilers shouldallow compiled components to be linked with target components potentially compiled fromother very different languages At the same time compilers should also be fully abstractthat is they should ensure that if two components are equivalent in all source contexts thentheir compiled versions are equivalent in all target contexts Fully abstract compilationallows programmers to reason about their code (eg about correctness of refactoring) byonly considering interactions with other code from the same language While this is obviouslyan extremely valuable property for compilers it rules out linking with target code that hasfeatures or restrictions that can not be represented in the source language that is beingcompiled

While traditionally fully abstract compilation and flexible linking have been thoughtto be at odds Irsquoll present a novel idea called Linking Types [1] that allows us to bringthem together by enabling a programmer to opt into local violations of full abstractiononly when she needs to link with particular code without giving up the property globallyThis fine-grained mechanism enables flexible interoperation with low-level features whilepreserving the high-level reasoning principles that fully abstract compilation offers

An open question is whether algebraic effects and effect handlers might be an effectiveway of designing linking-types extensions for existing languages

References1 Daniel Patterson and Amal Ahmed Linking Types for Multi-Language Software Have

Your Cake and Eat It Too In Summit on Advances in Programming Languages (SNAPL)2017

32 Idealised AlgolRobert Atkey (University of Strathclyde ndash Glasgow GB)

License Creative Commons BY 30 Unported licensecopy Robert Atkey

Joint work of Robert Atkey Michel Steuwer Sam Lindley Christophe DubachMain reference Robert Atkey Michel Steuwer Sam Lindley Christophe Dubach ldquoStrategy Preserving

Compilation for Parallel Functional Coderdquo CoRR Vol abs171008332 2017URL httpsarxivorgabs171008332

Idealised Algol was introduced by John Reynolds in the late 1970s as the orthogonalcombination of λ-calculus and imperative programming The resulting language is anelegant combination of imperative programming (variables while loops etc) and procedures(provided by λ-abstraction) A variant of Idealised Algol called Syntactic Control of

Interference provides a way to banish aliasing within the language and hence to provide away to express race free parallelism

In this talk I discussed the similarities between Idealised Algolrsquos expressive handlingof variables and mutable state in particular Reynoldsrsquo conception of variables asldquoobjectsrdquoconsisting of a getter and a setter and handlers for algebraic effects Idealised Algol appears tonaturally include a particularly efficient subset of handlers linear handlers (the continuationmust always be used) that are tail recursive By sticking to this subset it is possible togenerate efficient code without expensive stack manipulation

Some of this work is joint with Sam Lindley Michel Steuwer and Christophe Dubachwhere we have applied Idealised Algol with interference control to the problem of generatingcode from functional specifications for execution on parallel computing hardware such asmulticore processors and GPUs

33 What is algebraic about algebraic effects and handlersAndrej Bauer (University of Ljubljana SI)

License Creative Commons BY 30 Unported licensecopy Andrej Bauer

In this tutorial we reviewed the classic treatment of algebraic theories and their modelsin the category of sets We then drew an uninterrupted line of thought from the classicaltheory to algebraic effects and handlers First we generalized operations with integralarities to parameterized operations with arbitrary arities as these are needed for modelingcomputational effects The free models of theories with generalized operations can be usedas denotations of effectful programs The universal property of a free models can be used toderive the notion of handlers At the level of types the value types correspond to sets ofgenerators and the computation types to the free models The naive set-theoretic treatmentpresented in the tutorial should be replaced with a domain-theoretic one if we wantedadequate denotational semantics of a realistic programming language with general recursionThe contents of the tutorial has been written up an extended in [1]

References1 Andrej Bauer What is algebraic about algebraic effects and handlers ArXiv e-print

180705923 2018 httpsarxivorgabs180705923

34 Event Correlation with Algebraic EffectsOliver Bracevac (TU Darmstadt DE)

License Creative Commons BY 30 Unported licensecopy Oliver Bracevac

Joint work of Oliver Bracevac Nada Amin Guido Salvaneschi Sebastian Erdweg Patrick Eugster Mira MeziniMain reference Oliver Bracevac Nada Amin Guido Salvaneschi Sebastian Erdweg Patrick Eugster Mira Mezini

ldquoVersatile Event Correlation with Algebraic Effectsrdquo Proc ACM Program Lang Vol 2pp 671ndash6731 ACM 2018

URL httpdxdoiorg1011453236762

This talk presents a language design on top of algebraic effects and handlers for definingn-way joins over asynchronous event sequences The design enables mix-and-match-stylecompositions of join variants from different domains eg stream-relational algebra event

processing reactive and concurrent programming where joins are defined in direct stylepattern notation Their matching behavior is programmable via dedicated control abstractionsfor coordinating and aligning asynchronous streams Our insight is that semantic variantsof joins are definable as cartesian product computations with side effects influencing howthe computation unravels Based on this insight we can afford working with a naiveenumeration procedure of the cartesian product and turn it into efficient variants byinjection of appropriate effect handlers

35 Effect Handlers for the MassesJonathan Immanuel Brachthaumluser (Universitaumlt Tuumlbingen DE)

License Creative Commons BY 30 Unported licensecopy Jonathan Immanuel Brachthaumluser

Joint work of Jonathan Immanuel Brachthaumluser Philipp Schuster Klaus OstermannMain reference Jonathan Immanuel Brachthaumluser Philipp Schuster Klaus Ostermann ldquoEffect Handlers for the

Massesrdquo under submission at the Conference on Object Oriented Programming Systems Languagesamp Applications Boston USA 2018

Algebraic effect handlers are a program structuring paradigm with rising popularity inthe functional programming language community Effect handlers are less wide-spread inthe context of imperative object oriented languages We present library implementationsof algebraic effects in Scala and Java Both libraries are centered around the concept ofhandlercapability passing and a shallow embedding of effect handlers While the Scalalibrary is based on a monad for multi-prompt delimited continuations the Java libraryperforms a CPS translation as bytecode instrumentation We discuss design decisions andimplications on extensibility and performance

References1 Jonathan Immanuel Brachthaumluser Philipp Schuster Effekt Extensible Algebraic Effects

in Scala Proceedings of the 8th ACM SIGPLAN International Symposium on Scala Van-couver Canada 2017

2 Jonathan Immanuel Brachthaumluser Philipp Schuster Effect Handlers for the Masses Undersubmission at the Conference on Object Oriented Programming Systems Languages ampApplications Boston USA 2018

36 Combining Algebraic TheoriesJeremy Gibbons (University of Oxford GB)

License Creative Commons BY 30 Unported licensecopy Jeremy Gibbons

Joint work of Kwok Cheung Jeremy Gibbons

I summarized results due to Hyland Plotkin and Power [5 6] on combining algebraic theoriesas explored in the doctoral thesis [2] of my student Kwok Cheung Specifically the sumS + T of algebraic theories S and T has all the operations of S and T and all the equationsand no other equations The commutative tensor S otimes T adds equations of the form

f(g(x1 x2) g(y1 y2) g(z1 z2)) = g(f(x1 y1 z1) f(x2 y2 z2))

for each operation f of one theory and g of the other The distributive tensor S T adds tothe sum equations of the form

f(g(x1 x2) y z) = g(f(x1 y z) f(x2 y z))f(x g(y1 y2) z) = g(f(x y1 z) f(x y2 z))f(x y g(z1 z2)) = g(f(x y z1) f(x y z2))

for each operation f of S and g of T I also showed some examplesglobal state S rarr (1 +minus)times S arises as the sum of the theories State and Failurelocal state S rarr 1 + (minustimes S) arises as the commutative tensor State otimes Failureprobability and nondeterminism interact via probabilistic choice woplus distributing overnondeterministic choice but not vice versa so arises as the distributive tensor Prob Nondettwo-player games have both angelic choice t and demonic choice u each of whichdistributes over the other so arises as the two-way distributive tensor Nondet Nondet

and some non-examplesthe list monad does not arise as any of these combinations of the theories Nondet (iejust binary choice with associativity) and Failurethe list transformer done right [3] applied to the monad arising from some theory T doesnot arise as any of these combinations of the monoidal theory of the list monad with T symmetric bidirectional transformations [4] maintain two complementary data sources Aand B in synchronization they have the signature of two copies of the theory of Statebut the two implementations are entangled [1]mdashthe lsquogetrsquo operations of A and B commutewith each other but the lsquosetrsquo operation on one side does not commute with any operationon the the other

I conjecture there are more such well-behaved and useful combinators on algebraic theoriesto be found which might explain the above counter-examples and others like them

References1 Faris Abou-Saleh James Cheney Jeremy Gibbons James McKinna and Perdita Stevens

Notions of bidirectional computation and entangled state monads In Ralf Hinze and JanisVoigtlaumlnder editors Mathematics of Program Construction volume 9129 of Lecture Notesin Computer Science pages 187ndash214 Springer 2015

2 Kwok Cheung Distributive Interaction of Algebraic Effects Dphil thesis University ofOxford 2018

3 Yitzhak Gale ListT done right httpswikihaskellorgListT_done_right 20074 Martin Hofmann Benjamin C Pierce and Daniel Wagner Symmetric lenses In Thomas

Ball and Mooly Sagiv editors Principles of Programming Languages pages 371ndash384 ACM2011

5 Martin Hyland Gordon D Plotkin and John Power Combining effects Sum and tensorTheoretical Computer Science 357(1-3)70ndash99 2006

6 Martin Hyland and John Power Discrete Lawvere theories and computational effectsTheoretical Computer Science 366(1-2)144ndash162 2006

37 HandlersJs A Comparative Study of Implementation Strategiesfor Effect Handlers on the Web

Daniel Hillerstroumlm (University of Edinburgh GB)

License Creative Commons BY 30 Unported licensecopy Daniel Hillerstroumlm

Joint work of Sam Lindley Robert Atkey KC Sivaramakrishnan Jeremy Yallop

Handlers for algebraic effects have steadily been gaining traction since their inception Thistraction can be partly attributed to their wide application space which includes diverseprogramming disciplines such as concurrent programming probabilistic programming etcThey have been implemented in a variety of programming languages as either a nativeprimitive or embedded via existing abstraction facilities

The many different implementations have contributed to mapping out the implementationspace for effect handlers While the picture for how to implement effect handlers in nativecode is pretty clear the picture for implementing effect handlers via embedding in high-levelprogramming languages is more blurry Embedding in JavaScript is currently the only viableoption for implementing effect handlers on the Web

In this talk I will discuss and compare five viable different compilation strategies foreffect handlers to JavaScript Two of the five strategies are based on novel encodings viageneratorsiterators and generalised stack inspection respectively Although I will discussthese compilation strategies in the context of JavaScript they are not confined to JavaScriptThe strategies are also viable in other high-level languages such as say Python

38 First Class Dynamic Effect Handlers and Deep Finally HandlingDaan Leijen (Microsoft Research ndash Redmond US)

License Creative Commons BY 30 Unported licensecopy Daan Leijen

Main reference Daan Leijen ldquoFirst Class Dynamic Effect Handlersrdquo in TyDersquo18 St Louis US Sep 2018URL httpswwwmicrosoftcomen-usresearchpublicationfirst-class-dynamic-effect-handlers

We first show how ldquoinjectrdquo combined with higher-ranked types can encode first-class poly-morphic references However it is cumbersome to program this way as you need to ldquoinjectrdquocarefully to select the right handler by position To remedy this we extend basic algebraiceffect handlers with first class dynamic effects to refer to a handler directly by name Dynamiceffects add a lot more expressiveness but surprisingly only need minimal changes to theoriginal semantics As such dynamic effects are a powerful abstraction but can still beunderstood and reasoned about as regular effect handlers We illustrate the expressiveness ofdynamic effects with first class event streams in CorrL and also model full polymorphic heapreferences without requiring any further primitives Following this we add ldquofinallyrdquo andldquoinitiallyrdquo clauses to handlers to robustly deal with external resources We show you generallyneed a form of ldquodeeprdquo finally handling to reliably invoke all outstanding ldquofinallyrdquo clauses

Note the original title of the talk was ldquoAlgebraic Effects with Resources and DeepFinalizationrdquo However it was decided afterwards this naming caused too much confusionldquoResourcesrdquo was already used for external resources in Matijarsquos thesis and ldquoFinalizationrdquoreminded of finalization in the object oriented world which is invoked by the GC andnon-deterministic

39 Encapsulating effectsSam Lindley (University of Edinburgh GB)

License Creative Commons BY 30 Unported licensecopy Sam Lindley

391 Leaking effects

Naively composing effect handlers that produce and consume an intermediate effect leads tothat effect leaking such that external instances are accidentally captured I illustrate theproblem in Frank and then show how Biernacki et alrsquos lift operator resolves the issue I thenbriefly discuss other possible solutions

For the following I assume basic familiarity with the Frank programming language [6]Let us begin by defining in Frank a maybe data type reader and abort interfaces along witheffect handlers for them

data Maybe X = nothing | just X

interface Reader X = ask Xinterface Abort = abort X X

reads List S -gt ltReader SgtX -gt [Abort]Xreads [] ltask -gt kgt = abortreads (s ss) ltask -gt kgt = reads ss (k s)reads _ x = x

maybe ltAbortgtX -gt Maybe Xmaybe ltabort -gt _gt = nothingmaybe x = just x

The reads handler interprets the ask command by reading the next value if there is onefrom the supplied list if the list is empty then it raises the abort command The maybehandler interprets abort using the maybe data type

It seems natural to want to precompose maybe with reads A naive attempt yields thefollowing Frank code

bad List S -gt ltReader S AbortgtX -gt Maybe Xbad ss ltmgt = maybe (reads ss m)

The bad handler handles ask as expected yielding just v for some value v if input isnot exhausted

bad [123] (ask + ask + ask) == just 6

and nothing if input is exhausted

bad [12] (ask + ask + ask) == nothing

Alas as indicated by its type bad also exhibits additional behaviour As well as handlingany abort command raised by the reads handler it also captures uses of abort from theambient context

bad [123] (ask + ask + abort) == nothing

One might think that we could simply supply a different type signature to bad in orderto suppress Abort But the underlying problem is not with the types it is with the dynamicsemantics Without some way of hiding the Abort effect there is no way of preventingthe maybe handler from accidentally capturing any abort command raised by the ambientcontext

The current version of Frank (April 2018) provides a solution to the effect encapsulationproblem Biernacki et alrsquos lift operator [3] with which we can precompose maybe withreads as follows

good List S -gt ltReader SgtX -gt Maybe Xgood ss ltmgt = maybe (reads ss (lift ltAbortgt m))

An effect (ability in Frank parlance) in Frank (much like Koka [5]) denotes a total map frominterface names to finite lists of instantiations Interfaces that are not present are denotedby empty lists The head of a list denotes the active instantiation of an interface Thelift operator adds a dummy instantiation onto the head of the list associated with a giveninterface Thus the invocation lift ltAbortgt m adds a dummy instantiation of Abort ontothe ability associated with the computation m The dummy instantiation ensures that themaybe handler cannot accidentally capture abort commands raised by the ambient contextSo

good [123] (ask + ask + abort) [Abort]Maybe Int

maybe (good [123] (ask + ask + abort)) == nothing

The lift operator provides a means for hiding effects reminiscent of de Bruijn represen-tations for bound names It generates a fresh instantiation of an interface by shifting all ofthe existing instances along by one

392 Concurrency

In his Masterrsquos dissertation Lukas Convent identified the effect encapsulation problem inthe context of a previous version of Frank [4] that did not provide support for lift Hepresents a number of examples of trying to compose effect handlers together in order toimplement various forms of concurrency The resulting types expose many of the internalimplementation details illustrating how important the problem is to solve

To illustrate how lift helps to solve these problems I include an adaptation of codefrom Conventrsquos thesis to implement Erlang-style concurrency based on an actor abstractionin Frank by composing together a number of different handlers The adapted code takesadvantage of lift

include prelude

-------------------------------------------------------------------------------- Queue interface and FIFO implementation using a zipper------------------------------------------------------------------------------

interface Queue S = enqueue S -gt Unit| dequeue Maybe S

-- zipper queuedata ZipQ S = zipq (List S) (List S)

emptyZipQ ZipQ SemptyZipQ = zipq [] []

-- FIFO queue implementation using a zipper-- (returns the remaining queue alongside the final value)runFifo ZipQ S -gt ltQueue SgtX -gt Pair X (ZipQ S)runFifo (zipq front back) ltenqueue x -gt kgt = runFifo (zipq front (x back)) (k unit)runFifo (zipq [] []) ltdequeue -gt kgt = runFifo emptyZipQ (k nothing)runFifo (zipq [] back) ltdequeue -gt kgt = runFifo (zipq (rev back) []) (k dequeue)runFifo (zipq (x front) back) ltdequeue -gt kgt = runFifo (zipq front back) (k (just x))runFifo queue x = pair x queue

-- discard the queueevalFifo ltQueue SgtX -gt ZipQ S -gt XevalFifo lttgt q = case (runFifo q t) (pair x _) -gt x

-- start with an empty queuefifo ltQueue SgtX -gt Xfifo ltmgt = evalFifo m (emptyZipQ)

-- discard the valueexecFifo ltQueue SgtX -gt ZipQ S -gt ZipQ SexecFifo lttgt q = case (runFifo q t) (pair _ q) -gt q

---------------------------------------------------------------------------------- Definitions of interfaces data types--------------------------------------------------------------------------------

interface Co = fork [Co]Unit -gt Unit| yield Unit

data Mailbox X = mbox (Ref (ZipQ X))

interface Actor X = self Mailbox X| spawn Y [Actor Y]Unit -gt Mailbox Y| recv X| send Y Y -gt Mailbox Y -gt Unit

data WithSender X Y = withSender (Mailbox X) Y

---------------------------------------------------------------------------------- Example actor--------------------------------------------------------------------------------

spawnMany Mailbox Int -gt Int -gt [Actor Int [Console] Console]UnitspawnMany p 0 = send 42 pspawnMany p n = spawnMany (spawn let x = recv in print send x p) (n-1)

chain [Actor Int [Console] Console]Unitchain = spawnMany self 640 recv print n

-------------------------------------------------------------------------------- Implement an actor computation as a stateful concurrent computation------------------------------------------------------------------------------

-- Our syntactic sugar assumes that all instances of the implicit-- effect variable are instantiated to be the same but they neednrsquot be-- the same as the ambient effects---- For liftBody we need exactly that all but the ambient effects be-- the sameliftBody [Actor X]Unit -gt [E |][Actor X Co [RefState] RefState]UnitliftBody m = lift ltRefState Cogt m

act Mailbox X -gt ltActor XgtUnit -gt [Co [RefState] RefState]Unit

act mine ltself -gt kgt = act mine (k mine)act mine ltspawn you -gt kgt = let yours = mbox (new (emptyZipQ)) in

fork act yours (liftBody you)act mine (k yours)

act (mbox m) ltrecv -gt kgt = case (runFifo (read m) dequeue) (pair nothing _) -gt yield

act (mbox m) (k recv)| (pair (just x) q) -gt write m q

act (mbox m) (k x) act mine ltsend x (mbox m) -gt kgt = let q = execFifo (enqueue x) (read m) in

write m qact mine (k unit)

act mine unit = unit

runActor ltActor XgtUnit -gt [RefState]UnitrunActor ltmgt = bfFifo (act (mbox (new emptyZipQ)) (lift ltCogt m))

bfFifo ltCogtUnit -gt UnitbfFifo ltmgt = fifo (scheduleBF (lift ltQueuegt m))

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

data Proc = proc [Queue Proc]Unit

enqProc [Queue Proc]Unit -gt [Queue Proc]UnitenqProc p = enqueue (proc p)

runNext [Queue Proc]UnitrunNext = case dequeue (just (proc x)) -gt x

| nothing -gt unit

-- defer forked processes (without effect pollution)scheduleBF ltCogtUnit -gt [Queue Proc]UnitscheduleBF ltyield -gt kgt = enqProc scheduleBF (k unit)

runNextscheduleBF ltfork p -gt kgt = enqProc scheduleBF (lift ltQueuegt p)

scheduleBF (k unit)scheduleBF unit = runNext

-- eagerly run forked processesscheduleDF ltCogtUnit -gt [Queue Proc]UnitscheduleDF ltyield -gt kgt = enqProc scheduleDF (k unit)

runNextscheduleDF ltfork p -gt kgt = enqProc scheduleDF (k unit)

scheduleDF (lift ltQueuegt p)scheduleDF unit = runNext

main [Console RefState]Unitmain = runActor (lift ltRefStategt chain)

This code implements actors using a coroutining concurrency interface which in turnis implemented using an interface for queues of processes which are implemented using asimple zipper data structure The example chain spawns a collection of processes and passesa message through the entire collection

The crucial point is that the type of runActor mentions only the Actor interface thatis being handled and the RefState interface that is being used to implement it Conventrsquosoriginal code leaks out the Queue interface and the Co interface Moreover the type becomesparticularly hard to read because some of the interfaces are parameterised by several effects

393 Discussion

The designers of the Eff programming language [2] have explored several different designsfor effect handlers and effect type systems for effect handlers Some versions of Eff providefeatures that address the effect encapsulation problem to some degree The earliest versionof Eff [1] resolved the encapsulation problem by supporting the generation of fresh instancesof an effect This was relatively straightforward as at the time Eff did not provide an effecttype system A later version of Eff included a somewhat complicated effect type system withsupport for instances that used a region-like effect type system [7] The latest version ofEff at the time of writing [8] does not appear to offer a solution to the effect encapsulationproblem It provides an effect type system with subtyping without duplicate effect interfacesand no support for effect instances

For effect systems that allow only one copy of each effect interface we might solve theeffect encapsulation problem by adding a primitive for introducing a fresh copy of an interfaceFor instance to hide the intermediate Abort interface we could generate a fresh copy ofAbort ndash call it Abortrsquo ndash which we could then use to rename any abort commands in theambient context to abortrsquo before renaming them back after running the reads and maybehandlers

An as yet unimplemented Frank feature that is related to effect encapsulation is negativeadjustments [6] Currently an adjustment in Frank always adds interfaces to the ambientability and specifies which interfaces must be handled Negative adjustments would allowinterfaces to be removed enabling the programmer to specify that a computation beinghandled does not support some of the interfaces in the ambient Roughly the lift operationis the inverse of a negative adjustment It remains to be seen what the relative pros andcons of negative adjustments and lift are in practice

More generally there is a broad design space for effect type systems that support effectencapsulation and it is worth considering the full range of options

References1 Andrej Bauer and Matija Pretnar Programming with algebraic effects and handlers J

Log Algebr Meth Program 84(1)108ndash123 20152 Andrej Bauer and Matija Pretnar Eff 20183 Dariusz Biernacki Maciej Piroacuteg Piotr Polesiuk and Filip Sieczkowski Handle with care

relational interpretation of algebraic effects and handlers PACMPL 2(POPL)81ndash8302018

4 Lukas Convent Enhancing a modular effectful programming language Masterrsquos thesisThe University of Edinburgh Scotland 2017

5 Daan Leijen Type directed compilation of row-typed algebraic effects In POPL pages486ndash499 ACM 2017

6 Sam Lindley Conor McBride and Craig McLaughlin Do be do be do In POPL pages500ndash514 ACM 2017

7 Matija Pretnar Inferring algebraic effects Logical Methods in Computer Science 10(3)2014

8 Amr Hany Saleh Georgios Karachalias Matija Pretnar and Tom Schrijvers Explicit effectsubtyping In ESOP volume 10801 of Lecture Notes in Computer Science pages 327ndash354Springer 2018

310 Experiences with structuring effectful code in HaskellAndres Loumlh (Well-Typed LLP DE)

License Creative Commons BY 30 Unported licensecopy Andres Loumlh

Effectful Haskell code that is written using monad transformers can easily become difficultto maintain However it is unclear whether algebraic effects doenot suffer from the sameproblem Both approaches seem to encourage specifying a minimal amount of effects foreach code fragment leading to effect constraints being propagated in a bottom-up fashionthroughout the program often without much thought for control In this talk I argue thatsometimes it is better to be less general by identifying just a few meaningful interfaces ina program corresponding to different sets of available effects and keeping testing in mindThese interfaces are then pushed down and code is merely checked to not use effects thatare outside of the allowed subset

311 Make Equations Great AgainMatija Pretnar (University of Ljubljana SI)

License Creative Commons BY 30 Unported licensecopy Matija Pretnar

Joint work of Žiga Lukšič Matija Pretnar

Algebraic effects have originally been presented with equational theories ie a set ofoperations and a set of equations they satisfy Since a significant portion of computationallyinteresting handlers overrides the effectful behaviour in a way that invalidates the equationsmost approaches nowadays assume an empty set of equations

At the Dagstuhl Seminar 16112 I presented an idea in which the equations are representedlocally in computation types [1] In this way handlers that do not respect all equationsare not rejected but receive a weaker type In the talk I presented the progress made andquestions that remain open

References1 Matija Pretnar Capturing algebraic equations in an effect system In Dagstuhl Seminar

16112 pages 55ndash57 2016 DOI 104230DagRep6344

312 Quirky handlersMatija Pretnar (University of Ljubljana SI) and Žiga Lukšič (University of Ljubljana SI)

License Creative Commons BY 30 Unported licensecopy Matija Pretnar and Žiga Lukšič

Programming language terms are usually represented with an inductive type that lists alltheir possible constructors It turns out that most functions on such a type are routine Forexample the set of free variables in a given arithmetic expression is almost always the unionof free variables in subterms (except if the expression itself is a variable) Still we must treatevery single case in the function definition and this quickly becomes annoying

There are many ways in which this problem can be avoided for example using openrecursion or type classes In the talk we will see how to use handlers to define such functionswith as little boilerplate as possible yet ensure that the compiler forces us to revisit eachpart of the code when the type definition changes

313 What is coalgebraic about algebraic effects and handlersMatija Pretnar (University of Ljubljana SI)

In this tutorial we reviewed the work of Gordon Plotkin and John Power [1] in whichthey proposed comodels of algebraic theories and tensoring of comodels and models as amathematical model for the interaction of an effectful program with its external environmentA comodel of a theory T in a category C is a model of T in the opposite category Cop andthe category of comodels in C is the opposite of the category of models in Cop We maydefine the tensor M otimesW of a comodel W and a model M which is a certain quotient ofthe product M timesW A pair (p w) isinM timesW may be viewed as a program p running in theexternal environment w The comodel W provides resources needed for execution of algebraicoperations in M In the tutorial we emphasized the fact that comodels and tensoring are amore appropriate model of top-level behavior of effectful program than various notions ofldquotop-levelrdquo or ldquodefaultrdquo handlers A handler has access to the continuation but at the toplevel this is not the case or else programs would be able to control the external world Ithas to be the other way around

References1 Gordon D Plotkin and John Power Tensors of comodels and models for operational

semantics Electronic Notes in Theoretical Computer Science 218295ndash311 2008

314 Effect Handlers for WebAssembly (Show and Tell)Andreas Rossberg (Dfinity Foundation CH)

License Creative Commons BY 30 Unported licensecopy Andreas Rossberg

Integrating effects into Wasm involves a number of complications that do not exist inmore high-level (and purer) languages For example the presence of branches interactsin interesting ways with try blocks handlers and continuations It necessitates a stricterdistinction between exceptions and effects That in turn complicates the semantics and itsformalisation

We worked out a the semantics for handlers in Wasm as an extension to the existingproposal for exception handling The next far more challenging step will be to implementthem in a production engine in order to validate their practical feasibility and evaluate theirreal-world performance

315 Neither Web Nor AssemblyAndreas Rossberg (Dfinity Foundation CH)

WebAssembly (or ldquoWasmrdquo) [1] is a portable high-performance code format that has beendesigned not just for the Web but for a broad range of embedding environments Itis standardised and fully formalised using well-established techniques from programminglanguage theory Version 1 of WebAssembly which is currently available was deliberatelylimited in scope to encompass low-level programming languages such as C++ For the nextstage more support for high-level languages will be added

One central requirement is the ability to express the large variety of control abstractionsthat appear in high-level languages such as coroutines light-weight threads generators andasynchronous computations At the lowest level their commonality is the need to ldquoswitchstacksrdquo However ad-hoc mechanisms for doing so are inadequate for WebAssembly due toits nature of a code format that must be sufficiently high-level to guarantee safety and dueto the desire to maintain a high-assurance formal specification That asks for a primitivewith strong semantic foundations

Effect handlers would fit the bill perfectly But it is an open question how exactly they canbe designed in the context of a low-level stack machine and whether they can be implementedefficiently under the constraints imposed on existing WebAssembly implementations

References1 A Haas A Rossberg D Schuff B Titzer D Gohman L Wagner A Zakai JF Bastien

M Holman Bringing the Web up to Speed with WebAssembly PLDI 2017

316 Efficient Compilation of Algebraic Effects and HandlersTom Schrijvers (KU Leuven BE)

License Creative Commons BY 30 Unported licensecopy Tom Schrijvers

Joint work of Amr Hany Saleh Axel Faes Georgios Karachalias Matija Pretnar Tom Schrijvers

The popularity of algebraic effect handlers as a programming language feature for user-definedcomputational effects is steadily growing Yet even though efficient runtime representationshave already been studied most handler-based programs are still much slower than hand-written code

In this paper we show that the performance gap can be drastically narrowed (in somecases even closed) by means of type-and-effect directed optimising compilation Our approachconsists of two stages Firstly we combine elementary source-to-source transformationswith judicious function specialisation in order to aggressively reduce handler applicationsSecondly we show how to elaborate the source language into a handler-less target languagein a way that incurs no overhead for pure computations

This work comes with a practical implementation an optimizing compiler from Eff anML style language with algebraic effect handlers to OCaml Experimental evaluation withthis implementation demonstrates that in a number of benchmarks our approach eliminatesmuch of the overhead of handlers and yields competitive performance with hand-writtenOCaml code

317 Algebraic effects ndash specification and refinementWouter Swierstra (Utrecht University NL)

License Creative Commons BY 30 Unported licensecopy Wouter Swierstra

How should we reason about programs written with algebraic effects As the meaning of aprogram is determined by its handlers we need a way to specify the intended behaviour ofhandlers In this talk I sketched an approach based on predicate transformers that enablesthe calculation of effectful programs from their specification

318 Adding an effect system to OCamlLeo White (Jane Street ndash London GB)

License Creative Commons BY 30 Unported licensecopy Leo White

Joint work of Stephen Dolan Matija Pretnar Sivaramakrishnan Krishnamoorthy Chandrasekaran DanielHillerstroumlm

Type systems designed to track the side-effects of expressions have been around for manyyears but they have yet to breakthrough into more mainstream programming languagesThis talk focused on on-going work to add an effect system to OCaml

This effect system is primarily motivated by the desire to keep track of algebraic effects inthe OCaml type system Through the Multicore OCaml project support for algebraic effectsis likely to be included in OCaml in the near future However the effect system also allowsfor tracking side-effects more generally It distinguishes impure functions which performside-effects from pure functions which do not It also includes a tracked form of exceptionto support safe and efficient error handling

This talk gave an overview of the effect system and demonstrated a prototype implemen-tation on some practical examples

319 Multi-Stage Programming with Algebraic EffectsJeremy Yallop (University of Cambridge GB)

License Creative Commons BY 30 Unported licensecopy Jeremy Yallop

I showed how algebraic effects and handlers are useful in multi-stage programming (a kindof programmer-directed annotation-driven form of partial evaluation) There is a longtradition of using continuations and continuation-passing style to improve the results ofpartial evaluation and multi-stage programming [4 3] However algebraic effects and handlerslead to a particularly elegant formulation of various transformations of the code generatedby multi-stage programs

The running example in the talk was the staging of a standard functional program ndash typedprintfscanf [1] mdash using BER MetaOCamlrsquos staging facilities [3] and Multicore OCamlrsquosimplementation of effects [2] While naively staging the program produces some performanceimprovements the generated code is still sub-optimal Several transformations convenientlyexpressed using algebraic effects significantly improve the output

let insertion untangles nested computationsnormalization of destructuring let bindings avoids repeated tupling and detuplinginsertion of branches into the generated code exposes information about future-stagevalues in each branch (such as whether a boolean variable will have the value true orfalse in a particular region of the program) enabling further optimizations This lasttransformation makes essential use of multi-shot continuations

Some of these techniques are described in more detail in recent work [5]

References1 O Danvy Functional unparsing J Funct Program 8(6)621ndash625 Nov 19982 S Dolan L White K Sivaramakrishnan J Yallop and A Madhavapeddy Effective con-

currency through algebraic effects OCaml Users and Developers Workshop 2015 Septem-ber 2015

3 O Kiselyov The design and implementation of BER metaocaml ndash system descriptionIn Functional and Logic Programming ndash 12th International Symposium FLOPS 2014Kanazawa Japan June 4-6 2014 Proceedings pages 86ndash102 2014

4 J L Lawall and O Danvy Continuation-based partial evaluation SIGPLAN Lisp PointersVII(3)227ndash238 July 1994

5 J Yallop Staged generic programming Proc ACM Program Lang 1(ICFP)291ndash2929Aug 2017

4 Working groups

41 Denotational Semantics for Dynamically Generated EffectsRobert Atkey (University of Strathclyde ndash Glasgow GB)

We discussed a possible worlds functor category semantics for a simple language withdynamically generated effect names and handlers In this semantics types are indexed byeffect signatures describing the set of possible effect names in scope and computationsare given a semantics in terms of a monad that supports rsquofreersquo operations from the currenteffect signature world and the possible generation of new effect names in the style of Starkrsquosmonads for name generation Some interesting program equivalences were also discussedand it was noted that they depend on whether or not effect names can ldquoleakrdquo out of theirscope usually via higher-order state The encoding of ML-style references using handlerswas also discussed This requires that the ldquoaritiesrdquo of effects can also include effect names

42 Reasoning with EffectsJeremy Gibbons (University of Oxford GB)

We discussed a number of topics around the equations of algebraic effects and handlersgeneral concerns about the equations of an algebraic theory often being ignoredshould the equations be thought of as being attached to the operations of a theory or tothe handler(s) for that theorywhere do the equations come from the programmerrsquos intentions QuickCheck explorationof the properties of a handler

Participants

Amal AhmedNortheastern University ndashBoston US

Robert AtkeyUniversity of Strathclyde ndashGlasgow GB

Lennart AugustssonX Inc ndash Mountain View US

Andrej BauerUniversity of Ljubljana SI

Oliver BracevacTU Darmstadt DE

Jonathan ImmanuelBrachthaumluserUniversitaumlt Tuumlbingen DE

Edwin BradyUniversity of St Andrews GB

Stephen DolanUniversity of Cambridge GB

Jeremy GibbonsUniversity of Oxford GB

Daniel HillerstroumlmUniversity of Edinburgh GB

Mauro JaskelioffNational University ofRosario AR

Ohad KammarUniversity of Oxford GB

Andrew KennedyFacebook ndash London GB

Oleg KiselyovTohoku University ndash Sendai JP

SivaramakrishnanKrishnamoorthy ChandrasekaranUniversity of Cambridge GB

Daan LeijenMicrosoft Research ndashRedmond US

Sam LindleyUniversity of Edinburgh GB

Andres LoumlhWell-Typed LLP DE

Žiga LukšičUniversity of Ljubljana SI

Anil MadhavapeddyDocker Inc ndash Cambridge GB

Conor McBrideUniversity of Strathclyde ndashGlasgow GB

Adriaan MoorsLightbend Inc ndashLausanne CH

Matija PretnarUniversity of Ljubljana SI

Andreas RossbergDfinity Foundation CH

Tom SchrijversKU Leuven BE

Perdita StevensUniversity of Edinburgh GB

Wouter SwierstraUtrecht University NL

Leo WhiteJane Street ndash London GB

Nicolas WuUniversity of Bristol GB

Jeremy YallopUniversity of Cambridge GB

Executive Summary Sivaramakrishnan Krishnamoorthy Chandrasekaran Daan Leijen Matija Pretnar and Tom Schrijvers

Contents

Overview of Talks

Linking Types for Multi-Language Software Amal Ahmed

Idealised Algol Robert Atkey

What is algebraic about algebraic effects and handlers Andrej Bauer

Event Correlation with Algebraic Effects Oliver Bracevac

Effect Handlers for the Masses Jonathan Immanuel Brachthaumluser

Combining Algebraic Theories Jeremy Gibbons

HandlersJs A Comparative Study of Implementation Strategies for Effect Handlers on the Web Daniel Hillerstroumlm

First Class Dynamic Effect Handlers and Deep Finally Handling Daan Leijen

Encapsulating effects Sam Lindley

Experiences with structuring effectful code in Haskell Andres Loumlh

Make Equations Great Again Matija Pretnar

Quirky handlers Matija Pretnar and Žiga Lukšic

What is coalgebraic about algebraic effects and handlers Matija Pretnar

Effect Handlers for WebAssembly (Show and Tell) Andreas Rossberg

Neither Web Nor Assembly Andreas Rossberg

Efficient Compilation of Algebraic Effects and Handlers Tom Schrijvers

Algebraic effects ndash specification and refinement Wouter Swierstra

Adding an effect system to OCaml Leo White

Multi-Stage Programming with Algebraic Effects Jeremy Yallop

Working groups

Denotational Semantics for Dynamically Generated Effects Robert Atkey

Reasoning with Effects Jeremy Gibbons

Participants

1 Executive Summary

Sivaramakrishnan Krishnamoorthy Chandrasekaran (University of Cambridge GB)Daan Leijen (Microsoft Research ndash Redmond US)Matija Pretnar (University of Ljubljana SI)Tom Schrijvers (KU Leuven BE)

License Creative Commons BY 30 Unported licensecopy Sivaramakrishnan Krishnamoorthy Chandrasekaran Daan Leijen Matija Pretnar andTom Schrijvers

Algebraic effects and their handlers have been steadily gaining attention as a programminglanguage feature for composably expressing user-defined computational effects Algebraiceffect handlers generalise many control-flow abstractions such as exception handling iteratorsasyncawait or backtracking and in turn allow them to be expressed as libraries ratherthan implementing them as primitives as many language implementations do While severalprototype languages that incorporate effect handlers exist they have not yet been adoptedinto mainstream languages This Dagstuhl Seminar 18172 ldquoAlgebraic Effect Handlers GoMainstreardquo touched upon various topics that hinder adoption into mainstream languagesTo this end the participants in this seminar included a healthy mix of academics who studyalgebraic effects and handlers and developers of mainstream languages such as HaskellOCaml Scala WebAssembly and Hack

This seminar follows the earlier wildly successful Dagstuhl Seminar 16112 ldquoFrom Theoryto Practice of Algebraic Effects and Handlersrdquo which was dedicated to addressing fundamentalissues in the theory and practice of algebraic effect handlers We adopted a similar structurefor this seminar We had talks each day in the morning scheduled a few days ahead Thefolks from the industry were invited to present their perspectives on some of the challengesthat could potentially be address with the help of effect handlers The afternoons wereleft free for working in self-organised groups and show-and-tell sessions with results fromthe previous days We also had impromptu lectures on the origins of algebraic effects andhandlers which were quite well received and one of the highlights of the seminar

Between the lectures and working-in-groups the afternoons were rather full Hence afew participants offered after-dinner ldquocheesy talksrdquo just after the cheese was served in theevening The participants were treated to entertaining talks over delightful cheese and finewine We encourage the organisers to leave part of the day unplanned and go with what theparticipants feel like doing on that day The serendipitous success are what makes DagstuhlSeminars special

We are delighted with the outcome of the seminar There were interesting discussionsaround the problem of encapsulation and leaking of effects in certain higher order use caseswith several promising solutions discussed It was identified that the problem of encapsulationand leaking effect names is analogous to the name binding in lambda calculus Anothergroup made significant progress in extending WebAssembly with support for effect handlersThe proposal builds on top of support for exceptions in WebAssembly During the seminarweek the syntax extensions and operational semantics were worked out with work begun onthe reference implementation During the seminar Andrej Bauer pointed out that severalprototype implementations that incorporate effect handlers exist each with their own syntaxand semantics This makes it difficult to translate ideas across different research groupsHence Andrej proposed and initiated effects and handlers rosetta stone ndash a repository ofexamples demonstrating programming with effects and handlers in various programminglanguages This repository is hosted on GitHub and has had several contributions duringand after the seminar

2 Contents

Overview of Talks

Working groups

Participants 125

3 Overview of Talks

391 Leaking effects

392 Concurrency

include prelude

---------------------------------------------------------------------------------- Example actor--------------------------------------------------------------------------------

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

| nothing -gt unit

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

2 Contents

Overview of Talks

Working groups

Participants 125

3 Overview of Talks

391 Leaking effects

392 Concurrency

include prelude

---------------------------------------------------------------------------------- Example actor--------------------------------------------------------------------------------

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

| nothing -gt unit

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

2 Contents

Overview of Talks

Working groups

Participants 125

3 Overview of Talks

391 Leaking effects

392 Concurrency

include prelude

---------------------------------------------------------------------------------- Example actor--------------------------------------------------------------------------------

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

| nothing -gt unit

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

Working groups

Participants 125

3 Overview of Talks

391 Leaking effects

392 Concurrency

include prelude

---------------------------------------------------------------------------------- Example actor--------------------------------------------------------------------------------

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

| nothing -gt unit

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

3 Overview of Talks

391 Leaking effects

392 Concurrency

include prelude

---------------------------------------------------------------------------------- Example actor--------------------------------------------------------------------------------

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

| nothing -gt unit

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

391 Leaking effects

392 Concurrency

include prelude

---------------------------------------------------------------------------------- Example actor--------------------------------------------------------------------------------

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

| nothing -gt unit

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

391 Leaking effects

392 Concurrency

include prelude

---------------------------------------------------------------------------------- Example actor--------------------------------------------------------------------------------

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

| nothing -gt unit

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

391 Leaking effects

392 Concurrency

include prelude

---------------------------------------------------------------------------------- Example actor--------------------------------------------------------------------------------

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

| nothing -gt unit

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

391 Leaking effects

392 Concurrency

include prelude

---------------------------------------------------------------------------------- Example actor--------------------------------------------------------------------------------

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

| nothing -gt unit

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

391 Leaking effects

392 Concurrency

include prelude

---------------------------------------------------------------------------------- Example actor--------------------------------------------------------------------------------

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

| nothing -gt unit

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

392 Concurrency

include prelude

---------------------------------------------------------------------------------- Example actor--------------------------------------------------------------------------------

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

| nothing -gt unit

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

---------------------------------------------------------------------------------- Example actor--------------------------------------------------------------------------------

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

| nothing -gt unit

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

-------------------------------------------------------------------------------- Scheduling------------------------------------------------------------------------------

| nothing -gt unit

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

393 Discussion

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

4 Working groups

Participants

Contents

Overview of Talks




















Working groups



Participants

Participants

Contents

Overview of Talks




















Working groups



Participants

Participants

Contents

Overview of Talks




















Working groups



Participants

Documents

Report from Dagstuhl Seminar 18172 ...While traditionally fully abstract compilation and ﬂexible linking have been thought to be at odds, I’ll present a novel idea called Linking