As a small update on this for anyone following along, I submitted a GHC
proposal about a week ago to add the discussed primops (albeit with some
tweaked names). For those who haven’t seen it already, the pull request is here:
https://github.com/ghc-proposals/ghc-proposals/pull/313
So far,
> On Feb 10, 2020, at 02:18, Simon Marlow wrote:
>
>> On Mon, 10 Feb 2020 at 08:17, Simon Marlow wrote:
>>
>> Let me just say "unsafePerformIO" :) You probably want to at least ensure
>> that things don't crash in that case, even if you can't give a sensible
>> semantics to what actually
On Mon, 10 Feb 2020 at 08:17, Simon Marlow wrote:
> On Mon, 10 Feb 2020 at 08:10, Alexis King wrote:
>
>> On Feb 6, 2020, at 02:28, Simon Marlow wrote:
>>
>> The issue here is that raiseAsync is destructive - it *moves* the stack
>> to the heap, rather than copying it. So if you want to
On Mon, 10 Feb 2020 at 08:10, Alexis King wrote:
> On Feb 6, 2020, at 02:28, Simon Marlow wrote:
>
> The issue here is that raiseAsync is destructive - it *moves* the stack to
> the heap, rather than copying it. So if you want to continue execution
> where you left off, for shift#, you would
> On Feb 6, 2020, at 02:28, Simon Marlow wrote:
>
> The issue here is that raiseAsync is destructive - it *moves* the stack to
> the heap, rather than copying it. So if you want to continue execution where
> you left off, for shift#, you would have to copy it back onto the stack
> again.
On Sun, 2 Feb 2020 at 04:26, Alexis King wrote:
> I took a stab at implementing this today, using the “continuation is a
> stack” implementation strategy I described in my previous email. I
> haven’t tried very hard to break it yet, but this tiny test program
> works:
>
> {-# LANGUAGE
On Sat, 1 Feb 2020 at 00:23, Alexis King wrote:
> > On Jan 30, 2020, at 02:35, Simon Marlow wrote:
>
> > Also you might want to optimise the implementation so that it doesn't
> actually tear down the stack as it copies it into the heap, so that you
> could avoid the need to copy it back from
I took a stab at implementing this today, using the “continuation is a
stack” implementation strategy I described in my previous email. I
haven’t tried very hard to break it yet, but this tiny test program
works:
{-# LANGUAGE BangPatterns, BlockArguments, MagicHash,
> On Jan 30, 2020, at 02:35, Simon Marlow wrote:
>
> My guess is you can almost do what you want with asynchronous exceptions but
> some changes to the RTS would be needed.
>
> There's a bit of code in the IO library that literally looks like this
>
Simon Peyton Jones via ghc-devs writes:
> | Now that is very interesting, and certainly not something I would have
> | expected! Why would asynchronous exceptions need to capture any portion of
> | the stack? Exceptions obviously trigger stack unwinding, so I assumed the
> | “abort to the
My guess is you can almost do what you want with asynchronous exceptions
but some changes to the RTS would be needed.
There's a bit of code in the IO library that literally looks like this (
https://gitlab.haskell.org/ghc/ghc/blob/master/libraries%2Fbase%2FGHC%2FIO%2FHandle%2FInternals.hs#L175
):
> On Jan 29, 2020, at 03:32, Simon Peyton Jones wrote:
>
> Suppose a thread happens to be evaluating a pure thunk for (factorial 200).
> […] This stack-freezing stuff is definitely implemented.
That’s fascinating! I had no idea, but your explanation makes sense (as do the
papers you linked).
s' paper too.
Simon
| -Original Message-
| From: Alexis King
| Sent: 28 January 2020 22:19
| To: Simon Peyton Jones
| Cc: ghc-devs
| Subject: Re: Feasibility of native RTS support for continuations?
|
| > On Jan 28, 2020, at 04:09, Simon Peyton Jones
| wrote:
| &g
> On Jan 28, 2020, at 04:09, Simon Peyton Jones wrote:
>
> I've thought about this quite a bit in the past, but got stalled for lack of
> cycles to think about it more. But there's a paper or two
Many thanks! I’d stumbled upon the 2007 paper, but I hadn’t seen the 2016 one.
In the case of
Alexis
I've thought about this quite a bit in the past, but got stalled for lack of
cycles to think about it more. But there's a paper or two:
https://www.microsoft.com/en-us/research/publication/composable-scheduler-activations-haskell/
On that link you can also see a link to an earlier,
15 matches
Mail list logo
