<div dir="ltr"><div>"Illegal but unchecked" would be fine too, although we do already use the term "undefined" in the documentation for various primops.<br></div><div><br></div><div>We've so far taken the approach that undefined behaviour in primops is OK. The idea is that libraries built on top can provide a safe and fully-defined API. e.g.<br></div><div><br></div><div>* division-by-zero is undefined (libraries are supposed to check before invoking the primop)</div><div>* The uncheckedIShift family are undefined for arguments outside the allowed bounds<br></div><div><div>* unsafeCoerce is undefined when used in certain ways, of course<br></div></div><div><br></div><div>There are  probably more that aren't documented.</div><div><br></div><div>Cheers</div><div>Siimon<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 1 Dec 2020 at 18:25, 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">Oh I see. I'm always uncomfortable declaring things "undefined" because of how C/C++ compilers can run wild  with code that invokes UB. So I kinda prefer saying that it's "illegal but unchecked".<br>
<br>
On Tue, Dec 1, 2020, at 12:35, Simon Marlow wrote:<br>
> The issue with unsafePerformIO is really just that the proposal says <br>
> that it's illegal to use the primops with unsafePerformIO. I don't <br>
> think it's possible to make it "illegal" in any meaningful sense, <br>
> probably a better way to say it would be "undefined" or "unsupported" <br>
> or somesuch.<br>
> <br>
> Cheers<br>
> Simon<br>
> <br>
> On Mon, 30 Nov 2020 at 01:53, Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>> wrote:<br>
> > 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>
_______________________________________________<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>