some generator issues

Yuh-Ruey Chen maian330 at gmail.com
Sun Apr 22 02:04:49 PDT 2007


Brendan Eich wrote:
> On Apr 22, 2007, at 1:12 AM, Yuh-Ruey Chen wrote:
>
> > There are a couple of issues I see with the generator proposal.
> >
> > 1) What happens when send(x) is called on a newly created  
> > generator? In
> > Python, this results in an exception unless x is None.
>
> See http://developer.mozilla.org/es4/proposals/ 
> iterators_and_generators.html#generators which contains this sentence:
>
> "A generator must be started by a method call to next() or send 
> (undefined). It is a TypeError to send a value other than undefined  
> to a newborn generator."
>   

Ack, I didn't see that - I was only looking at the bulleted points above
that statement.

> > 3) Is there any way to get a generator from within a generator  
> > function?
> > One use case for this would be asynchronous callbacks (can't  
> > synchronous
> > because of issue 2 noted above):
> >
> > // client calls this function somewhere
> > function clientFoo() {
> >     let serverResponse = yield (server.asyncProcedure 
> > (clientFooGenerator));
> >     print(serverResponse);
> > }
> >
> > // server.asyncProcedure calls this once it's finished, passing
> > clientFooGenerator for gen
> > function serverCallback(gen, retvals) {
> >     gen.send(retvals);
> > }
> >
> > The only way to do this right now is to wrap the generator function
> > within a function that introduces the iterator to the generator
> > function's scope:
> >
> > function foo() {
> >     var $gen = function() {
> >        // generator code that can use $gen
> >     }();
> >     return $gen;
> > }
> >
> > This is fairly inefficient and is a hassle to do.
>
> Efficiency may be ok, depends on the implementation. Alternative to  
> this FP style is an OOP approach that makes |this| for the generator  
> be an instance with a var referencing the generator iterator for that  
> instance.
>   

I thought of that, but if foo were a method, |this| would already be taken.

> > Other methods rely on
> > some sort of generator manager (shift the responsibility to the code
> > handling the generators rather than within them) or using global
> > generator vars (which would force the generators to be specific to the
> > script containing those vars), both of which aren't ideal in the above
> > use case.
> >
> > I'm unaware of a Python solution to this issue.
>
> Hard to standardize an argument; don't want another keyword.  
> Suggestions?
>
> /be
>   

I was thinking of adding another property to the arguments object.
Perhaps, arguments.generator. The value for this property would be null
(or undefined) if the function isn't a generator function.

- Yuh-Ruey Chen



More information about the Es4-discuss mailing list