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

Mike Spille wrote:
> At 11:45 PM 1/26/2005, you wrote:
>> Mike Spille wrote:
>>> At 10:41 AM 1/26/2005, you wrote:
>> i.e. I think we should implement closures properly like other 
>> languages have done in the past (Smalltalk & Ruby to name 2 off the 
>> top of my head) rather than use a crippled Java-style closure system 
>> for fear of confusing users - who have never used closures before 
>> anyway. i.e. its not like they're gonna try use Java-closures and find 
>> they're different in Groovy - they just don't exist in Java.
> 
> 
> This is nonsense James.  Ask 3 people from 3 different languages what "A 
> Closure is", in detail, and you will get 3 very different answers.

 From my experience, folks who've actually used closures tend to have 
similar mental models (and tend to really love them too).

> Ask people if Groovy implements closures now, and many people will say 
> "yes".  Whether it's defined with a keyword or braces or braille is 
> immaterial.  You have closures now, I don't see why you should 
> complicate things by trying to pull extra features or semantics from 
> other languages.

We're not trying to complicate things or pull features; we just never 
quite properly finished implementing them & ducked out on properly 
handling return/break/continue. (We never quite formally defined what 
return/break/continue mean in a closure & never really used them before)

>> As an aside, someone coming from backgrounds in Smalltalk (you'd be 
>> surprised how many ex-Smalltalkers are in the Java community), Ruby or 
>> other languages with closure support - admittedly a much smaller user 
>> base I imagine -  would be instantly at home with Groovy closures; or 
>> be very confused if we crippled them as you suggest.
> 
> 
> You'd be surprised how small the ex-Smalltalker community is compared to 
> those who know nothing about Smalltalk.  Out of a 100 randomly chosen 
> Java developers I'd be surprised if 3 actually ever used Smalltalk.

I know many ex-smalltalkers and quite a few folks who've used ruby & 
lisp; maybe thats just me.

> Again, this is of course a leadership thing.  Are you trying to make a 
> language that appeals to ex-Smalltalkers, or are you trying to make a 
> language that appeals to Java developers?  The two are _quite_ 
> different, I can assure you.

The aim is still to appeal to Java developers - the entire language is 
designed with Java developers in mind.

I'm just saying there's no reason to not do closures right (like they've 
been done in every other language I'm aware of that implements them) - 
and moreover those folks who have used smalltalk/lisp/ruby will feel at 
home as a small added bonus.

Java (the language) had to dumb down various features (e.g. anonymous 
inner classes versus closures) to appeal to the masses at the time, who 
seemed to want something like a safer C++ - I don't think we need to 
dumb down feature, like closure support, in Groovy - since if folks want 
dumbed down closures, they can always go back to Java & use AIC :)

> Finally - please tell me how I'm "crippling" closures.

See Chris's control flow example; by using methods like each(), 
findAll(), collect() with closures we should be able to have the same 
control flow (exceptions / return / break / continue) as if we were 
using for & while statements.

 > Do your examples
> no longer work?  All that, ahem, stuff you sling in your various 
> presentations about Groovy - do they no longer apply after adding in my 
> modifications?  The answer is simple: of course they still apply.

Slides tend to have quite hello-worldy examples for brevity :)

Its not a major change we're proposing; just fixing the semantics of 
return/break/continue in closures.

A side benefit is that we can now make return mandatory in all methods - 
simplifying the rules on the 'return' statement - and allowing us to use 
the 'no dumb expression rule' to catch typeos.

FWIW I don't expect return/break/continue to be used *that* much - but 
since we're trying to clearly specify the language we need to define the 
exact semantics of return/break/continue.

James