`StaticPtr` support

[dmjio]

Hi Lennart,

I was wondering if it wouldn't be too much trouble to support StaticPtr. Specifically the static keyword, along with deRefStaticPtr / unsafeLookupStaticPtr / StaticKey, etc. Seen here.

The environment I'm targeting (the LynxJS runtime environment) has two JavaScript interpreters (similar to react-native reanimated), where the same JS payload executes at once in each environment. It seems to be an ideal use case for StaticPtr. One interpreter has access to Swift / ObjC / Java / Kotlin code, the other to the drawing context. I've had success in serializing Haskell ADTs for transfer between processes, passing along the StaticKey, and reifying the necessary functions for evaluation in each environment (all statically known and available in the static pointer table), to perform effects. This has come at the cost of some additional monomorphization / boilerplate, but it seems to be working.

I think with MicroHs we could do better and transfer any arbitrary function (compiled dynamically to combinators, and serialized) to a different interpreter. I believe both react-native and LynxJS do something very similar (it's called "worklets") where a JS function is serialized (.toString()) and its closure is also serialized and passed along to the other interpreter (via WebWorker). eval is then invoked on it in the new environment. But for compatibility with GHC, and to not rely on Data.Dynamic constraint, the StaticPtr seems "good enough".

Tangentially, regarding JSVal, I have a local branch, it follows the primop implementation instructions as you've defined on the README.md. It does not yet support sync / async callbacks which are important for web component mounting (to ensure correct ordering on the DOM). I might make a PR shortly after the Lynx integration to continue on in that effort with whatever I have at the moment. I do still think the compilation performance and portability will be very good.

The work I'm doing w/ StaticPtr is here.

[augustss]

Just to make sure I understand. You are asking for the static keyword and StaticPtr type for GHC compatibility, but you don't necessarily need the same semantics where each static value is serialized as a key.
So a possible implementation might be something like

newtype StaticPtr a = StaticPtr a
static :: a -> StaticPtr
static a = StaticPtr a
derefStaticPtr :: StaticPtr a -> a
derefStaticPtr (StaticPtr a) = a

Could this even be enough? The syntax would be a little different since static is a regular function here, but some parens should solve that.

[augustss]

Looking at this, it looks like you actually want the key.
That's a lot more complex.