
"Illegal but unchecked" would be fine too, although we do already use the
term "undefined" in the documentation for various primops.
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.
* division-by-zero is undefined (libraries are supposed to check before
invoking the primop)
* The uncheckedIShift family are undefined for arguments outside the
allowed bounds
* unsafeCoerce is undefined when used in certain ways, of course
There are probably more that aren't documented.
Cheers
Siimon
On Tue, 1 Dec 2020 at 18:25, Eric Seidel
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".
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
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
On Tue, Dec 1, 2020, at 12:35, Simon Marlow wrote: 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/lexi-lambda/ghc-proposals/blob/delimited-continuation-pri...
*Summary*
The proposal makes no language changes, it only adds three primops <
https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-pri... .
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-co...
*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-pri...
* 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-7321819...
Thoughts?
On Sat, 12 Sep 2020 at 22:59, Joachim Breitner < mail@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-pri...
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@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee