<div dir="ltr"><div dir="ltr"><div>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.</div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 30 Nov 2020 at 01:53, Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
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.<br>
<br>
On Mon, Nov 23, 2020, at 09:37, Simon Marlow wrote:<br>
> Committee,<br>
> <br>
> We have been asked to review <br>
> #313: Delimited continuation primops<br>
> <br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/313" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/313</a><br>
> <a href="https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md" rel="noreferrer" target="_blank">https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md</a><br>
> <br>
> *Summary*<br>
> <br>
> The proposal makes no language changes, it only adds three primops <br>
> <<a href="https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#proposed-change-specification" rel="noreferrer" target="_blank">https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#proposed-change-specification</a>>.<br>
> <br>
> The main motivation is to support building efficient implementations of <br>
> Algebraic Effect systems, which depend on being able to efficiently <br>
> capture a continuation. Currently this is done explicitly, which <br>
> imposes a severe performance penalty.<br>
> <br>
> These primops are the minimal support needed to be able to capture a <br>
> continuation and apply it at runtime, together with some basic type <br>
> safety via the PromtTag type to ensure that at least we don't replace a <br>
> continuation with a computation of a different type. (there are other <br>
> ways to go wrong with these primops though, they're not a safe <br>
> interface by themselves: they need to be wrapped in a safe library).<br>
> <br>
> The primops are implemented by copying chunks of stack into the heap. <br>
> This is something that GHC's runtime already does a lot of, so it's not <br>
> a new concept, although it does require a new closure type and knock-on <br>
> changes across several files in the runtime (though it's mainly <br>
> mechanical). There's a prototype implementation here: <br>
> <a href="https://gitlab.haskell.org/lexi.lambda/ghc/-/compare/master...first-class-continuations?view=inline" rel="noreferrer" target="_blank">https://gitlab.haskell.org/lexi.lambda/ghc/-/compare/master...first-class-continuations?view=inline</a><br>
> <br>
> *Decision*<br>
> *<br>
> *<br>
> I'm going to tentatively recommend acceptance. <br>
> * This is a sensible choice for the primtives, being the most general <br>
> of the alternatives, as explained in the proposal. <br>
> <<a href="https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#operational-semantics" rel="noreferrer" target="_blank">https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#operational-semantics</a>><br>
> * Would the new primops impose a significant ongoing maintenance <br>
> burden? Having looked at the patch, although there are some missing <br>
> pieces, I don't think the new concepts impose any significant new <br>
> requirements on other parts of the runtime.<br>
> * I suspect there may be some difficulties around unsafePerformIO, so <br>
> I raised that on the github thread <br>
> <<a href="https://github.com/ghc-proposals/ghc-proposals/pull/313#issuecomment-732181948" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/313#issuecomment-732181948</a>><br>
> Thoughts?<br>
> <br>
> <br>
> <br>
> On Sat, 12 Sep 2020 at 22:59, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br>
> > Dear Committee,<br>
> > <br>
> > this is your secretary speaking:<br>
> > <br>
> > Delimited continuation primops<br>
> > has been proposed by Alexis King<br>
> > <a href="https://github.com/ghc-proposals/ghc-proposals/pull/313" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/313</a><br>
> > <a href="https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md" rel="noreferrer" target="_blank">https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md</a><br>
> > <br>
> > I’ll propose Simon Marlow as the shepherd.<br>
> > <br>
> > Please guide us to a conclusion as outlined in <br>
> > <a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br>
> > <br>
> > Thanks,<br>
> > Joachim<br>
> > -- <br>
> > Joachim Breitner<br>
> > <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
> > <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
> > <br>
> > <br>
> > _______________________________________________<br>
> > ghc-steering-committee mailing list<br>
> > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div></div>