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).

[cgibbard]

Ah, fair enough, but... we also already have (&).

[Bodigrim]

Altogether we have 2 votes in favor, 3 votes against, and chessai is on a temporary leave (#82). Even if he votes in favor, we still fall short of 4 votes required to approve the proposal. Thanks all for the discussion (and foremost to @chshersh), unfortunately, the proposal is declined.

[chshersh]

@Bodigrim Thanks for shepherding the proposal!

No comments on the voting results. But I have comments on this particular note:

In the absence of such a plan I am extremely wary of admitting incremental changes, even if they locally look like improvements. I think base is past the point where incremental improvements can lead to global benefit.

This argument can be applied to reject every single proposal in this repository because all proposals here are exactly incremental changes to base.

The whole point of CLC is to evolve base by performing incremental changes. There's no bigger plan or roadmap to move base to a new better version at the moment and nobody is working on it AFAIK. However, I don't see this argument applied to other proposals, only to mine. Therefore, I feel like my proposal was treated in a special unfair way.

You may still have other arguments against this proposal. I'm just confused that this exact wording was used as it seems highly inconsistent with other voting results and, in fact, with the sole reason for the CLC existence.

---

If something has changed in the CLC process and CLC doesn't vote on incremental changes anymore, this should be clearly reflected in the repository guidelines and not decided in the middle of voting on the proposal.

[tomjaguarpaw]

Hello Dmitrii, I feel rather uncomfortable that two sentences that I have written have been taken out of their context and scrutinised to this degree. The CLC is not a parliament nor a court of common law where every written word must be laboured over to be legally precise and watertight. Perhaps in the future I should just write "-1" without giving any rationale. I am a volunteer and my time and energy are in short supply.

Still, I think I probably should have said "I am extremely wary of admitting incremental additions". I am not wary of incremental corrections, which have formed a significant proportion of CLC votes since I have been a member. (I am wary of incremental removals but for a different reason.) Furthermore, I think it would be very helpful to have a community-wide debate to determine fundamental principles for evolving base. I don't think there is any community-wide understanding, let alone agreement, of those principles.

It is your right to believe that your proposal "was treated in a special unfair way", of course, but I find it very unpleasant to be on the receiving end of such a claim in public, especially when it is unsupported with evidence from the historical voting record.

[hasufell]

Furthermore, I think it would be very helpful to have a community-wide debate to determine fundamental principles for evolving base

We already had. And I made a proposal of such principles, but got no response from CLC: https://github.com/haskell/core-libraries-committee/issues/12#issuecomment-968293690

[Ericson2314]

@chshersh Some of us actually have been trying to think about dramatic improvements to base (splitting base). It is still controversial but the way I think of it is this:

1. Any plan to dramatically overhaul things still needs to work somewhat incrementally for reasons of risk tolerance
2. Changes that have to go in base (e.g. adjusting some type classes in base, or instances involving type classes and types both in base) are fine to do now, because there is no alternative.
3. Stuff like this can happen outside of base, and therefore should be done that way.

(2) is still a large amount of work, (1) is more work still, and is definitely complicated by other proposals taking away attention from "the big issue". (3) is just something I don't think is worth all the time/bikeshedding such things inevitably espouse.

[emilypi]

Therefore, I feel like my proposal was treated in a special unfair way

Regardless of whether or not Tom felt that way (which he clarified was not the case), and supposing he were antagonistic towards your proposal (which he was not), his vote is still balanced by everyone else's vote. The rest of us outlined our thinking and, per the current state of upvotes and general sentiment in the thread, your proposal still wouldn't have been approved. It would not even have been approved if Tom's vote was nullified.

I'm sorry you feel this way, but it's just not confluent with reality.

[Bodigrim]

If something has changed in the CLC process and CLC doesn't vote on incremental changes anymore, this should be clearly reflected in the repository guidelines and not decided in the middle of voting on the proposal.

Just to answer the specific question: nothing has changed, there is no fundamental barrier for CLC to approve an incremental change / addition / removal. However, CLC is a broad church and individual members can exercise different beliefs and principles. E. g., it is completely possible for a CLC member always vote against anything, because they believe that base is perfect already.

[hasufell]

I also feel that it's a bit harsh.

Fairness is mostly a function of responsiveness, following the CLC process, fostering broad discussion. That was clearly done here with excellence.

I interpret Dimitris concerns more as a question about the quality of the decision. The quality is a function of the members and internal policies. If a member always votes nay, that's perfectly valid, but could be considered to compromise the quality of the decisions.

Yet, adding publicly visible policies will likely lead to people misinterpreting them as rules and challenge every decision made.

Because CLC is self governing, the only way for an individual to improve perceived lack of decision quality is to apply for a CLC position (and hence influence internal discussions or policies).