Concurrency support?

[Lars T Hansen]

Graydon Hoare writes:
 > Brendan Eich wrote:
 > 
 > >> That seems unlikely since the same restriction probably applies to PEP 
 > >> 324 yields.
 > > 
 > > No, it doesn't.  There is no yield across more than one level of call.
 > 
 > Oh. Somehow I was picturing a C python extension calling back into 
 > python, and trying to suspend itself in order to yield back to its 
 > caller. I guess they can just "not do that in an extension"; doesn't 
 > affect the python code on either side.
 > 
 > In any case, consider our two options:
 > 
 >    1. copying python: "no yield across more than one level of call"
 >    2. copying lua: "no yield across a language barrier"
 > 
 > We have a putative concept of "language barrier" in ES4 already: methods 
 > marked as "native". We could probably adopt #2. I claim that #2 is a much 
 > less severe restriction than #1, and gives the users (who mainly write 
 > 100% script) much more power.
 > 
 > Aside from the painful fact that we've already implemented something 
 > more like #1, is this really so unreasonable?

In most Scheme implementations that provide a foreign-function
interface with callbacks to Scheme the user program can't reliably
capture continuations in the callback.  This is generally considered a
hardship and implementations that fix it are considered superior.  Of
course, that's Scheme, and its users expect nothing but full
generality.  But I'd be worried about option #2 for that reason.

ECMAScript already has potential script-native-script call stacks in
library functions that accept callbacks, like Array.prototype.sort and
RegExp.prototype.replace.  So option #2 would be a restriction in all
implementations that are not prepared to write their libraries in
ECMAScript.  So it would be implementation dependent whether you could
yield from a callback to these methods.  This does not seem like a
feature.

Granted, the programmer is not likely to write a generator that yields
out of a callback to sort(), but I object to him having to discover
that he can't do so reliably.  And if a dominating product in a market
(eg, MSIE) decides to implement sort() in ECMAScript and thus allow
this pattern, other implementations will have little choice but to
follow suit.

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

--lars