Updated State of the Lambda

[=?GB2312?B?UqimbWkgRm9yYXg=?=]

 Le 18/10/2010 15:06, Alex Blewitt a ¨¦crit :
> 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).

I don't think it's possible to implements lambda that use the DA/DU
trick using method handle.
If this kind of lambda is implemented using an inner class, there is no
problem.

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

It's an API design. if method handles are mutable you can't use them to
specify target of
invokedynamic without spurious NPE because you will be able to publish
the target even
if some field containing bound object or adapted method handles are not
yet initialized.

> Why could the compiler not recognise the use of (lambda) this and
> provide it as an argument as you suggest?

Because it's not the same object. If you mutate a method handle, you
create a new one
due to its immutable nature.

MethodHandle mh = #{ MethodHandle anotherMH -> mh == anotherMH };
mh.invokeGeneric(mh) // false

because, it's translated to:

static boolean lambda$1(MethodHandle mh, MethodHandle anotherMH) {
return mh == anotherMH;
}

MethodHandle mh = #lambda$1;
mh = mh.bindTo(mh);

mh.invokeGeneric(mh); // return mh == #lambda$1 => false


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

Yes, as suggested by end of section 7, the only way to reference the
current lambda is
by a corresponding SAM object.

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

I don't see your point here. You will do taillcall in the inner-class.
Where is the problem ?

>
>> That why 'this' refers to the enclosing object.
>>
>> R¨¦mi

R¨¦mi