Di F #, penggunaan operator pipa-maju |>,, cukup umum. Namun, di Haskell saya hanya pernah melihat komposisi fungsi (.),, sedang digunakan. Saya memahami bahwa keduanya terkait , tetapi adakah alasan bahasa yang membuat pipa maju tidak digunakan di Haskell atau ada hal lain?

Saya menjadi sedikit spekulatif ...

Budaya : Saya pikir |>adalah operator penting dalam "budaya" F #, dan mungkin serupa dengan .Haskell. F # memiliki operator komposisi fungsi <<tetapi menurut saya komunitas F # cenderung menggunakan gaya bebas poin lebih sedikit daripada komunitas Haskell.

Perbedaan bahasa : Saya tidak cukup tahu tentang kedua bahasa untuk dibandingkan, tetapi mungkin aturan untuk menggeneralisasi let-binding cukup berbeda untuk memengaruhi hal ini. Misalnya, saya tahu di F # kadang-kadang menulis

let f = exp

tidak akan dikompilasi, dan Anda memerlukan konversi eta eksplisit:

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

untuk membuatnya dikompilasi. Ini juga menjauhkan orang dari gaya bebas poin / komposisi, dan menuju gaya pipelining. Juga, inferensi tipe F # terkadang menuntut pipelining, sehingga tipe yang diketahui muncul di sebelah kiri (lihat di sini ).

(Secara pribadi, saya menemukan gaya bebas poin tidak dapat dibaca, tetapi saya kira setiap hal baru / berbeda tampaknya tidak dapat dibaca sampai Anda terbiasa.)

Saya pikir keduanya berpotensi layak dalam kedua bahasa, dan sejarah / budaya / kecelakaan dapat menentukan mengapa setiap komunitas menetap di "penarik" yang berbeda.

Di F # (|>)penting karena pemeriksaan ketik kiri-ke-kanan. Sebagai contoh:

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

umumnya tidak akan memeriksa kesalahan ketik, karena meskipun jenisnya xsdiketahui, jenis argumen xke lambda tidak diketahui pada saat pemeriksa ketik melihatnya, jadi tidak tahu bagaimana menyelesaikannya x.Value.

Sebaliknya

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

akan berfungsi dengan baik, karena jenis xsakan mengarah pada jenis xyang diketahui.

Pemeriksaan ketik kiri-ke-kanan diperlukan karena resolusi nama yang terlibat dalam konstruksi seperti x.Value. Simon Peyton Jones telah menulis proposal untuk menambahkan jenis resolusi nama yang serupa ke Haskell, tetapi ia menyarankan menggunakan batasan lokal untuk melacak apakah suatu jenis mendukung operasi tertentu atau tidak. Jadi dalam sampel pertama persyaratan yang xmembutuhkan Valueproperti akan diteruskan sampai xsterlihat dan persyaratan ini dapat diselesaikan. Ini memang memperumit sistem tipe.

Lebih banyak spekulasi, kali ini dari sisi yang didominasi Haskell ...

($)adalah kebalikan dari (|>), dan penggunaannya cukup umum ketika Anda tidak dapat menulis kode tanpa poin. Jadi alasan utama yang (|>)tidak digunakan di Haskell adalah karena tempatnya sudah diambil alih ($).

Juga, berbicara dari sedikit pengalaman F #, saya pikir (|>)sangat populer di kode F # karena menyerupai Subject.Verb(Object)struktur OO. Karena F # bertujuan untuk integrasi fungsional / OO yang mulus, Subject |> Verb Objectmerupakan transisi yang cukup mulus untuk programmer fungsional baru.

Secara pribadi, saya juga suka berpikir dari kiri ke kanan, jadi saya menggunakan (|>)di Haskell, tapi menurut saya tidak banyak orang yang melakukannya.

Saya pikir kami sedang membingungkan. Haskell's ( .) setara dengan F #'s ( >>). Jangan bingung dengan F # 's ( |>) yang hanya aplikasi fungsi terbalik dan seperti Haskell's ( $) - terbalik:

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

Saya yakin programmer Haskell memang $sering menggunakannya . Mungkin tidak sesering pemrogram F # cenderung menggunakan |>. Di sisi lain, beberapa orang F # menggunakan >>gelar yang konyol: http://blogs.msdn.com/b/ashleyf/archive/2011/04/21/programming-is-pointless.aspx

Jika Anda ingin menggunakan F # |>di Haskell maka di Data.Function adalah &operatornya (sejak base 4.8.0.0).

Komposisi kiri-ke-kanan di Haskell

Beberapa orang menggunakan gaya kiri-ke-kanan (penyampaian pesan) di Haskell juga. Lihat, misalnya, pustaka mps di Hackage. Sebuah contoh:

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

Saya pikir gaya ini terlihat bagus dalam beberapa situasi, tetapi lebih sulit untuk dibaca (seseorang perlu mengetahui perpustakaan dan semua operatornya, definisi ulang (.)juga mengganggu).

Ada juga operator komposisi kiri-ke-kanan serta kanan-ke-kiri di Control.Category , bagian dari paket dasar. Bandingkan >>>dan <<<masing - masing:

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

Terkadang ada alasan bagus untuk memilih komposisi kiri-ke-kanan: urutan evaluasi mengikuti urutan pembacaan.

Saya telah melihat >>>digunakan untuk flip (.), dan saya sering menggunakannya sendiri, terutama untuk rantai panjang yang paling baik dipahami dari kiri-ke-kanan.

>>> sebenarnya dari Control.Arrow, dan bekerja pada lebih dari sekadar fungsi.

Selain gaya dan budaya, ini bermuara pada pengoptimalan desain bahasa untuk kode murni atau tidak murni.

The |>operator adalah umum di F # sebagian besar karena membantu menyembunyikan dua keterbatasan yang muncul dengan kode dominan-tidak murni:

• Jenis inferensi kiri-ke-kanan tanpa subtipe struktural.
• Pembatasan nilai.

Perhatikan bahwa batasan sebelumnya tidak ada di OCaml karena subtipe bersifat struktural, bukan nominal, sehingga tipe struktural mudah disempurnakan melalui penyatuan saat inferensi tipe berlangsung.

Haskell mengambil trade-off yang berbeda, memilih untuk fokus pada kode yang didominasi murni di mana batasan ini dapat dicabut.

Saya pikir operator pipa forward F # ( |>) harus vs ( & ) di 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

Jika Anda tidak menyukai &operator ( ), Anda dapat menyesuaikannya seperti F # atau Elixir:

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

ghci>> 5 |> factorial |> show

Kenapa infixl 1 |>? Lihat dokumen di Data-Function (&)

infixl = infix + asosiatif kiri

infixr = infix + asosiatif kanan

(.)

( .) berarti komposisi fungsi. Artinya (fg) (x) = f (g (x)) dalam Matematika.

foo = negate . (*3)

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

itu sama

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

atau

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

Operator ( $) juga didefinisikan dalam Data-Function ($) .

( .) digunakan untuk membuat Hight Order Functionatau closure in js. Lihat contoh:

// (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, Lebih sedikit (kode) lebih baik.

Bandingkan |>dan.

ghci> 5 |> factorial |> show

// equals

ghci> (show . factorial) 5 

// equals

ghci> show . factorial $ 5 

Ini adalah perbedaan antara left —> rightdan right —> left. ⊙﹏⊙ ||i>

Humanisasi

|>dan &lebih baik dari.

karena

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

Bagaimana pemrograman fungsional dalam bahasa berorientasi objek?

silakan kunjungi http://reactivex.io/

Ini mendukung:

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

Ini adalah hari pertama saya mencoba Haskell (setelah Rust dan F #), dan saya bisa mendefinisikan operator F #'s |>:

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

dan sepertinya berhasil:

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

main =     
    5 |> factorial |> print

Saya yakin pakar Haskell dapat memberi Anda solusi yang lebih baik.