Concurrency support?

[Brendan Eich]

On Jun 27, 2006, at 1:57 AM, Graydon Hoare wrote:

> Aside from the painful fact that we've already implemented something
> more like #1, is this really so unreasonable?

There's nothing painful for Mozilla's C implementation in doing more  
work, apart from the cost of more work which is minor if the design  
is right.  The question is, what's the best design?

If the design should not be compromised by implementation issues,  
then we should agree on that.  ECMA TG1 was not of one mind on "damn  
the implementation costs, full speed ahead".  We have JITted runtimes  
already tracking ES4 (Adobe), based on Waldemar's old drafts  
(JScript.NET).  We have small-ish to tiny interpreters (Apple,  
Opera).  We do not have the Lua single-implementation code-is-spec  
open source codebase.

The design questions that bother me are:

1.  Comprehensibility to mere mortals.

2.  No arbitrary/painful-in-extremis restrictions, such as "can't  
cross abstraction barrier B (but may cross A)".

3.  On the other hand, Nicolas's argument in favor of opening the  
black box.

By following Python we are using some leverage for 1, and even if you  
don't know Python, the current design (a kind of return from an  
iterator that allows resuming the iterator's underlying generator  
function where it left off) is simpler by one measure.

I'm with Lars on 2.

I'm still pondering 3.

/be