{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibxpe6c5sqolnmaizay4nvmelexvtceapi3qyy2r4bsr4plaei32m",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mhg33rs4flo2"
  },
  "path": "/t/rfc-sibyl-time-series-analysis-in-haskell/13823#post_8",
  "publishedAt": "2026-03-19T11:55:34.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "The problem I see with `(|>)` that we already have `(<|>)`, the alternative operator, and so it clashes with established practice. It’s also inconsistent with the established visual language for operators in Haskell: given `($) :: (a -> b) -> a -> b`, `(<$>) :: Functor f => (a-> b) -> f a -> f b` is like a “lifted” version of `($)`. So when you learn `(&) :: a -> (a -> b) -> b`, you can then immediately tell what `(<&>)` is going to do: `(<&>) :: Functor f -> f a -> (a -> b) -> f b`. `(|>)` is a road to nowhere in that regard: there is no `(<|>>)`, and if there was, it would be confused for an operator to do with `Alternative`. Training new Haskellers to use non-standard operators like `(|>)` artificially limits their ability to interact with the wider Haskell library space. I don’t endorse that, because the reason I value Haskell is exactly because the language, libraries, and community look for bigger more powerful ideas that can be expressed elegantly.\n\nI would recommend using a `WARNING` pragma to smooth the on-ramp for new users, teach them the common Haskell name for the operator, and provide a way to turn the nag off if the user really doesn’t care:\n\n\n    {-# WARNING in \"x-pipe-operator\" (|>) \"|> is conventionally written & in Haskell, and can be found in Data.Function.\" #-}\n    (|>) :: a -> (a -> b) -> b\n    (|>) = (&)\n",
  "title": "[RFC] Sibyl: Time Series Analysis in Haskell"
}