This is super interesting and I'm still going through the paper. For folks with a "Cool, but why" reaction, the introduction elaborates:<p><pre><code> For example, the P language [10] is a language for describing verifiable asyn-
chronous state machines, and used for example to implement and verify the core
of the USB device driver stack that ships with Microsoft Windows 8. Compiling
to C involves a complex CPS-style transformation [19, 26] to enable async/await
style programming [5] with a receive statement – using the effects library this
transformation is no longer necessary and we can generate straightforward C
code instead. Similarly, we hope to integrate this library with libuv [29] (the
asynchronous C library underlying Node [43]) and improve programming with
libuv directly from C or C++ using async/await style abstractions [12, 27]
</code></pre>
Since the linked abstract doesn't actually mention this practical application, consider this comment as a goad to encourage more people to click through to the paper :)
A little off-topic, but the author of this paper (Daan Leijen) is also the author of Koka[1], a programming language with algebraic effects.<p>IMO, Koka (or something similar) has more potential to become a mainstream language than "traditional" FP languages (Haskell, OCaml, Idris, etc.).<p>Effects seem to be easier to understand than monads (at least on a superficial level) and more modular (I don't have a lot of experience with Haskell, so take that with a grain of salt).<p>Its syntax is also very close to C-like languages.<p>Taken from the Koka book[2]:<p><pre><code> fun square1(x : int) : total int {
return x*x
}
fun square2(x : int) : io int {
println( "a not so secret side-effect" )
return x*x
}
</code></pre>
`square1` is a pure mathematical function, so its effect is `total`. `square2` has a side-effect because of `println`, so its effect is `io`. This means that `square2` can raise exceptions, not terminate, be non-deterministic, read and write to the heap, and do any input/output operations.<p>Note that Koka can infer effects, so these annotations are optional.<p>[1]: <a href="https://www.microsoft.com/en-us/research/project/koka/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fprojects%2Fkoka" rel="nofollow">https://www.microsoft.com/en-us/research/project/koka/?from=...</a><p>[2]: <a href="https://koka-lang.github.io/koka/doc/kokaspec.html#sec-effect-types" rel="nofollow">https://koka-lang.github.io/koka/doc/kokaspec.html#sec-effec...</a>
Hi, I am the author of this report -- thank you for the interest :-)<p>Just wanted to add that you can find the library at:
<a href="https://github.com/koka-lang/libhandler" rel="nofollow">https://github.com/koka-lang/libhandler</a><p>The `dev` branch contains a sample of `libuv` integration. There is still a lot to be done in terms of creating a better interface and providing implementations of standard effects but the core is working quite well by now.<p>Enjoy!
the authors cite Matija Pretnar who has an introduction on [algebraic effects](<a href="http://www.eff-lang.org/handlers-tutorial.pdf" rel="nofollow">http://www.eff-lang.org/handlers-tutorial.pdf</a>). I'm reading through it now as I have no idea what is going on :)
If all you want is generators and co-routines, then there's a lot of literature on this for C.<p>The original Icon compiler compiled to CPS C. That was pretty cool.<p>One can do much of what Icon did using GCC local functions and computed gotos to get something much closer to not-CPS.<p>There's Simon Tatham's PuTTY, which uses his co-routine macros, which are an extravagant meta-programming macros around a Duff's device. He also has an extensive set of meta-programming macros as well, not related to co-routines.<p>Some Schemes compile to C code where all functions always return immediately, but what they return is a continuation, and the top-level is a for(;;) { next = next(); }.<p>EDIT: I'm particularly fond of PuTTY. Its SSHv2 implementation all the way up to the end of authentication is a single, huge function. It looks completely synchronous, but it's not, because it's actually a co-routine. As a result, and in spite of being a single huge function, it's actually quite readable.
Algebraic effects are a hot topic. The name sounds fancy but maybe this intuition helps: an effect is like an exception where the exception handler receives enough information to resume the computation from where it was called. Just like exceptions, effects are dynamically scoped: the handler is always found up in the call stack.