External Publication
Visit Post

[RFC] Sibyl: Time Series Analysis in Haskell

Haskell Community [Unofficial] March 19, 2026
Source

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.

I 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:

{-# WARNING in "x-pipe-operator" (|>) "|> is conventionally written & in Haskell, and can be found in Data.Function." #-}
(|>) :: a -> (a -> b) -> b
(|>) = (&)

Discussion in the ATmosphere

Loading comments...