lambda and dynamic JVM languages interropt

[Jochen Theodorou]

Am 06.11.2012 14:48, schrieb Remi Forax:
[...]
> 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.

I think I still don't follow 100%.

There is Java lambda to my language... either I make a call from Java 
with some SAM to my runtime, so that I get the right thing already, or I 
have the ready object. Assuming I am using internally MethodHandles and 
want the handle from the proxy, I first need to know it is a lambda (for 
example a marker interface) and then means to extract the handle from 
the Java lambda. In this direction nailing the ways used in meta factory 
could help, if for example for the inner class case a certain layout is 
guaranteed. But the call site doing that is in Java code and not under 
my control, or am I wrong here? I mean I doubt there has been thought to 
a way to give an alternative bootstrap method, or to let the bootstrap 
method delegate to another method, defined at runtime. So what is 
essentially missing here is to extract the method handle from the ready 
object.

And the other way is me calling Java and converting my lambdas to Java 
lambdas. Assuming I have ways to get the MethodHandle from the code I 
control this should be no problem. Then when is that not the case? Maybe 
if I don't generate bytecode...

Is that what you wanted to say?

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org