For the past few months I’ve been mulling over some things that Russell Johnston made me realize about the relationship between effect systems and coroutines. You can read more of his thoughts on this subject here, but he made me realize that effect systems (like that found in Koka) and coroutines (like Rust’s async functions or generators) are in some ways isomorphic to one another. I’ve been pondering the differences between them, trying to figuring out the advantages and disadvantages of each.

A few weeks ago, Will Crichton posted something on Twitter that helped bring the contrast into sharper focus for me:

The entire field of PL right now: what if it was dynamically scoped…. but statically typed…………..? (effects, capabilities, contexts, metavariables…)

I’m just a humble language designer (and not a theorist of anything, especially not PL), so my focus is the difference in user experience and affordance. But this seems like a cutting insight and this property of effect handlers - static typing but dynamic scoping - seems to me to be a good jumping off point for understanding the difference between effect handlers and coroutines from a user perspective.

In a previous post, I shortly discussed the concept of “effects” and the parallels between them. In an unrelated post since then, Yosh Wuyts writes about the problem of trying to write fallible code inside of an iterator adapter that doesn’t support it. In a previous discussion, the users of the Rust Internals forum hotly discuss the notion of closures which would maintain the so-called “Tennant’s Correspondence Principle” - that is, closures which support breaking to scopes outside of the closure, inside of the function they are in (you can think of this is closures capturing their control flow environment in addition to capturing variables).

I think it may not be obvious, but these discussions are all deeply related. They all arise from what is, in my opinion, one of the biggest problems with the design of the Rust language: its failure at 1.0 to give good support for handling common effects related to program control flow.

I’ve long been a proponent of having some sort of syntax in Rust for writing functions which return results which “ok-wrap” the happy path. This is has also always been a feature with very vocal, immediate, and even emotional opposition from many of our most enthusiastic users. I want to write, in one place, why I think this feature would be awesome and make Rust much better.

I don’t want to get into the details too much of the specific proposal, but here’s a sketch of one way this could work (there are a number of variables). We would add a syntactic modifier to the signature of a function, like this:

fn foo() -> usize throws io::Error {
    //..
}

This function returns Result<usize, io::Error>, but internally the return expressions return a value of type usize, not the Result type. They are “Ok-wrapped” into being Ok(usize) automatically by the language. If users wish to throw an error, a new throw expression is added which takes the error side (the type after throws in the signature). The ? operator would behave in this context the same way it behaves in a function that returns Result.