On 20.01.2017 22:04, Cédric Champeau wrote:
Let me rephrase what I said. My concern is not about complexity. My concern is that parrot is an experimental parser, that requires Java 8, and an additional dependency, antlr4, which conflicts with an existing dependency, antlr2.
antlr2 and antrl4 are not conflicting. They use different package spaces and have no compile/runtime dependencies
I don't want to mix things like that. The new parser should be, as all Java 8+ things, Groovy 3 only.
I see no problem in distributing java8 code in 2.5 in an optional part
There's little, if any, value in mixing this in 2.5, but there's a high risk for users. Risks of unwanted behavior, bigger distribution, additional flags, ...
for me the value is that users can try it out in 2.5. Who knows how long it will take to get 3.0 out. There might be a 2.6 before even. Yes, there will be a maybe 1MB bigger distribution (antlr4 jar is 604K) and there will be 1 additional flags. It being optional means the groovy jars can stay the same size though.
I thought I was clear but it seems not: - 2.5 should be Java 7 and macros. - 3.0 should be the blow everything up version, that bumps to Java 8, adds the new parser, and removes the old call site caching stuff
Oh clear it is, I just disagree.
It will be easier for us too, because it's pretty clear where we can merge experimental stuff, as well as releasing betas, alphas, whatever you want to call them. But let's not mix stable and unstable things in a single distribution. Git branches are not so hard.
Git branches not, no. But I see use for the parser now, not in who knows when. I assume it will be at least a year before there is a 3.0.0 rc.
bye Jochen
