Generator.prototype.next bug (resolved, non-issue)

[perchingeagle]

comment deleted, see the next comment

[perchingeagle]

I found what I think is a problem with generator.prototype.next() and yield, the code below explains my problem:

Generator function

function* gen(){                 // line 1
var rv = (yield 1) + 3;          // line 2
console.log('rv = '+rv);         // line 3
yield 2;                         // line 4
}

Code one (logical code, but does not work)

var iter = gen();
console.log(iter.next(5));
console.log(iter.next()); 

Output

1                        //normal
rv = undefined           //abnormal: expected 'rv = 8'
2                        //normal

The workaround (I think the logic is twisted [no insult])
Code two (workaround, works but not logical)

var iter = gen();
console.log(iter.next());
console.log(iter.next(5));

Output (desired result)

1
rv = 8
2

Why was the variable rv (in line 2) in the generator function set only after the next yield (in line 4) was called?
The value that was sent back using the second call to iter.prototype.next() (that returned line 4's value) was then evaluated (in line 3) to assign a value to the first. (Are you already confused like me, now imagine having to do this with a complex code)
I know Python and Javascript are different languages, but the first code would work just fine in Python:

1. Line 2 would yield it value (in this case 1).
2. The first call to next will send back its argument (in this case 5) to the generator and return the first yielded value (1) from the generator.
3. Line 3 then executes with variable rv (5 + 3 = 8) already set.
4. Line 4 then yields its value (in this case 2).

(everything is in logical order this way)

In my opinion, when the state is SUSPENDEDSTART just like SUSPENDEDYIELD the value passed to generator.prototype.next() as in next(arg), should not be discarded, it solves that nasty problem.

[fkling]

This is not a bug in regenerator, this is how generators currently work in JS. That's the reason for the proposal of function.sent:

However, the first next that a generator's consumer invokes to start a generator object does not correspond to any yield within the body of the generator function. Instead, the first next simply causes execution of the generator function body to begin at the top of the body.

Because there the first next call does not correspond to a yield within the generator function body there is currently no way for the code with the body to access the initial next argument.

[perchingeagle]

Thanks, I tried to do the same with Python, and I realized that Python uses
send( ) to solve that little confusion.

On Monday, July 25, 2016, Felix Kling notifications@github.com wrote:

This is not a bug in regenerator, this is how generators currently work in
JS. That's the reason for the proposal of function.sent
https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md
:

However, the first next that a generator's consumer invokes to start a
generator object does not correspond to any yield within the body of the
generator function. Instead, the first next simply causes execution of
the generator function body to begin at the top of the body.

Because there the first next call does not correspond to a yield within
the generator function body there is currently no way for the code with the
body to access the initial next argument.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#254 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AExc1ZvRgi2-nJ9rLfnmH-LyhgsmSkCVks5qZE5dgaJpZM4JTwxE
.

[benjamn]

Thanks for digging into this.