Brendan Eich wrote:
> On May 14, 2009, at 4:34 PM, David-Sarah Hopwood wrote:
>
>> This approach avoids any problems due to a generator being able
>> to interfere with the control flow of its callers.
>
> A generator can't interfere with the control flow of its callers.
>
> Can you give an example of what you meant by that?
I meant this:
Brendan Eich wrote:
> Jason Orendorff wrote:
>> In ES5, when you call a function, you can expect it to return or throw
>> eventually. (Unless you run out of memory, or time, and the whole
>> script gets terminated.) With shallow generators, this is still true.
>> A 'yield' might never return control, but function calls are ok. But
>> with generators+lambdas, almost any function call *anywhere* in the
>> program might never return or throw. This weakens 'finally', at
>> least.
>
> To make this clear with an example (thanks to Jason for some IRC interaction):
>
> function gen(arg) {
> foo((lambda (x) yield x), arg);
> }
> function foo(callback, arg) {
> try {
> callback(arg);
> } finally {
> alert("I'm ok!");
> }
> }
> g = gen(42);
> print(g.next()); // tell the user the meaning of life, etc.
> g = null;
> gc();
>
> I think finally is the only issue, since how else can you tell that foo
> didn't see a return or exception from the callback?
The consequences of this issue are not restricted to code using
'finally'; even without finally, yield+generators complicates the
conceptual model of call-return control flow, in ways that are not
possible with yield alone (since yield is restricted to only making
non-local jumps to lexically enclosing labels) or shallow generators
alone (since they can be modelled as a local transformation).
The recent huge thread on python-ideas about "yield-from" disabused
me once and for all of the idea that (non-shallow) generator semantics
are simple to understand, even for experts.
--
David-Sarah Hopwood ⚥
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
