Aplikasi menulis, monads tidak

Aplikasi menulis, monads tidak.

Apa maksud pernyataan di atas? Dan kapan yang satu lebih disukai daripada yang lain?

Jika kita membandingkan jenisnya

(<*>) :: Applicative a => a (s -> t) -> a s -> a t
(>>=) :: Monad m =>       m s -> (s -> m t) -> m t

kami mendapatkan petunjuk tentang apa yang memisahkan kedua konsep tersebut. Bahwa (s -> m t)dalam tipe (>>=)menunjukkan bahwa nilai dalam sdapat menentukan perilaku komputasi dalam m t. Monads memungkinkan interferensi antara nilai dan lapisan komputasi. The (<*>)Operator memungkinkan tidak ada gangguan seperti: fungsi dan argumen perhitungan tidak bergantung pada nilai-nilai. Ini benar-benar menggigit. Membandingkan

miffy :: Monad m => m Bool -> m x -> m x -> m x
miffy mb mt mf = do
  b <- mb
  if b then mt else mf

yang menggunakan hasil dari beberapa efek untuk memutuskan antara dua perhitungan (mis. meluncurkan rudal dan menandatangani gencatan senjata), sedangkan

iffy :: Applicative a => a Bool -> a x -> a x -> a x
iffy ab at af = pure cond <*> ab <*> at <*> af where
  cond b t f = if b then t else f

yang menggunakan nilai abuntuk memilih di antara nilai-nilai dari dua perhitungan atdan af, setelah melakukan keduanya, mungkin menghasilkan efek yang tragis.

Versi monadik pada dasarnya bergantung pada kekuatan ekstra (>>=)untuk memilih penghitungan dari suatu nilai, dan itu bisa jadi penting. Namun, mendukung kekuatan tersebut membuat monad sulit untuk dibuat. Jika kita mencoba membangun 'ikatan ganda'

(>>>>==) :: (Monad m, Monad n) => m (n s) -> (s -> m (n t)) -> m (n t)
mns >>>>== f = mns >>-{-m-} \ ns -> let nmnt = ns >>= (return . f) in ???

kita sampai sejauh ini, tapi sekarang lapisan kita semua campur aduk. Kami memiliki n (m (n t)), jadi kami harus menyingkirkan bagian luarnya n. Seperti yang dikatakan Alexandre C, kita bisa melakukannya jika kita punya yang cocok

swap :: n (m t) -> m (n t)

untuk mengubah ke ndalam dan joinke yang lain n.

'Penerapan ganda' yang lebih lemah jauh lebih mudah untuk didefinisikan

(<<**>>) :: (Applicative a, Applicative b) => a (b (s -> t)) -> a (b s) -> a (b t)
abf <<**>> abs = pure (<*>) <*> abf <*> abs

karena tidak ada interferensi antar lapisan.

Sejalan dengan itu, ada baiknya untuk mengenali kapan Anda benar-benar membutuhkan kekuatan ekstra Monads, dan kapan Anda bisa lolos dengan struktur komputasi kaku yang Applicativemendukung.

Perhatikan, ngomong-ngomong, meskipun menyusun monad itu sulit, itu mungkin lebih dari yang Anda butuhkan. Jenis tersebut m (n v)menunjukkan komputasi dengan m-efek, kemudian komputasi dengan n-efek ke v-nilai, di mana m-efek selesai sebelum n-efek dimulai (karena itu diperlukan swap). Jika Anda hanya ingin mmenyisipkan -efek dengan n-efek, maka komposisi mungkin terlalu banyak untuk ditanyakan!

Aplikasi menulis, monads tidak.

Monad memang menulis, tetapi hasilnya mungkin bukan monad. Sebaliknya, komposisi dua aplikatif tentu saja aplikatif. Saya curiga maksud dari pernyataan asli adalah bahwa "sifat aplikatif membuat, sedangkan monadness tidak." Diucapkan ulang, " Applicativeditutup di bawah komposisi, dan Monadtidak."

Jika Anda memiliki aplikatif A1dan A2, maka jenisnya data A3 a = A3 (A1 (A2 a))juga aplikatif (Anda dapat menulis contoh seperti itu dengan cara yang umum).

Sebaliknya, jika Anda memiliki monad M1dan M2jenisnya data M3 a = M3 (M1 (M2 a))belum tentu monad (tidak ada implementasi umum yang masuk akal untuk >>=atau joinuntuk komposisi).

Salah satu contoh dapat berupa tipe [Int -> a](di sini kita membuat konstruktor tipe []dengan (->) Int, keduanya adalah monad). Anda dapat dengan mudah menulis

app :: [Int -> (a -> b)] -> [Int -> a] -> [Int -> b]
app f x = (<*>) <$> f <*> x

Dan itu menggeneralisasi untuk setiap aplikatif:

app :: (Applicative f, Applicative f1) => f (f1 (a -> b)) -> f (f1 a) -> f (f1 b)

Tetapi tidak ada definisi yang masuk akal tentang

join :: [Int -> [Int -> a]] -> [Int -> a]

Jika Anda tidak yakin akan hal ini, pertimbangkan ungkapan ini:

join [\x -> replicate x (const ())]

Panjang daftar yang dikembalikan harus ditetapkan sebelumnya sebelum bilangan bulat diberikan, tetapi panjang yang benar tergantung pada bilangan bulat yang disediakan. Jadi, tidak ada joinfungsi yang benar untuk tipe ini.

Sayangnya, tujuan kami yang sebenarnya, komposisi monad, agak lebih sulit. .. Faktanya, kami sebenarnya dapat membuktikan bahwa, dalam arti tertentu, tidak ada cara untuk membangun fungsi gabungan dengan tipe di atas hanya menggunakan operasi dua monad (lihat lampiran untuk garis besar pembuktian). Oleh karena itu, satu-satunya cara yang kita harapkan untuk membentuk komposisi adalah jika ada beberapa konstruksi tambahan yang menghubungkan kedua komponen tersebut.

Menulis monad, http://web.cecs.pdx.edu/~mpj/pubs/RR-1004.pdf

Solusi hukum distributif l: MN -> NM sudah cukup

untuk menjamin monadisitas NM. Untuk melihat ini, Anda memerlukan unit dan mult. saya akan fokus pada mult (unitnya adalah unit_N unitM)

NMNM - l -> NNMM - mult_N mult_M -> NM

Ini tidak menjamin bahwa MN adalah monad.

Pengamatan penting bagaimanapun, mulai berlaku ketika Anda memiliki solusi hukum distributif

l1 : ML -> LM
l2 : NL -> LN
l3 : NM -> MN

jadi, LM, LN dan MN adalah monad. Timbul pertanyaan apakah LMN adalah monad (baik oleh

(MN) L -> L (MN) atau oleh N (LM) -> (LM) N

Kami memiliki struktur yang cukup untuk membuat peta ini. Namun, seperti yang diamati oleh Eugenia Cheng , kita membutuhkan kondisi heksagonal (yang sama dengan presentasi persamaan Yang-Baxter) untuk menjamin monadisitas konstruksi. Padahal, dengan kondisi heksagonal, kedua monad yang berbeda itu bertepatan.