Kent  Pitman's

Personal FAQ

UNWIND-PROTECT vs. Continuations

Overview Original Update (2003) Update (2008)

Update by KMP, 7-Nov-2003

Since writing my critique of continuations, I've had a chance to look through Dorai Sitaram's “Unwind-protect in portable Scheme” and have these comments:

  • From a technical standpoint, what he says looks like it should mostly work. (I didn't try the code, but I read it over pretty carefully.)

  • From a community standpoint, I'm troubled by the fact that it means the call-with-current-continuation in the language definition is not the one that one would be using if they want unwind-protect.

  • Regarding Dorai's implementation (since these aren't applicable to Will's:

    I have some concern about the mentioned implementation of fluid-let based on dynamic-wind because discussions elsewhere have convinced me that dynamic-wind should not be used to implement process switching.

    I have some queasiness about code like:

     (letrec ((pl (lambda ()
                    (set! alive? #f)
                    (postlude)
                    ((my-escape-prompt delete) pl))))
       ...)
    

    because of concern about what happens if an error occurs during execution of (postlude) and whether it's possible to end up trying to execute that code twice because the removal is not reached until afterward.

  • Regarding Will's use of dynamic-wind, it seems to me that this use will preclude certain other uses of dynamic-wind. That might be ok, except the spec gives very little advice about right and wrong uses, and I don't know who's going to enforce good usage. For example, dynamic-wind could (absent advice to the contrary) be used to implement fluid variable bindings, but if we're going to use it to implement unwind-protect, then it seems to me that fluid-let has to be done by some other means. That's ok, but since fluid-let is not in the language, how is it to be built up? There's only so much functionality we can squeeze out without admitting that the core language is missing some functionality. I've said that unwind-protect was missing, and Will shows how to implement it by sacrificing dynamic-wind or fluid-let. I feel like we're pushing a bubble around under a carpet.

    Also, in Will's implementation there's this same issue of redefining call-with-current-continuation in order to get this functionality. I would like to see whatever call/cc the user was intended to really use be the one standardized, not have it left to user definition. We need to say whether the standard is a standard for "implementors" or for "users". Since it's often taught directly in class, it appears to be for users. But the posture of some in this discussion has made it sound like this is all subprimitive to some user language that is nowhere described.

I suppose if I had to sum up all of my concerns, I'd say I'm happier seeing this in the language rather than implemented in some kludgey way by users. I look at these implementations and I say "yeah, mostly" and kind of cringe. I'd like the definition to be clean and allow the implementations to try to meet the clean definition, rather than having the definition be "someone's implementation". To me, unwind-protect is quite primitive functionality, not an add-on.

HomeContactDonateLegal Notices

Copyright © 2010 by Kent M. Pitman. All Rights Reserved.