Will be streamed live today, 2026-01-21, at 1930 UTC.
Abstract:
“Static pointers” are references to statically known values, and can serialized independent of the type of the value (even if that value is a function), so that you can store them in files, send them across the network, etc. In this episode we discuss how static pointers work, and we show how we can use the primitive building blocks provided by ghc to implement a more compositional interface. We also briefly discuss how the rules for static pointers will change in ghc 9.14.2 and later.
If I’m not mistaken, polymorphic recursion is another reason why contexts can’t be static in general, right? For a function like:
polyRecurse :: Semigroup a => Int -> a -> a
polyRecurse 0 a = a
polyRecurse n a = sconcat $ polyRecurse (n-1) (NonEmpty.singleton a)
If we asked GHC to conjure up a static Dict (Semigroup a), it simply couldn’t because the a changes based on the recursion depth and so it keeps building a Semigroup dictionary dynamically for each depth.
Yes, true. This would be the case even for simpler examples:
foo :: Eq a => ..
bar :: Ord a => ..
bar = .. foo ..
We’d need to project out the Eq dictionary from Ord.
Either way, you’d need some kind of compositionality, something along the lines of what I sketched in the episode, although other variants are possible too of course. Non-composable StaticPtr is quite limited in its applicability.
I’m honestly not entirely sure, but I think probably yes. Something more powerful akin to Erlang’s system where you can ship “any” code would be nicer, but having static pointers I think is still better than not having it. Manual defunctionalization is less convenient. Whether it’s worth the cost of the language extension (the cost of adding complexity to the language) I’m not sure, but especially with the new rules for StaticPtr in 9.14.2 I think that cost isn’t actually all that high, it’s reasonably self-contained.
The upgrade problem seems like quite a serious drawback though?
(Regarding shipping any code, I’ve been toying with the idea of expressing actors as arrows (or better CCCs). It’s too bad that arrow notation inserts unnecessary arrs breaking the possibility of doing serialisation.)
