Concurrency support?

[Graydon Hoare]

> I'm with Brendan: "abstraction favors allowing arbitrary native or ES
> implementation of any function in a large program."

Ok. I was trying to make two points and I'm not sure if they made it:

  - You're making a *stronger* restriction by making yields only ever one frame deep;
    essentially this PEP technique is syntactic sugar for special sorts of call/return.
    Control never yields across multiple frames. With the technique lua uses, control
    "sometimes" yields across multiple frames. A strict superset of the functionality.

  - That "sometimes" need not be vague or hard to determine. We have a way for code to 
    indicate native-ness of a function already: the 'native' keyword. We could easily
    reflect that (and there's no sensible argument one can make that it's extra baggage
    to carry around; the implementation *must* know) so the user's script can find out 
    and insulate against it. 

    Keep in mind that the problem case is only yielding *through* a native frame. So 
    if your native sort() calls script, script can yield *to* the native frame if the
    yielding is part of the sort operation. Only if the script callback yields, expecting
    to yield *through* the native sort(), do you have a problem. I'd argue that such 
    yields are only likely to arise in a co-operative tasking system, and probably
    don't suffer so much from being insulated by being wrapped in a run-to-completion
    helper function. The yield is not being used as a part of an iteration protocol, just
    as a time slicer. Bigger slice, no big deal. All speculation, of course.

But I don't really care passionately; I was just arguing as devil's advocate because it didn't seem like you were giving the feature a fair shake. I also thought that by introducing script-level coroutines you might be able to appease some users who argue for further threads (or, gasp, call/cc) in the browser.

-graydon