{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifwgsb2qza2gxhsc7za6qgvgn7jpuh3nsct6ftxan7wrqfwozfdye",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3moarzhag7lv2"
  },
  "path": "/t/haskells-missing-mutable-reference-type/14248?page=3#post_54",
  "publishedAt": "2026-06-14T11:04:36.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "tomjaguarpaw:\n\n> That is, child threads inherit the value from the parent _at the time of forking_. Modifications in the parent after fork are not observed.\n\nSounds great. Not very clear from the article that that’s the intended semantics though!\n\nSo I guess my API question is whether this is best thought of as a new kind of thread-local variable. Is there anything that you can do with your `IOScopedRef` API that you couldn’t do with a `InheritedThreadLocalIORef`? (I imagine the API would be pretty much identical to that for `IORef` - just the behaviour would be different)\n\nThus far, we haven’t had any support for thread-local variables in GHC, as people have managed workarounds with `Map ThreadId IORef` or whatever. But I don’t think we have the tools to do that for a version where the value is inherited by child threads - we’d need a hook to run on thread creation or something. So it does seem like something that might need support in GHC.",
  "title": "Haskell's missing mutable reference type"
}