Mengapa efek samping dimodelkan sebagai monad di Haskell?

Adakah yang bisa memberikan beberapa petunjuk tentang mengapa perhitungan tidak murni di Haskell dimodelkan sebagai monad?

Maksudku monad hanyalah antarmuka dengan 4 operasi, jadi apa alasan untuk memodelkan efek samping di dalamnya?

Misalkan fungsi memiliki efek samping. Jika kita mengambil semua efek yang dihasilkannya sebagai parameter input dan output, maka fungsinya murni bagi dunia luar.

Jadi, untuk fungsi yang tidak murni

f' :: Int -> Int

kami menambahkan RealWorld ke dalam pertimbangan

f :: Int -> RealWorld -> (Int, RealWorld)
-- input some states of the whole world,
-- modify the whole world because of the side effects,
-- then return the new world.

kemudian fmurni lagi. Kami mendefinisikan tipe data parametrized type IO a = RealWorld -> (a, RealWorld), jadi kami tidak perlu mengetik RealWorld berkali-kali, dan cukup menulis

f :: Int -> IO Int

Bagi programmer, menangani RealWorld secara langsung terlalu berbahaya — khususnya, jika seorang programmer mendapatkan nilai tipe RealWorld, mereka mungkin mencoba menyalinnya , yang pada dasarnya tidak mungkin. (Bayangkan mencoba menyalin seluruh sistem file, misalnya. Di mana Anda meletakkannya?) Oleh karena itu, definisi IO kami merangkum keadaan seluruh dunia juga.

Komposisi fungsi "tidak murni"

Fungsi-fungsi tidak murni ini tidak berguna jika kita tidak dapat mengikatnya bersama. Mempertimbangkan

getLine     :: IO String            ~            RealWorld -> (String, RealWorld)
getContents :: String -> IO String  ~  String -> RealWorld -> (String, RealWorld)
putStrLn    :: String -> IO ()      ~  String -> RealWorld -> ((),     RealWorld)

Kami ingin

• dapatkan nama file dari konsol,
• baca file itu, dan
• cetak konten file itu ke konsol.

Bagaimana kita melakukannya jika kita dapat mengakses keadaan dunia nyata?

printFile :: RealWorld -> ((), RealWorld)
printFile world0 = let (filename, world1) = getLine world0
                       (contents, world2) = (getContents filename) world1 
                   in  (putStrLn contents) world2 -- results in ((), world3)

Kami melihat polanya di sini. Fungsinya disebut seperti ini:

...
(<result-of-f>, worldY) = f               worldX
(<result-of-g>, worldZ) = g <result-of-f> worldY
...

Jadi kita dapat mendefinisikan operator ~~~untuk mengikat mereka:

(~~~) :: (IO b) -> (b -> IO c) -> IO c

(~~~) ::      (RealWorld -> (b,   RealWorld))
      ->                    (b -> RealWorld -> (c, RealWorld))
      ->      (RealWorld                    -> (c, RealWorld))
(f ~~~ g) worldX = let (resF, worldY) = f worldX
                   in g resF worldY

maka kita cukup menulis

printFile = getLine ~~~ getContents ~~~ putStrLn

tanpa menyentuh dunia nyata.

"Impurifikasi"

Sekarang misalkan kita ingin membuat isi file huruf besar juga. Huruf besar adalah fungsi murni

upperCase :: String -> String

Tetapi untuk membuatnya menjadi dunia nyata, ia harus mengembalikan sebuah IO String. Mudah untuk mengangkat fungsi seperti itu:

impureUpperCase :: String -> RealWorld -> (String, RealWorld)
impureUpperCase str world = (upperCase str, world)

Ini dapat digeneralisasi:

impurify :: a -> IO a

impurify :: a -> RealWorld -> (a, RealWorld)
impurify a world = (a, world)

sehingga impureUpperCase = impurify . upperCase, dan kita bisa menulis

printUpperCaseFile = 
    getLine ~~~ getContents ~~~ (impurify . upperCase) ~~~ putStrLn

_{(Catatan: Biasanya kami menulis getLine ~~~ getContents ~~~ (putStrLn . upperCase))}

Kami bekerja dengan monads selama ini

Sekarang mari kita lihat apa yang telah kita lakukan:

1. Kami mendefinisikan operator (~~~) :: IO b -> (b -> IO c) -> IO cyang menghubungkan dua fungsi yang tidak murni secara bersamaan
2. Kami mendefinisikan fungsi impurify :: a -> IO ayang mengubah nilai murni menjadi tidak murni.

Sekarang kita membuat identifikasi (>>=) = (~~~)dan return = impurify, dan lihat? Kami punya monad.

Catatan teknis

Untuk memastikan itu benar-benar monad, masih ada beberapa aksioma yang perlu diperiksa juga:

1. return a >>= f = f a

    impurify a                =  (\world -> (a, world))
   (impurify a ~~~ f) worldX  =  let (resF, worldY) = (\world -> (a, world )) worldX 
                                 in f resF worldY
                              =  let (resF, worldY) =            (a, worldX)       
                                 in f resF worldY
                              =  f a worldX

2. f >>= return = f

   (f ~~~ impurify) worldX  =  let (resF, worldY) = f worldX 
                               in impurify resF worldY
                            =  let (resF, worldY) = f worldX      
                               in (resF, worldY)
                            =  f worldX

3. f >>= (\x -> g x >>= h) = (f >>= g) >>= h

   Dibiarkan sebagai latihan.

Adakah yang bisa memberikan beberapa petunjuk tentang mengapa perhitungan tidak murni di Haskell dimodelkan sebagai monad?

Pertanyaan ini mengandung kesalahpahaman yang meluas. Kenajisan dan Monad adalah gagasan independen. Kenajisan tidak dimodelkan oleh Monad. Sebaliknya, ada beberapa tipe data, seperti IO, yang mewakili perhitungan imperatif. Dan untuk beberapa tipe tersebut, sebagian kecil dari antarmuka mereka sesuai dengan pola antarmuka yang disebut "Monad". Selain itu, tidak ada dikenal murni / fungsional / denotatif penjelasan IO(dan ada tidak mungkin satu, mengingat "dosa bin" tujuan IO), meskipun ada cerita umum menceritakan tentang World -> (a, World)menjadi makna IO a. Kisah itu tidak dapat menggambarkan dengan jujur IO, karenaIOmendukung konkurensi dan nondeterminisme. Kisah ini bahkan tidak berfungsi ketika untuk perhitungan deterministik yang memungkinkan interaksi mid-komputasi dengan dunia.

Untuk penjelasan lebih lanjut, lihat jawaban ini .

Sunting : Saat membaca kembali pertanyaan, saya kira jawaban saya tidak sesuai. Model perhitungan imperatif sering berubah menjadi monad, seperti yang dikatakan pertanyaan. Penanya mungkin tidak benar-benar berasumsi bahwa keganjilan dengan cara apa pun memungkinkan pemodelan perhitungan imperatif.

Seperti yang saya pahami, seseorang bernama Eugenio Moggi pertama kali memperhatikan bahwa konstruksi matematika yang sebelumnya tidak jelas yang disebut "monad" dapat digunakan untuk memodelkan efek samping dalam bahasa komputer, dan karenanya menetapkan semantik mereka menggunakan kalkulus Lambda. Ketika Haskell sedang dikembangkan ada berbagai cara di mana perhitungan tidak murni dimodelkan (lihat kertas "kemeja" Simon Peyton Jones untuk lebih jelasnya), tetapi ketika Phil Wadler memperkenalkan monad, dengan cepat menjadi jelas bahwa ini adalah The Answer. Dan sisanya adalah sejarah.

Adakah yang bisa memberikan beberapa petunjuk tentang mengapa perhitungan tidak murni di Haskell dimodelkan sebagai monad?

Ya, karena Haskell murni . Anda memerlukan konsep matematika untuk membedakan antara perhitungan tidak murni dan yang murni pada tipe-tingkat dan untuk memodelkan aliran program di masing-masing.

Ini berarti Anda harus berakhir dengan beberapa jenis IO ayang memodelkan perhitungan yang tidak murni. Maka Anda perlu mengetahui cara-cara menggabungkan perhitungan ini yang berlaku secara berurutan ( >>=) dan mengangkat nilai ( return) adalah yang paling jelas dan mendasar.

Dengan keduanya, Anda telah mendefinisikan sebuah monad (bahkan tanpa memikirkannya);)

Selain itu, monad menyediakan abstraksi yang sangat umum dan kuat , sehingga banyak jenis aliran kontrol dapat dengan mudah digeneralisasikan dalam fungsi-fungsi monadik seperti sequence, liftMatau sintaksis khusus, membuat ketidaksatuan bukan kasus khusus.

Lihat monads dalam pemrograman fungsional dan pengetikan unik (satu-satunya alternatif yang saya tahu) untuk informasi lebih lanjut.

Seperti yang Anda katakan, Monadadalah struktur yang sangat sederhana. Separuh dari jawabannya adalah: Monadadalah struktur paling sederhana yang dapat kita berikan untuk fungsi-fungsi efek samping dan dapat menggunakannya. Dengan Monadkita dapat melakukan dua hal: kita dapat memperlakukan nilai murni sebagai nilai efek samping (return ), dan kita dapat menerapkan fungsi efek samping ke nilai efek samping untuk mendapatkan nilai efek samping baru ( >>=). Kehilangan kemampuan untuk melakukan salah satu dari hal-hal ini akan melumpuhkan, jadi tipe efek samping kami harus "setidaknya" Monad, dan ternyata Monadcukup untuk mengimplementasikan semua yang kami butuhkan sejauh ini.

Setengah lainnya adalah: apa struktur paling detail yang bisa kita berikan untuk "kemungkinan efek samping"? Kita tentu bisa memikirkan ruang semua efek samping yang mungkin sebagai satu set (satu-satunya operasi yang membutuhkan adalah keanggotaan). Kita dapat menggabungkan dua efek samping dengan melakukannya satu per satu, dan ini akan menimbulkan efek samping yang berbeda (atau mungkin efek yang sama - jika yang pertama adalah "mematikan komputer" dan yang kedua adalah "menulis file", maka hasilnya menyusun ini hanya "mematikan komputer").

Ok, jadi apa yang bisa kita katakan tentang operasi ini? Itu asosiatif; yaitu, jika kita menggabungkan tiga efek samping, tidak masalah urutan mana yang kita lakukan menggabungkan. Jika kita melakukan (menulis file kemudian membaca soket) kemudian mematikan komputer, itu sama seperti melakukan menulis file kemudian (baca soket lalu shutdown komputer). Tapi itu tidak komutatif: ("tulis file" lalu "hapus file") adalah efek samping yang berbeda dari ("hapus file" lalu "tulis file"). Dan kami memiliki identitas: efek samping khusus "tidak ada efek samping" berfungsi ("tidak ada efek samping" lalu "hapus file" adalah efek samping yang sama dengan hanya "hapus file") Pada titik ini setiap matematikawan berpikir "Grup!" Tetapi kelompok memiliki invers, dan tidak ada cara untuk membalikkan efek samping secara umum; "menghapus berkas" tidak dapat dipulihkan. Jadi struktur yang tersisa adalah monoid, yang berarti fungsi efek sampingnya adalah monad.

Apakah ada struktur yang lebih kompleks? Tentu! Kita dapat membagi efek samping yang mungkin menjadi efek berbasis sistem file, efek berbasis jaringan dan banyak lagi, dan kita bisa membuat aturan komposisi yang lebih rumit yang menjaga detail ini. Tapi sekali lagi turun ke: Monadsangat sederhana, namun cukup kuat untuk mengekspresikan sebagian besar properti yang kita pedulikan. (Khususnya, asosiatif dan aksioma lainnya mari kita uji aplikasi kita dalam potongan kecil, dengan keyakinan bahwa efek samping dari aplikasi gabungan akan sama dengan kombinasi efek samping dari potongan-potongan).

Ini sebenarnya cara yang cukup bersih untuk memikirkan I / O secara fungsional.

Di sebagian besar bahasa pemrograman, Anda melakukan operasi input / output. Di Haskell, bayangkan menulis kode bukan untuk melakukan operasi, tetapi untuk menghasilkan daftar operasi yang ingin Anda lakukan.

Monads hanya sintaks yang cukup untuk itu.

Jika Anda ingin tahu mengapa monad bukan yang lain, saya kira jawabannya adalah mereka adalah cara fungsional terbaik untuk mewakili I / O yang bisa dipikirkan orang ketika mereka membuat Haskell.

AFAIK, alasannya adalah untuk dapat memasukkan pemeriksaan efek samping dalam sistem tipe. Jika Anda ingin tahu lebih banyak, dengarkan episode - episode SE-Radio : Episode 108: Simon Peyton Jones tentang Pemrograman Fungsional dan Haskell Episode 72: Erik Meijer di LINQ

Di atas ada jawaban terinci yang sangat bagus dengan latar belakang teoretis. Tapi saya ingin memberikan pandangan saya tentang IO monad. Saya tidak berpengalaman dengan programmer haskell, jadi mungkin itu sangat naif atau bahkan salah. Tetapi saya membantu saya untuk berurusan dengan IO monad sampai batas tertentu (perhatikan, bahwa itu tidak berhubungan dengan monad lain).

Pertama saya ingin mengatakan, bahwa contoh dengan "dunia nyata" tidak terlalu jelas bagi saya karena kita tidak dapat mengakses (dunia nyata) sebelumnya. Mungkin itu tidak berhubungan dengan perhitungan monad sama sekali tetapi diinginkan dalam arti transparansi referensial, yang umumnya disajikan dalam kode haskell.

Jadi kami ingin bahasa kami (haskell) murni. Tetapi kami membutuhkan operasi input / output karena tanpa mereka program kami tidak dapat berguna. Dan operasi itu tidak bisa murni berdasarkan sifatnya. Jadi satu-satunya cara untuk menangani ini kita harus memisahkan operasi yang tidak murni dari sisa kode.

Di sini monad datang. Sebenarnya, saya tidak yakin, bahwa tidak ada konstruksi lain dengan properti yang diperlukan serupa, tetapi intinya adalah bahwa monad memiliki properti ini, sehingga dapat digunakan (dan berhasil digunakan). Properti utama adalah bahwa kita tidak dapat melarikan diri darinya. Antarmuka Monad tidak memiliki operasi untuk menyingkirkan monad di sekitar nilai kami. Monad lain (bukan IO) menyediakan operasi seperti itu dan memungkinkan pencocokan pola (mis. Mungkin), tetapi operasi itu tidak berada dalam antarmuka monad. Properti lain yang diperlukan adalah kemampuan untuk rantai operasi.

Jika kita berpikir tentang apa yang kita butuhkan dalam hal sistem tipe, kita sampai pada fakta bahwa kita perlu mengetik dengan konstruktor, yang dapat dililitkan di setiap lembah. Konstruktor harus bersifat pribadi, karena kami melarang melarikan diri darinya (yaitu pencocokan pola). Tetapi kita perlu fungsi untuk memberi nilai pada konstruktor ini (di sini kembali ke pikiran). Dan kita perlu cara untuk rantai operasi. Jika kita memikirkannya selama beberapa waktu, kita akan sampai pada fakta, bahwa operasi rangkaian harus memiliki tipe seperti >> = miliki. Jadi, kita sampai pada sesuatu yang sangat mirip dengan Monad. Saya pikir, jika kita sekarang menganalisis kemungkinan situasi yang bertentangan dengan konstruksi ini, kita akan sampai pada aksioma monad.

Perhatikan, konstruk yang dikembangkan tidak memiliki kesamaan dengan kenajisan. Itu hanya memiliki properti, yang kami harapkan harus mampu menangani operasi yang tidak murni, yaitu, tidak melarikan diri, merantai, dan cara untuk masuk.

Sekarang beberapa rangkaian operasi yang tidak murni ditentukan oleh bahasa dalam monad IO yang dipilih ini. Kami dapat menggabungkan operasi-operasi itu untuk membuat operasi tidak murni yang baru. Dan semua operasi itu harus memiliki IO dalam tipenya. Perhatikan bahwa kehadiran IO dalam beberapa fungsi tidak membuat fungsi ini tidak murni. Tapi seperti yang saya mengerti, itu adalah ide yang buruk untuk menulis fungsi murni dengan IO di tipe mereka, karena pada awalnya ide kami untuk memisahkan fungsi murni dan tidak murni.

Akhirnya, saya ingin mengatakan, bahwa monad tidak mengubah operasi yang tidak murni menjadi murni. Ini hanya memungkinkan untuk memisahkan mereka secara efektif. (Saya ulangi, bahwa itu hanya pemahaman saya)