1) Yielding is decoupled from the asynchronous action itself, giving the caller fine-grained control when to yield. For example, with async/await, management of parallel operations is straight-forward:
var promise = fetch('https://foo.com/');
// ... do something useful while the fetch runs ...
var result = yield promise;
var promise1 = fetch('https://foo.com/');
var promise2 = fetch('https://bar.com/');
[result1, result2] = yield Promise.all(promise1, promise2 );
async function f() {
var p = fetch('https://foo.com/');
p = p.then(function(inbetweenResult) {return new Promise(function(resolve) {
oldapi.onresult = resolve;
oldapi.process(inbetweenResult);
})});
return await p;
}
f().then(...)
*certain DOM APIs due violate this contract, notably window.open() on firefox pauses everything but setTimeout.
That being said you can totally have globals and whatnot that can be mutated anywhere (e.g. parameters passed to a function or literal globals installed in the global scope) or things declared at a lower scope that can still be modified by multiple functions.
Hope that clears it up
Is it possible to have a yield inside a called function (i.e., not the generator function itself)? Last time I checked this was not allowed (?)
Anyway, if so, I would strongly prefer this over a async/await construct, which is less general.
Call a generator function from a generator function? Sure, you just need to transitively yield its content using `yield* [[expr]]` (which delegates part of the iteration to the `expr` generator)
const res = fetch('https://api.github.com/orgs/facebook'); // yield here
Of course, fetch(), could yield a status specifying whether its calling-ancestors should yield, but this can become unwieldy very quickly, and might require an exception mechanism of its own. Better to just let called functions yield.
> But what if I want the fetch() function to decide whether to yield or not?
In javascript? The question doesn't really make sense, a function is either sync or async.
Well, either fetch() blocks, or not. If it blocks, then it should yield, its caller should yield, etc. If it doesn't block, then it can just run to completion.
> Well, either fetch() blocks, or not.
Javascript functions always block.
> If it blocks, then it should yield, its caller should yield, etc. If it doesn't block, then it can just run to completion.
If a function is async, you must yield[0]. It may not need* that capability (conditionally) and doesn't have to yield at all e.g.
function*() {
return 4;
}
[0] I think that's not an issue for async/await as it's syntactic sugar for then chains, the code itself may be converted to a generator or whatever but it will embed the driver
I guess the only realy difference would be that I would make `await` (and `async`) implicit, similar to how exceptions are handled implicitly in the above snippet (i.e. we don't annotate functions as `throwing` and we don't use an `attempt` statement (analogous to `await`) when calling `throwing` functions).
Edit: Reading various articles, the best explanation is that since the single-threaded nature of JavaScript makes synchronisity implicit (i.e. all code is run in an implicit transaction), it has to make asynchronisity explicit. The alternative would be to have coroutines/fibres (implicit asynchronisity), but with explicit `atomic` blocks (for synchronisity).
C# doesn't provide any synchronisity guarantees, so I guess the motivations there were different (it's really hard (impossible?) to implement fibres efficiently, and even harder to allow for native code interoperability).