groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: Groovy 3.0 Java Lambda
Date Tue, 03 Apr 2018 23:01:12 GMT
Hi Jochen,

that sounds good :-)

(I have posted a conceptually different idea for implementing "inlined 
'closure' blcoks"  in the "Appended Block Closures" Jira ticket:
https://issues.apache.org/jira/browse/GROOVY-8301?focusedCommentId=16424692&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16424692

)

Cheers,
mg


On 04.04.2018 00:03, Jochen Theodorou wrote:
> On 03.04.2018 19:17, mg wrote:
>> With regards to Groovy 3.0 Java lambda support: Is it practically 
>> doable to turn a Groovy closure into a Groovy Java lambda if only 
>> effectively final variables are used inside the closure ? And if yes, 
>> might that be a future Groovy feature ?
>
> My idea is to have a simple Closure object that has the required 
> information plus a handle for the method implementation(s) and that 
> this can be used internally with a special callsite to implement the 
> usage of the delegate and the resolution strategy. That means we my 
> not be able to use a lambda factory for this, but well, the 
> implementation would be similar to normal Java lambdas. Similar enough 
> to be able to use the exact same mechanism as lambdas in some cases. I 
> think with a bit thinking we would arrive at a more universal 
> mechanism usable for both... but maybe not with LambdaFactory like 
> Java does.
>
>> I am asking because otherwise there will exist two quite different 
>> anonymous function syntax varieties in Groovy, with both most likely 
>> being in active use, instead of one just existing for Java syntax 
>> compatibility reasons. Which of course works, but feels a bit messy / 
>> un-Groovy, and also can lead to code being executed slower than 
>> possible, if someone uses Groovy closure syntax everywhere.
>
> I think most cases of lambdas are operating on data they get. We could 
> define a closure like interface for these and convert a normal 
> Closures falling under that category to this new SAM Closure interface 
> instead.
>
>> Or would "closure inlining" support be the better approach here (also 
>> with regard to implementation effort), since turning e.g. a forEach + 
>> cls expression into a for-loop with the cls inlined as a block should 
>> be even faster than using a Java lambda ?
>
> I see what I described above actually as a required step for that kind 
> of inlining. You need that to be able to handle the pseudo Closures 
> you still require to handle strategies and special callsites. But I 
> see it possible
>
> bye Jochen
>
>
>


Mime
View raw message