I am being a little speculative...

Culture: I think |> is an important operator in the F# "culture", and perhaps similarly with . for Haskell. F# has a function composition operator << but I think the F# community tends to use points-free style less than the Haskell community.

Language differences: I don't know enough about both languages to compare, but perhaps the rules for generalizing let-bindings are sufficiently different as to affect this. For example, I know in F# sometimes writing

let f = exp

will not compile, and you need explicit eta-conversion:

let f x = (exp) x   // or x |> exp

to make it compile. This also steers people away from points-free/compositional style, and towards the pipelining style. Also, F# type inference sometimes demands pipelining, so that a known type appears on the left (see here).

(Personally, I find points-free style unreadable, but I suppose every new/different thing seems unreadable until you become accustomed to it.)

I think both are potentially viable in either language, and history/culture/accident may define why each community settled at a different "attractor".

More speculation, this time from the predominantly Haskell side...

($) is the flip of (|>), and its use is quite common when you can't write point-free code. So the main reason that (|>) not used in Haskell is that its place is already taken by ($).

Also, speaking from a bit of F# experience, I think (|>) is so popular in F# code because it resembles the Subject.Verb(Object) structure of OO. Since F# is aiming for a smooth functional/OO integration, Subject |> Verb Object is a pretty smooth transition for new functional programmers.

Personally, I like thinking left-to-right too, so I use (|>) in Haskell, but I don't think many other people do.

In F# (|>) is important because of the left-to-right typechecking. For example:

List.map (fun x -> x.Value) xs

generally won't typecheck, because even if the type of xs is known, the type of the argument x to the lambda isn't known at the time the typechecker sees it, so it doesn't know how to resolve x.Value.

In contrast

xs |> List.map (fun x -> x.Value)

will work fine, because the type of xs will lead to the type of x being known.

The left-to-right typechecking is required because of the name resolution involved in constructs like x.Value. Simon Peyton Jones has written a proposal for adding a similar kind of name resolution to Haskell, but he suggests using local constraints to track whether a type supports a particular operation or not, instead. So in the first sample the requirement that x needs a Value property would be carried forward until xs was seen and this requirement could be resolved. This does complicate the type system, though.

I have seen >>> being used for flip (.), and I often use that myself, especially for long chains that are best understood left-to-right.

>>> is actually from Control.Arrow, and works on more than just functions.

Left-to-right composition in Haskell

Some people use left-to-right (message-passing) style in Haskell too. See, for example, mps library on Hackage. An example:

euler_1 = ( [3,6..999] ++ [5,10..999] ).unique.sum

I think this style looks nice in some situations, but it's harder to read (one needs to know the library and all its operators, the redefined (.) is disturbing too).

There are also left-to-right as well as right-to-left composition operators in Control.Category, part of the base package. Compare >>> and <<< respectively:

ghci> :m + Control.Category
ghci> let f = (+2) ; g = (*3) in map ($1) [f >>> g, f <<< g]
[9,5]

There is a good reason to prefer left-to-right composition sometimes: evaluation order follows reading order.

I think we're confusing things. Haskell's (.) is equivalent to F#'s (>>). Not to be confused with F#'s (|>) which is just inverted function application and is like Haskell's ($) - reversed:

let (>>) f g x = g (f x)
let (|>) x f = f x

I believe Haskell programmers do use $ often. Perhaps not as often as F# programmers tend to use |>. On the other hand, some F# guys use >> to a ridiculous degree: http://blogs.msdn.com/b/ashleyf/archive/2011/04/21/programming-is-pointless.aspx

Aside from style and culture, this boils down to optimizing the language design for either pure or impure code.

The |> operator is common in F# largely because it helps to hide two limitations that appear with predominantly-impure code:

• Left-to-right type inference without structural subtypes.
• The value restriction.

Note that the former limitation does not exist in OCaml because subtyping is structural instead of nominal, so the structural type is easily refined via unification as type inference progresses.

Haskell takes a different trade-off, choosing to focus on predominantly-pure code where these limitations can be lifted.

If you want to use F#'s |> in Haskell then in Data.Function is the & operator (since base 4.8.0.0).

This is my first day to try Haskell (after Rust and F#), and I was able to define F#'s |> operator:

(|>) :: a -> (a -> b) -> b
(|>) x f = f x
infixl 0 |>

and it seems to work:

factorial x =
case x of
1 -> 1
_ -> x * factorial (x-1)


main =
5 |> factorial |> print

I bet a Haskell expert can give you an even better solution.

I think F#'s pipe forward operator (|>) should vs (&) in haskell.

// pipe operator example in haskell


factorial :: (Eq a, Num a) =>  a -> a
factorial x =
case x of
1 -> 1
_ -> x * factorial (x-1)

// terminal
ghic >> 5 & factorial & show

If you dont like (&) operator, you can custom it like F# or Elixir :

(|>) :: a -> (a -> b) -> b
(|>) x f = f x
infixl 1 |>

ghci>> 5 |> factorial |> show

Why infixl 1 |>? See the doc in Data-Function (&)

infixl = infix + left associativity

infixr = infix + right associativity

(.)

(.) means function composition. It means (f.g)(x) = f(g(x)) in Math.

foo = negate . (*3)

// ouput -3
ghci>> foo 1
// ouput -15
ghci>> foo 5

it equals

// (1)
foo x = negate (x * 3)

or

// (2)
foo x = negate $ x * 3

($) operator is also defind in Data-Function ($).

(.) is used for create Hight Order Function or closure in js. See example:

// (1) use lamda expression to create a Hight Order Function
ghci> map (\x -> negate (abs x)) [5,-3,-6,7,-3,2,-19,24]
[-5,-3,-6,-7,-3,-2,-19,-24]




// (2) use . operator to create a Hight Order Function
ghci> map (negate . abs) [5,-3,-6,7,-3,2,-19,24]
[-5,-3,-6,-7,-3,-2,-19,-24]

Wow, Less (code) is better.

Compare |> and .

ghci> 5 |> factorial |> show


// equals


ghci> (show . factorial) 5


// equals


ghci> show . factorial $ 5

It is the different between left —> right and right —> left. ⊙﹏⊙|||

Humanization

|> and & is better than .

because

ghci> sum (replicate 5 (max 6.7 8.9))


// equals


ghci> 8.9 & max 6.7 & replicate 5 & sum


// equals


ghci> 8.9 |> max 6.7 |> replicate 5 |> sum


// equals


ghci> (sum . replicate 5 . max 6.7) 8.9


// equals


ghci> sum . replicate 5 . max 6.7 $ 8.9

How to functional programming in object-oriented language?

please visit http://reactivex.io/

It support :

• Java: RxJava
• JavaScript: RxJS
• C#: Rx.NET
• C#(Unity): UniRx
• Scala: RxScala
• Clojure: RxClojure
• C++: RxCpp
• Lua: RxLua
• Ruby: Rx.rb
• Python: RxPY
• Go: RxGo
• Groovy: RxGroovy
• JRuby: RxJRuby
• Kotlin: RxKotlin
• Swift: RxSwift
• PHP: RxPHP
• Elixir: reaxive
• Dart: RxDart