lambda and dynamic JVM languages interropt

[Remi Forax]

On 11/06/2012 02:03 PM, Jochen Theodorou wrote:
> Am 06.11.2012 09:50, schrieb Remi Forax:[...]
>> Thinking a bit about that, the current lambda metafactory API is not
>> totally aligned with this goal.
>> The current API offers only single entry point (two in fact with
>> serialization) so there is no way for
>> JVM language developers to choose which representation of lambdas is
>> most suited for their language
>> (dynamic generation of inner-classes or method handle proxy).
>> I think we should provide 3 entry points (6 with serialization), the one
>> Java uses which select the best implementation
>> and delegates to one of the lambda implementation entrypoints, and 2 for
>> the two ways to represent a lambda.
>
> I am following the list only from time to time and I think there is a 
> detail I am missing here. So afaik we generate for the lambda a method 
> and we will have an invokedynamic based call site that is given the 
> handle of that method as well as the "target". The conversion is then 
> done by the metafactory API, which means either directly with 
> MethodHandles or with an inner class, which is generated at runtime. I 
> hope I am right so far.
>
> Now you suggest that I can force one or the other way, instead of 
> going though the generic path. My question now is... why should I not 
> want the generic way and force one?

Because you want back and forth interropt.
Being able to convert a method handle to a Java lambda is one side of 
the story,
the other side is to be able to take a Java lambda and convert it back 
to your language.

If your language uses an interfaces like Function0, Function1, etc then 
it's easy if
Java lambdas are represented as inner classes. If your language uses 
method handles,
it's easier if you can extract the method handle from the proxy.

>
> bye Jochen
>

cheers,
Rémi