I'm in agreement that we should not commit to behaviour that we believe to be wrong and later break it (i.e. lambda's)
So if we agree on a version that should be "the Parrot release" whether that is 2.6 or 3.0 we have to scope into that work resolving the semantics discussion. Cheers On Thu, Feb 2, 2017 at 12:47 PM, Jesper Steen Møller <jes...@selskabet.org> wrote: > Hi list > > On 2 Feb 2017, at 11.58, Paul King <pa...@asert.com.au> wrote: > > This thread has kind of gone into debate mode but I guess for the > record I would be -1 on any releases having parrot that weren't marked > as "experimental" or "incubating" until we thrash out future plans for > dealing with Java 8 features (default methods on interfaces/"real" > lambda expressions). > > > For this discussion, please note the difference between the parser > implementation and the new language features. Yes, at the moment, Parrot has > both. > > Upping the parser implementation only breaks compatibility in these cases: > 1) For clients who depend on the jarjar'ed antlr2 binaries or leaked > exceptions. This is IMHO bad form, but is likely required in projects the > groovy-eclipse plugin, as Jochen pointed out. These will need to update > anyway. > 2) A few grammar bugs in the old parser have been fixed, but AFAIK only for > confirmed bugs. Fixing a known bug is not a breaking change. > Obviously, the new parser can contain bugs, too, so testing should not be > taken lightly. > > Changing the language can be a breaking change. For now, Parrot adds the > syntax of Java 8 lambdas and method and constructor references to Groovy, > but with Groovy semantics, > Adding those can't be considered breaking as long as they only add new to > the language which weren't syntactically legal before? > But: As you rightly point out, the semantics of these haven't been explored > in depth, and there are pitfalls in addition to the one you mention: For > example: Adding lambdas as synonyms for closures (as they are now in the > parrot-branch), and later changing them to be Java 8 source compatible, e.g. > terms of how they resolve 'this', would be a breaking change. > > Where I'm getting at: > 1. Introducing Parrot needn't break anything. > 2. The roadmap suggested by Cédric doesn't stop us from having the Java 8 > semantics-discussions right now, in time for the proposed 2.6. > 3. Major numbers should only be used if we mean to break stuff. Parrot > shouldn't. > > Kind regards > Jesper > > > On Tue, Jan 31, 2017 at 6:37 PM, Cédric Champeau <cchamp...@apache.org> > wrote: > > Hi guys, > > There are multiple conversations going on for weeks, and I think they are > going nowhere. We could discuss for months what's the best plan for Groovy, > without releasing anything. Here are the challenges that are waiting for us: > > 1. release a version of Groovy that integrates Groovy macros > 2. upgrade the minimal runtime required for Groovy to 1.7, which is required > to smoothly transition to higher requirements (and also, make our devs lives > easier) > 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to > drop the old call site caching and use indy Groovy everywhere > 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4 > 5. compatibility with Jigsaw, aka "Groovy as a module" > > I would like to propose the following plan: > > - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting > for this for too long > - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7 > - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking > changes (we have no choice here) > > This plan is, I think, a good compromise for all the requirements we have: > backwards compatibility, and making progress and not having too many > branches. An alternative would be to keep Parrot on Java 8, but as some of > us have said, this is incompatible with a soonish release. The drawback is > that Parrot has the risk of being a breaking change (it is, typically if > people implicitly depend on the old parser, which would be bad), so there's > a risk of not following semantic versioning. > > - [ ] YES, I approve the roadmap above > - [ ] NO, I do not approve the roadmap abobe beause... > - [ ] I don't mind, or this goes beyond what I can think of > > This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017. > > -- Graeme Rocher
