W języku F # użycie operatora potoku do przodu |>jest dość powszechne. Jednak w Haskell widziałem tylko kompozycję funkcji (.), która jest używana. Rozumiem, że są one powiązane , ale czy jest jakiś powód językowy, dla którego funkcja potoku do przodu nie jest używana w Haskell, czy jest to coś innego?

Jestem trochę spekulatywny ...

Kultura : Myślę, że |>jest ważnym operatorem w „kulturze” języka F # i być może podobnie w .przypadku Haskella. F # ma operator kompozycji funkcji, <<ale myślę, że społeczność F # ma tendencję do mniejszego używania stylu bez punktów niż społeczność Haskell.

Różnice językowe : nie wiem wystarczająco dużo na temat obu języków, aby je porównać, ale być może reguły uogólniających powiązań let są na tyle różne, że mają na to wpływ. Na przykład wiem, że w F # czasami piszę

let f = exp

nie skompiluje się i potrzebujesz jawnej konwersji eta:

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

aby to skompilować. To także odwraca ludzi od stylu bez punktów / kompozycji i kieruje się w stronę stylu pipelining. Ponadto wnioskowanie o typie F # czasami wymaga potokowania, tak że znany typ pojawia się po lewej stronie (patrz tutaj ).

(Osobiście uważam, że styl bez punktów jest nieczytelny, ale przypuszczam, że każda nowa / inna rzecz wydaje się nieczytelna, dopóki się do tego nie przyzwyczaisz.)

Myślę, że oba są potencjalnie możliwe w każdym języku, a historia / kultura / przypadek mogą definiować, dlaczego każda społeczność osiedliła się w innym „atraktorze”.

W języku F # (|>)jest ważne ze względu na sprawdzanie pisma od lewej do prawej. Na przykład:

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

generalnie nie sprawdza typu, ponieważ nawet jeśli typ xsjest znany, typ argumentu xdo lambda nie jest znany w momencie, gdy sprawdzacz typu go widzi, więc nie wie, jak rozwiązać x.Value.

W przeciwieństwie

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

będzie działać dobrze, ponieważ rodzaj xsbędzie prowadził do typu xbycia znanym.

Sprawdzanie typu od lewej do prawej jest wymagane z powodu rozpoznawania nazw zaangażowanych w konstrukcje, takie jak x.Value. Simon Peyton Jones napisał propozycję dodania podobnego rodzaju rozpoznawania nazw do Haskella, ale sugeruje użycie lokalnych ograniczeń do śledzenia, czy typ obsługuje określoną operację, czy nie. Tak więc w pierwszej próbce wymaganie xwymagające Valuewłaściwości zostanie przeniesione do momentu, gdy xszostanie zauważone i można go rozwiązać. To jednak komplikuje system czcionek.

Więcej spekulacji, tym razem ze strony z przewagą Haskella ...

($)jest odwrotnością (|>), a jej użycie jest dość powszechne, gdy nie można pisać kodu bez punktów. Więc głównym powodem, który (|>)nie jest używany w Haskell, jest to, że jego miejsce jest już zajęte ($).

Ponadto, mówiąc z doświadczenia F #, myślę, że (|>)jest tak popularny w kodzie F #, ponieważ przypomina Subject.Verb(Object)strukturę OO. Ponieważ F # ma na celu płynną integrację funkcjonalną / OO, Subject |> Verb Objectjest to całkiem płynne przejście dla nowych programistów funkcjonalnych.

Osobiście lubię też myśleć od lewej do prawej, więc używam (|>)w Haskell, ale nie sądzę, żeby wielu innych ludzi to robiło.

Myślę, że mylimy rzeczy. Haskell ( .) jest odpowiednikiem F # ( >>). Nie mylić z F # ( |>), która jest po prostu odwróconą aplikacją funkcji i jest jak Haskell ( $) - odwrócona:

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

Uważam, że programiści Haskell $często używają . Być może nie tak często, jak zwykle używają programiści F # |>. Z drugiej strony, niektórzy faceci z F # używają >>w śmiesznym stopniu: http://blogs.msdn.com/b/ashleyf/archive/2011/04/21/programming-is-pointless.aspx

Jeśli chcesz używać F # |>w Haskell, to w Data.Function jest &operator (od base 4.8.0.0).

Kompozycja od lewej do prawej w Haskell

Niektórzy ludzie używają w Haskellu stylu od lewej do prawej (przekazywanie wiadomości). Zobacz na przykład bibliotekę mps w witrynie Hackage. Przykład:

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

Myślę, że ten styl wygląda ładnie w niektórych sytuacjach, ale jest trudniejszy do odczytania (trzeba znać bibliotekę i wszystkie jej operatory, redefinicja (.)też przeszkadza).

Istnieją również operatory kompozycji od lewej do prawej oraz od prawej do lewej w Control.Category , części pakietu podstawowego. Porównaj >>>i <<<odpowiednio:

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

Jest dobry powód, aby czasami preferować kompozycję od lewej do prawej: kolejność oceny jest zgodna z porządkiem czytania.

Widziałem, jak >>>byłem używany flip (.)i często tego używam, szczególnie w przypadku długich łańcuchów, które najlepiej rozumieć od lewej do prawej.

>>> pochodzi z Control.Arrow i działa nie tylko na funkcjach.

Oprócz stylu i kultury sprowadza się to do optymalizacji projektu języka pod kątem czystego lub nieczystego kodu.

|>Operator jest powszechne w F # w dużej mierze dlatego, że pomaga ukryć dwa ograniczenia, które pojawiają się głównie z kodem-zanieczyszczonego:

• Wnioskowanie o typie od lewej do prawej bez podtypów strukturalnych.
• Ograniczenie wartości.

Należy zauważyć, że poprzednie ograniczenie nie istnieje w OCaml, ponieważ podtypy są strukturalne, a nie nominalne, więc typ strukturalny można łatwo doprecyzować poprzez ujednolicenie w miarę postępu wnioskowania o typie.

Haskell wybiera inny kompromis, wybierając skupienie się na czystym kodzie, w którym te ograniczenia można znieść.

Myślę, że operator potoku F # do przodu ( |>) powinien vs ( & ) w 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

Jeśli nie lubisz &operatora ( ), możesz go dostosować, na przykład F # lub Elixir:

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

ghci>> 5 |> factorial |> show

Dlaczego infixl 1 |>? Zobacz dokument w Data-Function (&)

infixl = wrostek + lewe skojarzenie

infixr = wrostek + prawe skojarzenie

(.)

( .) oznacza kompozycję funkcji. Oznacza to (fg) (x) = f (g (x)) w Math.

foo = negate . (*3)

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

to jest równe

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

lub

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

( $) operator jest również zdefiniowany w Data-Function ($) .

( .) służy do tworzenia Hight Order Functionlub closure in js. Zobacz przykład:

// (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, mniej (kod) jest lepsze.

Porównaj |>i.

ghci> 5 |> factorial |> show

// equals

ghci> (show . factorial) 5 

// equals

ghci> show . factorial $ 5 

To jest różnica między left —> righti right —> left. ⊙﹏⊙ |||

Uczłowieczenie

|>i &jest lepszy niż.

ponieważ

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

Jak programować funkcjonalnie w języku obiektowym?

odwiedź http://reactivex.io/

Obsługuje:

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

To mój pierwszy dzień, aby wypróbować Haskell (po Rust i F #) i udało mi się zdefiniować operator F # |>:

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

i wydaje się, że działa:

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

main =     
    5 |> factorial |> print

Założę się, że ekspert Haskell może dać ci jeszcze lepsze rozwiązanie.