groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From daniel_sun <>
Subject Re: Lambda expression for Groovy 3
Date Mon, 17 Oct 2016 23:40:17 GMT
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.


在 "Jochen Theodorou [via Groovy]" <>,2016年10月18日

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:
To unsubscribe from Lambda expression for Groovy 3, click here<>.

View this message in context:
Sent from the Groovy Dev mailing list archive at
View raw message