{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicosl5szmki7uqsglarpfwcwfdephsms2fj3ikwx54cvhr5v4dd4q",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mhi6b6wevus2"
  },
  "path": "/t/rfc-sibyl-time-series-analysis-in-haskell/13823#post_17",
  "publishedAt": "2026-03-20T03:14:10.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "sibyl/planning/design_draft.md at main · jackiedorland/sibyl · GitHub",
    "grenade"
  ],
  "textContent": "mchav:\n\n> in the name of putting down one less hurdle I made the synonym.\n\nYes, its a tough spot to be in, because the pitch for Haskell itself is that you have to learn new ways and unlearn some old ones, but we promise that the payoff will be worth it. This is why I suggested preserving the on-ramp with a custom warning group. Thanks for considering it.\n\njackiedorland:\n\n> Additionally, I’ve just begun drafting Sibyl’s model API, which is uploaded as a doc in the latest commit sibyl/planning/design_draft.md at main · jackiedorland/sibyl · GitHub after some revision & discussion with other folks at dataHaskell. I’d appreciate comments on this as well!\n\nI’ve tried to read this but I don’t have enough domain knowledge to offer strong opinions. It does sound like there’s not a lot of data you’d want to keep at the type level, and if some of your models don’t have statically-knowable features then it does seem like it’d be best to avoid the type-level features. You might find that the grenade library provides some idioms you could use, if you do take the typelevel route.\n\nIf you don’t have laws to describe the typeclass, or if there aren’t very many generic functions you can write over the instances, you might also get value from looking at specifying the models themselves as values instead of typelevel tags. Not entirely in the record-of-functions “capability” sense but as some inert data that could be read by model-agnostic functions.",
  "title": "[RFC] Sibyl: Time Series Analysis in Haskell"
}