You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by daniel_sun <re...@hotmail.com> on 2016/10/17 15:40:54 UTC
Lambda expression for Groovy 3
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. 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)
assert 9 == [1, 2, 3].stream().map((e) -> e + 1).reduce(0, (r, e) -> {r +
e})
assert 32 == ((e) -> e + 1)(2) + ((e, f) -> e + f)(2, 3) + ((e, f, g) -> e *
f * g)(2, 3, 4)
assert 24 == ((e, f, g) -> {e * f * g})(2, 3, 4)
assert 24 == ((int e, int f, int g) -> {
int tmpE = e;
int tmpF = f;
int tmpG = g;
return tmpE * tmpF * tmpG;
})(2, 3, 4)
assert 24 == ((int e, int f, int g=4) -> {
int tmpE = e;
int tmpF = f;
int tmpG = g;
return tmpE * tmpF * tmpG;
})(2, 3)
def list = [2, 3, 1]
Collections.sort(list, (n1, n2) -> n1 <=> n2)
assert [1, 2, 3] == list
*BTW, lambda expression is the first-class citizen in the expression
hierarchy, you can use lambda expression in the almost any place where you
use the closure as usual.* More information can be found at the home of
groovy-parser: https://github.com/danielsun1106/groovy-parser/
*In addition, you can try the groovy-parser by following the steps:*
$ git clone https://github.com/danielsun1106/groovy-parser.git
$ cd groovy-parser
$ ./gradlew groovyConsole
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
Hi Jochen,
I agree with you that the parentheses is not that groovy when lambda expression is a method parameter. In the past two days, I tried to achieve the ideal implementation through a variety of ways, but some code have to be duplicated, which is not elegant for the new parser.
It is the initial implementation, anyway. I'll set aside more time to try to refine it later ;) Thanks for your suggestions and reviewing.
Cheers,
Daniel.Sun
在 "Jochen Theodorou [via Groovy]" <ml...@n5.nabble.com>，2016年10月18日 上午12: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<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736169&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjE2OXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736174.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
Currently it leverages the power of closure, i.e. lambda expression for groovy is a subclass of closure.
Cheers,
Daniel.Sun
在 "Guillaume Laforge [via Groovy]" <ml...@n5.nabble.com>，2016年10月19日 上午2:21写道：
Is it actually Groovy closures? or "real" Java lambdas?
On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou <[hidden email]> 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<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
________________________________
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-tp5736169p5736178.html
To unsubscribe from Lambda expression for Groovy 3, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736169&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjE2OXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736183.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by Jochen Theodorou <bl...@gmx.org>.
On 19.10.2016 12:21, Remi Forax wrote:
[...]
> The main issue i see of having one semantics is that the meaning of
> 'this' in a Groovy closure means the closure itself while 'this' in a
> Java lambda means the enclosing object, so { -> this } in Groovy is a
> substitute to () -> this in Java.
that is not the case anymore in any version since 1.0. We do make a
difference between the implicit and the explicit this though. The
implicit this has a cofigurable meaning, while the explicit this always
points to the enclosing class. So if you do {-> toString()}, you may get
the toString() of the Closure, the enclosing class, the owner (which
might be an enclosing closure) or the delegate. Which is why with static
compilation we have to do tricks here.
[...]
> That said, the lambda metafactory takes a desugared lambda as argument
> (a plain old static method, apart in corner cases), so choosing the
> semantics of the lambda in Groovy is orthogonal to the choice of using
> the lambda metafactory or not.
if in a first step we map to Closure, then we won�t use the lambda
metafactory. If we do Closures similar to lambdas (which basically means
to get rid of Closure) Then the "resolution scope" for the implicit this
would have to become part of the method we map to
bye Jochen
Re: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
Hi Rémi,
'this' inside the closure references the instance of enclosing class, so no difference exists in the semantic of 'this'.
PS: I verified it using groovy2.4.7
Cheers,
Daniel.Sun
在 "Remi Forax [via Groovy]" <ml...@n5.nabble.com>，2016年10月19日 下午7:17写道：
Hi Cedric,
________________________________
De: "Cédric Champeau" <[hidden email]>
À: [hidden email]
Envoyé: Mercredi 19 Octobre 2016 09:09:51
Objet: Re: Lambda expression for Groovy 3
First of all, great work, Daniel ! I'm confident that making the "lambdas" be "closures" in Groovy is enough. I stated it in the past but I'm going to repeat myself here, I don't think having 2 syntax for "closures/lambdas" with slightly different semantics would help our users/language. That said, the static compiler can do better, doing escape analysis, and using "real" lambdas when the target bytecode is 8, as an optimization.
The main issue i see of having one semantics is that the meaning of 'this' in a Groovy closure means the closure itself while 'this' in a Java lambda means the enclosing object, so { -> this } in Groovy is a substitute to () -> this in Java.
The choice seems to be, the semantics of 'this' in a lambda in Groovy can be either the same as Java so you can copy/paste a Java code and it will work as is in Groovy or the same semantics as in a Groovy closure so as you said you will not have to explain why in Groovy { -> this } and () -> this do not return the same value.
I have no opinion about that, i let you guys decide :)
That said, the lambda metafactory takes a desugared lambda as argument (a plain old static method, apart in corner cases), so choosing the semantics of the lambda in Groovy is orthogonal to the choice of using the lambda metafactory or not.
Rémi
________________________________
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-tp5736169p5736202.html
To unsubscribe from Lambda expression for Groovy 3, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736169&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjE2OXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736217.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by Remi Forax <fo...@univ-mlv.fr>.
Hi Cedric,
> De: "Cédric Champeau" <ce...@gmail.com>
> À: dev@groovy.apache.org
> Envoyé: Mercredi 19 Octobre 2016 09:09:51
> Objet: Re: Lambda expression for Groovy 3
> First of all, great work, Daniel ! I'm confident that making the "lambdas" be
> "closures" in Groovy is enough. I stated it in the past but I'm going to repeat
> myself here, I don't think having 2 syntax for "closures/lambdas" with slightly
> different semantics would help our users/language. That said, the static
> compiler can do better, doing escape analysis, and using "real" lambdas when
> the target bytecode is 8, as an optimization.
The main issue i see of having one semantics is that the meaning of 'this' in a Groovy closure means the closure itself while 'this' in a Java lambda means the enclosing object, so { -> this } in Groovy is a substitute to () -> this in Java.
The choice seems to be, the semantics of 'this' in a lambda in Groovy can be either the same as Java so you can copy/paste a Java code and it will work as is in Groovy or the same semantics as in a Groovy closure so as you said you will not have to explain why in Groovy { -> this } and () -> this do not return the same value.
I have no opinion about that, i let you guys decide :)
That said, the lambda metafactory takes a desugared lambda as argument (a plain old static method, apart in corner cases), so choosing the semantics of the lambda in Groovy is orthogonal to the choice of using the lambda metafactory or not.
Rémi
Re: 答复: Lambda expression for Groovy 3
Posted by Jochen Theodorou <bl...@gmx.org>.
On 19.10.2016 14:12, daniel_sun wrote:
> Hi R�mi,
>
> Groovy can choose the right method to call :)
>
> assert ['1', '2', '3'] == [1, 2, 3].collect(Integer.&toString)
I am sure that works only because the static Integer.toString(int) and
the virtual Integer.toString() return the same values. If you look at
> class X {
> def foo() {1}
> static foo(X x) {2}
> }
Then for a X.&foo covering virtual and static methods, there is no way
of knowing if we want to call the virtual foo or the static foo method.
Both would take and instance of X as argument.
bye Jochen
答复: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
Hi Rémi,
Groovy can choose the right method to call :)
assert ['1', '2', '3'] == [1, 2, 3].collect(Integer.&toString)
Cheers,
Daniel.Sun
________________________________
发件人: Remi Forax [via Groovy] <ml...@n5.nabble.com>
发送时间: 2016年10月19日 19:29
收件人: daniel_sun
主题: Re: Lambda expression for Groovy 3
Daniel,
you have also to test that Type::method work not only with static methods but also with instance method.
The awful case being when you have a static method that takes an instance in parameter that 'overload' an instance method, like Integer.toString() and Integer.toString(int).
Rémi
----- Mail original -----
> De: "daniel_sun" <[hidden email]</user/SendEmail.jtp?type=node&node=5736203&i=0>>
> à: [hidden email]</user/SendEmail.jtp?type=node&node=5736203&i=1>
> Envoyé: Mercredi 19 Octobre 2016 12:23:09
> Objet: Re: Lambda expression for Groovy 3
> Hi Jochen,
>
> I plan to map Java's *::* to Groovy's *.&*, the following code is ok
> now. What do you think about it?
>
> [1, 2, 3].stream().forEach(System.out.&println) // object method,
> [1, 2, 3].stream().forEach(System.out::println)
> [1, 2, 3].stream().forEach(Objects.&requireNonNull) // class method, [1, 2,
> 3].stream().forEach(Objects::requireNonNull)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736195.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
________________________________
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-tp5736169p5736203.html
To unsubscribe from Lambda expression for Groovy 3, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736169&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjE2OXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736204.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by Remi Forax <fo...@univ-mlv.fr>.
Daniel,
you have also to test that Type::method work not only with static methods but also with instance method.
The awful case being when you have a static method that takes an instance in parameter that 'overload' an instance method, like Integer.toString() and Integer.toString(int).
Rémi
----- Mail original -----
> De: "daniel_sun" <re...@hotmail.com>
> À: dev@groovy.incubator.apache.org
> Envoyé: Mercredi 19 Octobre 2016 12:23:09
> Objet: Re: Lambda expression for Groovy 3
> Hi Jochen,
>
> I plan to map Java's *::* to Groovy's *.&*, the following code is ok
> now. What do you think about it?
>
> [1, 2, 3].stream().forEach(System.out.&println) // object method,
> [1, 2, 3].stream().forEach(System.out::println)
> [1, 2, 3].stream().forEach(Objects.&requireNonNull) // class method, [1, 2,
> 3].stream().forEach(Objects::requireNonNull)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736195.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
(a) That's great! We can get feedback from Groovy developers and refine the new parser.
(b) It's really a hard work. I believe you can achieve it at last :)
Cheers,
Daniel.Sun
在 "Jochen Theodorou [via Groovy]" <ml...@n5.nabble.com>，2016年10月19日 上午9:30写道：
On 19.10.2016 02:49, daniel_sun wrote:
> The new parser is based on Java8, so it has to target to Groovy3. As far
> I know, there are some amazing features under development or test, e.g.
> MOP2, new Joint compiler, Macro(appears at the snapshot of 2.5.0), etc.
> Looking forward to them :)
(a) I think it would be ok if the new parser is only usable if java8 is
used as long as it is not the default. If for example 2.5.0 is going out
with the old parser as default, then I see no problem in delivering
2.5.0 with a new parser, that will work only with java8.
(b) the MOP2 work I am doing right now is far from complete. The current
work is based on what I did 2 years ago already, but was not happy with
in the end. You can call it a continuation of that. But it is nowhere
usable atm. And I still have one big limitation I would like to be
lifted. While I can easily isolate classes and give them their own meta
class realm, it is not so easy to do the opposite and let a class
participate in a foreign realm, without knowing it. I would like not to
rely on a caller sensitive logic if possible.
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-tp5736169p5736191.html
To unsubscribe from Lambda expression for Groovy 3, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736169&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjE2OXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736192.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
Hi Jochen,
Thanks for your detail explanation. I'll try to implement the method
reference for Groovy 3 :)
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736212.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by Paul King <pa...@asert.com.au>.
On Wed, Oct 19, 2016 at 8:25 PM, Guillaume Laforge <gl...@gmail.com> wrote:
> That's what I thought too.
> Although there's one :: case that .& doesn't support in Groovy.
> (details escape me at this point as I'm in a hurry to go & grab lunch :D)
I think these are the references you had in mind Guillaume:
https://issues.apache.org/jira/browse/GROOVY-7772
https://github.com/apache/groovy/pull/287
There is some useful discussion but also a final comment that a bit
more work is required over and above the proposal in that PR.
Cheers, Paul.
> On Wed, Oct 19, 2016 at 12:23 PM, daniel_sun <re...@hotmail.com>
> wrote:
>>
>> Hi Jochen,
>>
>> I plan to map Java's *::* to Groovy's *.&*, the following code is ok
>> now. What do you think about it?
>>
>> [1, 2, 3].stream().forEach(System.out.&println) // object method,
>> [1, 2, 3].stream().forEach(System.out::println)
>> [1, 2, 3].stream().forEach(Objects.&requireNonNull) // class method, [1,
>> 2,
>> 3].stream().forEach(Objects::requireNonNull)
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>> --
>> View this message in context:
>> http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736195.html
>> Sent from the Groovy Dev mailing list archive at Nabble.com.
>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge / Google+
Re: Lambda expression for Groovy 3
Posted by Guillaume Laforge <gl...@gmail.com>.
That's what I thought too.
Although there's one :: case that .& doesn't support in Groovy.
(details escape me at this point as I'm in a hurry to go & grab lunch :D)
On Wed, Oct 19, 2016 at 12:23 PM, daniel_sun <re...@hotmail.com>
wrote:
> Hi Jochen,
>
> I plan to map Java's *::* to Groovy's *.&*, the following code is ok
> now. What do you think about it?
>
> [1, 2, 3].stream().forEach(System.out.&println) // object method,
> [1, 2, 3].stream().forEach(System.out::println)
> [1, 2, 3].stream().forEach(Objects.&requireNonNull) // class method, [1,
> 2,
> 3].stream().forEach(Objects::requireNonNull)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736195.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
Hi Jesper,
> Be careful with that approach, as it won’t work for static methods —
> leading to very different semantics for the two languages.
'.&' can reference the static methods, here is the sample code:
[1, 2, 3].each(Objects.&requireNonNull)
> Also, you won’t be able to support constructor references without some
> new AST construct, I guess.
As you said, '.&' does not support constructors..., the following code
is valid in Java, but I have no idea the equivalent in Groovy.
GenericsType[]::new
Thanks for your reminding :)
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736201.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by Jochen Theodorou <bl...@gmx.org>.
On 19.10.2016 12:34, Jesper Steen M�ller wrote:
> Hi Daniel
>
> Be careful with that approach, as it won\u2019t work for static methods \u2014 leading to very different semantics for the two languages.
> Also, you won\u2019t be able to support constructor references without some new AST construct, I guess.
Normally Object.&newInstance should for that... should, but does not,
because MethodClosure does actually only look at the static method and
newInstance is from DGM.
bye Jochen
Re: Lambda expression for Groovy 3
Posted by Jesper Steen Møller <je...@selskabet.org>.
Hi Daniel
Be careful with that approach, as it won’t work for static methods — leading to very different semantics for the two languages.
Also, you won’t be able to support constructor references without some new AST construct, I guess.
-Jesper
> On 19. okt. 2016, at 12.23, daniel_sun <re...@hotmail.com> wrote:
>
> Hi Jochen,
>
> I plan to map Java's *::* to Groovy's *.&*, the following code is ok
> now. What do you think about it?
>
> [1, 2, 3].stream().forEach(System.out.&println) // object method,
> [1, 2, 3].stream().forEach(System.out::println)
> [1, 2, 3].stream().forEach(Objects.&requireNonNull) // class method, [1, 2,
> 3].stream().forEach(Objects::requireNonNull)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736195.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by Jochen Theodorou <bl...@gmx.org>.
On 19.10.2016 12:23, daniel_sun wrote:
> Hi Jochen,
>
> I plan to map Java's *::* to Groovy's *.&*, the following code is ok
> now. What do you think about it?
>
> [1, 2, 3].stream().forEach(System.out.&println) // object method,
> [1, 2, 3].stream().forEach(System.out::println)
> [1, 2, 3].stream().forEach(Objects.&requireNonNull) // class method, [1, 2,3].stream().forEach(Objects::requireNonNull)
The problem is that a method reference call should be something like a
tuple of (class, methodname, instance, arguments). The reference itself
is then (class, methodname, instance), which makes the call (class,
methodname, instance)(arguments). But it could also be: (class,
methodname) (instance, arguments).
Examples:
(1) Object::toString -> (Object, "toString") called with (instance,
arguments)
(2) x::toString -> (Object, "toString", x) called with (arguments)
(3) Foo::staticMethod -> (Foo, "staticMethod", null) called with (arguments)
you could say that (Object, "toString", x) is the same as (Object,
"toString"), with a curried x.
MethodClosure now offers (owner, name) with a call (arguments). owner is
either the instance or the class. As you see from this already, there is
a difference. This means we can do x.&toString (case 2 above) and we can
do Foo.&staticMethod (case 3 above), but for case 1 we are lacking
something.
Quite a lot of discussion and analysis has been done in
https://issues.apache.org/jira/browse/GROOVY-7772
bye Jochen
Re: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
Hi Jochen,
I plan to map Java's *::* to Groovy's *.&*, the following code is ok
now. What do you think about it?
[1, 2, 3].stream().forEach(System.out.&println) // object method,
[1, 2, 3].stream().forEach(System.out::println)
[1, 2, 3].stream().forEach(Objects.&requireNonNull) // class method, [1, 2,
3].stream().forEach(Objects::requireNonNull)
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736195.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by Jochen Theodorou <bl...@gmx.org>.
On 19.10.2016 12:26, C�dric Champeau wrote:
>
>
> 2016-10-19 10:51 GMT+02:00 Jochen Theodorou <blackdrag@gmx.org
> <ma...@gmx.org>>:
>
>
>
> On 19.10.2016 09:09, C�dric Champeau wrote:
>
> First of all, great work, Daniel ! I'm confident that making the
> "lambdas" be "closures" in Groovy is enough.
>
>
> I think it won't be enough for :: and MethodClosures. Actually,
> Daniel, are those supported in the new Grammar and what are they
> mapped to?
>
>
> That's correct. I would really love to have _real_ method mapping for ::
> in the static compiler. This is obviously not possible for the dynamic
> runtime. One option, if we want to make it possible to optimize from the
> static compiler is to have a new AST node, MethodPointer, that would be
> interpreted as a MethodClosure, and potentially optimized by the static
> compiler later as a method pointer.
why should the exsiting node for a MethodClosure not be used for that?
The static compiler can still optimize that version, or not?
bye Jochen
Re: Lambda expression for Groovy 3
Posted by Cédric Champeau <ce...@gmail.com>.
2016-10-19 10:51 GMT+02:00 Jochen Theodorou <bl...@gmx.org>:
>
>
> On 19.10.2016 09:09, Cédric Champeau wrote:
>
>> First of all, great work, Daniel ! I'm confident that making the
>> "lambdas" be "closures" in Groovy is enough.
>>
>
> I think it won't be enough for :: and MethodClosures. Actually, Daniel,
> are those supported in the new Grammar and what are they mapped to?
That's correct. I would really love to have _real_ method mapping for :: in
the static compiler. This is obviously not possible for the dynamic
runtime. One option, if we want to make it possible to optimize from the
static compiler is to have a new AST node, MethodPointer, that would be
interpreted as a MethodClosure, and potentially optimized by the static
compiler later as a method pointer.
>
>
> I stated it in the past but
>> I'm going to repeat myself here, I don't think having 2 syntax for
>> "closures/lambdas" with slightly different semantics would help our
>> users/language.
>>
>
> They should have the semantics of Closure, then it is probably good.
>
> That said, the static compiler can do better, doing
>> escape analysis, and using "real" lambdas when the target bytecode is 8,
>> as an optimization.
>>
>
> In Groovy 3 I do plan to make out Closures behave similar to lambdas. Of
> course with the additional problem of Closure not being a functional
> interface... well... let's not get started on MOP2 here ;)
>
> bye Jochen
>
Re: Lambda expression for Groovy 3
Posted by Jochen Theodorou <bl...@gmx.org>.
On 19.10.2016 09:09, C�dric Champeau wrote:
> First of all, great work, Daniel ! I'm confident that making the
> "lambdas" be "closures" in Groovy is enough.
I think it won't be enough for :: and MethodClosures. Actually, Daniel,
are those supported in the new Grammar and what are they mapped to?
> I stated it in the past but
> I'm going to repeat myself here, I don't think having 2 syntax for
> "closures/lambdas" with slightly different semantics would help our
> users/language.
They should have the semantics of Closure, then it is probably good.
> That said, the static compiler can do better, doing
> escape analysis, and using "real" lambdas when the target bytecode is 8,
> as an optimization.
In Groovy 3 I do plan to make out Closures behave similar to lambdas. Of
course with the additional problem of Closure not being a functional
interface... well... let's not get started on MOP2 here ;)
bye Jochen
Re: Lambda expression for Groovy 3
Posted by Cédric Champeau <ce...@gmail.com>.
First of all, great work, Daniel ! I'm confident that making the "lambdas"
be "closures" in Groovy is enough. I stated it in the past but I'm going to
repeat myself here, I don't think having 2 syntax for "closures/lambdas"
with slightly different semantics would help our users/language. That said,
the static compiler can do better, doing escape analysis, and using "real"
lambdas when the target bytecode is 8, as an optimization.
2016-10-19 3:29 GMT+02:00 Jochen Theodorou <bl...@gmx.org>:
>
> (a) I think it would be ok if the new parser is only usable if java8 is
> used as long as it is not the default. If for example 2.5.0 is going out
> with the old parser as default, then I see no problem in delivering 2.5.0
> with a new parser, that will work only with java8.
>
>
I'm not as ok as you are for 2 reasons:
1. we have no evidence that using the new parser doesn't introduce a
performance regression in compile time. We have the "performance"
subproject to help here.
2. it would mean adding a dependency on antlr4 for all users even if they
don't use the new grammar, unless we produce new artifacts. And given the
number of variants we already produce, I'm not sure it's a good idea.
Re: Lambda expression for Groovy 3
Posted by Jochen Theodorou <bl...@gmx.org>.
On 19.10.2016 02:49, daniel_sun wrote:
> The new parser is based on Java8, so it has to target to Groovy3. As far
> I know, there are some amazing features under development or test, e.g.
> MOP2, new Joint compiler, Macro(appears at the snapshot of 2.5.0), etc.
> Looking forward to them :)
(a) I think it would be ok if the new parser is only usable if java8 is
used as long as it is not the default. If for example 2.5.0 is going out
with the old parser as default, then I see no problem in delivering
2.5.0 with a new parser, that will work only with java8.
(b) the MOP2 work I am doing right now is far from complete. The current
work is based on what I did 2 years ago already, but was not happy with
in the end. You can call it a continuation of that. But it is nowhere
usable atm. And I still have one big limitation I would like to be
lifted. While I can easily isolate classes and give them their own meta
class realm, it is not so easy to do the opposite and let a class
participate in a foreign realm, without knowing it. I would like not to
rely on a caller sensitive logic if possible.
bye Jochen
Re: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
The new parser is based on Java8, so it has to target to Groovy3. As far I know, there are some amazing features under development or test, e.g. MOP2, new Joint compiler, Macro(appears at the snapshot of 2.5.0), etc. Looking forward to them :)
Cheers,
Daniel.Sun
在 "Guillaume Laforge [via Groovy]" <ml...@n5.nabble.com>，2016年10月19日 上午8:36写道：
Nothing's definitive at all for Groovy 2.5 or 3.0.
It's up for discussion here on the list :-)
On Wed, Oct 19, 2016 at 2:33 AM, daniel_sun <[hidden email]> wrote:
Thanks :)
Guillaume, is there a road map to show us the plan of Groovy3? e.g. when to release the first beta version and what feature should be included?
Cheers,
Daniel.Sun
在 "Guillaume Laforge [via Groovy]" <ml-node+[hidden email]>，2016年10月19日 上午7:47写道：
Thanks for the explanations!
(and great achievement!)
On Wed, Oct 19, 2016 at 1:43 AM, daniel_sun <[hidden email]> wrote:
To be exact, lambda expression of Groovy enhances the syntax of Java lambda expression, e.g. lambda expression of Java is not callable.
Cheers,
Daniel.Sun
在 "Remi Forax [via Groovy]" <ml-node+[hidden email]>，2016年10月19日 上午4:36写道：
I would say Groovy Closure with the Java syntax.
Rémi
On October 18, 2016 8:21:34 PM GMT+02:00, Guillaume Laforge <[hidden email]> wrote:
Is it actually Groovy closures? or "real" Java lambdas?
On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou <[hidden email]> 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<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
________________________________
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-tp5736169p5736179.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-tp5736169p5736184.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<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
________________________________
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-tp5736169p5736185.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-tp5736169p5736188.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<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
________________________________
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-tp5736169p5736189.html
To unsubscribe from Lambda expression for Groovy 3, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736169&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjE2OXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736190.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by Guillaume Laforge <gl...@gmail.com>.
Nothing's definitive at all for Groovy 2.5 or 3.0.
It's up for discussion here on the list :-)
On Wed, Oct 19, 2016 at 2:33 AM, daniel_sun <re...@hotmail.com> wrote:
> Thanks :)
> Guillaume, is there a road map to show us the plan of Groovy3? e.g. when
> to release the first beta version and what feature should be included?
>
> Cheers,
> Daniel.Sun
>
>
>
> 在 "Guillaume Laforge [via Groovy]" <ml-node+[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5736188&i=0>>，2016年10月19日
> 上午7:47写道：
>
> Thanks for the explanations!
> (and great achievement!)
>
> On Wed, Oct 19, 2016 at 1:43 AM, daniel_sun <[hidden email]> wrote:
>
>> To be exact, lambda expression of Groovy enhances the syntax of Java
>> lambda expression, e.g. lambda expression of Java is not callable.
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>> 在 "Remi Forax [via Groovy]" <ml-node+[hidden email]>，2016年10月19日
>> 上午4:36写道：
>>
>> I would say Groovy Closure with the Java syntax.
>>
>> Rémi
>>
>> On October 18, 2016 8:21:34 PM GMT+02:00, Guillaume Laforge <[hidden
>> email]> wrote:
>>>
>>> Is it actually Groovy closures? or "real" Java lambdas?
>>>
>>> On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou <[hidden email]>
>>> 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 <http://twitter.com/glaforge> / Google+
>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> ------------------------------
>> 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-
>> tp5736169p5736179.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-tp5736169p5736184.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 <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
>
> ------------------------------
> 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-
> tp5736169p5736185.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-tp5736169p5736188.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 <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
Thanks :)
Guillaume, is there a road map to show us the plan of Groovy3? e.g. when to release the first beta version and what feature should be included?
Cheers,
Daniel.Sun
在 "Guillaume Laforge [via Groovy]" <ml...@n5.nabble.com>，2016年10月19日 上午7:47写道：
Thanks for the explanations!
(and great achievement!)
On Wed, Oct 19, 2016 at 1:43 AM, daniel_sun <[hidden email]> wrote:
To be exact, lambda expression of Groovy enhances the syntax of Java lambda expression, e.g. lambda expression of Java is not callable.
Cheers,
Daniel.Sun
在 "Remi Forax [via Groovy]" <ml-node+[hidden email]>，2016年10月19日 上午4:36写道：
I would say Groovy Closure with the Java syntax.
Rémi
On October 18, 2016 8:21:34 PM GMT+02:00, Guillaume Laforge <[hidden email]> wrote:
Is it actually Groovy closures? or "real" Java lambdas?
On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou <[hidden email]> 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<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
________________________________
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-tp5736169p5736179.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-tp5736169p5736184.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<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
________________________________
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-tp5736169p5736185.html
To unsubscribe from Lambda expression for Groovy 3, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736169&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjE2OXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736188.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by Guillaume Laforge <gl...@gmail.com>.
Thanks for the explanations!
(and great achievement!)
On Wed, Oct 19, 2016 at 1:43 AM, daniel_sun <re...@hotmail.com> wrote:
> To be exact, lambda expression of Groovy enhances the syntax of Java
> lambda expression, e.g. lambda expression of Java is not callable.
>
> Cheers,
> Daniel.Sun
>
>
>
> 在 "Remi Forax [via Groovy]" <ml-node+[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5736184&i=0>>，2016年10月19日
> 上午4:36写道：
>
> I would say Groovy Closure with the Java syntax.
>
> Rémi
>
> On October 18, 2016 8:21:34 PM GMT+02:00, Guillaume Laforge <[hidden
> email]> wrote:
>>
>> Is it actually Groovy closures? or "real" Java lambdas?
>>
>> On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou <[hidden email]> 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 <http://twitter.com/glaforge> / Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ------------------------------
> 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-
> tp5736169p5736179.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-tp5736169p5736184.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 <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
To be exact, lambda expression of Groovy enhances the syntax of Java lambda expression, e.g. lambda expression of Java is not callable.
Cheers,
Daniel.Sun
在 "Remi Forax [via Groovy]" <ml...@n5.nabble.com>，2016年10月19日 上午4:36写道：
I would say Groovy Closure with the Java syntax.
Rémi
On October 18, 2016 8:21:34 PM GMT+02:00, Guillaume Laforge <[hidden email]> wrote:
Is it actually Groovy closures? or "real" Java lambdas?
On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou <[hidden email]> 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<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
________________________________
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-tp5736169p5736179.html
To unsubscribe from Lambda expression for Groovy 3, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736169&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjE2OXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736184.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
Thanks :)
Cheers,
Daniel.Sun
在 "Roman Shaposhnik-2 [via Groovy]" <ml...@n5.nabble.com>，2016年10月19日 上午7:17写道：
On Tue, Oct 18, 2016 at 4:15 PM, Jesper Steen Møller
<[hidden email]> wrote:
> "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!
+1 great stuff!
Thanks,
Roman.
________________________________
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-tp5736169p5736182.html
To unsubscribe from Lambda expression for Groovy 3, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736169&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjE2OXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736187.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Tue, Oct 18, 2016 at 4:15 PM, Jesper Steen Møller
<je...@selskabet.org> wrote:
> "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!
+1 great stuff!
Thanks,
Roman.
Re: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
It is really a big job to implement the real lambda in the backend. So far so good ;) Thank you, Jesper.
Cheers,
Daniel.Sun
在 Jesper Steen Møller [via Groovy] <ml...@n5.nabble.com>，2016年10月19日 上午7:16写道：
"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
On 18. okt. 2016, at 22.46, Guillaume Laforge <[hidden email]> wrote:
I assumed so, but wanted to be sure :-)
On Tue, Oct 18, 2016 at 10:35 PM, Remi Forax <[hidden email]> 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 <[hidden email]> wrote:
Is it actually Groovy closures? or "real" Java lambdas?
On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou <[hidden email]> 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<http://nabble.com>.
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
--
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<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
________________________________
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-tp5736169p5736181.html
To unsubscribe from Lambda expression for Groovy 3, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736169&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjE2OXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736186.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by fo...@univ-mlv.fr.
> De: "Jesper Steen Møller" <je...@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 < glaforge@gmail.com > wrote:
>> I assumed so, but wanted to be sure :-)
>> On Tue, Oct 18, 2016 at 10:35 PM, Remi Forax < forax@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 < glaforge@gmail.com
>>> > wrote:
>>>> Is it actually Groovy closures? or "real" Java lambdas?
>>>> On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou < blackdrag@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+
Re: Lambda expression for Groovy 3
Posted by Jesper Steen Møller <je...@selskabet.org>.
"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
> On 18. okt. 2016, at 22.46, Guillaume Laforge <gl...@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 <gl...@gmail.com> wrote:
>>> Is it actually Groovy closures? or "real" Java lambdas?
>>>
>>>> On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou <bl...@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+
Re: Lambda expression for Groovy 3
Posted by Guillaume Laforge <gl...@gmail.com>.
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 <
> glaforge@gmail.com> wrote:
>>
>> Is it actually Groovy closures? or "real" Java lambdas?
>>
>> On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou <bl...@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/c380e4
>>>> 230ecef350855b9f56a220411635a7ff87
>>>>
>>>> https://github.com/danielsun1106/groovy-parser/blob/master/s
>>>> rc/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-Gro
>>>> ovy-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-Gr
>>>> oovy-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 <http://twitter.com/glaforge> / Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>
> --
> 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 <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Lambda expression for Groovy 3
Posted by Remi Forax <fo...@univ-mlv.fr>.
I would say Groovy Closure with the Java syntax.
R�mi
On October 18, 2016 8:21:34 PM GMT+02:00, Guillaume Laforge <gl...@gmail.com> wrote:
>Is it actually Groovy closures? or "real" Java lambdas?
>
>On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou <bl...@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/c380e4
>>> 230ecef350855b9f56a220411635a7ff87
>>>
>>> https://github.com/danielsun1106/groovy-parser/blob/master/
>>> src/test/resources/core/Lambda_01x.groovy
>>>
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>> \u5728 "Jochen Theodorou [via Groovy]" <ml-node+[hidden email]
>>> </user/SendEmail.jtp?type=node&node=5736176&i=0>>\uff0c2016\u5e7410\u670818\u65e5 00:37
>>>
>>> \u5199\u9053\uff1a
>>>
>>>
>>>
>>> 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 <http://twitter.com/glaforge> / Google+
><https://plus.google.com/u/0/114130972232398734985/posts>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Lambda expression for Groovy 3
Posted by Guillaume Laforge <gl...@gmail.com>.
Is it actually Groovy closures? or "real" Java lambdas?
On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou <bl...@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/c380e4
>> 230ecef350855b9f56a220411635a7ff87
>>
>> 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 <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Lambda expression for Groovy 3
Posted by Jochen Theodorou <bl...@gmx.org>.
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
>
>
>
> \u5728 "Jochen Theodorou [via Groovy]" <ml-node+[hidden email]
> </user/SendEmail.jtp?type=node&node=5736176&i=0>>\uff0c2016\u5e7410\u670818\u65e5 00:37
> \u5199\u9053\uff1a
>
>
>
> 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.
Re: Lambda expression for Groovy 3
Posted by daniel_sun <re...@hotmail.com>.
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...@n5.nabble.com>，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<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736169&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjE2OXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/Lambda-expression-for-Groovy-3-tp5736169p5736176.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda expression for Groovy 3
Posted by Jochen Theodorou <bl...@gmx.org>.
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