Syntax for generators with resume arguments

[PoignardAzur]

@felix.s

This clearly demonstrates why decoupling receiving from yielding (what function.sent enables) is necessary: without it, map would have to either collect its first resumed value on its regular argument list (leaving the question of how to handle the case where there aren't any values is handled) or yield a dummy value at the start, which is how one would write in in JS now:

I'm not sure we're communicating the same thing here.

In particular, I'm not sure what you mean by "decoupling receiving from yielding". I think we agree that yielding has to be coupled with receiving on some level; as in, the function has to receive a new value every time it yields. The problem is how we handle the first and/or last yield.

Anyway, the first JS example you give seems close to the semantics I think would be ideal:

• From the "inside", the generator can always expect function.sent to have a usable value (which means that, wherever you are in the generator body, resume has already been called at least once). No special case.
• From the "outside", the generator can always be used like a function from the get go: pass arguments, get return value.

How exactly these semantics are achieved is secondary, as long as the two conditions above are respected. RFC PR #2781 achieves these semantics by having the closure arguments also be the resume arguments, but that's not the only approach.

@felix.s

The enemy AI example doesn’t look like it would care about the relative order of yielding and receiving values. It could receive the initial player position on the argument list just as easily as through the resume argument(s),

I think an important feature with the AI example is that the code doesn't care how many times resume has been called; and in fact, "is this the first yield" isn't even something the generator body knows.

If there was a player_pos_init and terrain_init values that were passed as functions argument, and were different from the regular player_pos and terrain values that the generator uses, then the generator would need to do some work to convert from one to the other. This work would be pure boilerplate, with no semantic value.

In the example code, the generator's entire body is a loop, with no setup or teardown code. If the AI finds a condition that resets it to its default behavior, all the code has to do is continue 'main_loop and it is guaranteed to behave as if the generator had been called for the first time.

I think that's desirable. Most generators ideal representation is (eg your map example) is a loop, with nothing before or after the loop body. That's only possible if the two properties mentioned above are respected.