Closures for Java (0.6) specification part b

[Jonathan Gibbons]

Mark Mahieu wrote:
>
> On 15 Dec 2009, at 22:09, Jonathan Gibbons wrote:
>
>> Neal Gafter wrote:
>>> On Tue, Dec 15, 2009 at 9:10 AM, Jonathan Gibbons 
>>> <Jonathan.Gibbons at sun.com <mailto:Jonathan.Gibbons at sun.com>> wrote:
>>>
>>>     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.
>>>
>>>
>>> I think it would be a mistake to have no lambda form that is 
>>> transparent.  The control invocation shorthand is convenient for 
>>> some, but not all useful control APIs.  Your suggestion would only 
>>> allow one transparent block per invocation, which must be the last 
>>> parameter, which cannot have its own return value, and only in an 
>>> invocation with no result value.  Because the language features are 
>>> not orthogonal in that formulation, those restrictions prevent 
>>> expressing many kinds of useful control APIs and code refactorings.
>>>
>>> Cheers,
>>> Neal
>>>
>>
>> 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.  
>>
>> 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, and be surprised at the need to use the somewhat 
>> less obvious expression lambdas, with the somewhat curious "(Void) 
>> null" at the end.  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.
>>
>> -- Jon
>
> I think the "(Void) null" is intended to be added by the compiler, and 
> isn't something the programmer would see.
>
> But I agree people might think they should use 'statement lambdas' to 
> build control 'statements'.  It threw me when I first read it.  This 
> could well be just an case of finding alternative terminology though.
>
> Mark
>


Mark,

"(Void) null" will be added by the compiler when the user is using 
control invocation syntax, but Neal was saying that won't be enough for 
all cases, implying that sometimes, the user will want to explicitly 
create their own lambdas with transparent control flow semantics.

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