Proposal: Async keyword

[ElianHugh]

This is super neat! Perhaps a niche idea but, I saw in #15 that you were looking at generators/iterators, and the other proposal about a defer keyword, and it made think of how much nicer it would be in R if async was a keyword. I guess this also presupposes that async will be a thing?

x <- await(foo())

x <- await foo()

# or

x <- await {
  foo()
}

[dgkf]

I'd love to have a comfortable syntax that feels idiomatic within the R landscape and powerful enough to allow all sorts of lazy/coroutine/multithreaded/multiprocess execution models. But frankly I don't feel I have enough experience with these patterns to really be opinionated on what "good" looks like.

That said, I hope such a person finds this project and feels like it offers an adequate space for experimenting so that we can find something that has the right feel.

Just some really early thoughts:

What you suggest looks like a natural enough syntax to me. Where javascript uses an async keyword when declaring functions, I prefer this idea of having an async block. A wholly async function becomes an extension of this syntax:

connect <- function(database) async {
  # connect to database
}

I'd love to hear from experienced javascript folks to hear what pain points they feel the javascript flavor still has. When javascript's async syntax was on the rise there was at least part of the community that felt is sort of splintered things, but many more modern languages seem to be going this route regardless.

Resources

There are a ton of blog posts on this topic and deliberation from every programming language on the block to start referencing, but I'll just start with two that I've found particularly helpful:

• The classic What Color is your Function
• I recently read part of Let Futures be Futures and feel like it's a good successor that covers some language development since WCIYF. I still need to sit down with it and really internalize its grievances.

Feel free to start aggregating others and we can start to scope out what "good" looks like

[sebffischer]

here is a nice blog post on shortcomings of current async primitives, as well as a suggestion for a solution: https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/

see https://github.com/python-trio/trio for the actual library that implements the ideas. I have so say I really like how simple it seems.