transparent lambda

[Peter Levart]

Currently the straw-man proposal does not propose transparent lambdas. The "expression" form:

#() ( expression )

is transparent but limited. It does not allow "continue, break, return" to be specified as part 
of expression and the "statement" form:

#() { statements...; }

is not transparent since it does not allow "continue, break" to transfer the control of 
execution out of the lambda and "return" is specified to be local (returning control to the 
invoker of the lambda).

The "expression" lambda form can be viewed as a shorthand for:

#() { return expression; }

So what straw-man actually proposes is a form that is not much different from anonymous inner 
implementations of SAM interfaces with shorter syntax.

The question is: Are we settling for less? Will we regret it in the future?

The answer in my opinion is: Yes, if we use the syntax now for non-transparent form, Java will 
never get real transparent lambdas.

On the other hand, there is Neal's CfJ proposal that in essence (0.6a) is not much different 
(though much more complete) to straw-man. It has the "expression lambda" form:

#() expression            // note the absence of parentheses

and the "statement lambda" form:

#() { statements...; }

The "expression lambda" form is specified to be transparent. The extended proposal (0.6b) 
specifies the so called "block expression" that allows statements to precede  final expression. 
Statements in block expression can contain "break, continue, return" that, when used in 
"expression lambda" transfer control transparently to non-local locations out of the lambda.

But the "statement lambda" form is still specified as non-transparent form.

So we have two forms, using two syntax variations and two different behaviors.

If we have two forms, the transparent and non-transparent one, why do we need the non-
transparent at all? 

Is it because non-transparent form allows early local returns, so the code can be structured 
more naturally like inside the method? I don't see any other reason. (BGGA specification allowed 
APIs to specify that they only accept "restricted" (non-transparent) closures. Current 
specifications don't have any provision for that. My opinion is that this was a complication that 
was not needed.)

If the only reason for non-transparent forms is that they allow local returns, then maybe, 
instead of having two lambda forms, we only keep the transparent one (expression lambda) and add 
something like the following:

(see attached HTML)

Please note that there may be errors in the attached document. If you spot some, please report 
them.

Regards, Peter