Committee,
We have been asked to review
#313: Delimited continuation primops
Summary
The proposal makes no language changes, it only adds
three primops.
The main motivation is to support building efficient implementations of Algebraic Effect systems, which depend on being able to efficiently capture a continuation. Currently this is done explicitly, which imposes a severe performance penalty.
These primops are the minimal support needed to be able to capture a continuation and apply it at runtime, together with some basic type safety via the PromtTag type to ensure that at least we don't replace a continuation with a computation of a different type. (there are other ways to go wrong with these primops though, they're not a safe interface by themselves: they need to be wrapped in a safe library).
Decision
I'm going to tentatively recommend acceptance.
- This is a sensible choice for the primtives, being the most general of the alternatives, as explained in the proposal.
- Would the new primops impose a significant ongoing maintenance burden? Having looked at the patch, although there are some missing pieces, I don't think the new concepts impose any significant new requirements on other parts of the runtime.
- I suspect there may be some difficulties around unsafePerformIO, so I raised that on the github thread
Thoughts?