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

Alan Green wrote:
> Mike Spille wrote:
> 
>> At 03:02 PM 1/27/2005, you wrote:
>> Right.  OK, so the first example is a closure.  Now what's this?
>>
>>         b = { foo(); };
>>
>> ...where foo is a method returning an int.  Is b a closure or an int?
> 
> 
> b is definitely a closure.

Agreed

> The rule I'm seeing here - and I hope John or James will jump in to 
> confirm this - is that where a block is part of an expression it isn't 
> automatically called, but where it is used as a statement, it is 
> executed just like it would be in Java.

Yes

> Expressions:
> 
> b = { foo(); };
> b = list.each { foo(); };
> 
> Statements:
> 
> { foo(); };
> while (true) { foo(); }
> if (true) { foo(); } else {bar(); }
> 
>> As I said, this is a slippery slope we're going down.  
> 
> 
> I think we're at the bottom of this little slope already, though.

Agreed. Plus everything you've just said Alan is in Classic Groovy as 
well; we're just trying to formalise/specify exactly what we've been 
doing all this time.

>  > John Rose's proposal said things like:
> 
>>
>> "A block (closure or open block) normally yields as its value the  
>> value of the last statement in the block, or null if there are none."
>>
> 
>> Note that Java and Classic Groovy blocks do not yield a value - there 
>> is no "value of a block". This is a huge change.  And hugely 
>> ambiguous, as the 'b' example above shows - is b a closure or an int?
> 
> 
> I disagree - it's clear enough to me.

Thanks; I'm glad others agree :)

>> Even worse - to get into the more subtle closure return rules, it's 
>> advocated that an exception be used as a control device.  Given that 
>> Groovy is already thoroughly slow, I can't really envision this as a 
>> serious suggestion - yet it was.
> 
> 
> The exception isn't part of the Groovy language, just a suggested 
> implementation mechanism. If you think it will be too slow, maybe dig up 
> some numbers to support your case.

Agreed. Plus you can do really fast stuff with exceptions - especially 
if you know that you are never gonna need the stack trace (e.g. using a 
singleton exception). Throwing/catching exceptions in the VM is very 
fast - its the stack trace creation thats slow.

>> Again, look at the control change proposals:
>>
>>     break;   // exit from innermost do/for/while/switch block
>>     break L;   // exit from block labeled L
>>     break L: x;  // exit from block labeled L with value x (any 
>> expression)
>>
>>     continue;   // exit from BODY of innermost do/for/while/switch block
>>     continue L;   // exit from BODY (appended closure arg.) of method  
>> call labeled L or BODY of Java loop labeled L
>>     continue L: x;  // ditto, with value x (any expression)
> 
> 
> Which means to get the behaviour of a Classic Groovy "return" in New 
> Groovy, you can use "continue", and it probably doesn't require an 
> exception in the implementation, so that ought to make you happy :).

:)

Its worth saying that really, the main change this would make to groovy 
users is that rather than 'return' inside a closure, you'd use 
'continue'. Not a massive change really.

> <snip>
> 
>> This is fundamentally changing what a "block" means in Groovy, 
> 
> 
> Yes, but I'd take out the word "fundamentally".
> 
>  > it's an attempt to unify closures and blocks.
> 
> Yes.
> 
>  > Which I think is highly un-groovy.

I think its very groovy - e.g. see Chris's example

>> This brings me back to one of my original questions - what real value 
>> does this change bring us? 
> 
> 
> Well, it brings the behaviour of the "return" keyword more in line with 
> its meaning in Java (fixing the "why doesn't this return method work?" 
> problem that newbies have with closures), it increases Groovy's 
> flexibility and expressiveness, it provides a sensible answer to the 
> 'break in closure' question, it gives a clear definition of closure 
> syntax and semantics and it does all this while keeping a fairly 
> stripped down, scripting like syntax that still looks enough like Java 
> that Java programmers can learn it.

Great summary, thanks Alan.

>  > And how much _new_ ambiguity does it pull
> 
>> into the mix?  
> 
> 
> I think it resolves more ambiguities than it creates.

Agreed.

I think at first, to a Java guy who's only got anonymous inner classes 
as a guide, the block/closure stuff in Groovy might appear different at 
first; but I'm sure once we properly explain them & implement them, 
they'll learn to like them (or at least some of them will, you can't 
please everyone in language design).

James