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]" 
<ml-node+s329449n5736171...@n5.nabble.com>,2016年10月18日 上午12:37写道:

On 17.10.2016 17:40, daniel_sun wrote:
> Hi all,
>        Lambda expression for Groovy has been completed with a little
> limitation, which is due to the existing closure whose parameter list can be
> ambiguous to lambda expression, e.g. {a -> a} which can be parsed as a
> lambda expression in a block, but we expect it a closure.

I think that limitation is ok

> In order to
> resolve the ambiguities, the parentheses for parameters is a must, e.g.
> *Java8* allows parentheses-less parameter for lambda when the parameter is
> single and without type: e -> e, but *Groovy* only allows parameter with
> parentheses: (e) -> e.
>        *Here are some examples for lambda expression for Groovy:*
> assert 9 == [1, 2, 3].stream().map((e) -> e + 1).reduce(0, (r, e) -> r + e)

which means you cannot write
> assert 9 == [1, 2, 3].stream().map(e -> e + 1).reduce(0, (r, e) -> r + e)

which I find not so ok. Here again it would be no problem if it is
recognized as Closure if that is more easy to accomplish.

bye Jochen

If you reply to this email, your message will be added to the discussion below:
To unsubscribe from Lambda expression for Groovy 3, click 

View this message in context: 
Sent from the Groovy Dev mailing list archive at Nabble.com.

Reply via email to