Dataflow concurrency instead of generators

[David-Sarah Hopwood]

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 ⚥