Update by KMP, 7-Nov-2003
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
Regarding Dorai's implementation (since these aren't applicable
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)
((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