Add the '|>' pipe operator

[chshersh]

Proposal

Add the |> pipe operator to the Data.Function module, similar to the already existing &:

infixl 0 |>
(|>) :: forall r a (b :: TYPE r). a -> (a -> b) -> b
x |> f = f x
{-# INLINE (|>) #-}

⚠️ There's a difference between |> and &: & has fixity infixl 1 while I propose for |> to have fixity infixl 0 (same priority as $). Having the same priority results in a compilation error when using both $ and |> together in a single expression. This is intentional because the flow can be extremely confusing. For example, when writing f $ x |> g (or f $ x & g currently) it's not immediately clear from just looking at the code whether it's g (f x) or f (g x).

ℹ️ I'm proposing to add this operator only to the Data.Function module and not Prelude to avoid massive breaking changes which are not justified at this point.

Motivation

Haskell is one of the oldest Functional Programming languages that are still actively used nowadays. It inspired multiple features in many other programming languages. And I believe it's time for Haskell to take expiration from more modern FP langs.

Specifically, the pipe application operator |> (and sometimes <|) is popular in other FP languages while Haskell remains almost the only language that uses $ and &.

These are quite popular languages that use or want to add <| or |> (the list might not be exhaustive):

• TC39: Pipe operator in JavaScript: |>
• F#: <|and |>
• OCaml: |>
• Elm: <| and |>
• Elixir: |>
• Gleam: |>

In fact, Haskell itself has several libraries that reimplement these operators:

• flow
• op

And some libraries reimplement |> in their internals:

• ghc
• fuzzyset

Here are some people on Twitter who like using the flow library or forward style of application:

• Example 1
• Example 2 and Example 3 (from the same person)
• Example 4
• Example 5

According to the Haskell2010 report, one of the Haskell goals is:

5. It should reduce unnecessary diversity in functional programming languages.

I strongly believe that having $ and & while the rest of the world uses <| and |> is exactly that unnecessary diversity, so adding these two operators to base will help to reduce this while not conflicting with other goals (and, in fact, it might even help! Lots of people find $ and & confusing for various reasons, having <| and |> can improve Haskell teaching and learning experience).

[JakobBruenker]

typo:

already existing & and &

probably should be "$ and &".

[chshersh]

@JakobBruenker Thanks! Fixed 🤗

[tomjaguarpaw]

& is a much more recent addition to base than $. Does anyone know why |> wasn't chosen instead of &? I think that information is important to take into consideration.

[chshersh]

@tomjaguarpaw The (&) operator was added in this commit 8 years ago. There's also a discussion on the issue GHC tracker.

The discussion contains a link to the libraries mailing list archive that discusses adding (&):

• https://mail.haskell.org/pipermail/libraries/2013-October/021423.html

Everyone is welcome to read it. This is a really long thread with lots of bikeshedding 🚲 🖌️

I've read through the thread and below are the points against |> I've found:

• |> conflicts with Data.Sequence in containers
• & is better than |> because you also want a functorial version and <&> looks better than <|>>
• lens already used & for years
• OCaml has |> and someone doesn't want Haskell to be like OCaml

There were arguments for other operators and many people were against adding the reverse application operator in that thread but I'm highlighting only |>-related arguments here.

---

The above thread contains only the opinions of various people. Apparently, the decision was made by vote of the previous CLC boards but it wasn't public.

[tomjaguarpaw]

Fantastic summary, thank you.

[Kleidukos]

Thank you for opening this proposal, @chshersh !

I remember when I switched from Elixir to Haskell, and tried to keep my idiom of using (|>) for data pipelines. I tried to re-use (|>) while writing this comment to remind me of what had failed in terms of ergonomics (I do recall that the order of the arguments declared by HoFs could prove problematic), but actually I can't seem to hit problematic cases.

It would indeed be worth integrating (|>) in base, and maybe (|>>) for the functorial version. :)

[alt-romes]

Funnily enough, I just came across |> in GHC.Data.TrieMap https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Data/TrieMap.hs#L105

(|>) :: a -> (a->b) -> b     -- Reverse application
x |> f = f x

[mixphix]

Regarding the Data.Sequence clash, most of the containers modules are imported with some sort of qualification. To me, it wouldn’t seem out-of-place to qualify its (|>) if the need for the one from this proposal should arise in the same module. And since it’s not an outright replacement for (&), the latter would remain an option.

This helps new-to-Haskell users as well as providing slightly-more-intuitive symbols for these operators than the existing ones. Thanks for the proposal, I’m excited for the MR!

[dsyme]

For those into history giggles, the origins of |> via Tobias Nipkow and Larry Paulson are documented in the paper at https://fsharp.org/history and in the blog post at https://docs.microsoft.com/en-us/archive/blogs/dsyme/archeological-semiotics-the-birth-of-the-pipeline-symbol-1994

[int-index]

As much as I dislike $, it is used so pervasively in Haskell that you’re not going to phase it out. And having both $ and <| (and neither of them deprecated) sounds worse than having just one of those.

[mixphix]

I remember there being some curfuffle around GHC 7 about special compilation rules for ($). Have those become “naturalized” in the compiler?

[JakobBruenker]

I remember there being some curfuffle around GHC 7 about special compilation rules for ($). Have those become “naturalized” in the compiler?

The accepted & implemented Quick Look Impredicativity proposal says

Currently, GHC contains a hard-coded typing rule for ($) which ensures that f $ e works even when ($) would need to be impredicatively instantiated. The million dollar question is: can we drop this special case from the compiler?

Yes, we can. This also means that other combinators such as (&) or (.) no longer are second-class with respect to impredicativity.

However, to maintain backward compatibility, we propose to retain the special behaviour of ($) in one respect: applications of ($) will always be treated as if -XImpredicativeTypes is on. Why? Because if not, many existing program (which rely on the magical treatment of ($), without any extension flags) would suddenly fail to typecheck. For example, this code compiles today without extensions:

> import Control.Monad.ST
> runST $ return 0
0

If it is to continue to typecheck without extensions, we must switch on Quick Look for applications of ($). However, rather than a magical ad-hoc rule, the new treatment of ($) will be fully covered by the Quick Look specification.

I would also note that this special behavior becomes less critical when you consider that -XBlockArguments with do can usually be used instead.

[emilypi]

It's relatively harmless to add these, and I wouldn't block their addition to base.

However, just to set expectations, as much as I can appreciate wanting conformity with other languages for onboarding's sake, the pipe operators are never going to enjoy the same level of adoption as the existing operators. The fact that there exists an old and pervasive hierarchy of useful $ and &-based mnemonics (see: $>, <$, <$>, <$$>, $$, <&>) that the pipe operators have no hope of fitting into due to clashes with Alternative means the buck stops at the relatively inconsequential use case of "apply function to thing". That in and of itself doesn't quite meet my personal Fairbarn threshold.

A library flow implements these operators in Haskell.

You should evangelize flow and have people use that? I see 9 packages that use it in the wild, of which, half are Taylor's. That doesn't strike me as a pervasive need.

[treeowl]

The fact that $ is infixr has always been kind of weird. Adding another right associative application operator ... why?

[KristianBalaj]

I like the idea of giving Haskell this touch.
However, I agree with @int-index

Having both $ and <| (and neither of them deprecated) sounds worse than having just one of those.

I think that this would come with even more diversity in Haskell's code bases. So I would be for deprecating/removing those 2 older alternatives i.e. $, & to NOT give developers the choice of selecting what they like more in these cases.