Em F #, o uso do operador pipe-forward,, |>é bastante comum. No entanto, em Haskell, eu só vi composição de funções,, (.)sendo usada. Eu entendo que eles estão relacionados , mas há um motivo de linguagem para que o pipe-forward não seja usado em Haskell ou é outra coisa?

Estou sendo um pouco especulativo ...

Cultura : Eu acho que |>é um operador importante na "cultura" F #, e talvez da mesma forma .para Haskell. F # tem um operador de composição de função, <<mas acho que a comunidade F # tende a usar menos o estilo sem pontos do que a comunidade Haskell.

Diferenças de idioma : Não sei o suficiente sobre os dois idiomas para comparar, mas talvez as regras para generalizar as ligações let sejam suficientemente diferentes para afetar isso. Por exemplo, eu sei em F # às vezes escrevendo

let f = exp

não irá compilar e você precisa de conversão eta explícita:

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

para fazê-lo compilar. Isso também afasta as pessoas do estilo de composição / sem pontos e em direção ao estilo de tubulação. Além disso, a inferência de tipo F # às vezes exige pipelining, para que um tipo conhecido apareça à esquerda (veja aqui ).

(Pessoalmente, acho o estilo sem pontos ilegível, mas suponho que cada coisa nova / diferente parece ilegível até que você se acostume a ela.)

Eu acho que ambos são potencialmente viáveis ​​em qualquer idioma, e história / cultura / acidente podem definir porque cada comunidade se estabeleceu em um "atrator" diferente.

Em F # (|>)é importante por causa da verificação de tipo da esquerda para a direita. Por exemplo:

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

geralmente não verifica o tipo, porque mesmo se o tipo de xsfor conhecido, o tipo do argumento xpara o lambda não é conhecido no momento em que o verificador de tipo o vê, então ele não sabe como resolver x.Value.

Em contraste

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

vai funcionar bem, porque o tipo de xsvai levar ao tipo de xser conhecido.

A verificação de tipo da esquerda para a direita é necessária devido à resolução de nomes envolvida em construções como x.Value. Simon Peyton Jones escreveu uma proposta para adicionar um tipo semelhante de resolução de nome a Haskell, mas ele sugere o uso de restrições locais para rastrear se um tipo suporta uma operação específica ou não. Portanto, na primeira amostra, o requisito que xprecisa de uma Valuepropriedade seria transportado até xsser visto e esse requisito pudesse ser resolvido. Porém, isso complica o sistema de tipos.

Mais especulação, desta vez do lado predominantemente de Haskell ...

($)é a inversão de (|>), e seu uso é bastante comum quando você não pode escrever código sem pontos. Portanto, o principal motivo que (|>)não é usado em Haskell é que seu lugar já está ocupado ($).

Além disso, falando com um pouco de experiência em F #, acho que (|>)é tão popular no código F # porque se assemelha à Subject.Verb(Object)estrutura do OO. Uma vez que o F # visa uma integração funcional / OO suave, Subject |> Verb Objecté uma transição bastante suave para novos programadores funcionais.

Pessoalmente, também gosto de pensar da esquerda para a direita, então uso (|>)em Haskell, mas não acho que muitas outras pessoas o façam.

Acho que estamos confundindo as coisas. Haskell's ( .) é equivalente a F #'s ( >>). Não deve ser confundido com F #'s ( |>), que é apenas uma aplicação de função invertida e é como Haskell ( $) - invertido:

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

Eu acredito que os programadores de Haskell usam $frequentemente. Talvez não com a frequência que os programadores de F # costumam usar |>. Por outro lado, alguns caras do F # usam >>até um grau ridículo: http://blogs.msdn.com/b/ashleyf/archive/2011/04/21/programming-is-pointless.aspx

Se você quiser usar o F # |>em Haskell, em Data.Function é o &operador (desde base 4.8.0.0).

Composição da esquerda para a direita em Haskell

Algumas pessoas também usam o estilo da esquerda para a direita (passagem de mensagens) em Haskell. Veja, por exemplo, biblioteca mps no Hackage. Um exemplo:

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

Acho que este estilo fica bem em algumas situações, mas é mais difícil de ler (é preciso conhecer a biblioteca e todos os seus operadores, a redefinição (.)também atrapalha).

Existem também operadores de composição da esquerda para a direita e da direita para a esquerda em Control.Category , parte do pacote básico. Compare >>>e <<<respectivamente:

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

Há uma boa razão para preferir a composição da esquerda para a direita às vezes: a ordem de avaliação segue a ordem de leitura.

Já vi >>>ser usado para isso flip (.), e frequentemente uso isso, especialmente para cadeias longas que são mais bem compreendidas da esquerda para a direita.

>>> é, na verdade, de Control.Arrow e funciona em mais do que apenas funções.

Além do estilo e da cultura, isso se resume a otimizar o design da linguagem para código puro ou impuro.

O |>operador é comum em F # principalmente porque ajuda a ocultar duas limitações que aparecem com o código predominantemente impuro:

• Inferência de tipo da esquerda para a direita sem subtipos estruturais.
• A restrição de valor.

Observe que a primeira limitação não existe em OCaml porque a subtipagem é estrutural em vez de nominal, de modo que o tipo estrutural é facilmente refinado por meio da unificação conforme a inferência de tipo progride.

Haskell faz uma troca diferente, optando por focar no código predominantemente puro, onde essas limitações podem ser removidas.

Acho que o operador de pipe forward do F # ( |>) deve vs ( & ) em 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

Se você não gosta do &operador ( ), pode personalizá-lo como F # ou Elixir:

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

ghci>> 5 |> factorial |> show

Porque infixl 1 |>? Veja o documento em Data-Function (&)

infixl = infix + associatividade à esquerda

infixr = infix + associatividade direita

(.)

( .) significa composição da função. Significa (fg) (x) = f (g (x)) em matemática.

foo = negate . (*3)

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

é igual a

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

ou

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

O $operador ( ) também é definido em Data-Function ($) .

( .) é usado para criar Hight Order Functionou closure in js. Consultar exemplo:

// (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]

Uau, menos (código) é melhor.

Compare |>e.

ghci> 5 |> factorial |> show

// equals

ghci> (show . factorial) 5 

// equals

ghci> show . factorial $ 5 

É a diferença entre left —> righte right —> left. ⊙﹏⊙ |||

Humanização

|>e &é melhor que.

Porque

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

Como fazer programação funcional em linguagem orientada a objetos?

visite http://reactivex.io/

Suporta:

• Java: RxJava
• JavaScript: RxJS
• C #: Rx.NET
• C # (unidade): 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: reaxivo
• Dart: RxDart

Este é meu primeiro dia para experimentar Haskell (depois de Rust e F #), e pude definir o operador F # |>:

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

E parece que funciona:

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

main =     
    5 |> factorial |> print

Aposto que um especialista em Haskell pode lhe dar uma solução ainda melhor.