jastrachan | 4 Mar 08:37 2005

Re: Groovy beta 10 released! (+JSR Early Access)

On 2 Mar 2005, at 08:19, Chris Poirier wrote:
>> Currently the parser handles any kind of whitespace layout for
>> if/for/while you like - but we figured it might be good to gently
>> encourage folks to use a consistent { placement policy to avoid
>> confusion; so we generate a warning (actually currently we don't
>> display it :).
> We had this /exact/ discussion on the JSR list a few weeks ago.  At the
> time, you seemed very happy with the idea of closures as equivalent to
> blocks.  As I recall, you said, "great example, Chris!"

Chris this is a completely different discussion. Here we are discussing 
newline placement with closures and blocks. Before we were discussing 
how return/break/continue should behave inside blocks with for/while 
loops and closures. Completely different things.

>> * keep doing what we're doing; handle any indentation on if/for/while
>> but generate a warning (which could be turned on/off) but still 
>> require
>> the { on the same line for closure calls
>> * disallow free standing blocks (which could also confuse and has
>> issues in the grammar, e.g. with labels)
>> * let users use any indentation policy they wish and possible let them
>> get confused with the above example - i.e. restricting the { placement
>> rule to only closure invocations
>> * force that every single statement absolutely must end with a 
>> semicolon
> 5) fix the grammar to remove the ambiguity of closure identification 
> by:
>    1) providing a long-hand syntax for closure parameter lists (you
>       don't have to use it, but some of us certainly would);

A keyword isn't required per se - we can always avoid ambiguity via 

>    2) ditching closures as a free r-values on assignment;

Closures are useful to pass around

>    3) making unattached blocks illegal.

Sure - we currently don't allow unattached blocks; FWIW I've just 
documented the ambiguities involved on the JSR list and proposed a 
solution which is similar to yours