> De: "Jesper Steen Møller" <jes...@selskabet.org> > À: dev@groovy.apache.org > Cc: "Remi Forax" <fo...@univ-mlv.fr> > Envoyé: Mercredi 19 Octobre 2016 01:15:47 > Objet: Re: Lambda expression for Groovy 3
> "Real lambdas" with the full invokedynamic treatment is a big job, and > requires > static type inference. > Given that Groovy can already coerce closures into functional interfaces > (dynamically), we could implement the whole metafactory-stuff with the static > compilation, and as a separate effort, right? > Also: Fantastic job, Daniel! > -Jesper You can even use the LambdaMetaFactory at runtime, if you propagate the target type to the point you create the lambda, currently it's two operations in groovy, create the closure and then convert it to a functional interface, but it can be done in one operation, this is what Nashorn does. But you don't have to do that now. It's more an optimization than anything else. The thing is that if you you the lambda metafactory, you get two optimizations: if the lambda doesn't capture any values, the lambda is seen by the JIT as a constant, this optimization is important mostly for the stream API because the JIT can inline all the lambda code at the location you use the stream (otherwise, it depends if the escape analysis is in a good day or not). The second optimization is that if the lambda capture values these values are seen as field that can not be changed after the creation of the lambda (like true final fields that the reflection can not change). This second optimization is less important and just nice to have. Also, you can emulate what the lambda metafactory does in the MOP2, but it requires to use Unsafe (a part which is not removed in 9) which is no a good strategy on the long term, it's better to delegate the creation of the lambda to the metafactory to the optimizations for free. The static compilation will make easier to see the creation of the closure and its cast to a functional interface as one operation, enabling to use the lambda metafactory but as i said above, you can use the lambda metafactory at runtime. Rémi > On 18. okt. 2016, at 22.46, Guillaume Laforge < glafo...@gmail.com > wrote: >> I assumed so, but wanted to be sure :-) >> On Tue, Oct 18, 2016 at 10:35 PM, Remi Forax < fo...@univ-mlv.fr > wrote: >>> I would say Groovy Closure with the Java syntax. >>> Rémi >>> On October 18, 2016 8:21:34 PM GMT+02:00, Guillaume Laforge < >>> glafo...@gmail.com >>> > wrote: >>>> Is it actually Groovy closures? or "real" Java lambdas? >>>> On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou < blackd...@gmx.org > >>>> wrote: >>>>> hah, I knew you can do it ;) >>>>> On 18.10.2016 18:34, daniel_sun wrote: >>>>>> Jochen, lambda expression is fully supported now :) >>>>>> https://github.com/danielsun1106/groovy-parser/commit/c380e4230ecef350855b9f56a220411635a7ff87 >>>>>> https://github.com/danielsun1106/groovy-parser/blob/master/src/test/resources/core/Lambda_01x.groovy >>>>>> Cheers, >>>>>> Daniel.Sun >>>>>> 在 "Jochen Theodorou [via Groovy]" <ml-node+[hidden email] >>>>>> </user/SendEmail.jtp?type=node&node=5736176&i=0>>，2016年10月18日 00:37 >>>>>> 写道： >>>>>> On 17.10.2016 17:40, daniel_sun wrote: >>>>>> > Hi all, >>>>>> > Lambda expression for Groovy has been completed with a little >>>>>> > limitation, which is due to the existing closure whose parameter >>>>>> list can be >>>>>> > ambiguous to lambda expression, e.g. {a -> a} which can be parsed >>>>>> as a >>>>>> > lambda expression in a block, but we expect it a closure. >>>>>> I think that limitation is ok >>>>>> > In order to >>>>>> > resolve the ambiguities, the parentheses for parameters is a >>>>>> must, e.g. >>>>>> > *Java8* allows parentheses-less parameter for lambda when the >>>>>> parameter is >>>>>> > single and without type: e -> e, but *Groovy* only allows >>>>>> parameter with >>>>>> > parentheses: (e) -> e. >>>>>> > *Here are some examples for lambda expression for Groovy:* >>>>>> > assert 9 == [1, 2, 3].stream().map((e) -> e + 1).reduce(0, (r, e) >>>>>> -> r + e) >>>>>> which means you cannot write >>>>>> > assert 9 == [1, 2, 3].stream().map(e -> e + 1).reduce(0, (r, e) >>>>>> -> r + e) >>>>>> which I find not so ok. Here again it would be no problem if it is >>>>>> recognized as Closure if that is more easy to accomplish. >>>>>> bye Jochen >>>>>> ------------------------------------------------------------------------ >>>>>> If you reply to this email, your message will be added to the >>>>>> discussion below: >>>>>> http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736171.html >>>>>> To unsubscribe from Lambda expression for Groovy 3, click here. >>>>>> NAML >>>>>> < >>>>>> http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml >>>>>> > >>>>>> ------------------------------------------------------------------------ >>>>>> View this message in context: Re: Lambda expression for Groovy 3 >>>>>> < >>>>>> http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736176.html >>>>>> > >>>>>> Sent from the Groovy Dev mailing list archive >>>>>> < http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html > at >>>>>> Nabble.com . >>>> -- >>>> Guillaume Laforge >>>> Apache Groovy committer & PMC Vice-President >>>> Developer Advocate @ Google Cloud Platform >>>> Blog: http://glaforge.appspot.com/ >>>> Social: @glaforge / Google+ >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> -- >> Guillaume Laforge >> Apache Groovy committer & PMC Vice-President >> Developer Advocate @ Google Cloud Platform >> Blog: http://glaforge.appspot.com/ >> Social: @glaforge / Google+
