transparent lambda

[Neal Gafter]

On Wed, Dec 30, 2009 at 10:47 AM, Stefan Schulz <schulz at the-loom.de> wrote:
> On 30.12.2009 17:42, Neal Gafter wrote:
>> What does this do?
>>
>>   1. prints "4"
>>   2. throws an exception
>>   3. prints "2"
>>   4. Sometimes prints "2", sometimes throws an exception
>>   5. does not compile
>
> Choice 5, as four is not static ;)
> With the current syntax planned for lambdas, Choice 1 would be correct and to me the least surprising one (no puzzler at all).

Right: statement lambdas are not transparent in project lambda.  I've
taken that position in CfJ 0.6 as well.  The point of the present
discussion is to determine if there is a (reasonable) way to have only
one kind of lambda that is transparent.

>> If you make statement lambdas transparent, the answer is choice 4: the
>> method prints "2" on its first execution, and throws an exception
>> (unmatched transfer) thereafter.
>
> So you'd bind the creation of the lambda to the actual first run of the method? Why is that? IMHO, if it were the same instance and the same method, it should just work fine, as long as it is invoked from within the method's scope.

You bind a "return" statement to return from the *invocation* of the
method the lambda was created within (analogously, when you capture
local variables you capture them from the invocation at the time the
lambda was created).  In the sample program, the lambda from the first
invocation is reused for the second invocation, after its enclosing
method has already returned.

You're advocating dynamic scoping, which pretty much died in the mid
1970's.  Dynamic scoping interacts particularly badly with recursion.