{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiaeblvixt52xlcfezx7pyzo7oijoihxbuybwiymjntbjznqjiehdq",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mhezjtyc7ba2"
  },
  "path": "/t/rfc-sibyl-time-series-analysis-in-haskell/13823#post_3",
  "publishedAt": "2026-03-19T02:22:41.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "github.com/jackiedorland/sibyl",
    "src/Sibyl.hs",
    "f545ed364"
  ],
  "textContent": "It’s very exciting to see DataHaskell stuff moving again. Scattershot feedback, in no particular order, though I hope it’s useful:\n\ngithub.com/jackiedorland/sibyl\n\n#### src/Sibyl.hs\n\nf545ed364\n\n\n\n\n\n\n        19. type TS t y = TimeSeries t y\n\n\n        20. type FC t = Forecast t\n\n\n\n\n\nI recommend dropping the parameters, as GHC can only expand a type alias when all parameters are provided:\n\n\n    type TS = TimeSeries\n    type FC = Forecast\n\n\nI can’t find where you define `(|>)`, but I’d recommend using `(&)` from `Data.Function`:\n\n  * It’s in package `base`, so you don’t pull in another dependency\n  * It’s the standard Haskell operator for this concept\n  * It reads well (verbally): \"fromDataFrame … _and_ fit … _and_ forecast … _and_ toDataFrame`\n  * The `<` and `>` on operators have an established meaning in Haskell, they usually imply something is “lifted”: `(<$>)`, `(<$)`, `($>)`, `(<*>)`, `(<*)`, `(*>)`, `(<&>)`, `(<$?>)`, `(<&?>)` etc.\n\n\n\nYou may want to think about documenting your type parameters, because `m` in a constraint often means “some monad” and `t` often means “some traversable”. Choosing short abbreviations and using them consistently (e.g. `mdl` or `model` for “model”?) might help here.\n\nI personally don’t think `-XDataKinds` is that scary, particularly if you can put in the work to do helpful custom type errors, and `-XRequiredTypeArguments` means you can ask for type variables that you need, and don’t have to rely on users’ intuition that an inference failure requires an application. But I’m not on the data wrangler and might not be your target audience. I do note that if your type checking is fast enough, changing something and getting a type error is a better experience than changing something, trying to run your code, and having it fall over with a runtime type error. Whether you can get Python- or R-using data people across the initial hump of “the types are there to help you” is a question best answered by testing on real users.",
  "title": "[RFC] Sibyl: Time Series Analysis in Haskell"
}