⟨/⟩ AT Protocol Record Source
at://did:plc:pi6woz4d47bkuws673w2il2r/site.standard.document/3mnubtcytnja2
← Back to post
{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicyeyvfeabaeqg6e77ocsbwlhd7wynjdvzepyexy2dvzzgrmsuube",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mnubtcytm7a2"
  },
  "path": "/t/haskells-missing-mutable-reference-type/14248#post_5",
  "publishedAt": "2026-06-09T12:27:07.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "prophet:\n\n> the logging example _doesn’t_ capture the logger\n\nWell, the definition of `Logger` does not use `IOScopedRef` directly. `Logger` could be defined in a module that doesn’t even know `IOScopedRef` exists. The `IOScopedRef` _is_ captured in the closures that are stored in the `Logger` value, isn’t it? If not, what do you mean by “capture”?\n\nprophet:\n\n> So it’s really equivalent to\n\nSure, if you inline and use shadowing you can obtain similar behaviour. But what about when you can’t inline everything, because you’re trying to combine code from two independent libraries?\n\n> I don’t see the advantage of passing this additional reference around if all you’re doing with it is modifying it in a lexically scoped way like you already can with regular variables\n\nOK, then tell me how I could obtain the same behaviour using a lexically-scoped variable but without `IOScopedRef`.",
  "title": "Haskell's missing mutable reference type"
}