jastrachan | 4 Dec 01:36 2004

Re: [groovy-dev] Groovy 1.0 timeline, bugs

On 3 Dec 2004, at 22:47, LARSON, BRIAN (SBCSI) wrote:
> James:
> Can you come up with a tentative schedule for when we plan to deliver
> version 1.0.  Maybe with a few milestones (some basic language
> decisions, parser rework, bytecode rewrite, formalizing spec, ...).  I
> think that would help everyone get a sense of where we are and when
> Groovy will finally make it to 1.0.

I'm hoping to tie down, as a suite of test cases, the core 1.0 language 
spec by the end of January - Christmas, vacation, a fair bit of 
travelling and a fairly busy day job will add pressure to that, but it 
should be do-able. Most of the thorny issues I think we've resolved, 
its most a case of dumping them all into a large test suite to check 
we've got the edge cases sorted.

How long it takes to implement is a harder thing to gauge though. There 
might be things we add later. Currently the most undefined thing seems 
to be markup / with clause - most of the rest we went through at the 
conference & I'm fairly happy all the smelly & ambiguous things can be 
resolved (or kinda have done but not explicitly in a test case yet).

> Guillaume:
> You recently talked about the work that Jeremy Rayner and John Rose are
> doing on the parser in the user list.  I have a little time and I'd 
> like
> to look at some bugs or help in other ways, but I'm afraid of doing
> things which will be superseded by the parser work.  Can you suggest 
> the
> best ways to help or areas to avoid for bug fixing right now?

Is it a parse bug or a validation bug? Its hard to know really; the two 
parsers are experiments up to now - though I hope they could implement 
the full Groovy language, and auto-generate EBNF for the language. I'd 
like to, given the time, try replacing the bytecode generation with a 
Java AST based one as it'd make the code easier to follow & fix. 
Hopefully most of the logic of the runtime/RI can then be on the Groovy 
AST and how it translates to Java AST - rather than deeply nested 
inside the parser or in ASM / bytecode stuff.