return when desugaring to closures

Mark S. Miller erights at
Sat Oct 11 15:26:07 PDT 2008

Hi Dave, first, my compliments on your lambda proposal. This should
significantly simplify the core language after expanding sugars --
especially if you succeed at redefining function as desugaring to
lambdas. That would be awesome!

On Sat, Oct 11, 2008 at 5:34 AM, David Herman <dherman at> wrote:
> Here's roughly the semantics of return-to-label:
> - return-to-label first checks to see if the label is live on the stack
> - if not, it raises an exception from the point where the return was attempted
> - but if so, it attempts to unwind the stack to the point where the label was executed, passing through any intervening finally clauses
> - if any of the finally clauses has its own non-local exit, this interrupts and aborts the unwinding
> Thank you for pointing out, though, that try/catch isn't so easily defined on top of return-to-label, since it still needs special handling for finally. The options are either to define a lower-level primitive underlying try/finally (akin to Scheme's dynamic-wind), or to leave exceptions -- or at least try/finally -- as primitive. I lean towards the latter; dynamic-wind is a subtle beast.
> [For those interested in dynamic-wind, Flatt et al's ICFP 07 paper has a nice investigation into its semantics:]

I haven't looked at the Flatt paper yet. But the semantics you explain
above corresponds exactly to E's escape expressions. And E also treats
try/finally primitive for similar reasons. (Historical note: The E
escape construct and the call/ec previously explained both originate
in an "escape" statement by Reynolds from a paper in the late 60s or
early 70s. I don't recall whether Reynolds had any mechanism analogous
to try/finally.)


More information about the Es-discuss mailing list