Re: About array initializer of Java style for Groovy 3

Can this feature be added without the parser getting confused with {1, 2, 3}, thinking it's a closure instead of an initializer? AFAIK this is the same reason why instance initializers are not supported by Groovy. If it can be done then great! This would remove one gotcha when migratation Java cod

Re: About array initializer of Java style for Groovy 3

Hi Andres, Parrot can parse ` def a = {1, 2, 3}` properly, but it can not parse `{1, 2, 3}`, which is not supported by Java too. This is the initial implementation :) https://github.com/danielsun1106/groovy-parser/commit/96e6c923a4d09d48448f8731a314c918ee6c0e7c Cheers, Daniel.Sun

Re: About array initializer of Java style for Groovy 3

What happens for def a = { 2 }, is it parsed as a closure or an array initializer? On Tue, Jan 24, 2017 at 9:52 AM, Daniel Sun wrote: > Hi Andres, > >Parrot can parse ` def a = {1, 2, 3}` properly, but it can not parse > `{1, 2, 3}`, which is not supported by Java too. > >This is

Re: About array initializer of Java style for Groovy 3

closure 在 "Guillaume Laforge [via Groovy]" ，2017年1月24日 16:54写道： What happens for def a = { 2 }, is it parsed as a closure or an array initializer? On Tue, Jan 24, 2017 at 9:52 AM, Daniel Sun <[hidden email]> wrote: Hi Andres, Parrot can parse ` def a = {1, 2, 3}` properly, but it can

Re: About array initializer of Java style for Groovy 3

or we just support new int[] {1,2,3} ？ 在 "Guillaume Laforge [via Groovy]" ，2017年1月24日 16:54写道： What happens for def a = { 2 }, is it parsed as a closure or an array initializer? On Tue, Jan 24, 2017 at 9:52 AM, Daniel Sun <[hidden email]> wrote: Hi Andres, Parrot can parse ` def a =

Re: About array initializer of Java style for Groovy 3

I think we should support only explicit array initilization with array type, that is "new int[] { 2 }" for compatibility's sake. Sent from my iPhone > On 24 Jan 2017, at 09:59, Daniel Sun wrote: > > or we just support new int[] {1,2,3} ？ > > > > 在 "Guillaume Laforge [via Groovy]" ，2017年1月

Re: About array initializer of Java style for Groovy 3

Good point. We should definitely avoid confusion as much as possible, and avoid introducing ambiguities. On Tue, Jan 24, 2017 at 10:12 AM, Andres Almiray wrote: > I think we should support only explicit array initilization with array > type, that is "new int[] { 2 }" for compatibility's sake. >

Re: About array initializer of Java style for Groovy 3

+1 在 "Guillaume Laforge [via Groovy]" ，2017年1月24日 下午5:19写道： Good point. We should definitely avoid confusion as much as possible, and avoid introducing ambiguities. On Tue, Jan 24, 2017 at 10:12 AM, Andres Almiray <[hidden email]> wrote: I think we should support only explicit array initiliz

Re: About array initializer of Java style for Groovy 3

Also note that in Java Integer[] o = { 3 }; and int[] o = { 3 }; both work but Object o = { 3 }; does not compile because the syntax '{' '}' with no explicit array type do inference (and here Object is not an array so the inference fails). Supporting only explicit array initialization seems

Re: About array initializer of Java style for Groovy 3

Hi Rémi, The improvement has been completed in my groovy-parser repository, it is being tested now. I'll sync them to parrot branch of apache/groovy later :) Thanks for your clear explanation and advice! Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.

Array initializer of Java style for Groovy 3

Hi all, The new parser Parrot support array initializer of Java style, e.g. new int[] {1, 2, 3}, new int[][]{new int[]{1, 1.plus(1)}, new int[] {2.plus(1), 4}}, new String[] {'hello', 'world'} More examples can be found at https://github.com/danielsun1106/groovy-parser/blob/master/src

Re: Array initializer of Java style for Groovy 3

Great work! 2017-01-24 13:12 GMT+01:00 Daniel Sun : > Hi all, > > The new parser Parrot support array initializer of Java style, e.g. > new int[] {1, 2, 3}, new int[][]{new int[]{1, 1.plus(1)}, new int[] > {2.plus(1), 4}}, new String[] {'hello', 'world'} > > More examples can be found

答复: Array initializer of Java style for Groovy 3

Thanks ?? 发件人: Cédric Champeau [via Groovy] 发送时间: 2017年1月24日 20:18 收件人: Daniel Sun 主题: Re: Array initializer of Java style for Groovy 3 Great work! 2017-01-24 13:12 GMT+01:00 Daniel Sun <[hidden email]>: Hi all,

Re: Array initializer of Java style for Groovy 3

Nice! On Tue, Jan 24, 2017 at 1:18 PM, Cédric Champeau wrote: > Great work! > > 2017-01-24 13:12 GMT+01:00 Daniel Sun : > >> Hi all, >> >> The new parser Parrot support array initializer of Java style, e.g. >> new int[] {1, 2, 3}, new int[][]{new int[]{1, 1.plus(1)}, new int[] >> {2.plus(1

Parrot and the ++ and -- operators

I accidentally discovered that Groovy 2, in contrast to Java, allows you to apply the ++ and -- operators to the left and right sides of variables simultaneously. int i = 0 ++i++ assert i == 1 and you can also chain them in a single statement provided you apply parens int i = 0 ((i++)++)++ asser

Re: release process

Is the plan for 3.0 to break binary compatibility for existing libraries? Personally I don't think we should ever have a version that we call "blow everything up version" that would be a big red flag for me. Imagine Oracle announcing the Java JDK "blow everything up" edition. Is there a way to re

Re: release process

2017-01-24 14:50 GMT+01:00 Graeme Rocher : > Is the plan for 3.0 to break binary compatibility for existing libraries? > > Personally I don't think we should ever have a version that we call > "blow everything up version" that would be a big red flag for me. > Imagine Oracle announcing the Java JD

Re: MavenGrapeEngine?

IMO we should be looking to create a JARJARed version of Aether and removing Ivy all together Ivy is broken fundamentally in numerous ways and is no longer developed and maintained. I cannot recommend that anyone uses @Grab currently because it breaks down in pretty much any real world scenarios.

Re: About array initializer of Java style for Groovy 3

On 24.01.2017 10:54, Remi Forax wrote: Also note that in Java Integer[] o = { 3 }; and int[] o = { 3 }; both work but Object o = { 3 }; does not compile because the syntax '{' '}' with no explicit array type do inference (and here Object is not an array so the inference fails). Supporti

Re: release process

So if the changes are required for Java 9 then I guess breaking binary compatibility is justifiable. What I would like us to consider then is a Java 8 + Parrot release that is binary compatible. I think it would be a real shame that using Parrot required updating to a version that is not compatib

Re: release process

On 24.01.2017 14:50, Graeme Rocher wrote: Is the plan for 3.0 to break binary compatibility for existing libraries? Personally I don't think we should ever have a version that we call "blow everything up version" that would be a big red flag for me. Imagine Oracle announcing the Java JDK "blow

Re: release process

Understood. I still think it would be valuable to have a Parrot + Java 8 + Groovy 2.x release before Groovy 3.x Maybe I am alone here, but it seems a shame that actual users won't get to benefit from Parrot for quite a few years. Cheers On Tue, Jan 24, 2017 at 3:03 PM, Jochen Theodorou wrote:

Re: release process

The main problem is parrot is that it requires Java 8, and 2.5 is planned to support 1.7. And bundling such a core thing as an experimental, optional module is a no-go for me (imagine the bug reports...). We could have a 2.9 release (or something similar) with Parrot sooner, though. (as a side not

Re: release process

With Grails and GORM we plan to drop Java 7 support soon. So a 2.9 (or whatever) would be nice to add to the release plan Cheers On Tue, Jan 24, 2017 at 3:51 PM, Cédric Champeau wrote: > The main problem is parrot is that it requires Java 8, and 2.5 is planned to > support 1.7. And bundling suc

Re: release process

On 24.01.2017 15:45, Graeme Rocher wrote: Understood. I still think it would be valuable to have a Parrot + Java 8 + Groovy 2.x release before Groovy 3.x Maybe I am alone here, but it seems a shame that actual users won't get to benefit from Parrot for quite a few years. nope, we are on the

Re: release process

On 24.01.2017 15:51, Cédric Champeau wrote: The main problem is parrot is that it requires Java 8, and 2.5 is planned to support 1.7. And bundling such a core thing as an experimental, optional module is a no-go for me (imagine the bug reports...). We could have a 2.9 release (or something simi

Re: Parrot and the ++ and -- operators

Hi Joe, I've added your sample code as test cases(https://github.com/danielsun1106/groovy-parser/commit/9914682e53fb2fe3d4bb335c8153e61066cea317). Parrot has same result with the old parser ;) Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/Parrot-

Re: release process

2017-01-24 16:59 GMT+01:00 Jochen Theodorou : > > > On 24.01.2017 15:51, Cédric Champeau wrote: > >> The main problem is parrot is that it requires Java 8, and 2.5 is >> planned to support 1.7. And bundling such a core thing as an >> experimental, optional module is a no-go for me (imagine the bug

Re: Parrot and the ++ and -- operators

Good to know I'll be able to use these patterns in Groovy 3...I think :) -Joe On Tue, Jan 24, 2017 at 11:00 AM, Daniel Sun wrote: > Hi Joe, > > I've added your sample code as test > cases(https://github.com/danielsun1106/groovy-parser/commit/ > 9914682e53fb2fe3d4bb335c8153e61066cea317). >

Re: release process

On 24.01.2017 18:08, Cédric Champeau wrote: [...] you misunderstand one essential part here. The parrot module would require java8, building Groovy would require Java8, executing Groovy would not require Java8 as long as parrot is not used. I do understand this. But we're talking abo

Re: release process

But - I recognise that the Antlr4 parser AST building looks really neat in Java 8, but easthetics aside, wouldn’t it we a relatively easy task to port back to Java 7? -Jesper > On 24 Jan 2017, at 16.59, Jochen Theodorou wrote: > > > > On 24.01.2017 15:51, Cédric Champeau wrote: >> The main

Re: release process

I plan to experiment with creating an "uber" jar (maybe using a different name) for 2.5 that would have the parrot parser. It would be like the indy jars for now, requiring a move into the correct directory to enable. But it isn't high up on my priority list just yet. Cheers, Paul. On Wed, Jan 2