Re: Lambda expression for Groovy 3
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
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]"
，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
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
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
Re: Lambda expression for Groovy 3
On 19.10.2016 12:34, Jesper Steen Møller wrote: 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. 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
On 19.10.2016 12:26, Cédric Champeau wrote: 2016-10-19 10:51 GMT+02:00 Jochen Theodorou mailto:blackd...@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
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
答复: Lambda expression for Groovy 3
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] 发送时间: 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]> > à: [hidden email] > 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
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" > À: d...@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
Hi Cedric,
> De: "Cédric Champeau"
> À: 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
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
> De: "Jesper Steen Møller"
> À: dev@groovy.apache.org
> Cc: "Remi Forax"
> Envoyé: Mercredi 19 Octobre 2016 01:15:47
> Objet: Re: Lambda expression for Groovy 3
> "Real lambdas" with the full invokedynamic treatment is a big job, and
> requires
> static type inference.
> Given that Groovy can already coerce closures into functional interfaces
> (dynamically), we could implement the whole metafactory-stuff with the static
> compilation, and as a separate effort, right?
> Also: Fantastic job, Daniel!
> -Jesper
You can even use the LambdaMetaFactory at runtime, if you propagate the target
type to the point you create the lambda, currently it's two operations in
groovy, create the closure and then convert it to a functional interface, but
it can be done in one operation, this is what Nashorn does. But you don't have
to do that now. It's more an optimization than anything else. The thing is that
if you you the lambda metafactory, you get two optimizations: if the lambda
doesn't capture any values, the lambda is seen by the JIT as a constant, this
optimization is important mostly for the stream API because the JIT can inline
all the lambda code at the location you use the stream (otherwise, it depends
if the escape analysis is in a good day or not). The second optimization is
that if the lambda capture values these values are seen as field that can not
be changed after the creation of the lambda (like true final fields that the
reflection can not change). This second optimization is less important and just
nice to have.
Also, you can emulate what the lambda metafactory does in the MOP2, but it
requires to use Unsafe (a part which is not removed in 9) which is no a good
strategy on the long term, it's better to delegate the creation of the lambda
to the metafactory to the optimizations for free.
The static compilation will make easier to see the creation of the closure and
its cast to a functional interface as one operation, enabling to use the lambda
metafactory but as i said above, you can use the lambda metafactory at runtime.
Rémi
> On 18. okt. 2016, at 22.46, Guillaume Laforge < glafo...@gmail.com > wrote:
>> I assumed so, but wanted to be sure :-)
>> On Tue, Oct 18, 2016 at 10:35 PM, Remi Forax < fo...@univ-mlv.fr > wrote:
>>> I would say Groovy Closure with the Java syntax.
>>> Rémi
>>> On October 18, 2016 8:21:34 PM GMT+02:00, Guillaume Laforge <
>>> glafo...@gmail.com
>>> > wrote:
>>>> Is it actually Groovy closures? or "real" Java lambdas?
>>>> On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou < blackd...@gmx.org >
>>>> wrote:
>>>>> hah, I knew you can do it ;)
>>>>> On 18.10.2016 18:34, daniel_sun wrote:
>>>>>> Jochen, lambda expression is fully supported now :)
>>>>>> https://github.com/danielsun1106/groovy-parser/commit/c380e4230ecef350855b9f56a220411635a7ff87
>>>>>> https://github.com/danielsun1106/groovy-parser/blob/master/src/test/resources/core/Lambda_01x.groovy
>>>>>> Cheers,
>>>>>> Daniel.Sun
>>>>>> 在 "Jochen Theodorou [via Groovy]" >>>>> >，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 +
Re: Lambda expression for Groovy 3
On Wed, Oct 19, 2016 at 8:25 PM, Guillaume Laforge 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 > 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
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 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
2016-10-19 10:51 GMT+02:00 Jochen Theodorou : > > > 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
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 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
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
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
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 : > > (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
(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]" ，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
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
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]"
，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]" ，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]" ，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]" >，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-nabb
Re: Lambda expression for Groovy 3
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 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]" <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]" ，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]" >>>> >，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/
>>>
Re: Lambda expression for Groovy 3
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]"
，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]" ，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]" >，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
Apac
Re: Lambda expression for Groovy 3
Thanks :) Cheers, Daniel.Sun 在 "Roman Shaposhnik-2 [via Groovy]" ，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
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]
，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]" >，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&
Re: Lambda expression for Groovy 3
Thanks for the explanations!
(and great achievement!)
On Wed, Oct 19, 2016 at 1:43 AM, daniel_sun 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]" <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]" >>> >，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>
Re: Lambda expression for Groovy 3
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]"
，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]" >，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
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]"
，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]" >，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
On Tue, Oct 18, 2016 at 4:15 PM, Jesper Steen Møller 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
"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 wrote:
>
> I assumed so, but wanted to be sure :-)
>
>> On Tue, Oct 18, 2016 at 10:35 PM, Remi Forax 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
>>> wrote:
>>> Is it actually Groovy closures? or "real" Java lambdas?
>>>
>>>> On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou
>>>> 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]" >>>> >，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
I assumed so, but wanted to be sure :-)
On Tue, Oct 18, 2016 at 10:35 PM, Remi Forax wrote:
> I would say Groovy Closure with the Java syntax.
>
> Rémi
>
> On October 18, 2016 8:21:34 PM GMT+02:00, Guillaume Laforge <
> glafo...@gmail.com> wrote:
>>
>> Is it actually Groovy closures? or "real" Java lambdas?
>>
>> On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou
>> 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]" >>> >，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
I would say Groovy Closure with the Java syntax.
Rémi
On October 18, 2016 8:21:34 PM GMT+02:00, Guillaume Laforge
wrote:
>Is it actually Groovy closures? or "real" Java lambdas?
>
>On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou
>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]" >> >，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.
Re: Lambda expression for Groovy 3
Is it actually Groovy closures? or "real" Java lambdas?
On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou 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]" > >，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
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]" >，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.
Re: Lambda expression for Groovy 3
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]"
，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
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]"
，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
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
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.
