Subject: Re: call/cc in lisp
From: rpw3@rigden.engr.sgi.com (Rob Warnock)
Date: 24 Sep 2001 01:37:37 GMT
Newsgroups: comp.lang.lisp
Message-ID: <9om2p1$m2h86$1@fido.engr.sgi.com>
Erik Naggum  <erik@naggum.net> wrote:
+---------------
| * Per Bothner <per@bothner.com>
| > R5RS has 'dynamic-wind' which is a generalizationm of unwind-protect.
| 
|   Kent Pitman has shown that the two mechanisms are orhogonal.  I do not
|   buy the line that dynamic-wind can implement unwind-protect properly.
|   Could you show us how it can?
+---------------

Indeed, the last time this came up (back in May?), I believe I showed
in <URL:news:9e00uc$915mi$1@fido.engr.sgi.com> that R5RS "dynamic-wind"
specifically *lacks* the ability to emulate UNWIND-PROTECT, since in CL
the cleanup form is allowed to THROW (provided it's to a context further
up the stack than the target of the current non-local exit, see CLHS 5.2
and 5.3->THROW), whereas in R5RS the "after" form is not:

        6.4 Control features
        ...
        (dynamic-wind before thunk after)
        ...
        The effect of using a captured continuation to enter or exit the
        dynamic extent of a call to "before" or "after" is undefined.

But even more important was the observation that:

    ...there is no guarantee anywhere in R5RS that "signalling an error"
    interacts in any way with dynamic-wind!! At most an implementation
    is required to "detect and report" certain errors, but it's not
    required to do this by calling a continuation captured with call/cc
    in the top-level REPL (albeit that's one "obvious" implementation),
    and thus it's not required to execute any "after" thunks in any
    active dynamic-winds.

    This means that R5RS call/cc + dynamic-wind are inadequate to
    implement a portable exception-handling system.

Q.E.D.


-Rob

-----
Rob Warnock, 30-3-510		<rpw3@sgi.com>
SGI Network Engineering		<http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA

[Note: aaanalyst@sgi.com and zedwatch@sgi.com aren't for humans ]