You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Jochen Theodorou <bl...@gmx.org> on 2016/02/01 10:05:51 UTC
Re: Groovy 3.0
On 31.01.2016 21:29, Thibault Kruse wrote:
> Are Antlr 4 and Jva 8 syntax linked somethow, meaning is there a hard
> problem describing certain java8 features using whatever antlr version
> is used right now?
They are linked in that way, that it does not really make sense to do
bigger syntax changes in antlr2, if we then want to go to antlr4 would
be double work to do it for antlr2 and antlr4. But thats actually all
that is to it.
> I would assume that porting Groovy to Java9 takes precendence over
> changing the syntax, so it would be nice to have a roadmap that decide
> which version will contain which of those changes.
We can make a "1 feature per version" style roadmap.. without target
times... not sure if that really makes sense though. If someone wants to
work on a new feature out of order (because for example that person has
a fitting current skill set for that task, but not for the scheduled
one), then I am not really against this person doing that. A roadmap
might be problematic in that... so we imho need one for enduser
information and one for developers
> Given the scarce
> resources it might be useful to separate these changes, but given that
> the API will change in either case, it might be better to have one
> avalanche of a change rather than annoying users multiple times.
It is normally better to release more often. I would have released a
beta on Groovy 2.5 for example a long time ago, even without the module
part completed. And that is mainly because I have experienced dragged
out releases in the past before Groovy 1.0, and what negative effects
they have. But anyway... a change that breaks compatibility is
different. So I agree... but given the sparse resources, I am afraid it
would be too long too. Best would be to have a migration plan, do the
breaking changes in one release, but back that with old logic... if that
is possible.
bye Jochen
Re: Groovy 3.0
Posted by Jochen Theodorou <bl...@gmx.org>.
On 06.02.2016 09:37, Guillaume Laforge wrote:
> On Sat, Feb 6, 2016 at 3:01 AM, Paco Zarate <contacto@nazcasistemas.com
> <ma...@nazcasistemas.com>> wrote:
>
> For reference here is a java 8 grammar for antlr 4.
> https://github.com/antlr/grammars-v4/tree/master/java8/Java8.g4
>
>
> Initially, I was thinking we should start with a blank slate, instead of
> doing the same approach as we did in the past, which is indeed start
> from an existing Java grammar... but OTOH... it's likely better Java 8
> support out of the box to do so.
A Java grammar has been made with Java in mind, not Groovy. Look at all
the modifications we had to do to the grammar we started with we are
currently using. There are huge changes. Plus the error reporting is not
all that good if the grammar makes a check. I have no idea if that is
improved with antlr4, but a custom error message can always give a much
more to the point error message, than a general error message generated
from the grammar could do. And not only that... for our uses the old
grammar is overly complicated. Part of this is because of the checks,
but there is also lacking abstraction (from a Groovy point of view only
though).
bye Jochen
Re: Groovy 3.0
Posted by Guillaume Laforge <gl...@gmail.com>.
On Sat, Feb 6, 2016 at 3:01 AM, Paco Zarate <co...@nazcasistemas.com>
wrote:
> For reference here is a java 8 grammar for antlr 4.
> https://github.com/antlr/grammars-v4/tree/master/java8/Java8.g4
>
Initially, I was thinking we should start with a blank slate, instead of
doing the same approach as we did in the past, which is indeed start from
an existing Java grammar... but OTOH... it's likely better Java 8 support
out of the box to do so.
> One good thing that groovy has for its version 2 to version 3 transition
> is that all the java libraries would be available. This would be a key
> difference with the python 2 -> 3 migration.
>
True. Good point.
It's indeed more an apple to orange comparison, so we should perhaps not
bring that counter-example on the table. My fault.
Guillaume
>
>
> On Tue, Feb 2, 2016 at 9:32 AM, Esteban Gínez <eg...@gmail.com> wrote:
>
>> Hey guys
>> That's awesome.
>> It would be more so if you could share the details/instructions on the
>> working environment, perhaps a wiki?. It would make it easier to help out
>> and contribute to the task :D
>>
>> I was personally investigating ways on hooking up antlr grammar to the
>> new graal/truffle infraestructure. At this point is a lot more of an idea
>> than a concrete proposal.
>> Anyways keep up the good work
>> E.
>>
>>
>> On Tue, Feb 2, 2016 at 2:05 AM, Guillaume Laforge <gl...@gmail.com>
>> wrote:
>>
>>> Great news Jesper!
>>>
>>> Please keep us updated on your progress, and if you need any help, don't
>>> hesitate.
>>> Indeed the first milestone is to get a working environment, and the
>>> second one to be able to have the same scope as the current parser, ideally
>>> generating the same AST (but perhaps there might be areas where we might
>>> think some updates are needed)
>>> For the third milestone, that would be discussing and progressivly
>>> adding the Java 8 related construct we want to support or not in Groovy 3.
>>>
>>> Guillaume
>>>
>>> On Tue, Feb 2, 2016 at 10:41 AM, Jesper Steen Møller <
>>> jesper@selskabet.org> wrote:
>>>
>>>> Hi list
>>>>
>>>> On 31.01.2016 21:29, Thibault Kruse wrote:
>>>>
>>>> > Are Antlr 4 and Jva 8 syntax linked somethow, meaning is there a hard
>>>> > problem describing certain java8 features using whatever antlr version
>>>> > is used right now?
>>>>
>>>> I’ve decided to give the Antlr4 task another go.
>>>> I had some major trouble getting a reasonable development setup (even
>>>> with IntelliJ), but now it seems I can actually get the ball rolling with a
>>>> reasonable unit test turnaround time (again using Eclipse and a slightly
>>>> patched Groovy-Eclipse compiler).
>>>>
>>>> I guess the next milestone is to ensure that the parser derives the
>>>> same AST’s as the Antlr2 parser, but before that there are some constructs
>>>> I know aren’t behaving correctly.
>>>>
>>>> -Jesper
>>>
>>>
>>>
>>>
>>> --
>>> Guillaume Laforge
>>> Apache Groovy committer & PMC member
>>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>>
>>> Blog: http://glaforge.appspot.com/
>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>
>>
>>
>
--
Guillaume Laforge
Apache Groovy committer & PMC member
Product Ninja & Advocate at Restlet <http://restlet.com>
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Groovy 3.0
Posted by Paco Zarate <co...@nazcasistemas.com>.
For reference here is a java 8 grammar for antlr 4.
https://github.com/antlr/grammars-v4/tree/master/java8/Java8.g4
One good thing that groovy has for its version 2 to version 3 transition is
that all the java libraries would be available. This would be a key
difference with the python 2 -> 3 migration.
On Tue, Feb 2, 2016 at 9:32 AM, Esteban Gínez <eg...@gmail.com> wrote:
> Hey guys
> That's awesome.
> It would be more so if you could share the details/instructions on the
> working environment, perhaps a wiki?. It would make it easier to help out
> and contribute to the task :D
>
> I was personally investigating ways on hooking up antlr grammar to the new
> graal/truffle infraestructure. At this point is a lot more of an idea than
> a concrete proposal.
> Anyways keep up the good work
> E.
>
>
> On Tue, Feb 2, 2016 at 2:05 AM, Guillaume Laforge <gl...@gmail.com>
> wrote:
>
>> Great news Jesper!
>>
>> Please keep us updated on your progress, and if you need any help, don't
>> hesitate.
>> Indeed the first milestone is to get a working environment, and the
>> second one to be able to have the same scope as the current parser, ideally
>> generating the same AST (but perhaps there might be areas where we might
>> think some updates are needed)
>> For the third milestone, that would be discussing and progressivly adding
>> the Java 8 related construct we want to support or not in Groovy 3.
>>
>> Guillaume
>>
>> On Tue, Feb 2, 2016 at 10:41 AM, Jesper Steen Møller <
>> jesper@selskabet.org> wrote:
>>
>>> Hi list
>>>
>>> On 31.01.2016 21:29, Thibault Kruse wrote:
>>>
>>> > Are Antlr 4 and Jva 8 syntax linked somethow, meaning is there a hard
>>> > problem describing certain java8 features using whatever antlr version
>>> > is used right now?
>>>
>>> I’ve decided to give the Antlr4 task another go.
>>> I had some major trouble getting a reasonable development setup (even
>>> with IntelliJ), but now it seems I can actually get the ball rolling with a
>>> reasonable unit test turnaround time (again using Eclipse and a slightly
>>> patched Groovy-Eclipse compiler).
>>>
>>> I guess the next milestone is to ensure that the parser derives the same
>>> AST’s as the Antlr2 parser, but before that there are some constructs I
>>> know aren’t behaving correctly.
>>>
>>> -Jesper
>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC member
>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>
>
Re: Groovy 3.0
Posted by Esteban Gínez <eg...@gmail.com>.
Hey guys
That's awesome.
It would be more so if you could share the details/instructions on the
working environment, perhaps a wiki?. It would make it easier to help out
and contribute to the task :D
I was personally investigating ways on hooking up antlr grammar to the new
graal/truffle infraestructure. At this point is a lot more of an idea than
a concrete proposal.
Anyways keep up the good work
E.
On Tue, Feb 2, 2016 at 2:05 AM, Guillaume Laforge <gl...@gmail.com>
wrote:
> Great news Jesper!
>
> Please keep us updated on your progress, and if you need any help, don't
> hesitate.
> Indeed the first milestone is to get a working environment, and the second
> one to be able to have the same scope as the current parser, ideally
> generating the same AST (but perhaps there might be areas where we might
> think some updates are needed)
> For the third milestone, that would be discussing and progressivly adding
> the Java 8 related construct we want to support or not in Groovy 3.
>
> Guillaume
>
> On Tue, Feb 2, 2016 at 10:41 AM, Jesper Steen Møller <jesper@selskabet.org
> > wrote:
>
>> Hi list
>>
>> On 31.01.2016 21:29, Thibault Kruse wrote:
>>
>> > Are Antlr 4 and Jva 8 syntax linked somethow, meaning is there a hard
>> > problem describing certain java8 features using whatever antlr version
>> > is used right now?
>>
>> I’ve decided to give the Antlr4 task another go.
>> I had some major trouble getting a reasonable development setup (even
>> with IntelliJ), but now it seems I can actually get the ball rolling with a
>> reasonable unit test turnaround time (again using Eclipse and a slightly
>> patched Groovy-Eclipse compiler).
>>
>> I guess the next milestone is to ensure that the parser derives the same
>> AST’s as the Antlr2 parser, but before that there are some constructs I
>> know aren’t behaving correctly.
>>
>> -Jesper
>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC member
> Product Ninja & Advocate at Restlet <http://restlet.com>
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
Re: Groovy 3.0
Posted by Guillaume Laforge <gl...@gmail.com>.
Great news Jesper!
Please keep us updated on your progress, and if you need any help, don't
hesitate.
Indeed the first milestone is to get a working environment, and the second
one to be able to have the same scope as the current parser, ideally
generating the same AST (but perhaps there might be areas where we might
think some updates are needed)
For the third milestone, that would be discussing and progressivly adding
the Java 8 related construct we want to support or not in Groovy 3.
Guillaume
On Tue, Feb 2, 2016 at 10:41 AM, Jesper Steen Møller <je...@selskabet.org>
wrote:
> Hi list
>
> On 31.01.2016 21:29, Thibault Kruse wrote:
>
> > Are Antlr 4 and Jva 8 syntax linked somethow, meaning is there a hard
> > problem describing certain java8 features using whatever antlr version
> > is used right now?
>
> I’ve decided to give the Antlr4 task another go.
> I had some major trouble getting a reasonable development setup (even with
> IntelliJ), but now it seems I can actually get the ball rolling with a
> reasonable unit test turnaround time (again using Eclipse and a slightly
> patched Groovy-Eclipse compiler).
>
> I guess the next milestone is to ensure that the parser derives the same
> AST’s as the Antlr2 parser, but before that there are some constructs I
> know aren’t behaving correctly.
>
> -Jesper
--
Guillaume Laforge
Apache Groovy committer & PMC member
Product Ninja & Advocate at Restlet <http://restlet.com>
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Groovy 3.0
Posted by Jesper Steen Møller <je...@selskabet.org>.
Hi list
On 31.01.2016 21:29, Thibault Kruse wrote:
> Are Antlr 4 and Jva 8 syntax linked somethow, meaning is there a hard
> problem describing certain java8 features using whatever antlr version
> is used right now?
I’ve decided to give the Antlr4 task another go.
I had some major trouble getting a reasonable development setup (even with IntelliJ), but now it seems I can actually get the ball rolling with a reasonable unit test turnaround time (again using Eclipse and a slightly patched Groovy-Eclipse compiler).
I guess the next milestone is to ensure that the parser derives the same AST’s as the Antlr2 parser, but before that there are some constructs I know aren’t behaving correctly.
-Jesper
Re: Groovy 3.0
Posted by Thibault Kruse <ti...@googlemail.com>.
So one thing that could be useful already is to add stories either in
JIRA or github for each of these epic (in size) issues individually,
where all discussions can be followed. Then a Roadmap document could
list these "epics" as large things on the horizon, without any
specific order or deadline. Then a mapping to release dates could be
done once these epics are close to being done. Maybe such epics
already exist.
On Mon, Feb 1, 2016 at 10:05 AM, Jochen Theodorou <bl...@gmx.org> wrote:
>
>
> On 31.01.2016 21:29, Thibault Kruse wrote:
>>
>> Are Antlr 4 and Jva 8 syntax linked somethow, meaning is there a hard
>> problem describing certain java8 features using whatever antlr version
>> is used right now?
>
>
> They are linked in that way, that it does not really make sense to do bigger
> syntax changes in antlr2, if we then want to go to antlr4 would be double
> work to do it for antlr2 and antlr4. But thats actually all that is to it.
>
>> I would assume that porting Groovy to Java9 takes precendence over
>> changing the syntax, so it would be nice to have a roadmap that decide
>> which version will contain which of those changes.
>
>
> We can make a "1 feature per version" style roadmap.. without target
> times... not sure if that really makes sense though. If someone wants to
> work on a new feature out of order (because for example that person has a
> fitting current skill set for that task, but not for the scheduled one),
> then I am not really against this person doing that. A roadmap might be
> problematic in that... so we imho need one for enduser information and one
> for developers
>
>
>> Given the scarce
>> resources it might be useful to separate these changes, but given that
>> the API will change in either case, it might be better to have one
>> avalanche of a change rather than annoying users multiple times.
>
>
> It is normally better to release more often. I would have released a beta on
> Groovy 2.5 for example a long time ago, even without the module part
> completed. And that is mainly because I have experienced dragged out
> releases in the past before Groovy 1.0, and what negative effects they have.
> But anyway... a change that breaks compatibility is different. So I agree...
> but given the sparse resources, I am afraid it would be too long too. Best
> would be to have a migration plan, do the breaking changes in one release,
> but back that with old logic... if that is possible.
>
> bye Jochen