{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifxg6vfbduorpajfibqfc7v7vmujmjkhvuqrwgzkkvq5upmf4y7v4",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mgksg5cvxkg2"
  },
  "path": "/t/changing-the-binary-instance-for-double-and-float/13758?page=2#post_26",
  "publishedAt": "2026-03-07T20:35:14.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "I use `cereal` for saving and restoring state. I switched from binary many years ago due to something I forget, I vaguely recall it was more strict in some important way. Actually it turns out at some point I also stopped using its Serialize class and wrote my own, which I think was due to Float serialization messing up -0, so it’s actually somewhat related to the topic. But also it’s necessary to retain control over backward compatibility, since as is being discussed, the libraries are free to change the format if they’re not implementing a standard.\n\nSo in my case, I think it’s fine to fix Binary Float, it would have saved me from a surprise, though I would also document that if you need a stable format, don’t use the library’s typeclass but write your own. Also, it’s fast enough for me, I don’t really have a need for high performance. I’m just curious about what is efficient and what is not. Also I recall a rationale behind wanting better performance for `binary` was that ghc used it, and of course anything that can speed up compiles is welcome.\n\nIs there a relevant distinction between deserialization and parsing? I think of what I’m doing as the former, there aren’t any branches except some version checks, whereas what I think of a parser has a lot of “or” operations and hence might have things like backtracking. Maybe the distinction is too fuzzy to be useful though.",
  "title": "Changing the `Binary` instance for `Double` and `Float`"
}