On May 14, 2009, at 2:10 PM, Mark S. Miller wrote:
On Thu, May 14, 2009 at 1:22 PM, Brendan Eich <bren...@mozilla.com>
wrote:
On May 14, 2009, at 12:24 PM, Jason Orendorff wrote:
3. When a lambda yields, [...]
there may be other functions on the stack, in between. You can't
always statically tell which ones. This means that generator
semantics affect the integrity of code that isn't in a generator.
[...] this extends the finally integrity
degradation outside of the lexical scope of the generator function.
Good
point.
[...] with generators+lambdas, almost any function call *anywhere*
in the
program might never return or throw. This weakens 'finally', at
least.
[...]
function gen(arg) {
foo((lambda (x) yield x), arg);
}
function foo(callback, arg) {
try {
callback(arg);
} finally {
alert("I'm ok!");
}
}
g = gen(42);
print(g.next()); // tell the user the meaning of life, etc.
g = null;
gc();
Thanks all, this has been very clarifying. You both have put your
finger on what was nagging at me and explained it clearly.
I think we missed an alternative that comports with Tennent's Oversold
Correspondence Principle, *and* composes. Thanks to Dave Herman for
pointing it out.
function gen(x) {
foo( lambda (x) (yield x*x) );
}
need not yield from gen if the lambda is called from foo or another
function -- it can throw the same error it would throw if the lambda
escaped upward/heapward and was called after gen had returned. There's
no requirement that yield not throw in any case where the lambda is
not applied in the context of gen.
I've seen magical thinking applied to both TCP and LSP, to the
detriment of the concrete application of these principles. TCP does
not mean yield plus lambdas must require delimited continuation.
The big advantage of yield other than the utility (good not great,
less than some folks want, and hard to compose), and the Python
brainprint re-use (also good IMHO, but this could degrade over time),
is the ease of implementation. Ecma TC39 is going to have a hard time
standardizing deeper continuations. Never mind the challenges facing
lambda.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
