jastrachan | 26 Jan 12:11 2005

Re: [groovy-dev] Diff of Java and Groovy grammars

Great post Mike - lets move detailed discussion of the grammar over the 
JSR list. Remember this grammar is work in progress - and was always 
intended to produce such discussions - and there still be gremlins in 

On 25 Jan 2005, at 23:35, Mike Spille wrote:
> Thanks!
> I don't mind saying that this grammar scares the bejesus out of me - 
> just too many diffs from the baseline.  At this point it would seem 
> more profitable to either:
>         a) Go with my plan :-)
>         b) Start a grammar from scratch
>         c) Go back to hand coding.
> Issues and comments I see at a glance after a quick perusual:
> - Obviously sprinkling nls! all over the place is a monster hack.  If 
> you find yourself sprinkling a term like that everywhere it's an 
> indication that you're hacking, not creating a clean grammar.  You 
> could spend forever and a day just getting all the nls! nuances right.

In the grand scheme of things I'm not too worried about this but I hear 

> - I'm sure I'm reading this wrong - it looks like its saying that a 
> script is "package, scripting stuff, imports, classes/interfaces"
> - Plain evil: On var decls, "In the absence of explicit method-call 
> parens, we assume a capitalized name is a type name".  Relying on a 
> capital letter to indicate a Java class-based type?  Evil.

Yes, that is a bit smelly

> - I see that 'any' is in there.  I thought this was now "var".
> - Typed closure parameters must be parenthesized e.g.:
>         c = {String x, String y | println ("${x} ${y}"); };
> ....doesn't work, you need:
>         c = {(String x, String y) | println ("${x} ${y}"); };

I'd far prefer

    c = {|String x, Stringy| ... }

> - The "?" stuff in closure parameter is new to me, to signify optional 
> args.  The "*" stuff for turning an arg list into a list.
> - Double braces to disambiguate blocks from closures.  Ugh.

Yes - we need to fix this.

> - Optional eliding of "return" in closure but only on a single line - 
> ugh.

Its a concesssion & as I said a day or two ago, maybe we should 
reconsider - but it would be nice to have really expressive GPath (like 
XPath) without unnecessary cruft...

coll.findAll { it.country = "UK" }.collect { it.name }.sort { it.age }

rather than

coll.findAll { return it.country = "UK" }.collect { return it.name 
}.sort { return it.age }

So I was hoping we could maybe consider closures of 1 expression to be 
a special case; maybe its simpler to enforce mandatory return 

> - Already mentioned, bitwise or (|) is disallowed.

We should enable it, if we can use the double-bar notation & avoid 

> - And 'if' statement has to be all one line (sort of).  You can't say:
>         if (
>                 expr
>            )
> Yay, white space sensitivty is fun!

Sounds like a bug. To be pedantic, its newline sensitive

> - Hell, it appears lots of the control constructs have some whitespace 
> sensitivity.

Again, sounds like a bug

> - Still no do...while support for Groovy.  Stupid incompatibility that 
> will trip up countless Groovy newbies.
> - Lots of changes to very basic parts of the Java grammar to 
> incorporate various Groovyisms (stuff like assignmentTail and big 
> changes various expression and statement bits).  It's very depressing 
> to see several hundred lines of custom definitions replacing the short 
> and sweet Java equivalents.

I don't think its the end of the world or anything; so long as we test 
it well.

> - I'm not convinced that throwing in "greedy=true" all over the place 
> is so hot.  It appears that a large number of counter-intuitive parse 
> errors will pop up.  In fact, looking through the grammar Groovy is 
> becoming extraordinarily rigid in what it will allow and might throw 
> an error just if the breeze changes slightly in direction.
> - All the path stuff - complex and buggy in the parse definition, 
> don't want to think about the tree walker that has to figure this and 
> generate some sort of reasonable code.  This is all the perlisms that 
> people are complaining about: "this is the grammar for what can follow 
> a dot:  x.a, x. <at> a, x.&a, x.'a'".  We also of course also have "x*.y".  
> <Shudder>.

The merits of these can be discussed on the JSR list.

> - Looking at the x. <at> a stuff, and comments on properties vs. fields, it 
> is more apparent than ever that properties are hellishly confusing and 
> add little value.  I confidently predict this will be an _endless_ 
> source of bugs to people "oh crap, I said x.a when I meant x. <at> a".
> - Huh, looks like 'as' snuck in there.

Yes. This was brought up a long time ago on the JSR wiki.

foo = bar as String

as a neater syntax to using casts.

> - Hmmm....dollar is a unary expression that indicates "SCOPE_ESCAPE".  
> Oh, I see, a builder thing.


> - Reminded that Map stuff "barewords" get converted to Strings.  I 
> can't remember if this is Classic Groovy or not, but it's evil and a 
> source of endless stupid bugs.  Too terse, people can remember to 
> quote things!

Though we use barewords on named parameter passing in method 
calls/markup - so you could argue its more consistent.

> Overall summary comments:
>         - making newlines optional alone was obviously 75% of the 
> effort here, and obviously has made the grammar extremely fragile.
>         - In general this grammar is extraordinarily fragile.  I feel 
> sorry for anyone who would have to maintain this beast, and it is a 
> beast.
>         - As a basis for a standard grammar specification it's not 
> very useful.  It's way too complex - but then that's because the 
> current groovy syntax is too complex and too hard to parse.
>         - All this work the grammar is doing trying to figure out 
> Groovy is the same work that a human will have to do to understand the 
> language.
>         - Jeremy in particular - make semi-colons and parenthesis work 
> like Java (required), add in required pipe to distinguish a closure, 
> get rid of properties and the perlisms, and now look back at the 
> original studman grammar.  How hard would Groovy be to implement then? 
>  How many lines in groovy.g would be eliminated by this simple change 
> to the rules?

Sure, I hear you - but the idea here isn't to make life easy on the 
implementers, its to make a very expressive language for developers to 
use. Though I agree with your point that stuff should be easy to parse 
- though I disagree that the newline issue is such a big deal - even if 
it does lead to a large delta from the java grammar.