Re: Groovy beta 10 released! (+JSR Early Access)

On 2 Mar 2005, at 03:00, Chris Poirier wrote:
> Hi Jochen,
>
>>> (with the wrong tool, at that)
>>
>> what is the right tool, that allows closures to start in the next 
>> line?
>
> The right tool I was referring to was a parser generator that isn't LL.
> LL isn't up to Groovy.

Huh?

Are you saying that the current Antlr parser for groovy isn't up to 
groovy? Got any evidence to back this claim up?

>>> corrected in an intelligent fashion that didn't risk alienating large
>>> portions of the community.
>>
>> and that is done by which tool?
>
> This is done by good language design.  Could it have been done with an
> LL tool?  Maybe.  Depends on the syntax used.  But the tool was a side
> point (hence the paren) that admittedly detracted from my actual point:
> that brace handling should have been fixed in the JSR grammar.

See my previous mail

>> Having a from grammar generated parser allows us to change the grammar
>> to change the behavior. For example it would be easy to implement a
>> compiler switch to make semicolons mandatory or optional.
>
> It's an interesting argument.  It seems to me that some large number of
> man hours (I'm guessing in excess of 600) was spent using a tool to
> generate the new parser -- and I'd be very surprised if many 
> compromises
> weren't made to accomodate ANTLR.

Huh? I'm not aware of any compromise for Antlr. All compromises are for 
the language design itself.

> The last parser was written in under
> 400 hours, by hand, for comparison's sake (yes, including the lexer and
> the AST builder).  I'd also be very surprised if the new grammar was
> less fragile than the old one.  Am I saying a hand-written parser was a
> better deal?  Absolutely not.  I can tell you that I'd loved to have
> used a tool when I wrote the bloody thing.  What I'm saying is that the
> grammar should have been fixed so that it could be implemented in an
> orthogonal fashion and in a reasonable time frame, and the tool to do
> the generation should have been selected /after/ the grammar was worked
> out, not before.
>
> In the end, how much of Groovy's new grammar is because of good design,
> and how much of it is because of what the (allegedly) better ANTLR
> approach could handle?

The new grammar is purely an attempt at a better design, making things 
more clear. Its got nothing to do with what Antlr can or can't do.

> For my part, I'm saying that the language dictating brace policy is a
> clear indication that the JSR grammar is not well designed.

See my previous mail - I await your preferred solution from the list I 
made.

>  For my
> part, the productivity lost to tracking down missing braces will more
> than eat up my savings over writing Java directly.

Huh? What productivity lost - the parser gives a pretty clear warning 
or error right now if you make any mistake with braces/parens.

> I know this from
> experience.

Have you even tried the JSR parser?

James
-------
http://radio.weblogs.com/0112098/