Updated State of the Lambda

[Maurizio Cimadamore]

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