Closures for Java (0.6) specification part b

Jonathan Gibbons Jonathan.Gibbons at Sun.COM
Mon Dec 14 21:52:58 PST 2009


Neal Gafter wrote:
> On Mon, Dec 14, 2009 at 11:47 AM, Jonathan Gibbons 
> <Jonathan.Gibbons at sun.com <mailto:Jonathan.Gibbons at sun.com>> wrote:
>
>     Ouch. That's pretty subtle, especially as the statement in a
>     control invocation form is defined to use an expression lambda
>     instead of a statement lambda. 
>
>
> Maybe subtle for the specification, but not subtle for the Java 
> programmer, as you don't see a lambda when you're writing a control 
> invocation.
>
> Cheers,
> Neal
>
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. 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.

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

-- Jon

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091214/860b4ce1/attachment.html 


More information about the closures-dev mailing list