Allen's lambda syntax proposal
jaz at bu.edu
Sat Dec 6 12:39:45 PST 2008
On Sat, Dec 6, 2008 at 2:03 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Dec 6, 2008, at 9:57 AM, Jon Zeppieri wrote:
>> On Sat, Dec 6, 2008 at 11:49 AM, Maciej Stachowiak <mjs at apple.com> 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
>>> then in the face of exceptions alone you can wrap it in try/catch.
>>> 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
>>> 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
I'd say that under the proposed semantics, return from lambda isn't
normal control flow; it's a (potentially) non-local jump. Normal
"return" inside a lambda is just falling off the end.
>> 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.
Yes, because it is very similar to throwing an exception. Would you
prefer that return inside lambda instead return from the lambda's own
activation? That could be done, with some violence to TCP.
In the most common case, however -- namely, return from function,
which, under Dave's proposal, desugars to a return from lambda --
couldn't the additional cost be optimized away easily? You can
determine statically that the jump doesn't unwind the stack, so the
cost of returning should remain the same.
> 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.
Okay, but you only incur this expense when you actually take the
non-local exit. There is no reason why normal returns should be more
More information about the Es-discuss