How would shallow generators compose with lambda?

[Brendan Eich]

On May 14, 2009, at 2:10 PM, Mark S. Miller wrote:

> On Thu, May 14, 2009 at 1:22 PM, Brendan Eich <brendan at 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