Closures for Java (0.6) specification part b

[Jonathan Gibbons]

Neal Gafter wrote:
> On Tue, Dec 15, 2009 at 9:10 AM, Jonathan Gibbons 
> <Jonathan.Gibbons at sun.com <mailto:Jonathan.Gibbons at sun.com>> 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.
>
> Cheers,
> Neal
>

All fair enough, but wouldn't it be clearer to have some explicit syntax 
to indicate transparent rules, rather than (ab)using the difference 
between expression lambdas and statement lambdas.  

It seems to me that control flow abstraction is more likely to involve 
statement forms, and so anyone wanting to build control flow abstraction 
using explicit lambdas is more likely to try and use statement lambdas, 
and be surprised at the need to use the somewhat less obvious expression 
lambdas, with the somewhat curious "(Void) null" at the end.  I guess 
I'm still trying to find some suggestions for explicit syntax to use, 
that is somewhat more obvious than round vs curly parens.   Maybe some 
variant of "#" can be used, so that simple # means simple/standard 
lambda, and ## or #word or word# (for some word tbd) could mean a 
transparent lambda.

-- Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091215/57b836a5/attachment.html