Concurrency support?

[Brendan Eich]

> I don't follow this.  A tiny interpreter will have to escape from
> natural host recursion anyway just in order to do simple Python/Icon
> generators, and I don't see that yielding within C functions is
> so essential to the concept -- I'd be happy with just what Lua
> (unJITted) provides.

  I mean by natural recursion that each activation of an ES function  
is interpreted by a host (let's say C) function.  Unwinding and  
winding back through C functions requires mangling them to use  
explicit control state, or else using something akin to a user-level  
thread (setjmp/longjmp, setcontext, etc.).

With the Pythonic generators currently proposed for ES4, there's no  
need for such host stack saving and restoring.  As Bob pointed out,  
you just need to save the generator function's frame.

Native C functions don't have to be involved for this stack saving/ 
restoring to be an unwanted burden, but if you propose to allow yield  
to "return across" many frames, then it's hard to avoid a native  
frame creeping into the stack that's being crossed, and then you  
definitely need user-level threads, safe stack allocation with  
redzones for overflow, etc.  That's too costly for small  
implementations.

Murphy was an optimist, and abstraction favors allowing arbitrary  
native or ES implementation of any function in a large program.

/be