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

[Spiwack, Arnaud]

I like delimited continuations a lot. They are a fantastic tool of
delicious sweetness. So I'm delighted at the idea of delimited
continuations coming to GHC. I may not be very objective here.

I haven't looked at the proposal for a while. But, last I checked, I found
it rather convincing. I have little opinion about the implementation, which
touches parts of GHC of which I know very little. But if Simon and Simon,
you both find the prototype reasonable, I'll be quite happy to accept the
proposal.

On Mon, Nov 23, 2020 at 3:38 PM Simon Marlow <marlowsd at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201125/c707e340/attachment.html>