[racket-dev] Changing call/cc

On 2012-08-30 06:53:58 -0600, Matthew Flatt wrote:
> That variant is called `call/cc-via-composable' in the tests. It's
> meant for use with `call-with-continuation-prompt-for-composable',
> which is why there is an extra `call-with-continuation-prompt'.

I think you may want the extra prompt in there, because a `call/cc`
currently does not drop the prompt when it installs the new
continuation.  On the other hand, after the abort handler is run, the
prompt is discarded.

> Can you say more about the example that would break?

The example that would break uses `call/cc` and delimiters to implement
`amb`. The expressions in the `amb` are tried in succession if one
fails, in which case a `call/cc` is used to restart. When *all*
computations fail, an `abort-current-continuation` is used to return the
final result via an abort handler (not the default one).

The abort handler here isn't prepared to deal with thunks that it would
receive from an emulated `call/cc`. The simplest workaround is to just
add another prompt and use two separate prompt tags. One for the
`call/cc` use and one for the final abort.

> I think this combination of replacing both `call/cc' and `dynamic-wind'
> would be equivalent to a smaller change to the semantics of `call/cc',
> which is that it behaves as it does now if there's a shared
> `dynamic-wind' between the source and target continuations, but it
> behaves like your replacement `call/cc' if there's no intervening
> prompt (which addresses the reasoning problem). Also, implementing the
> change directly in the existing `call/cc' implementation sounds fairly
> easy to me.

Did you mean behaves like the replacement if there *is* an intervening
prompt? Since `call/cc` is not a problem if we have no prompts around.

> I agree that it would be better to avoid `call/cc' in the first place,
> but I think we need a better compatibility story with respect to
> `dynamic-wind' --- at least for Scheme variants, and possibly even for
> Racket.
>
> By making a smaller adjustment to `call/cc', I think we can break fewer
> programs (only those that run afoul of non-default abort handlers)
> while solving the local-reasoning problem.

Ok, I think that's a good direction too.

Thanks,
Asumu