Allen's lambda syntax proposal

Maciej Stachowiak mjs at
Sat Dec 6 11:03:41 PST 2008

On Dec 6, 2008, at 9:57 AM, Jon Zeppieri wrote:

> On Sat, Dec 6, 2008 at 11:49 AM, Maciej Stachowiak <mjs at>  
> wrote:
>> On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote:
>>> I don't get it.  What issue is raised by return-to-label that isn't
>>> already raised by exceptions?  They're practically the same thing,
>>> only return-to-label is *easier* to analyze statically, because
>>> 'return' can only jump to a label that is lexically (not just
>>> dynamically) in scope.
>> If you want to call a function and make sure control flow does not  
>> escape,
>> then in the face of exceptions alone you can wrap it in try/catch.  
>> However,
>> with multi-level returning lambdas, if you are passed a function  
>> then you
>> have no way to prevent it from returning early, since it could be a  
>> lambda
>> in the lexical scope of your caller.
> The strawman contains the following text:
> "Unwinding the execution context may pass through finally blocks,
> which execute and may perform their own control effects, effectively
> canceling the unwinding."
> So, you have a dynamic-wind-like mechanism, if you need it.

I guess then the damage can be contained, but it's unusual to use a  
mechanism like this for normal control flow rather than just  
exceptional conditions.

> Also, what was the performance issue?

It turns return inside a lambda into a construct that has to unwind  
the stack (and apparently run finally handlers), which makes its cost  
more like the cost of throwing an exception than the cost of a normal  
return. In most implementations, throwing an exception is much more  
expensive. Actually, it could be worse than throwing an exception,  
since if you can't actually unwind the call stack until you find  
whether the lambda's containing function is currently on the stack.


More information about the Es-discuss mailing list