{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig3gbgajyx65veguuhgw2espsafwrgkuljihp7hv7fym5spunj2ea",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3moarze3zsu52"
  },
  "path": "/t/haskells-missing-mutable-reference-type/14248?page=3#post_55",
  "publishedAt": "2026-06-14T11:16:58.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "loggerExampleConcurrently",
    "Concurrency"
  ],
  "textContent": "michaelpj:\n\n> Sounds great. Not very clear from the article that that’s the intended semantics though!\n\nOK, this is supposed to be clear from loggerExampleConcurrently. I’ll see if I can clarify that.\n\nmichaelpj:\n\n> So 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\nHow would the behaviour differ? Do you mean that `InheritedThreadLocalIORef` could be modified within a thread like an `IORef`? If so then it would need a function of type\n\n\n    InheritedThreadLocalIORef a -> a -> IO ()\n\n\nwhich isn’t in the `IOScopedRef` API. But `IOScopedRef` could be implemented in terms of `InheritedThreadLocalIORef`. I just don’t like the semantics of the latter. It would allow you to observe whether you’re running in a forked thread. See “the interaction between the semantics of thread creation and of `IOScopedRef` are good” in the Concurrency section.\n\nWhat’s the use of having thread local state that allows non-scoped modifications?",
  "title": "Haskell's missing mutable reference type"
}