Closures for Java (0.6) specification part b
Jonathan.Gibbons at Sun.COM
Tue Dec 15 17:53:53 PST 2009
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the closures-dev