Closures for Java (0.6) specification part b

[Neal Gafter]

On Tue, Dec 15, 2009 at 2:09 PM, Jonathan Gibbons
<Jonathan.Gibbons at sun.com>wrote:

>  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.
>

I don't think it is abuse.  Expression lambdas are always transparent.
Statement lambdas are not.  They already have different syntax.

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,
>

I think this is confusing the API with the API client.  The abstractions are
written as methods and don't involve closures.  They might not even use
function types (they could use interfaces instead).  The client, on the
other hand, can use whichever form best expresses the purpose in the client.

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.
>

That was the restricted versus unrestricted function type distinction in
BGGA.

Perhaps you'd like both of the lambda forms in 0.6a to have returns treated
locally, and add a third form that provides transparency?

*#( FormalParameters ) => ( **Statementsopt Expression **)
*

As I pointed out previously, if we do that then we don't need block
expressions, and we can use a slightly different lambda conversion for
transparent lambdas that allows boxing and unboxing when matching lambda
parameters to the interface function.

Cheers,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091215/2e6c5827/attachment.html