Closures for Java (0.6) specification part b
Jonathan.Gibbons at Sun.COM
Tue Dec 15 09:10:46 PST 2009
Neal Gafter wrote:
> On Mon, Dec 14, 2009 at 9:52 PM, Jonathan Gibbons
> <Jonathan.Gibbons at sun.com <mailto:Jonathan.Gibbons at sun.com>> wrote:
> There is still potential confusion for the programmer using lambda
> expressions however.
> Someone reading 0.6a might reasonably infer that an expression
> lambda could easily be converted to statement lambda by adding a
> "return" and changes parens to curlies.
> I think that issue is mainly academic. I'd be surprised to find
> someone trying to use an expression lambda with a block expression
> (i.e. statements in the parens). Given the existence of statement
> lambdas, the code would be awkward for no apparent reason. The only
> real reason to do so would be to be able to use the nonlocal transfers
> in a context where you can't use the control invocation syntax (e.g.
> there are two controlled blocks to pass to a method). If you try to
> change a lambda from expression lambda to statement lambda, the
> transfers become compilation errors (except for a return statement in
> the unlikely event that the enclosing method and the lambda have the
> same return type).
> Most people nowadays make such local transformations using IDEs, and
> the IDE would presumably know how to do it correctly.
> If 0.6a were all there was, that would work. But in 0.6b, you've
> added block expressions. They look great - I want to use them -
> but they've broken that "obvious" rule relating expression lambdas
> to statement lambdas. Suddenly, there is a substantial non-obvious
> difference between expression lambdas and statement lambdas.
> I think it's pretty obvious that "return" means something different.
> That's the whole point of introducing statement lambdas. break and
> continue just turn into compile-time errors.
> With the for loop invocation syntax, we get to add another
> modifier to the signature, which makes it very clear this is a
> different sort of function type.
> The for modifier doesn't affect the function type, but I see where
> you're going with this.
> Is there any similar way we could mark the type of any function
> type that is to be used for control flow abstraction, not just for
> loops? This would then avoid the need for the subtle semantic
> difference between expression lambdas and statement lambdas, and
> avoid the downstream puzzlers comparing the behavior of the two.
> Puzzlers are only worrisome if they bite you, and I believe this one
> The "for" modifier on the method doesn't affect the interpretation of
> the lambda or its contents... it is the appearance of the "for" on the
> invocation that changes the labels that are in scope when the lambda
> occurs. I would be very concerned about having the target type affect
> the meaning of the lambda body.
> I believe you still need both kinds of lambdas: you need expression
> lambdas for things like concise aggregate operations, and some people
> have insisted that you need statement lambdas where returning early is
> important for structuring the computation. So you're probably talking
> about a third lambda form. It is the lambda that needs another form,
> not the function type, even if you are saying that you like the
> restricted versus unrestricted function type distinction from BGGA,
> and want to bring that back into this revision of the spec.
> P.S. It wouldn't be quite so bad if the difference were the other
> way around, with local return, no break/continue in expression
> lambdas, and non-local return in statement lambdas, but it would
> still be even better if we could make the difference more
> explicit, somehow.
> I think the current spec is a worthwhile simplification versus BGGA,
> but I'd be happy to entertain further revisions. Maybe you like
> BGGA's lambda syntax for these "blocks" ?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the closures-dev