That First Next Argument

Kevin Smith zenparsing at gmail.com
Tue Aug 19 07:26:21 PDT 2014


Originally this came up while studying these slides on async generators:

https://docs.google.com/file/d/0B4PVbLpUIdzoMDR5dWstRllXblU/edit

In this design, `Observable.observe` is specified as taking a generator
which acts as a data sink.  However, because of the "lost next" issue, it
appears that newborn generators must be "pumped" before they can be used by
that function.

In the following gist, I've implemented `readFile` and `writeFile` using
async generators.  The async/await stuff isn't crucial to the point.  I've
implemented the functions using both `x = yield y` and a purely
hypothetical `next` keyword to pull data from the consumer.

https://gist.github.com/zenparsing/26b200543bb8ae0ca4df

(BTW, I'm not asking for any changes - this is just a theoretical question.)



On Tue, Aug 19, 2014 at 9:21 AM, Kevin Smith <zenparsing at gmail.com> wrote:

>
>> // the same, advancing to the first `yield` at instantiation
>> class echo2 extends echo {
>>     construct(...args) {
>>         let iter = super(...args)
>>         iter.next()
>>         return iter
>>     }
>> }
>>
>
> Nice pattern!  Would this also work?
>
>     var skipFirst = genFn => function*(...args) {
>         var iter = genFn(...args);
>         iter.next();
>         yield * iter;
>     };
>
>     var echo2 = skipFirst(echo);
>
> If we have decorators, then we can write:
>
>     @skipFirst
>     function echo() { /*_*/ }
>
> which is fairly pleasant.
>
> Still, it seems like we're papering over a hole.  In principle, why
> shouldn't we be able to access the first next argument?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140819/dff37257/attachment.html>


More information about the es-discuss mailing list