return-from-lambda viewed as dangerous, good alternatives

[Jonathan Gibbons]

Neal Gafter wrote:
> On Thu, Jan 7, 2010 at 3:06 PM, Jonathan Gibbons
> <Jonathan.Gibbons at sun.com>wrote:
>
>   
>> I don't deny the importance of control abstraction, and I don't deny that
>> closures can provide the implementation mechanism; I was simply noting that
>> we don't need identical syntax for them, or even (for users) to think of
>> them as the same concept.    So, in a closure, return means return from the
>> enclosing closure; in a control abstraction, return means return from the
>> enclosing method, and it is merely an implementation detail for compiler
>> engineers that control abstraction might get desugared into a closure, with
>> any return statements being converted into an appropriate non-local return.
>>
>>     
>
> I'm not sure I understand what you mean by "control abstraction" here.  The
> BGGA control invocation statement form can only express a limited subset of
> the use cases for control abstraction (e.g., only one controlled block),
> which is why there's an underlying transparent lambda form.  What do you
> have in mind for "control abstraction" that is not a closure?
>
>   

I don't have specific syntax in mind. I just have a sense that 
closures/lambdas are functions and within those functions, return should 
have its "obvious" meaning of "return from the function", whereas 
control abstraction is a potential new language feature that allows the 
user to create a limited set of new statement forms without having to 
wait for the next version of Java.  Within these statement forms, return 
should have its "obvious" meaning of "return from the enclosing 
method".  So, at some level, this is just naming.   I think of closures 
as what I believe you call "non-transparent closures", and I think of 
"control abstraction" or "new statement forms" or whatever the right 
name is as what you are calling "transparent closures".   I think the 
two are different enough to have significantly different names, and to 
be treated separately, even though one may be built on top of the other.