peter.levart at gmail.com
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?
On 12/30/09, Neal Gafter <neal at gafter.com> wrote:
> 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.
Sent from Gmail for mobile | mobile.google.com
More information about the closures-dev