Updated State of the Lambda

[Peter Levart]

On 10/18/10, Rémi Forax wrote:
>   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.

That's right. But does it matter? Aren't method handles primarily meant to be invoked? And as far as the invoking is concerned, the two method handles could be indistinguishable. Method handles are immutable, so they don't suffer from problems of SAM classes. It's like having new Integer(1) vs. new Integer(1);

Peter

> 
> >>> Peter
> >>>
> >>>
> 
> Rémi
> 
> 
>