An extensible Syntax for effects like e.g. async-await

[adamkemp]

As @Max_Desiatov said, the requirement is purely syntactical. It's for readability. They could make it so that you don't literally have to use the async keyword on the function header just to use the await keyword inside the function body, but the result would be the same: if you use await in a function then that function must necessarily get transformed by the compiler. Putting the keyword on it just reinforces this fact in the mind of the developer and makes it clear to someone reading the code that "there's an await in there somewhere so keep that in mind".

There's no getting around the requirement that using await means the function must be transformed.

One difference between C# and what has been proposed so far for Swift is that in C# making a function use async does not actually change its signature and does not require that callers must use await when calling it. These two functions work the same:

async Task<int> GetValueAsync() { ... }
Task<int> GetValueAsync2() { ... }

And they can be called either with or without await:

Task<int> task = GetValueAsync(); // Calling async method without using await
int value = await GetValueAsync2(); // Caling non-async method using await

People often say async is viral, but what that really means is that an asynchronous function (regardless of whether it uses async/await or something else) can only be called by a function that can handle an asynchronous completion. The most convenient way to do that in most cases is by also using async/await in the caller because async/await is just so much better than using nested callbacks, but you don't have to. You could just use the raw promises API directly.

[QuinceyMorris]

I wasn't talking about a restriction on try, I was talking about the quoted restriction on await. Let's not get sidetracked by try, since it's a different scenario. (For try, there's an implicit transfer of control if an error occurs. await always gives control to the next source line — there's no invisible branching involved.)

[Max_Desiatov]

@QuinceyMorris

Let's not get sidetracked by try , since it's a different scenario.

In no way I'd like to sidetrack, I only would like to highlight that parallels between async/await and throws/try are not concidental. I agree with the OP pitch in principle: both error handling and asynchrony are effects and it would make sense to handle them similarly if not in the same way. The only thing I don't like is introduction of new keywords, which could be resolved with different approaches.

Regardless, there's no way around the fact that in statically typed languages one would expect that unhandled effects don't escape. As @adamkemp expalins here for the asynchrony case:

@adamkemp

People often say async is viral, but what that really means is that an asynchronous function (regardless of whether it uses async/await or something else) can only be called by a function that can handle an asynchronous completion.

The pretty much mirrors what one would expect when handling errors in Swift: "throwing function can only be called by a function that can handle an error being thrown". If the effect type was different, say an abstraction over "environment", one would expect this property to hold. You wouldn't want to call a function that expects environment to exist from another function that's not able to provide that environment (read "not able to handle the effect").

[QuinceyMorris]

Here is the essential problem to be solved:

You are writing code for the main thread, and (currently) you want to call a function with an asynchronous completion handler. Currently, you must write something like this:

   let a = someA()
   a.doSomethingWithCompletion {
      result in
      let b = someB(result)
      print(b)
   }

What we're trying to achieve is the ability to write this instead:

   let a = someA()
   let result = await a.doSomething
   let b = someB(result)
   print(b)

This is not inside an async function, because on the main thread we don't have an async starting point. If you try to force the above code to be enclosed in an async function context, then you just drive the problem back to an earlier point in the code, and eventually you hit a function context that you have no control over and can't add async to.

I don't agree that we're committed to any concept of "effects" here, unless you think sequential execution is an effect, but if you want to acknowledge the asynchronous nature of doSomething, it's already being done by the await keyword.

My question is: what else is necessary and why do you think it so?

[Max_Desiatov]

@QuinceyMorris

This is not inside an async function, because on the main thread we don't have an async starting point.

There's a problem here with intermingling concurrency and multi-threading, these are orthogonal. I don't know what exactly you mean by an "async starting point", but I could guess that in single-theaded environment this could be an event loop. This is essentially how async/await works in JavaScript, where you don't have multi-threading and the main event loop is always implicit. In Python (where async/await is also orthogonal to multi-threading) concurrency is also tied to event loops, but those are explicit there.

[Max_Desiatov]

What I'm saying is that async/await could be helpful (and is already shown to be quite helpful) in single-threaded environments. This has direct applications in Swift, which is also viable in single-threaded environments such as WebAssembly and microcontrollers/bare metal. Thus, a concurrency model that relies on multi-threading (instead of being orthogonal to it) would exclude important use cases here.

[adamkemp]

I think you're conflating two things, which are admittedly a bit confusing.

1. Is a function that uses await asynchronous?
2. Should a function that uses await require the use of the async keyword?

The answer to the first question is necessarily "yes". The function you wrote out that uses async is an asynchronous function. You didn't write out the function signature for it, so what if it looked like this?

func doSomething() -> Int {
  let a = someA()
   let result = await a.doSomething
   let b = someB(result)
   print(b)
  return result;
}

It doesn't matter whether you're on the main thread here. The caller of this function must wait for the asynchronous completion of this function in order to get the result.

But what if it was void?

func doSomething() {
  let a = someA()
   let result = await a.doSomething
   let b = someB(result)
   print(b)
}

You could argue that a caller of this function does not have to wait for its completion. In fact, C# allows for this:

async void Foo() {
    await DoSomethingAsync();
    DoSomethingElse();
}

void CallAsyncVoid() {
    Foo(); // fire and forget
    Bar();
}

That is allowed explicitly because it's often necessary in UI code, for instance for starting some async work in response to an event handler for a control. I agree with you that this should be allowed in Swift. I've made that case before, and I will continue pushing for it.

I should mention that in C# it is strongly discouraged to use async void for any other reason because of the implications around error handling (i.e., what happens if an exception is thrown from an asynchronous function?). Since Swift's try/catch works fundamentally differently I don't think that same concern applies. I would say that it should not be legal to call an async void function that throws without using await, but throwing in Swift is more like syntactic sugar around a return value so this is really just saying "a throwing function is never really void, and its result must be used".

All of this is completely orthogonal to the second question: should the async keyword be required when you use the await keyword? The argument for requiring it is that it makes it clear to someone reading the function that this function is asynchronous (again, it must be), and therefore you know to look for where its control flow may be interrupted.

[adamkemp]

See also this article: There Is No Thread. Just because you're using async/await doesn't mean you have multiple threads. The asynchronous thing you're waiting on may not use a thread at all.

[Max_Desiatov]

Thanks, I'll also shamelessly plug my article about event loops here, which is a part of a longer cycle about generators and coroutines. I don't think my pitches in those areas were successful, but it certainly was helpful for me personally to understand how crucial event loops are for concurrency, and how frequently multi-threading is conflated with concurrency (causing a lot of confusion that way).

[Anachron (Markus Kasperczyk)]

There's a lot to cover since I last wrote something, but some things have already been addressed by others in this thread.

@QuinceyMorris this case, there has to be a wait of some kind and the wait cannot block the thread on which the code is running. A monad solution doesn't intrinsically satisfy that requirement, so you still need compiler magic (e.g. coroutines) to make this possible.

I agree insofar as I see the need to be able to de-sugar things. As I said in my original proposal:

Would calling throwing functions without try now be legal? After all, they would simply return a Result then. Under which circumstances should there be a compiler warning and when should it be fine? This is mostly a discussion about communicating the intended use, at the type level there is no problem.

The real question is how we prevent confusion. For example, if await f(a) outside an async function just returned the monad that has been used to implement async-await, the g(b) simply wouldn't compile for type reasons. But would everyone understand why that is? This is something that really needs some further discussion as the idea matures.

@sveinhal I see your point. However, what is the likelihood for programmers that want to get things done to over-use that feature? I mean, Java provides annotations and a rich reflection API (and in a restricted form, Swift does too now), but how many frameworks use that in a way that one could say these uses aren't justified? Sure, people are going to experiment with the new feature - as they have done with property wrappers. I would even encourage them to! But only few real use cases actually stick, and most of the time these are very much justified. From what I can see, the Swift community has been very responsible with new language features so far.

Your question regarding other keywords has been answered by @pthariensflame, I hope that helps.

@Max_Desiatov Sorry, I should have mentioned Haskell style do-notation and for comprehensions known from other languages. However, in these designs, all monads just get the same 'syntactic sugar'. Also, the do-model might fit the state monad or asynchronous monads, but is it a good fit for arrays for instance? Conversely, for comprehensions are great for async stuff and arrays, but how am I supposed to parse the reader monad with for comprehension?

The keyword-based variation that treats monads as effects is actually something that is currently actively explored, for example by the experimental Eff programming language, but there are also Scala frameworks. I personally like the approach because the keywords kind of tell you what is going on (if you read the documentation).

I agree though that I should have mentioned the other approaches. If this idea matures to the point that I make an official proposal (as far as I understand the intention of the Pitches section, this is more about testing the waters), I will put these in the 'alternatives considered' section.

Circling back to @adamkemp :

I'm honestly not sure what problem this proposal is trying to solve. My original question is "where is the code that actually controls the compiler transform, and how does this feature allow that to be extended?" I haven't seen an answer to that question so far. How does using monads solve any of the actual challenges with coroutines or async/await specifically? And if it doesn't solve those challenges then what does it solve?

Ok, let's try again.

My concern with the async-await feature that is sometimes requested is how it would fit into Swift from a syntactical point of view and when it comes to the way it is implemented. I mean, there were times when error handling wasn't a feature that was syntactically supported in most languages. Async-await is another feature that many languages adopted only way later. When people see these concepts, they often think that they were always around, but there really is a progression. Say, in 10 years we get another effect and in 20 years yet another one and say each of these features had their own syntax (like in Kotlin where async functions look very differently from throwing functions) and the poor people implementing the feature had to inject the new syntax and how it should be handled every time. That can lead to a lot of confusion for developers and a less clear language design.

What I propose is simply a general tool to write those effects. Obviously, each monad still has to be implemented - but injecting them into the language in a clear and readable way without long map and flatMap chains is then simple.

Note that I changed the title to 'An extensible Syntax for effects like e.g. async-await'. I haven't touched the specific challenges of async-await here much, other than delivering a oversimplified implementation of promises and referring to RxSwift. Since async-await is a feature that many people would want to see, I would like the new syntax feature to ship alongside async-await (and it can be implemented with monads, just like any effect) which would showcase the generality and simplicity of the monadic approach.

@all There's another monad that just came to my mind: randomness. In Haskell, all functions are pure - meaning that the same input always produces the same output. To express randomness, they have a monad that in essence provides some primitive operations to produce random results, but forcing you to tell users of that function that you do random stuff via the type system. In Swift, you can always do random stuff freely (just like you can do IO or asynchronous stuff using GCD or even manipulate references), but introducing a random monad and keywords like 'random/flip/rerandom' could cause people to consider freely doing random stuff a code smell. Just like the introduction of the IO monad and keywords like 'io/show/reIOs' could make free IO actions a code smell.

Speculation: I could actually even imagine splitting Haskell's IO monad in Swift into an Input monad and an Output monad. If you write a controller class and create a delegate protocol for that, you could then specify that delegate methods may only do outputs, not inputs, thereby promoting unidirectional data flow at the type level.

[adamkemp]

You still haven't connected the dots for me regarding how using monads actually helps in the implementation of async/await, though. As I've already covered, async/await cannot be implemented by just converting a function into a chain of calls so it really does require an AST-aware transformation of source code. What does the monad add to that? The best I can tell is that you only want to be able to use monads to enforce the rules about what can call what, but even then I'm not sure it applies to async/await (there must inherently be a root that is not async in the call chain of an async function).

[Anachron (Markus Kasperczyk)]

The AST-aware transformation would apply to all monads that implement the syntactic sugar protocol. The question thus becomes: is it possible to implement async-await semantics with monads? If by async-await you understand something similar to what RxSwift (GitHub - ReactiveX/RxSwift: Reactive Programming in Swift) is doing, then the answer is definitely 'yes'. I am not sure what could be meant by async-await that cannot be expressed in a monadic way. Monads are a really powerful tool: flatMap and map can hand your continuations to almost arbitrary parts of your code that can almost arbitrarily decide what to do with them, the only requirement being that the sequential-looking code you write actually has sequential semantics.

Your point that

there must inherently be a root that is not async in the call chain of an async function

is, if I understand you correctly, probably related to my note that there needs to be some way to 'get back' the underlying monad, in the case of async-await in order to actually start async execution or in the case of the Result monad in order to handle errors. I admit that this is weakest point in my design so far - which is why I would love suggestions. Currently, my answer would be that if you call e.g. async functions inside non-async functions or you call them without the appropriate keyword, you would simply get back the monad (in case of the monad used for implementing async-await, you could then call some 'startExecution' function) and I admitted that this might be confusing and that it conflicts with the established language design around throws-try. Suggestions are very much welcome.

[Anachron (Markus Kasperczyk)]

Thinking about the Eff programming language, it just crossed my mind that interaction with the monad itself could be achieved via do-throw-catch.

Effectively, do-throw-catch has two responsibilities: intervening in the control flow and turning monadic functions into normal ones. Do here’s a rough sketch of the idea:

Monads implementing the syntactic sugar protocol can declare multiple mutating „onThrow“ functions. These are no protocol requirements because it is unknown how many of these functions there will be - the design is more comparable to the @_functionbuilder design.

The signature of these functions is:

mutating func onThrow(thrown: A, continuation: @escaping (B) -> Void) -> C

where A, B and C are arbitrary types. The compiler will then allow the user of the monad to write code like

do{
let b : B = throw A(...)
}
catch c : C{
...
}

It is left to the implementing monad if the continuation is invoked or not. The continuation simply encapsulates the code below the throw statement. Since the implementation of onThrow is known, it should still be possible for the compiler to check if a throw statement means „don’t continue“ (i.e. the closure isn’t called and isn’t actually escaped) so guard statements with throw would still be legal in those cases. (One could also have two different keywords for disambiguation)

That way, you can further customize control flow and pass arbitrary information back and forth. The catch clause for the reader monad can pass back the environment if C is simply the continuation. One can introduce recoverable errors to the Result monad by passing appropriate continuations. It might even be possible to use this as a handy syntax for fully interpreted monads.

[Avi]

I don't really understand the functional aspects being discussed here, but I also don't understand the basis for the pitch. Every async/await proposal I've seen expects to be implemented via coroutines. Having some kind of meta-programming way to add keywords doesn't help the compiler rewrite code to create coroutines and continuations.

[Anachron (Markus Kasperczyk)]

Coroutines and continuations are high level concepts. Continuations are already a public part of Swift and coroutines can be emulated in any programming language. How exactly code with keywords would be transformed into code with coroutines/continuations is an entirely different discussion that would probably require some deep dive into the existing Swift compiler or at least preprocessing tools like Sourcery.

We definitely should have that discussion at some point if we are ever going to have the feature in the language, but I am not sure if we can say we already settled on semantics and/or syntax.

Edit: oops, I thought this was the other async/await thread.

[Avi]

@Anachron

Continuations are already a public part of Swift and coroutines can be emulated in any programming language.

That's not what we want. We want the compiler transforming code. We don't want to emulate it. If that were the goal, we'd have standardized on one of the competing implementations and not be continuously proposing it be added as a language feature.

@Anachron

How exactly code with keywords would be transformed into code with coroutines/continuations is an entirely different discussion

I disagree. If you don't have even a theory for how it could work, this doesn't belong as a pitch. It's akin to asking us to consider some feature X, to be implemented by magic.

I am not suggesting that you must have an implementation. That's for the proposal phase. But I don't think it's worthwhile to discuss the introduction of a feature that cannot be implemented.

[adamkemp]

@Anachron

I am not sure what could be meant by async-await that cannot be expressed in a monadic way.

How does this get transformed into a simple chain of calls using monads?

func asyncThrowing() async throws -> Int {
...
}

func asyncCaller() async throws -> Int {
    var result = -1
    while result < 0 {
        let result = try await asyncThrowing()
    }
    return result
}

[Avi]

Take property wrappers as an example. They allow for developers to define new types that modify the behavior of properties. The compiler contains rules for how the rewriting will happen, and those rules are followed the same way for every usage of a wrapper.

To follow the same model for your extensible effects, you would need rules that the compiler can follow in every instance. If you have a different model in mind, you should propose it.

[Anachron (Markus Kasperczyk)]

Other languages have implemented it, so what should the problem be here?

All in all, it should be doable by some relatively simple automated code transformations - precisely because we can do this stuff on the high level. Note that a huge part of Swift is written in Swift itself, so there's no reason why not to use high level code. There is no need to go really low level.

The tricky bits come in when the information needed to run the continuation in the expected way leave the boundaries of a single scope. @adamkemp provided a great example where this can be hard: a while loop.

In @QuinceyMorris's pitch on async/await, I demonstrated an example how to resolve an if-clause and I speculated that while-clauses could be done with some recursive scheme, provided we find some compiler directive that ensures tail-call elimination.

Let me try:

func asyncCaller(base: Int = -1, continuation: @escaping (Int) -> Void) -> Int{
var result = base
if result < 0{
asyncThrowing{//also parsed into something with a continuation
result = $0
if result < 0{
asyncCaller(base: $0, continuation: continuation)
}
else{
continuation(result)
    }
  }
 }
else{
continuation(result)
}
}

Note that this is something I just made up right now. I do have to think about correctness and optimality for some time.

Edit: in an earlier version, I messed up the recursion. Not sure yet if it is correct, no time to think about it right now.

[Avi]

@Anachron

Note that a huge part of Swift is written in Swift itself, so there's no reason why not to use high level code.

The standard library is written in Swift. The compiler is all C++.

@Anachron

There is no need to go really low level.

Again, there are already libraries written in Swift to implement async/await. We know it can be done. What we want are the benefits of letting the compiler do the heavy lifting, so we can get optimizations.