Updated State of the Lambda

[Rémi Forax]

  Le 18/10/2010 16:22, Peter Levart a écrit :
> On 10/18/10, Maurizio Cimadamore wrote:
>> 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
> I'm not suggesting to stop specifying other synthetic arguments via bindTo/insertArgs. Just the "this" Method handle argument (not called 'this' anymore) which can always be re-constructed inside the lambda method. I don't think it is possible to re-construct the same MethoHandle (by reference), but I think it's possible to reconstruct the equivalent one.
>
> Peter

The reconstructed method handle could have a different identity or not
depending on the implementation of the JSR 292 spec.

>>> Peter
>>>
>>>

Rémi