[LaurentRDC]

Towards Haskell in the Cloud introduced the concept of static pointers, but they didn't land until GHC 7.10. Therefore, distributed-process (and the implementation of Towards Haskell in the Cloud) relied on a different mechanism to get things done, RemoteTable.

The upcoming GHC 10 fixes several usability issues and outstanding bugs with static pointers. This is the perfect opportunity to remove the historical wart that is RemoteTable and lean into static pointers fully.

This patch does just that: update distributed-static to redefine Closure and remove Static, for a more streamlined implementation that does not rely on a dynamic pointer table. Everything else follows from this change.

This leads to breaking changes in multiple packages, most importantly distributed-static and distributed-process. I took this opportunity to address the type signature of call (to take a Closure).

[LaurentRDC]

@davidsd I'm happy to produce a patch for hyperion based on this pull request, so that this breaking change incurs minimal cost to you

[davidsd]

@vasdommes and I discussed this today, and we are preparing a patch to hyperion ourselves. I think this is a good direction to go, and it will not be hard to adapt hyperion to it. (We only used RemoteTable in a few places, all of which are removable.)

But I should point out that this patch does remove functionality -- namely the ability to essentially extend the Process environment with arbitrary data that can be retrieved anywhere in the Process monad. I don't think that functionality is replaced in a simple way by the existence of StaticPointer's because you still need to pass the StaticPointer around in order to get access to it.

You could argue that in this case the user should use their own ReaderT on top of Process (which is what we do in hyperion). But maybe others like the old functionality?

[LaurentRDC]

But I should point out that this patch does remove functionality -- namely the ability to essentially extend the Process environment with arbitrary data that can be retrieved anywhere in the Process monad

Hmmm that's true. I didn't think about the RemoteTable this way.

I have publicized this pull request on Discourse; hopefully someone can chime in if they use this functionality, although I would consider it accidental functionality.

[hyperthunk]

I would add that this makes hibernating processes harder, for the reasons @davidsd mentions - albeit we don't really do that in the same way the Erlang vm does.

I started thinking about this in the gen_server package here, and on a branch attempting to support server swaps in the same manner as Erlang processes.

[joelmccracken]

Would it be possible to spin out the remote table functionality into a separate package, and use static pointers as the primary mechanism, or perhaps add some other similar way to extend the process environment?

[LaurentRDC]

Would it be possible to spin out the remote table functionality into a separate package, and use static pointers as the primary mechanism, or perhaps add some other similar way to extend the process environment?

We could. Then we end up in a situation where a CH program could use static pointers, or, optionally, a remote table (or both). That's what we actually have today!

If people want to use RemoteTable, it needs to be wired into distributed-process, at which point then let's not create churn

[joelmccracken]

If people want to use RemoteTable, it needs to be wired into distributed-process, at which point then let's not create churn

TBH/FYI I don't have a preference here; I haven't used RemoteTable. My question was about curiosity really. But I have wondered about extensibility of Process, say by it using and underlying monad transformer instead of concrete Process (); it has been quite a while since I looked at that though.