> On Nov 30, 2019, at 09:23, Matthew Flatt <[email protected]> wrote:
>
> There's not a safe way. In many cases, Racket lets you write new things
> that have the power of built-in through unsafe APIs --- and it turns
> out that there are unadvertised procedures (provided by the primitive
> `#%unsafe` module) for this particular case:
>
> unsafe-abort-current-continuation/no-wind
> unsafe-call-with-composable-continuation/no-wind
Thanks, those operations look helpful. I do worry a little bit that maybe they
only solve the `dynamic-wind` problem, though, and don’t solve some other,
related problems. For example, imagine I were to replace `dynamic-wind` with
`parameterize-break`:
(run-amb/first
(thunk
(parameterize-break #f
(+ (amb 1 2) (amb 3 4)))))
Presumably, breaks would still be re-enabled and local exception handlers would
be uninstalled during the handling of `amb`, even with the use of those unsafe
operations, right? That seems wrong, too, since presumably the client would be
surprised if a break were delivered inside the scope of `(parameterize-break #f
_)`.
I think what it comes down to is I somehow want the ability to “atomically”
insert some new continuation frames around the current prompt without
uninstalling the current break state, exception handlers, continuation marks,
and so on. I want to be able to go from
E_1[(run-amb/first E_2[(amb e_1 e_2)])]
to
E_1[(run-amb/first (or E_2[e_1] E_2[e_2]))]
in a single “step.” I guess I could resort to atomic mode, but that seems like
a very heavy hammer, and I’m not even sure if continuation operations are safe
in atomic mode. On the other hand, I don’t really know what a safe API for what
I’m trying to do would look like.
> I don't know of any published work on this topic (so let me know if you
> find something!). As you probably have seen already, our ICFP'07 paper
> just points out that `dynamic-wind` causes problems, but doesn't try to
> hold `dynamic-wind` itself responsible for those problems.
>
> An opinion and some pointers to newsgroup discussions:
>
> http://okmij.org/ftp/continuations/against-callcc.html#dynamic_wind
>
> It would be interesting to check whether `dynamic-wind` is really
> needed in Racket libraries, at least in its current form. Most uses are
> really a "finally" mechanism that could be tied to explicit escapes
> like exceptions, instead of imposed for all continuation jumps. Maybe
> the uses that don't fit that pattern would be better expressed with
> another mechanism. Maybe the guarantees on `dynamic-wind` just need to
> be weakened and the `/no-wind` variants declared "safe" by defining
> away the unsafety.
Yes, most of the relevant discussions I’ve found have been about Lisp’s
`unwind-protect` and how it relates to Scheme’s `dynamic-wind`. It’s alluded to
in Matthias’s original POPL ’88 paper and mentioned explicitly in the following
LASC paper, but neither address this particular issue. I also found Dorai
Sitaram’s “Unwind-protect in portable Scheme”[1] and the related commentary by
Kent Pitman[2] and Will Clinger[3], but though obviously related, both Sitaram
and Clinger seem to imagine a system where the author of the program defines
all control operations, so there isn’t as much of a problem. I’ve also been
trying to find if any of these issues are discussed in any algebraic effects
literature, but I haven’t found anything there yet, either.
[1]: http://www.ccs.neu.edu/~dorai/uwcallcc/uwcallcc.html
[2]:
http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuations-overview.html
[3]: http://www.ccs.neu.edu/home/will/UWESC/uwesc.sch
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/AE70AFAC-89FA-4260-A8AE-6726A1AFE261%40gmail.com.
