Updated State of the Lambda

[Alex Blewitt]

On 18 Oct 2010, at 13:26, R¨¦mi Forax <forax at univ-mlv.fr> wrote:

>  Hi Alex,
> I really hope that most of the lambdas can be implemented using method 
> handles.

Yes, I agree. 

> There are several advantages to use a method handle instead of a plain 
> old inner class
> to represent a lambda at runtime.

Yes, I agree. 

> 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.

There is no difference between "this" and a recursive reference to the lambda as per the current proposal's example, though. The majority wouldn't be recursive so wouldn't need any capturing - and for when it is needed, could be captured as per the implementation suggested (unlike instance inner classes which capture it all the time). 

> 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,

That's an implementation issue, not language design. Why could the compiler not recognise the use of (lambda) this and provide it as an argument as you suggest?

> 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.

This mechanism implies all recursive functions will be promoted to objects. When tail calls are added to the VM, not having a good way to do recursive calls with method handles without doing implicit SAM conversion will be potentially problematic. 

> 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.
>>>> 
>>>> 
>>>> 
>> 
> 
>