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

[Eric Seidel]

This is a very well-written and motivated proposal, and I love that it's just three new primops (really two, plus a tag to add some guard rails). I'm not very familiar with the literature on delimited continuations, but I support going with the most general formulation, especially for primops.

I'm not sure we need to be able to detect all uses of the new primops with unsafePerformIO, it's already a deeply unsafe function. Just another thing that advanced users will need to keep in mind.

On Mon, Nov 23, 2020, at 09:37, Simon Marlow wrote:
> 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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>