Closures for Java (0.6) specification part b

[Jonathan Gibbons]

Neal Gafter wrote:
> On Tue, Dec 15, 2009 at 2:09 PM, Jonathan Gibbons 
> <Jonathan.Gibbons at sun.com <mailto: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.

I accept that they have different syntax.  They also have different and 
obvious meanings depending on whether you want a lambda to be a simple 
expression or not.   Overloading that relatively simple difference with 
transparency semantics is ingeniously clever in a way that is not as 
intuitively obvious and clever as the rest of the proposals. My $0.02.

>
>     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?
Yes, I'm suggesting both of the lambda forms in 0.6a to have returns 
treated locally, and then to have another way, either a third form or 
variants of the other forms, that provide transparency.  I phrase it 
that way to try and emphasize that transparency seems to be an othogonal 
property to the difference between expression and statement lambdas.

>
> *#( 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
>

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