return-from-lambda viewed as dangerous, good alternatives

[Stephen Colebourne]

2010/1/7 Jonathan Gibbons <Jonathan.Gibbons at sun.com>:
> I don't deny the importance of control abstraction, and I don't deny
> that closures can provide the implementation mechanism; I was simply
> noting that we don't need identical syntax for them, or even (for users)
> to think of them as the same concept.    So, in a closure, return means
> return from the enclosing closure; in a control abstraction, return
> means return from the enclosing method, and it is merely an
> implementation detail for compiler engineers that control abstraction
> might get desugared into a closure, with any return statements being
> converted into an appropriate non-local return.

Yep. +1.

To put some notional user syntax on it:

. list.each(#(String str) {
. . // some code with local return
. });

. for (String str : list.each()) {
. . // some code with method return
. }

. list.eachInParallel(#() {
. . // some code with local return
. . // method return would be broken, so this must not be used as
control invocation
. });

. do (lock.lock()) {
. . // some code with method return
. }

There is no reason why the method argument (Project Lambda) and
control invocation forms need to be thought of by the user as the same
language feature.

In the examples, the control invocation syntax looks to the developer
like a variation of an existing control statement, and nothing like
the Project Lambda style closures. Looks different, ergo syntax
elements like 'return' have a different meaning.

(Whether they actually are the same feature is something I'm a little
ambivalent about. I suspect that it will be cleaner for control
abstraction to be a related but different feature. Ideally I'd like to
see in place expansion, a la macros, but I'm not going to work on the
details of control abstraction which is an unlikely change to Java in
the next 5 years.)

Stephen