Updated State of the Lambda

[Rémi Forax]

  Hi Alex,
I really hope that most of the lambdas can be implemented using method 
handles.
There are several advantages to use a method handle instead of a plain 
old inner class
to represent a lambda at runtime.

Method handles are anonymous functions, there aren't bound to an object 
by default,
they are more like static methods.
Trying to provide a 'this' that reference the current lambda is not 
easily doable.
Method handles are immutable by design and the only way to get the 
current method handle
in a method handle is to inject itself as argument, but because the 
injection is a mutation
this will create a new method handle which is different from the one 
injected.

In my opinion, a lambda should be seen as an expression or an 
instruction, not as an object.
The SAM conversion will transform the lambda to an object.
That why 'this' refers to the enclosing object.

Rémi

Le 18/10/2010 10:37, Alex Blewitt a écrit :
> I think the change has just flipped the polarity of the changes; whereas before we had abnormal return and normal this, now we have abnormal this and normal return (or vice versa, if such is your preference). We have a crossover of the two concepts here which was present in the first release as well.
>
> As I have said before, I think not binding 'this' to lambdas is a mistake. The DA/DU rules are being stretched, some would say to breaking point, to permit this convolution. Will the weakening of DA/DU cause problems elsewhere? It's certainly a possibility.
>
> The argument of not referring to 'this' as the lambda uses a argument to say that a lambda that doesn't hold onto the enclosing class' instance will be more memory efficient than one that does (c.f. inner classes). However, whether the source code refers to 'this' is an orthogonal concept to whether the runtime representation refers to the instance of the enclosing class. For example, a (non-static) inner class has an implicit reference to the enclosing instance; it doesn't need to refer to 'this' in the body. Conversely, a static inner class may have 'this' injected into it, and thus maintain a reference.
>
> So whilst the conclusion - that lambdas holding an instance to another object are a kind of leak - is valid, it has nothing to do with the type of 'this' captured in the scope of a lambda. A reference to 'this' could point to the current closure (without referring to the original instance in which it was valid) whilst Outer.this could refer to the original instance; unless Outer.this was used, it wouldn't be leaked away in the example described.
>
> Finally: the rules for interpreting 'this' within inner classes are already well known. This is orthogonal to whether the runtime instance actually captures a reference if no 'this' is used, and the argument on this basis is fallacious. Whether there are other reasons for choosing this are not well defined.
>
> Alex
>
> On 18 Oct 2010, at 09:04, Peter Levart wrote:
>
>> This is good news. In particular the 1st notable change below. This is a move in the right direction. I wonder if the reason for the cahnge was a result of desire to keep the door open for possible future extension to support "transparent" lambda or just of realization that lexical scoping has a better solution:problem ratio than annonymous inner classes style of scoping? In either case I think we are getting better lambda this way.
>> I can also understand that the benefit of "yield" was not worth the additional confusion it might cause, although replacing it for "return" it is a step away from transparent lambda.
>>
>> Regards, Peter
>>
>>
>> On 10/15/10, Brian Goetz wrote:
>>> An updated draft (Version 3) of the State of the Lambda has been published at:
>>>
>>>    http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html
>>>
>>> Notable differences from the previous draft include:
>>>   - 'this' in lambda expressions is lexically scoped
>>>   - 'yield' keyword dropped in favor of 'return'
>>>   - new syntax
>>>
>>> Maurizio will be pushing an implementation conforming to this draft soon.
>>>
>>>
>>>
>