I'm personally a fan of using an implicit parameter here and special call syntax (task foo()). I should propose it for real.
-
-
Replying to @wycats
async function isn't a minor detail in a language. It finishes the story of an async-IO-only language.
1 reply 0 retweets 1 like -
Replying to @wycats
interesting thing about cancellation is that there's already a place to hook the implicit token param most of the time (await)
2 replies 0 retweets 1 like -
Replying to @wycats
you just need new syntax to kick off the chain, and you can have `task` produce a tuple of (Promise, CT) w/o leaking everywhere
1 reply 0 retweets 1 like -
Replying to @wycats
you can also allow funcs to override propagating w/ somethg like await.cancel = null (or a different CT) also w/o worse defaults
1 reply 0 retweets 1 like -
Replying to @wycats
I like. If you bottom out on a hand-rolled promise, it can presumably just capture await.cancel and wire up a callback on the token.
1 reply 0 retweets 1 like -
-
Replying to @wycats
it could be passed into the promise constructor potentially for the last mile. Tricky to cross the lang/lib divide.
1 reply 0 retweets 1 like -
Replying to @wycats
I think some people don't like await.cancel being available in all functions (I don't mind).
2 replies 0 retweets 1 like -
Replying to @wycats
also need to make sure it's possible to convey to combinators like Promise.all. Perhaps enough to immediate invoke async func
1 reply 0 retweets 0 likes
thing I like about `task`: it creates a notion of task that isn't just some combo of promises.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.