Dataflow concurrency instead of generators

[Brendan Eich]

On May 15, 2009, at 11:15 AM, Jason Orendorff wrote:

> I like the idea of going after the concurrency problem now.  I like
> the idea of doing one language feature instead of two (concurrency and
> generators).  Do you have a solution in mind for this kind of problem?

Not to rain on anyone's parade here, but Ecma TC39 is not the right  
group to do research and then standardize it.

We can spend unlimited es-discuss messages on this, of couse, but (a)  
at a cost to other discussions; (b) not if the undelivered, always- 
over-the-next-hill promise of a unified solution is used to stop  
progress of extensions toward standardization in TC39. One can easily  
wait forever for the best -- Voltaire had something to say about that.

Implementors should experiment and take risks in the market. TC39  
should standardize after that all shakes out. If we can have  
agreements in committee on direction and even details, great. But the  
committee does not have the breadth or competence to invent much  
that's new while standardizing.

Meanwhile, until some two-birds-one-stone solution emerges (which  
could happen, I'm skeptical about it happening soon), we have  
generators shipping in SpiderMonkey and Rhino, and they help  
programmers avoid having to hand-code tedious and error-prone state  
management (control blocks for callbacks) when solving common  
iteration and pseudo-threading problems.

But perhaps generators could be informative for a while. The reason  
they came up was, as Mark said, because they were an extension already  
considered Harmonious in TC39.

/be