Dataflow concurrency instead of generators

[Brendan Eich]

On May 16, 2009, at 5:50 PM, David-Sarah Hopwood wrote:

> But you are right that dataflow concurrency is probably not
> sufficient on its own if we want to make Harmony a practical
> concurrent language.

That is not a goal at this point, and TC39 wouldn't hold the "H"- 
release for it.


> Bear in mind, though, that adding message passing significantly
> increases the expressiveness of the language, so we should take that
> into account when comparing the complexity of (lambdas + generators)
> with that of (lambdas + dataflow concurrency + message passing).
> The latter is much more powerful.

Who says lambdas are "in"? Who says power is the good to maximize?  
We've talked about avoiding things like lambdas with completion result  
and TCP hazards, and full call/cc, to avoid inappropriate programmer  
and implementor burdens and honey traps.

Generators do not require concurrency in the implementation or the  
language, and they're easy to implement in current engines.

Harmony is not a research language. Anything like what you describe  
would have to be prototyped by one or more of the major implementors.  
We'll see. Some grains of salt are prescribed along with enthusiasm in  
the mean time.


> I'll describe the details of what I'm proposing, and how it applies
> to your example (which does work in this model), in a separate
> message, with subject "Dataflow concurrency and message passing
> for Harmony".

Looking forward to it.

/be