Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Paul King
I kind of got the impression that the thread seemed to turn into a discussion thread - but happy to be corrected if others didn't get that impression. My impression was that there was a lot of consensus around what we want in the next "non-bugfix" release (e.g. macros and jdk 7+) but some fuzzines

Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Cédric Champeau
The result is that the vote turned into a debate again. I give up :) 2017-02-07 4:18 GMT+01:00 Daniel Sun : > Hi Cédric, > > 72h has gone. The result is ? > > Cheers, > Daniel.Sun > > > > -- > View this message in context: http://groovy.329449.n5. > nabble.com/VOTE-Apache-Groovy-Roadmap-

Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Daniel Sun
Hi Cédric, It seems that too many choices are a annoying problem, but I believe we can conquer it sooner or later ;) BTW, is it possible to keep groovy' lambda expression as it is(i.e. groovy closure with lambda syntax) but generate *real* lambda bytecode for it(https://github.com/a

Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Cédric Champeau
2017-02-07 14:44 GMT+01:00 Daniel Sun : > Hi Cédric, > > It seems that too many choices are a annoying problem, but I believe > we can conquer it sooner or later ;) > BTW, is it possible to keep groovy' lambda expression as it is(i.e. > groovy closure with lambda syntax) but generate *

Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Jochen Theodorou
On 07.02.2017 14:44, Daniel Sun wrote: Hi Cédric, It seems that too many choices are a annoying problem, but I believe we can conquer it sooner or later ;) BTW, is it possible to keep groovy' lambda expression as it is(i.e. groovy closure with lambda syntax) but generate *real* lam

Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Jesper Steen Møller
Well, I didn't see many actually object to the contents or order that you suggested, but primarily the numbering. I'll give it another go. The vote thread seemed to raise three issues: 1) Whether or not to provide the parrot parser as a standalone option ASAP (this is actually quite a bit of wor

答复: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Daniel Sun
Hi Jochen, That’s great! Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime?? Cheers

Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

2017-02-07 Thread Jesper Steen Møller
(changing the subject so we don't disrupt the main discussion) Not quite 😔 The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while bac

答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

2017-02-07 Thread Daniel Sun
Hi Jesper, To fully support *real* lambda expression, (to be honest)currently I have no idea how to generate bytecode for it. In addition, supporting Static Compilation will be another big work… * For instance, we could warn the user if the lambda referred to 'this' or 'super' direct

Re: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

2017-02-07 Thread Jesper Steen Møller
> On 7 Feb 2017, at 16.27, Daniel Sun wrote: > To fully support *real* lambda expression, (to be honest)currently I > have no idea how to generate bytecode for it. In addition, supporting Static > Compilation will be another big work… > > A real lambda expression is implemented in Java a

答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

2017-02-07 Thread Daniel Sun
Hi Jesper, Gotcha 😊 For me, I don’t like two versions of lambda expression… it will confuse developers. Cheers, Daniel.Sun 发件人: Jesper Steen Møller [via Groovy] 发送时间: 2017年2月7日 23:44 收件人: Daniel Sun 主题: R

Re: [VOTE] Apache Groovy Roadmap

2017-02-07 Thread Keith Suderman
I will let the PMC decide on the exact numbering and what goes where. However; +1 on getting Macros and Parrot out the door and available in a 2.x compatible version as soon as possible. > On Feb 7, 2017, at 9:59 AM, Jesper Steen Møller wrote: > > Well, I didn't see many actually object to t

[VOTE]About the implementation of lambda expression

2017-02-07 Thread Daniel Sun
Hi all, Jesper and I discussed the *real* lambda expression(i.e. Java8's lambda expression) just now. As Jesper found, Java8's lambda expression is implemented in Java as an invokedynamic call which makes use of a bootstrap method calling into a class called the LambdaMetafactory (https://do

答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

2017-02-07 Thread Daniel Sun
Hi Jesper, I’ve opened a new vote for the implementation of lambda expression, you can find it in the dev-list 😉 Cheers, Daniel.Sun 发件人: 孙 岚 发送时间: 2017年2月7日 23:49 收件人: Jesper Steen Møller [via Groovy] 主题: 答复: L

答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

2017-02-07 Thread Daniel Sun
Hi Jesper, * I'm not sure why we need a separate discussion. If most of us want the current lambda expression(based on closure), we need not thrash out how to implement Java-lambda semantics 😉 * We have a basic choice: 1) Use Java-lambda semantics or 2) Groovy-closure semantics. As

Re: Lambda vs. Closure

2017-02-07 Thread Jochen Theodorou
On 07.02.2017 16:44, Jesper Steen Møller wrote: [...] Generating faster/tighter code for lambdas (or even closures) can be implemented as a separate task, the two aren't really interconnected, since the Groovy closure is so versatile to begin with. The problem is that Closure has delegates, o

答复: Lambda vs. Closure

2017-02-07 Thread Daniel Sun
Hi Jochen, Gotcha 😊 BTW, Generating the real lambda needs type information which is only available in the static compilation mode…so it’s impossible to have universal version of lambda if we want to implement the real lambda. Cheers, Daniel.Sun 发件人: Jochen Theodorou [via Groovy]

Re: 答复: Lambda vs. Closure

2017-02-07 Thread Jochen Theodorou
On 07.02.2017 17:39, Daniel Sun wrote: [...] * We have a basic choice: 1) Use Java-lambda semantics or 2) Groovy-closure semantics. As a variation on 2, we can add some help for people pasting Java code into a Groovy program. Agreed. hmm... let me add some thoughts to this... I

Re: [VOTE]About the implementation of lambda expression

2017-02-07 Thread Remi Forax
Hi Daniel, On February 7, 2017 5:20:11 PM GMT+01:00, Daniel Sun wrote: >Hi all, > > Jesper and I discussed the *real* lambda expression(i.e. Java8's >lambda expression) just now. As Jesper found, Java8's lambda expression >is >implemented in Java as an invokedynamic call which makes use of

Re: [VOTE]About the implementation of lambda expression

2017-02-07 Thread Daniel Sun
Hi Rémi, Thanks for your explaination and suggestion. The following email was sent by Jochen in another thread. The implementation of lambda expression can be discussed here together :) Cheers, Daniel.Sun - Jochen's email --