Re: About the native-lambda branch

Hi Jochen, Thanks a lot for your detailed explanation block by block! > If you use the Closure code, then variables used in Closures are marked > as Reference even if they are only read According to your suggestion, I've fixed the loading variable issue[1] :-) Thanks for

Re: About the native-lambda branch

Am 15.01.2018 um 10:53 schrieb Daniel Sun: Hi Jochen, `ArrayIndexOutOfBoundsException` is fixed. I encounter another problem(i.e. How to load arguments according to some specified order): I want to load local variables[1] according to the order in which the local variables appear in

Re: About the native-lambda branch

Hi Jochen, I still have a quesiton: How can I load variables via Groovy utilities? Here[1] is my current way to load varaibles, it is not correct though it can compile and run(i.e. the related test can not pass[2]): I tried the following way, but error occurred[3]... ``` int

Re: About the native-lambda branch

Am 15.01.2018 um 15:21 schrieb Daniel Sun: Hi Jesper, Thanks for your advice :-) That's much easier than making the order dependent on the usage. Actually javac makes the order dependent on the local variables usage in the lambda body. I'll follow its way for the time being

Re: About the native-lambda branch

Hi Jesper, Thanks for your advice :-) > That's much easier than making the order dependent on the usage. Actually javac makes the order dependent on the local variables usage in the lambda body. I'll follow its way for the time being because I can reference how it make lambda work ;-)

Re: About the native-lambda branch

Hi Daniel > On 15 Jan 2018, at 10.53, Daniel Sun wrote: > > Hi Jochen, > > `ArrayIndexOutOfBoundsException` is fixed. I encounter another > problem(i.e. How to load arguments according to some specified order): I > want to load local variables[1] according to the

Re: About the native-lambda branch

Hi Jochen, `ArrayIndexOutOfBoundsException` is fixed. I encounter another problem(i.e. How to load arguments according to some specified order): I want to load local variables[1] according to the order in which the local variables appear in lambda body. For example: (1) ``` String x =

Re: About the native-lambda branch

Hi Jochen, Thanks for your detailed explanation, which is very helpful to me. Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About the native-lambda branch

On 14.01.2018 01:10, Daniel Sun wrote: Hi Jochen, What I wish for in a static compile lambda is the following: * bar is a parameter to the method generated for the lambda I am trying to make native lambda support sharing local variables, but ASM reports the following error[1]: Caused by:

Re: About the native-lambda branch

It seems that I found where go wrong. The shared local variables in generated method body should have been replaced with parameters. Let me try later :-) Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About the native-lambda branch

Hi Jochen, > What I wish for in a static compile lambda is the following: > * bar is a parameter to the method generated for the lambda I am trying to make native lambda support sharing local variables, but ASM reports the following error[1]: Caused by: java.lang.ArrayIndexOutOfBoundsException:

Re: About the native-lambda branch

On 13.01.2018 04:07, Nathan Harvey wrote: Sure thing. Here's a Java example: void sample(Function fn) { System.out.println("fn"); } void sample(Supplier sp) { System.out.println("sp"); } These methods can exist side

Re: About the native-lambda branch

Hi Jochen, Here is an example: ``` import java.util.stream.Collectors; import java.util.stream.Stream; public class Test1 { public static void main(String[] args) { p(); } public static void p() { Stream.of(1, 2, 3).map(e -> e +

Re: About the native-lambda branch

Sure thing. Here's a Java example: void sample(Function fn) { System.out.println("fn"); } void sample(Supplier sp) { System.out.println("sp"); } These methods can exist side by side, and are called correctly even in

Re: About the native-lambda branch

One of the largest reasons I found myself preferring Groovy over Java is the quasi-final scoping restrictions of Lambdas. Please do not let this behavior exist in Groovy. It makes functional programming very hard. On the other hand, lambdas are superior for functional programming because they can

Re: About the native-lambda branch

Am 12.01.2018 um 18:54 schrieb Russel Winder: On Fri, 2018-01-12 at 05:54 -0700, Daniel.Sun wrote: […] As you see, the latest implementation is to generate method for lambda at the class generation stage, in addition new inner classes will be generated for each lambda. […] I

Re: About the native-lambda branch

Am 12.01.2018 um 15:00 schrieb Daniel Sun: Hi Jochen, but I think you should then not use the closure inner class mechanism. I remain the implementation for non-native lambda[1] to make lambda work in legacy code, where closures are widely used. For example, `[1, 2, 3].collect(e -> e + 1)`

Re: About the native-lambda branch

On Fri, 2018-01-12 at 05:54 -0700, Daniel.Sun wrote: > […] > As you see, the latest implementation is to generate method for lambda > at the class generation stage, in addition new inner classes will be > generated for each lambda. > > […] I haven't read the code, I am reacting to the above

Re: About the native-lambda branch

Am 12.01.2018 um 14:13 schrieb Daniel.Sun: Hi Jesper, The bytecode generation for lambda of the current implementation should be somehow same with javac does, because I reference the ASM code, which is decomplied from bytecode generated by javac. If you have some spare time to

Re: About the native-lambda branch

Hi Jochen, > I did also not understand the innclass attribute visit... I've cleaned up the useless code: https://github.com/apache/groovy/commit/6aeaa1c5a7863af5d2c126a5bdf9da9aff2a8db6 Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About the native-lambda branch

Hi Jochen and Daniel > On 12 Jan 2018, at 12.48, Jochen Theodorou wrote: > > > > Am 12.01.2018 um 04:05 schrieb Daniel Sun: >> Hi Nathan, >>> What's will the differences be between closures and lambdas? >> The native lambda will have better performance than closure. In

Re: About the native-lambda branch

Am 12.01.2018 um 04:05 schrieb Daniel Sun: Hi Nathan, What's will the differences be between closures and lambdas? The native lambda will have better performance than closure. In addition, native lambda, which conforms to Java specification, is less versatile than closure, which is really

Re: About the native-lambda branch

Hi Nathan, > What's will the differences be between closures and lambdas? The native lambda will have better performance than closure. In addition, native lambda, which conforms to Java specification, is less versatile than closure, which is really powerful... Cheers, Daniel.Sun -- Sent

Re: About the native-lambda branch

Time is the problem, but I'll try to set aside some time to push the progress ;-) Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About the native-lambda branch

Great work, Daniel. What's will the differences be between closures and lambdas? I love that you can have fine control over closure scoping, but lambdas play very well with functional interfaces, which are very important! -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About the native-lambda branch

Awesome to see progress on this. Keep it up! On Thu, Jan 11, 2018 at 9:07 AM, Daniel Sun wrote: > Hi all, > > I created the native-lambda branch and pushed the first commit to > support very basic native lambda in the static compilation mode[1]. After > native