Do we really need async generators?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Do we really need async generators?

Axel Rauschmayer-2
I’ve thought some more about the async iteration proposal [1] and my thinking has evolved:

* I find the async iteration protocol and `for-await-of` useful.
* But I still suspect that Communicating Sequential Processes (i.e., async functions plus library code) are a simpler solution than async generators.

I’m genuinely interested in finding the best possible approach, so any kind of feedback is welcome – especially if CSP have any kind of deficiency that I have overlooked.

Details: https://gist.github.com/rauschma/4dc86ea81585fcfe056de3caa19aa38f (I’ll probably publish this blog post on Monday or Tuesday)



Axel

-- 
Dr. Axel Rauschmayer
[hidden email]
dr-axel.de


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Do we really need async generators?

Isiah Meadows-2
Missed the list...

---------- Forwarded message ----------
From: Isiah Meadows <[hidden email]>
Date: Mon, Mar 13, 2017 at 12:14 AM
Subject: Re: Do we really need async generators?
To: Axel Rauschmayer <[hidden email]>


From my basic reading, this is not that far off of how iterators work
without `for ... of`. When I don't have those loops available (e.g.
working in ES5 code), I've found this pattern to be really helpful in
interoperating with ES6 collections:

```js
for (var next = iter.next(); !next.done; next = iter.next()) {
  // use `next.value`
}
```

That's very similar to your idea of iterating CSP collections:

```js
for (var next = await channel.take(); next !== Channel.DONE; next =
await channel.take()) {
  // use `next`
}
```

It's also similar to how C++'s iterators worked before C++ 11:

```cpp
for (std::vector<int>::iterator iter = vec.begin(); iter != vec.end(); iter++) {
    // use `*iter`
}
```

This will get unwieldy in a hurry due to its verbosity, though, and
even C++ added a sugar version to abstract this. Hence the async
iterator proposal.

I do feel CSP channels are closer to Node streams and observables than
async iterators, though, and your proposal seems awfully similar to
[this][1]. I do feel that your CSP ideas could really carry over with
my [non-linear control flow strawman][2], though (Note that I'm about
to redo much of that strawman, to clean it up substantially).

[1]: https://github.com/tc39/proposal-observable/issues/129
[2]: https://gist.github.com/isiahmeadows/ba298c7de6bbf1c36448f718be6a762b
-----

Isiah Meadows
[hidden email]


On Sat, Mar 11, 2017 at 11:00 AM, Axel Rauschmayer <[hidden email]> wrote:

> I’ve thought some more about the async iteration proposal [1] and my
> thinking has evolved:
>
> * I find the async iteration protocol and `for-await-of` useful.
> * But I still suspect that Communicating Sequential Processes (i.e., async
> functions plus library code) are a simpler solution than async generators.
>
> I’m genuinely interested in finding the best possible approach, so any kind
> of feedback is welcome – especially if CSP have any kind of deficiency that
> I have overlooked.
>
> Details: https://gist.github.com/rauschma/4dc86ea81585fcfe056de3caa19aa38f
> (I’ll probably publish this blog post on Monday or Tuesday)
>
> [1] https://github.com/tc39/proposal-async-iteration
>
>
> Axel
>
> --
> Dr. Axel Rauschmayer
> [hidden email]
> dr-axel.de
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Loading...