Closures for Java (0.6) specification part b

Neal Gafter neal at
Tue Dec 15 11:27:18 PST 2009

On Tue, Dec 15, 2009 at 9:10 AM, Jonathan Gibbons
<Jonathan.Gibbons at>wrote:

> I don't think you need any new syntax for the invocation. If it looks like
> a lambda expression (as in Mark's proposal, or your 0.6a), it is a
> "standard" lambda expression, with local control flow (return is local, no
> break/continue).   If it looks like control invocation syntax, it is an
> "extended" lambda expression, with non-local control flow (return is
> non-local, break/continue allowed depending on context.)  The only thing I
> would suggest is a more explicit marker on the parameter type to indicate
> that an extended lambda expression is expected.

I think it would be a mistake to have no lambda form that is transparent.
The control invocation shorthand is convenient for some, but not all useful
control APIs.  Your suggestion would only allow one transparent block per
invocation, which must be the last parameter, which cannot have its own
return value, and only in an invocation with no result value.  Because the
language features are not orthogonal in that formulation, those restrictions
prevent expressing many kinds of useful control APIs and code refactorings.

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the closures-dev mailing list