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

[Simon Marlow]

The issue with unsafePerformIO is really just that the proposal says that
it's illegal to use the primops with unsafePerformIO. I don't think it's
possible to make it "illegal" in any meaningful sense, probably a better
way to say it would be "undefined" or "unsupported" or somesuch.

Cheers
Simon

On Mon, 30 Nov 2020 at 01:53, Eric Seidel <eric at seidel.io> wrote:

> 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
> >
> _______________________________________________
> 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/20201201/c70653a2/attachment-0001.html>