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

On 26 Jan 2005, at 11:11, jastrachan@... wrote:

> 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 there.

Whoops, meant to CC the JSR list on the previous send.

> 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 you.
>
>
>> - 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 
> everywhere.
>
>
>> - Already mentioned, bitwise or (|) is disallowed.
>
> We should enable it, if we can use the double-bar notation & avoid 
> ambiguity.
>
>
>> - 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.
>
> Yes.
>
>> - 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.
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>

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