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
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/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
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