{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibpkm6lvsmksz4ktzlhglb4zrr2jxd4l7lmuwmahawvh62jj7qrgm",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mnwsqqv6kmh2"
  },
  "path": "/t/haskells-missing-mutable-reference-type/14248?page=2#post_31",
  "publishedAt": "2026-06-10T13:01:48.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "BurningWitness:\n\n> Not exactly, my point is that tacking dynamic allocations onto this feature is at best unnecessary and at worst would pollute the language with a second way to do something it already excels at.\n\nI don’t understand. What is “this feature”? Your “contextual”?\n\nBurningWitness:\n\n> A static reference table is the “missing” thing in the language as I see it.\n\nOK, fine, and if that missing thing is added, I’ll add the API that I want on top. What’s wrong with that?\n\nBurningWitness:\n\n> tomjaguarpaw:\n>\n>> With “references”, the libraries providing `Logger` and `writeUserData` need not know anything about the existence of “references”. Only the caller need use them.\n>\n> I don’t think this has anything to do with whether the references are static or dynamic, you can wrap the library either way.\n\nI agree. But you said “With references _the library_ would declare an implicit configuration” (my emphasis). I’m pointing out it’s not the library that declares the implicit configuration, it’s the caller.",
  "title": "Haskell's missing mutable reference type"
}