Updated State of the Lambda

[Rémi Forax]

  Le 18/10/2010 16:14, Maurizio Cimadamore a écrit :
> On 18/10/10 15:05, Peter Levart wrote:
>> On 10/18/10, Rémi Forax wrote:
>>
>>>> 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.
>>>
>>>
>> Ah, now I understand your concern. You would like lambda expressions to be convertible to method handles (java.dyn.MethodHandle) as well as to SAM types.
>>
>>
>>> 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
>>>
>> Why couldn't compiler translate it to:
>>
>> static boolean lambda$1(MethodHandle anotherMH) {
>>     return #lambda$1 == anotherMH;
>> }
>>
>> MethodHandle mh = #lambda$1;
>>
>> mh.invokeGeneric(mh); // return #lambda$1 == #lambda$1 =>   true?
>>
> Hi Peter,
> note that the bindTo/insertArgs solution avoids the problem that one or
> more 'synthetic' arguments could not be available anymore when the
> lambda expression is called (i.e. when the Sam type escapes its creation
> context). You really want clients to just specify the arguments required
> by the SAM method, regardless of any other synthetic arg that the
> compiler might have inserted in the translated code.
>
> Maurizio

As Maurizio said, it doesn't work if the lambda capture variable 
contents from outer scope.

>> Peter

Rémi