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
___
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&quo
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 ar
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.
Norma
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.
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].st
nt).
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
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&q
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
> 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
> requir
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:/
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:
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
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 followin
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) //
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
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,
(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
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
mespace-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: La
t;>>>>
>>>>> 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 proble
amp;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>
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 c
ace&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-expressio
roblem if it is
>>>> recognized as Closure if that is more easy to accomplish.
>>>>
>>>> bye Jochen
>>>>
>>>>
>>>> --------
>>>>
>>>>
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: R
e%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 arc
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 metafactor
> recognized as Closure if that is more easy to accomplish.
>>>>>
>>>>> bye Jochen
>>>>>
>>>>>
>>>>>
>>>>>
f that is more easy to accomplish.
>>>>
>>>> bye Jochen
>>>>
>>>>
>>>> ------------
>>>>
>>>> If you reply to this email, your message will be added to the
gt;>
>>>
>>>
>>> If you reply to this email, your message will be added to the
>>> discussion below:
>>> http://groovy.329449.n5.nabble.com/Lambda-expression-for-
>>
>> <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.NodeNa
------------
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.
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
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.
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,
36 matches
Mail list logo
