Closures for Java (0.6) specification part b

[Neal Gafter]

On Mon, Dec 14, 2009 at 9:52 PM, Jonathan Gibbons
<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
doesn't.

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" ?

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