Lars T Hansen
lth at opera.com
Tue, 27 Jun 2006 08:51:01 +0200
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
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
I'm with Brendan: "abstraction favors allowing arbitrary native or ES
implementation of any function in a large program."