4 ms·

> In the article, it seems like we are just looping over a set of 11 cookies and doing exactly the same thing to all of them. Not sure what I'm missing. You're

> In the article, it seems like we are just looping over a set of 11 cookies and doing exactly the same thing to all of them. Not sure what I'm missing. You're missing that we're not just looping over a set of 11 cookies and doing exactly the same thing to all of them. We're streaming over a lazy sequence of cookies and doing the same thing to them until we stop (in the example when they hit 5 cookies eaten instead of eating them all and, presumably, becoming ill). Generators act like streams, and are useful in any place you might see this pattern: value, state = next_value(state) -- alternatively if we can mutate the state directly -- value = next_value(state) But they permit you a greater deal of flexibility about the way "state" mutates than a typical state structure might (or at least greater ease of use).

wruza 4y ago
Do js generators resume from a yield point? Reading this thread I see no mentions of the fact that generators usually(?) resume from whatever branching-looping state they were at yield, which is hard to simulate in general. A simple for(i){yield} - yes, just store an index somewhere and simulate to “resume” at it in your stream-like closure. A complex stateful algorithm with lots of cached lexical context - well, manageable with a corresponding data structure, but more expensive in terms of mapping it to a state table. The whole point of a generator is its stack frame and its “instruction pointer”. You can implement a state machine right in regular code via cheap primitives. Otherwise the difference is just syntactical, afaiu.
- Jtsummers 4y ago
  I mean, you could look at the examples in the article and see that, yes, they resume from a yield point. But here's a simple illustrative example: function* bar() { yield 3; console.log("Resumed after the 3") yield 4; console.log("Resumed after the 4") } function* foo() { yield 1; console.log("Resumed after the 1") yield 2; console.log("Resumed after the 2") yield* bar(); } for(let n of foo()) { console.log(n); } Output: 1 Resumed after the 1 2 Resumed after the 2 3 Resumed after the 3 4 Resumed after the 4

wruza 4y ago

Do js generators resume from a yield point? Reading this thread I see no mentions of the fact that generators usually(?) resume from whatever branching-looping state they were at yield, which is hard to simulate in general. A simple for(i){yield} - yes, just store an index somewhere and simulate to “resume” at it in your stream-like closure. A complex stateful algorithm with lots of cached lexical context - well, manageable with a corresponding data structure, but more expensive in terms of mapping it to a state table. The whole point of a generator is its stack frame and its “instruction pointer”. You can implement a state machine right in regular code via cheap primitives. Otherwise the difference is just syntactical, afaiu.

Jtsummers 4y ago
I mean, you could look at the examples in the article and see that, yes, they resume from a yield point. But here's a simple illustrative example: function* bar() { yield 3; console.log("Resumed after the 3") yield 4; console.log("Resumed after the 4") } function* foo() { yield 1; console.log("Resumed after the 1") yield 2; console.log("Resumed after the 2") yield* bar(); } for(let n of foo()) { console.log(n); } Output: 1 Resumed after the 1 2 Resumed after the 2 3 Resumed after the 3 4 Resumed after the 4