return-from-lambda viewed as dangerous, good alternatives

[Jonathan Gibbons]

Mark Thornton wrote:
> Mike Swingler wrote:
>   
>> On Jan 7, 2010, at 12:45 PM, Stephen Colebourne wrote:
>>
>>   
>>     
>>> The whole purpose of John's argument is to leave return free to be
>>> used in a later JDK for non-local transfer. Lets say that is JDK 8 or
>>> 9.But given the glacial speed at which many shops upgrade JDK
>>> versions, this will mean that many developers will face jumping
>>> straight from JDK 6 to this new JDK 8/9 with non-locals. The same
>>> problems that Josh described in Devoxx thus re-appear.
>>>
>>> Thus I have some rules I'm following here:
>>> 1) Developers must be able to trust the 'return' keyword. It must
>>> never throw a NonLocalTransfer, now or in the future.
>>>
>>> 2) Some other element is allowed to do non-local return and throw a
>>> NonLocalTransferError, eg 'throw return'.
>>>
>>> 3) If it looks like a method, ie. round-bracketed arguments followed
>>> by code, then it must be a local return.
>>>     
>>>       
>> +1
>>
>> In all the mainstream languages that have adopted closures, "return" really means the least surprising thing. I think non-local transfers should have a unique keyword or label syntax or whatever, and should work across traditional methods and closures when their time comes.
>>
>> Regards,
>> ~Mike
>>
>>   
>>     
> Surely the point of control abstraction is that return/break/continue 
> look local to the containing method and that the very existence of the 
> 'lambda' may not be immediately apparent to casual observation. Using 
> different keywords for the local transfers breaks this illusion.
>
>
> Mark
>
>
>   

Doesn't this just go to show how control abstraction != closures, 
although they could be desugared into closures?

-- Jon