return-from-lambda viewed as dangerous, good alternatives

[Lawrence Kesteloot]

On Fri, Jan 8, 2010 at 12:56 PM, Neal Gafter <neal at gafter.com> wrote:
> The basic rules of Java aren't yet defined for closures.  These aren't
> word games: you can't reasonably claim that a construct not yet in the
> language is already defined.

That's precisely what I'm claiming. If someone proposed that closures
use dynamic scoping and argued that scoping rules "aren't yet defined
for closures", you could still reasonably claim that Java programmers
expect static scoping in all function calls, both today and for the
remainder of the life of the language. I claim this for "return"
within something that looks like a function definition.

> I'm not sure I understand your proposal.

How about I start with requirements-by-example. I expect return (and
break/continue) transparency in this snippet:

    forEach (Item item : itemList) {
        if (item.isGood()) {
            return item;
        }
    }

    return null;

and return non-transparency in this one:

    newList = oldList.map(#(Item item) {
        try {
            return item.process();
        } catch (ProcessException e) {
            return null;
        }
    });

Something like:

1. A function defined in a control invocation syntax (not with a
preceding "#()") is return transparent, and also break/continue
transparent as appropriate to the "for" modifier. This could be called
a "block".

2. A function defined as an expression (with a preceding "#()") is not
return transparent. This could be called a "closure".

3. A "closure" is assignable to "block", since it's more limited.

4. An API call that accepts a "closure" (e.g. addListener()) would not
be able to accept a "block" (since it's less restricted).

5. The implicit contract when you accept a block is that you must not
invoke the block after you return.

I apologize for the sloppy terminology.

This doesn't satisfy Stephen Colebourne's requirements (e.g., the
author of forEach above could violate the contract of "block" by
storing the block and invoking it later, throwing an exception on
"return"), but does satisfy mine.

> How would one declare the parameters of a block?

See your control invocation syntax, which I like a lot.

> How would one yield its result value?

Blocks never yield results. Blocks don't yield results now, functions
do. You need that, use a closure.

> Or is CfJ 0.6 a/b <http://www.javac.info> already what you're describing,
> but with your "block" called an "expression closure"?

Right, but with a more restrictive variant when the definition looks
like a function (see "closure" above).

Lawrence