Thank you! This is helpful.
Do you believe there is no positive sum because Promises are out there already, and this could have been avoided had they been released with cancellation in the first place?
I think it's very likely that we could avoid turning this into a zero-sum debate with one total-winner and one total-loser.
That said, I think there's no positive sum because some folks believe that (1) Promises should be the primary async story in JS, and (2) Promises must not allow communication between two parties who hold a reference to the Promise. This means that `async function`s must return a Promise, and the Promise but not have a `cancel()` method on it (because it would allow communication between two parties holding references to the Promise).
Others (I'll speak for myself here) believe that the return value of `async function` should be competitive (ergonomically) with generators used as tasks (I showed examples in the parent comment). Since generators-as-tasks can be cancelled (via `.return()` and `.throw()`), the desire to make `async function x` as ergonomic as `function* x` conflicts with the goal of disallowing the return value of async functions from being cancellable.
In Ember's case, since generators already exist, it's hard for us to justify asking application developers to participate in an error-prone (and verbose) protocol that we could avoid by using generators-as-tasks instead. And that is likely the conclusion that we will ship (and the conclusion that ember-concurrency has already shipped).
For me, the bottom line is that we have very little budget to introduce new restrictions on `async functions`, because people can always choose to reject async functions and use generators instead (with more capabilities and less typing!). I think the cancellation token proposal is well over-budget from that perspective.
Indeed, Eric Demain is amazing. Thanks for the reference. There's a lot to be discussed about computational origami and computer science. And there are many materials on the subject. I was trying to also touch the behavioral aspect of the connection between being a programmer and a folder.
Well it's a good point about the other angle of not using anyone else's code at all. I think there should be a good balance between using others' and writing your own code. It requires good judgement. In origami, however, you almost solely use other people's designs, but I think we should encourage putting in your own interpretation.
Oh there are so many good ones. Robert Lang's "Origami Design Secrets" is sort of a bible. Also, there are 2 publishers worth checking out: Origami house and Origami Shop (http://www.origami-shop.com/m_index.php)
admittedly I haven't looked at them for years, but they still seem to have quite a range of Robert J Lang, John Montroll, etc.
An aside - there are other connections between computing and origami; 20 years ago Bern & Hayes showed that assigning mountain or valley folds to a crease pattern in order to make it fold flat was NP-complete http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28.1... (and is also in the "I wish I'd thought of that" category. It was a question from me on Usenet that piqued their interest in origami, so I got an acknowledgement in the paper - but I wouldn't have come up with that idea in a million years)
