transparent lambda

Peter Levart peter.levart at
Wed Dec 30 13:00:01 PST 2009

How is 'invocation of a method' defined? What would happen if method
four was invoked multiple times from a loop:

for (int i=0; i<2; i++)

Would it this also throw unmatched transfer?

Regards, Peter

On 12/30/09, Neal Gafter <neal at> wrote:
> On Wed, Dec 30, 2009 at 10:47 AM, Stefan Schulz <schulz at> 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.

Sent from Gmail for mobile |

More information about the closures-dev mailing list