jstrachan | 27 Jan 05:54 2005

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

I'm a bit puzzled as to why you see this as a "massive sea change". 
Really all John's been doing is formalising the semantics of 
blocks/closures in Groovy - something we've always had, in some form, 
since day one.

Like I said in the previous mail; blocks and closures are essential core 
features of Groovy though in Classic Groovy we never formally defined 
them - we just used them. The only real difference between Classic and 
New Groovy is that we're defining what return/break/continue mean inside 
a closure to follow more properly how closures are used in other 
languages (which we always skipped over in Clasic Groovy).

Other than that not much has changed. Given how rare it is that folks 
use break/continue/return (the first 2 have never been implemented 
AFAIK) its not gonna change that much in reality - the only real 
difference is gonna be the tightening up of the 'return' semantics.

 From a language semantic perspective users should be able to think of 
blocks and closures as being kinda the same thing (as John describes). 
Though thinking of closures as objects you can pass around is another 
way of thinking about them too.


Mike Spille wrote:
> At 05:29 PM 1/26/2005, you wrote:
>> jastrachan@... wrote:
>>> So the 'optional' return disappears - return is now mandatory on 
>>> functions/methods, but closures don't use return (in the same way at 
>>> least) and the last expression in the block is the value returned to 
>>> the caller of the closure.
>>> Thoughts?
>> There was a discussion about returns in closure on the JSR mailing 
>> list last September, under the title, "Optional stuff: a proposal: 
>> return and value-producing statements":
>> http://thread.gmane.org/gmane.comp.lang.groovy.jsr/164
>> John Rose proposed that "return" should return from the function that 
>> owns the closure. There was some back-and-forth about what happens 
>> when there is a return in a block and the function that it belongs to 
>> is no longer active. John also also explained how this form of return 
>> could be implemented on the JVM using an exception.
> It's obvious that John Rose has a great deal of language experience.  
> But in the case of Groovy, I'm deeply concerned that he's turning it 
> into a monster.  In a nutshell he's drawing a number of ideas 
> willy-nilly from any number of languages, and his bias is to ignore Java 
> and go more towards a psuedo-functional paradigm.
> This is fine if you want a pseudo-functional language.  But I thought 
> Groovy was supposed to be a language for gluing together Java code and 
> which would be easy for Java developers to learn?
> A great deal of the confusion comes from the term "block".  Most Java 
> developers have a good notion of what a block is - it's pretty much just 
> a scope in which your code runs.
> Other languages have other uses for the term "block", for examples see 
> Smalltalk and Ruby.  When John Rose talks about blocks, he invariably is 
> talking about this latter interpretation.  In fact his Groovy grammar 
> goes as far to talk about "open" and "closed" blocks to talk about 
> closures and blocks.
> Here's where a very, very fundamental decision needs to be made, and 
> people need to be razor sharp and crystal clear in their terminology.  
> Here's where leadership needs to happen and someone needs to decide a 
> very basic rule of Groovy.
> Currently, Classic Groovy blocks are Java blocks.  They are a scoping 
> mechanism which are most often part of a method definition or a control 
> statement (while, if, etc).  This is what Classic Grooovy blocks are, 
> and I don't think it can be reasonably disputed.
> Classic Groovy closures are almost, but not completely, unlike Groovy 
> blocks.  A Groovy Closure can take parameters, is _never_ executed until 
> someone calls call() on it (or one of the variants), and can be hoisted 
> out of its scope and executed.
> Most importantly, you cannot use a Groovy block where a Closure would 
> do, or vice versa.
> To steal Guillaume's words, 'in groovy a closure is a first-class 
> object".  A block is not an object.  Period.
> Most of John Rose's words on blocks completely ignore this fact, and in 
> he tries very hard to convince us that blocks and closures are (almost) 
> the same thing.  In the thread you're referring to, he says:
> "2. 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".  
> Again, as in the New Groovy grammar, we have "open blocks" and "closed 
> blocks".
> He goes in that same thread to argue that "return" doesn't make sense 
> for a closure "because a return from a block means return from the 
> method".  This is not a Classic Groovy notion, it's his invention based 
> on other languages that have closures.  In that world, you don't have 
> Java-style blocks.  You have just blocks, which are open or closed.
> John goes on to talk about the proper way to return a value from a 
> closure - because return doesn't match his notion of blocks:
> [John Rose]
>   For Groovy, the Java 'break' and
> '  continue' statements need to be enhanced to transmit values.  My 
> proposal is:
>       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)
> [John Rose]
> If you're into closure theory and Ruby and are striving towards an 
> ultimate-functional paradigm, this makes a great deal of sense.
> But we're talking about Groovy, what Classic Groovy does and what New 
> Groovy should do.  What John Rose is proposing, cleverly disguised, is a 
> complete sea change.  I know some other people familiar with Ruby want 
> to see this or something similar.  It so happens that I don't.
> The sea change is to abandon the notion of Java blocks and only have 
> functional-style blocks.  The problem here can maybe best be explained 
> if you see the new Closure documents I've written on the wiki.
> Those docs do a halfway decent job of getting across the point that a 
> closure is a snippet of code encapsulated in an object, with its 
> surrounding state sort of hijacked into it.  It has nothing to do with 
> Java blocks - it just happens to have a syntax that looks alot like them 
> :-)  A closure is of type Closure, it has an implicit method, it gets 
> invoked like a method, it has state.
> John's many proposals around closures add up to nuking Java blocks from 
> Groovy and going whole-hog to functional style blocks.  You have closed 
> blocks and open blocks, and ideas like "don't return from a block 
> -that's returning from a method" and "continue L" fit nicely into this.
> But it's a massive change for Groovy.  Truly massive.  Can you imagine a 
> scoping block in Java returning a value?  In Rose Groovy, a block can.  
> And a closure is nothing more than a block which has its surrounding 
> environment "closed" around it.  Likewise, others have proposed nuking 
> Java-style control structures and going full hog to 
> all-functional-blocks, so even if and for and while would be operate 
> with these new-fangled blocks, not Java-style blocks.
> Now, if you can wrap your head around this concept sufficiently, go back 
> and read the docs.  Now imagine how you will explain Rose Groovy blocks 
> to a Java programmer.  Remember, Groovy is supposed to be easy for Java 
> programmers to learn and its primary purpose in life is to glue Java 
> code together.
> Does this sort change really make sense for Groovy?  What value does it 
> add to the primary aims of the language?  Does in fact add any value at 
> all - or is it just something that Ruby programmers think is really cool?
> This is one of the fundamental reasons why I've always leaned towards a 
> closure keyword, and avoiding blocks and the Ruby-style parameter 
> lists.  It's promoting a concept that doesn't really exist in Groovy 
> Classic, and that I hope doesn't make it into New Groovy.  The way 
> closures work now, and what will add value and make sense to Java 
> programmers, is that a closure is an class definition with an implicit 
> method and a type of Closure, and when the compiler encounters such a 
> beast it is instantiated, not executed.  This Java developers will 
> understand, with a bit of coaching.
> All this Ruby and functional stuff will turn Java developers off quicker 
> than minus 30 degree cold snap.
> I will add that John seems determined to truly change Groovy in very 
> fundamental ways.  James, you may disagree with me here, but from where 
> I sit John keeps proposing radical changes to move Groovy into a more 
> functional realm, and away from Java.  The plethora of new composite dot 
> operators (. <at>  etc).  Changing Java blocks into functional style blocks. 
> Adding a "return value" to break and return.  Bizarre compromises in the 
> new grammar - typed arguments need parens, untyped ones don't?  You 
> determine types by whether they're upper case or not?  The '--' 
> operator?  Entirely different and new ways of being whitespace sensitive?
> Hey, we all have ideas on how to grow Groovy and mature it.  All of us 
> have at least one whacky idea, maybe even several.  What really worries 
> me is that John Rose is given almost free reign with his ideas, while 
> others are quashed.  Many people are told "no" on various ideas, but 
> John just goes ahead and puts his ideas into the grammar.
> James, I'm sure you'll say "none of this is final, we still need to 
> evaluate it" - but the problem is that of unequal representation.  Undue 
> weight is given to John's ideas, and too little is given to others.  And 
> since you're letting him drive the grammar, the bulk of "new" stuff is 
> in fact John's own private ideas.  Almost as bad, the grammar is moving 
> so far away from Java that it's already almost twice the size, and it's 
> chock full of nasty hacks.
> Yeah, it's provisional and can be evaulated - but how much time is 
> wasted, especially once someone's already gone ahead and put it into the 
> grammar?  And things put into the grammar tend to have a weight all 
> their own.
> This isn't an anti-John rant, but it is strongly against what he's doing 
> to the language, and the undue gravity given to his ideas.  James, 
> you've put the future of Groovy into the hands of someone determined to 
> change almost every fundamental aspect of it.  I fully expect New Groovy 
> to not really be backwards compatible with Classic Groovy - but I expect 
> there to be at least a passing resemblance.
>> Alan
>         -Mike