[racket-dev] Changing call/cc

The issue as I see it is that call/cc can replace all the code above a
prompt with a continuation captured from above a different prompt.
This can break the invariants that TR wants to enforce.

I proposed to Asumu on IRC the follow adjustment which I think gets
all the behavior that is wanted.

call-with-continuation-prompt adds the equivalent of a
dynamic-wind-frame after installing the prompt but before invoking the
thunk. This dynamic wind frame has no-op pre and post thunks. Invoking
a continuation captured by call/cc has the behavior that it has now if
there is shared dynamic-wind-frame between the current continuation
and the one being invoked. If there isn't then the whole continuation
up to the prompt is removed and the abort handler is called with the
appropriate composable continuation, such that if the abort handler is
the default then the behavior is the same as the old call/cc.

This gets us the following behaviors:
Code that uses call/cc but doesn't install any prompts works just as before.
The abort handler is called exactly whenever a continuation
application would replace the current continuation up to the prompt
with one that was captured from a different prompt.

This gets around the counter example that Asumu mentioned earlier,
because when k1 is invoked it put the original prompts dynamic-wind
frame in the continuation, so that when k2 is invoked they share the
same base and the effectful dynamic wind is not executed.



On Wed, Sep 5, 2012 at 4:27 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Tue, 4 Sep 2012 06:51:49 -0600, Matthew Flatt wrote:
>> Yes, that's true. I don't think there will be a difference for typical
>> uses of `call/cc' and typical abort handlers, though. And as I
>> understand it, we're not at this point trying to make `call/cc' work
>> seamlessly, but instead support it reasonably well for backward
>> compatibility.
>
> It turns out that non-default abort handlers are more common than I
> thought: every module-level form is wrapped with a prompt whose handler
> re-aborts to an enclosing prompt. So, relying on default-like behavior
> of a prompt handler doesn't work in that case, and it seems like a
> prominent case.
>
> (The `module' form was misdocumented on this point. I've fixed the
> documentation. Not realted to that change, but related to the rest of
> this thread: I changed the initial prompt for each thread to use the
> default handler, instead of ignore all abort arguments.)
>
> I think it would make sense to add a new argument to
> `call-with-continuation-prompt' that handles continuation applications.
> That addition would allow a use of `call-with-continuation-prompt' to
> enforce invariants on its result --- although it seems awkward to add
> support for a feature that we'd prefer to get rid of.
>
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev