{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihaw6tfkdi6fnijsweynyaji4sgldrcifrhyeoaqp2kvgcvim55oi",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3moarz23jaek2"
  },
  "path": "/t/haskells-missing-mutable-reference-type/14248?page=3#post_57",
  "publishedAt": "2026-06-14T12:30:41.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "loggerExampleConcurrently",
    "Concurrency",
    "fork-fragile-reader-like-operations"
  ],
  "textContent": "michaelpj:\n\n> > OK, this is supposed to be clear from loggerExampleConcurrently. I’ll see if I can clarify that.\n>\n> In that example you do the modification _inside_ the fork, so it wasn’t obvious to me whether the modification would be visible if you did it the other way around.\n\nAh yes, this example needs improving, thanks!\n\nmichaelpj:\n\n> > What’s the use of having thread local state that allows non-scoped modifications?\n>\n> What’s a “non-scoped modification”? Do you mean `writeIORef` versus `withModifiedIORef :: IORef a -> (a -> a) -> IO a -> IO a`?\n\nYes\n\nmichaelpj:\n\n> > 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>\n> I don’t understand how it would do that, can you give an example?\n\nSure, suppose we have an inherited, thread-local `IORef`-like type, `ITLIORef`, and someone gives me a function\n\n\n    foo :: IO a -> IO a\n\n\nThen I can call it like\n\n\n    ref <- newITLIORef False\n    foo $\n      writeITLIORef ref True\n    readITLIORef ref\n\n\nand the result depends on whether `foo` ran its body in a new thread or not. Now that’s not _terrible_. There are all sorts of ways we could get similar behaviour, such as `myThreadId`, but it does suggest to me it’s not a particularly principled primitive, whereas it seems to me that `IOScopedRef` _is_ principled (although I don’t know in what terms to formulate that claim).\n\nmichaelpj:\n\n> The problems you observe in fork-fragile-reader-like-operations seem to me to be related to these two things. I’m arguing that the “scoped” part of it is perhaps not the crux!\n\nRight, whereas I think the “scoped” part probably _is_ the crux. That’s the part where I see an opportunity for a new primitive with principled behaviour. I understand the general form of your argument that the “scoped” part isn’t the crux: in principle there’s a use for a souped-up version of the thing I propose, which allows for more behaviours. But In _practice_ is there a use for it? Where are people using that?",
  "title": "Haskell's missing mutable reference type"
}