[ghc-steering-committee] Please review #313: Delimited continuation primops, Shepherd: Simon Marlow

[Simon Marlow]

Committee,

We have been asked to review
#313: Delimited continuation primops
https://github.com/ghc-proposals/ghc-proposals/pull/313
https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md

*Summary*

The proposal makes no language changes, it only adds three primops
<https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#proposed-change-specification>
.

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).

The primops are implemented by copying chunks of stack into the heap. This
is something that GHC's runtime already does a lot of, so it's not a new
concept, although it does require a new closure type and knock-on changes
across several files in the runtime (though it's mainly mechanical).
There's a prototype implementation here:
https://gitlab.haskell.org/lexi.lambda/ghc/-/compare/master...first-class-continuations?view=inline

*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.
   <https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#operational-semantics>
   - 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
   <https://github.com/ghc-proposals/ghc-proposals/pull/313#issuecomment-732181948>

Thoughts?



On Sat, 12 Sep 2020 at 22:59, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Delimited continuation primops
> has been proposed by Alexis King
> https://github.com/ghc-proposals/ghc-proposals/pull/313
>
> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md
>
> I’ll propose Simon Marlow as the shepherd.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> Thanks,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201123/586bb926/attachment.html>