{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiex4i7b7iq6rvkd7223gneehacrbogabuvgbhvnpkkgrv7kfxj3gq",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3moalcwnqz2c2"
  },
  "path": "/t/fork-fragile-reader-like-operations-in-haskell/14258#post_8",
  "publishedAt": "2026-06-14T10:15:17.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "quite the array of options"
  ],
  "textContent": "The `hs-opentelemetry` example is good. The current behaviour is, IMO, utterly unusable for any application that uses concurrency to a significant degree.\n\nThe way we’ve solved this at CircuitHub is that we use `Effectful`, which already implements the correct thread-scoped state behaviour for its own state, provided you use its concurrency wrappers (which we do). So we wrote an effect that tracks the `hs-opentelemetry` `Context` inside the effect data, instead of in thread-local storage. That works pretty much perfectly.\n\nWhich suggests to me that `effectful` itself would likely benefit from a thread-and-children-scoped-ioref primitive. However - if you dig into `effectful` you will find that it actually offers quite the array of options for how its environment should be cloned in various different situations. Perhaps `effectful` needs this because it’s trying to be quite a general framework, but it’s interesting to think about.",
  "title": "Fork-fragile reader-like operations in Haskell"
}