Re: Re: thoughts on the closure/return/break/continue issue

On 2 Feb 2005, at 04:10, Alan Green wrote:
> jastrachan@... wrote:
>> So how about this minor change...
>
>> (i) Method bodies and closure blocks with a single expression do not 
>> need a return/continue statement.
>
>> (ii) method bodies and closures which return a value and have more 
>> than one expression/statement, must use a return or continue 
>> statement
>
>> (iii) unless a method body or closure is a single expression, then no 
>> dumb expressions are allowed anywhere in the block.
>
>> Thoughts?
>
>
> I suppose that I would get used to "continue" in time, but overall, I 
> prefer your first set of rules.

Its certainly a little odd at first - but I think you get used to it 
quite quickly - as its use is symmetrical with regular Java loop blocks

> A driver for this proposal seems to be dumb expression rule.

To an extent yes - though mostly this amendment was driven by wanting 
to simplify rules as much as possible and making the rules for methods 
& closure blocks & loop blocks as similar as possible. So

'return' terminates execution of the method
'continue/break' terminates execution of the block/closure

Then I figured we should use the same rules as to whether a terminator 
statement was required or not in both methods & closures.

>  I'm not too worried about allowing dumb expressions in more places. 
> The dumb expression rule's only purpose is to help the parser catch a 
> specific kind of error. Catching dumb expressions is helpful, but it 
> shouldn't hold the rest of the grammer back.

Agreed - the above changes though were really hoping to simplify when a 
return/continue is mandatory

> I'd be more enthusiastic if there were a lighter-weight way to spell 
> "continue" in the sense of "exit-closure-with-value". Perhaps a 
> leading '=' on a statement?
>
> list.collect {if (it > 123) {println "hey";=1} else {=0}}

Though the great thing about using continue, is it can be used in the 
traditional 'continue-to-label' way and the new 'continue-with-value' 
way.

> I'd also be quite comfortable with the existing rule, "the value of 
> the last executed expression before falling off the end of the 
> closure, is the value of the closure." Smalltalk works just fine like 
> this, and I think Groovy would too.

Though if we did that, we'd have to do the same for return as well I 
suppose, so we'd have optional return again. Its certainly a thought.

I was thinking if we should probably shave off a few optional things 
for now & see where we get to and maybe put some back if we want to 
later - but I guess this decision - whether or not return/continue is 
mandatory or not is mostly a semantic check and doesn't cause any 
ambiguity.

My main reservation is it could hide a dumb expression...

def foo() {
   x += 1
   +1
}

Thoughts?

> Just my $0.02.
>
> Alan
>
> PS: I was just wondering, do you misspell "typos" on purpose? :)

no that was a freaky accident :)

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