Re: getting in line for the releases of groovy 2.4.8 and 2.5.0-beta-1

[Guillaume Laforge]

Mario, did you try the WIP by Daniel Sun, to provide feedback, see how it
works on your code base?
That's also a way to help and assess how far we are from having the new
parser ready, if you've got a bit of time to try it out.

On Wed, Oct 19, 2016 at 6:11 PM, Mario Garcia  wrote:

> +1 for releasing 2.4.8 asap
>
> Does anyone have any idea of how long is going to take the new parser to
> be ready ? It's a matter of weeks, months, maybe days? I think that
> information would help to plan future releases.
>
> Mario
>
> On 19 Oct 2016 17:15, "Pascal Schumacher" 
> wrote:
>
>> +1 for releasing 2.4.8 as soon as possible. There are already 67 fixed
>> issues:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20G
>> ROOVY%20AND%20fixVersion%20%3D%202.4.8%20ORDER%20BY%20stat
>> us%20DESC%2C%20priority%20DESC
>>
>> Am 19.10.2016 um 16:32 schrieb Jochen Theodorou:
>>
>>> Hi,
>>>
>>> I´dd like to collect here a list of things we have to do to get the next
>>> 2.4 and the first beta of 2.5.0 out. I do not know of any criticals for
>>> 2.4.x, so afaik it is ready for release any time now. For 2.5.0 I see the
>>> following we should integrate the new parser (could be done for 2.4.x as
>>> well), but otherwise I think we should go forward here as well.
>>>
>>> Any objections?
>>>
>>> bye Jochen
>>>
>>>
>>


-- 
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

[Cédric Champeau]

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

[Cédric Champeau]

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

[Guillaume Laforge]

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.)  // object method,
> [1, 2, 3].stream().forEach(System.out::println)
> [1, 2, 3].stream().forEach(Objects.) // 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

[Jesper Steen Møller]

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.)  // object method,
> [1, 2, 3].stream().forEach(System.out::println) 
> [1, 2, 3].stream().forEach(Objects.) // 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

[Remi Forax]

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.)  // object method,
> [1, 2, 3].stream().forEach(System.out::println)
> [1, 2, 3].stream().forEach(Objects.) // 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.

答复: Lambda expression for Groovy 3

[daniel_sun]

Hi Rémi,

 Groovy can choose the right method to call :)

assert ['1', '2', '3'] == [1, 2, 3].collect(Integer.)


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.)  // object method,
> [1, 2, 3].stream().forEach(System.out::println)
> [1, 2, 3].stream().forEach(Objects.) // 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.
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

[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?



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

[Paul King]

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.)  // object method,
>> [1, 2, 3].stream().forEach(System.out::println)
>> [1, 2, 3].stream().forEach(Objects.) // 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

[Remi Forax]

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

[forax]

> 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 + 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
>> <
>> 

Re: Lambda expression for Groovy 3

[daniel_sun]

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.)

>  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

[daniel_sun]

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.)  // object method,
[1, 2, 3].stream().forEach(System.out::println) 
[1, 2, 3].stream().forEach(Objects.) // 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

[Jochen Theodorou]

On 19.10.2016 12:26, Cédric Champeau 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 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

[Jochen Theodorou]

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. 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

[Jochen Theodorou]

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.)  // object method,
[1, 2, 3].stream().forEach(System.out::println)
[1, 2, 3].stream().forEach(Objects.) // 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. (case 2 above) and we can 
do Foo. (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