One-shot Delimited Continuations with Effect Handlers

/#!/JoePea joe at
Wed Mar 16 17:25:34 UTC 2016

The effect addition to try-catch seems like some sort of hacky
workaround, that would get the job done, but then would make try-catch
be used for purposes other than catching errors, which defeats it's
original purpose. I think it's important to keep that error-based
meaning and not mix it with anything else. "Try this, catch errors"
and that's all.

> What if we simply allowed await expressions anywhere in the call stack of an async function, rather than only in the bodies of async functions?

Although it is more work for the person writing code, I believe having
to explicitly use keywords (await or yield) in function bodies makes
it very clear what is happening, and ultimately leads to better code
with less potential for human error in the long run. I would vote
against allowing a relaxed await anywhere in the call stack. One of
the pains I had with Java was realizing after debugging for a while
that something I was doing was async (I was new to Java).

The beauty of JavaScript from the very beginning (the reason I love
JavaScript) is that dealing with asynchronous behavior is something a
JavaScript developer is forced to do from the get go. Introducing
invisible asynchronous behavior would deviate from that (and be more
like Java). It might be suitable at first, for new programmers, but as
soon as they have problems, the source of those problems could be
invisible unless they go read the docs on every API (and if lucky,
that API mentions that a function is async). Requiring `await` will
force everyone to learn how to deal with async behavior from the get
go, just like we all had to learn how to deal with callback hell from
the get go, which was a good thing (despite the syntax "hell").

> we're not able to control scheduling or context in async functions?

I think we can:

import {run} from 'some/scheduler/library'

let ctrl = run(async function() {
  await ctrl(sleep(1000))
  await ctrl(somePromise)

// ...
ctrl.pause() // paused at the sleep statement.
setTimeout(() => ctrl.resume(), 5000)

// ----- or

import {Task, sleep} from 'some/scheduler/library'

let task = new Task(async function(...args) {
  console.log(args) // [1,2,3]
  await task.ctrl(sleep(1000))
  await task.ctrl(somePromise)

// ...
setTimeout(() => task.resume(), 5000)

// ----- or

import {Task} from 'some/scheduler/library'

let task = new Task
let {run, ctrl} = task // run and ctrl are bound to the `task` by the
Task constructor.

run(async function() {
  await ctrl(sleep(1000))
  await ctrl(somePromise)

run(otherAsyncFunction) // runs after the first run completes.

// ...
setTimeout(() => task.resume(), 5000)

// ----- or

import {Task} from 'some/scheduler/library'

let task = new Task
let ctrl = task.ctrl

async function foo() {
  await somePromise
async function bar() {
  await ctrl(someOtherPromise)
~async function() {
  await ctrl(sleep(1000))
  await ctrl(foo)
  await ctrl(Promise.all(yetAnotherPromise, bar))

// ...
setTimeout(() => task.resume(), 5000)

ctrl() could accept promises, zone things, generator functions, async
functions, anything async. ctrl() obviously uses a Promise to resume
the execution of the "context".

On Wed, Mar 16, 2016 at 12:43 AM, Benjamin Gruenbaum
<benjamingr at> wrote:
>> async functions only address the async use case and they're all scheduled
>> on a simple micro-task queue. We need fine grained control over scheduling.
>> Perhaps Zones can help a bit with that but that's just one of severals
>> concepts that need this.
> Isn't the problem we actually need to solve here the fact we're not able to
> control scheduling or context in async functions?
> Other languages with async functions like Python and C# provide the means to
> control the scheduling of async functions.
> This is also indeed deeply related to zones since there is no inherent
> reason the same doesn't apply to async things that are not promises (like
> observables, async iterators and event emitters).
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list