Closures for Java (0.6) specification part b

[Jonathan Gibbons]

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


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.

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