Questions/issues regarding generators

Jason Orendorff jason.orendorff at gmail.com
Thu Mar 14 18:33:44 PDT 2013


On Thu, Mar 14, 2013 at 3:48 PM, Andreas Rossberg <rossberg at google.com>wrote:

> On 8 March 2013 18:23, Jason Orendorff <jason.orendorff at gmail.com> wrote:
> > and you definitely don't want new state here, because what would that
> even
> > mean? A read position is kind of inherent to a file descriptor, right?
>
> A generator is an abstraction that is intended to be invokable many
> times. Are you saying that there are generators for which you cannot
> do that?
>

Eh? No, I'm saying you generally don't want to restart functions
automatically and implicitly.

Currently, if you call a generator, you get a coroutine. I think what
you're suggesting would instead make generators return a coroutine factory,
and have coroutines implicitly created in many situations. That seems like
it might be bad to me. Not all generators are as straightforward as enum.
They can have side effects, etc. Implicitly creating extra copies of these
things which are kind of like new threads of execution sounds potentially
awful to me.

Also—if you wanted to use generators in a really coroutine-like way, like
task.js does, under your scheme you'd have to explicitly call the @iterator
method in order to get the object you want, the one that has .next(),
.send(), .throw(), and so on. (Not a showstopper, as it's going to be
pretty specialized code that does that.)

I can see that the suggestion might look like a complication, but I
> think it is a fairly minor one, and more importantly, in practice will
> almost always be confined to abstractions.
>

I agree that in most use cases, no difference will be observed.

-j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130314/ef34475f/attachment-0001.html>


More information about the es-discuss mailing list