return-from-lambda viewed as dangerous, good alternatives

[Alex Buckley]

BGGA offered transparency and non-transparency via unrestricted and 
restricted function types and closures. CfJ 0.6a and 0.6b, taken 
together, offer both too. The differences are well understood.

However, the Project Lambda strawman - and this list - are about 
non-transparent a.k.a. restricted lambdas. I will soon be sending a 
draft spec for lambdas as envisaged in the strawman. Hopefully further 
discussion about transparency can occur on closures-dev, as Neal said 
earlier.

Alex

Lawrence Kesteloot wrote:
> 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
>