{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifzcwvf4ogyd52gwxlylapyfdzih4a24l3xx2fildwa55pde4x4t4",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mewhnh3ulbh2"
  },
  "path": "/t/minimal-processing-of-continued-fractions/13689#post_6",
  "publishedAt": "2026-02-15T13:24:42.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "This formulation also made me wonder whether there’s an opportunity to encode productivity at the type/structure level rather than relying on the y0 == y1 check alone.\n\nFor example, you could imagine splitting the state machine into two explicit phases:\n\n  * Accumulate: consume CF terms until the matrix is “stable enough.”\n  * Emit: guaranteed to produce at least one digit before needing more input\n\n\n\nIn other words, make it emit totally once entered, so the only partiality lives in the transition between phases. That might let you model the whole thing as something like a Mealy machine or even a Stream transformer, where non-productivity becomes structurally impossible rather than a runtime condition.\n\nIt feels like continued fractions are crying out for that kind of “digit-safe” invariant, similar to how digit-by-digit algorithms for √2 or π enforce progress by construction. I don’t know if it simplifies the code, but it might make the reasoning story even cleaner.\n\nEither way, this fold-inside-unfold pattern is a great lens - it’s much clearer than the recursive versions I was circling around before.",
  "title": "Minimal processing of continued fractions"
}