Програми складаються, монади ні

Програми складаються, монади ні.

Що означає вищезазначене твердження? А коли одне переважне перед іншим?

Якщо порівнювати типи

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

ми отримуємо підказку до того, що розділяє ці два поняття. Це (s -> m t)за типом (>>=)показує, що значення в sможе визначати поведінку обчислення в m t. Монади дозволяють втручатися між значеннями та рівнями обчислень. (<*>)Оператор не допускає таких перешкод: функція і аргумент обчислення не залежать від значень. Це справді кусає. Порівняйте

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

який використовує результат деякого ефекту для вирішення між двома обчисленнями (наприклад, запуск ракет і підписання перемир'я), тоді як

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

яке використовує значення abдля вибору між значеннями двох обчислень atтаaf , провівши обидва, можливо, для трагічного ефекту.

Монадічна версія по суті покладається на додаткову силу (>>=)вибору обчислення зі значення, і це може бути важливо. Однак підтримка цієї влади робить монадів складно скласти. Якщо ми спробуємо побудувати "подвійне зв'язування"

(>>>>==) :: (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 ???

ми дістаємось так далеко, але тепер наші шари все підскочили. У нас є n (m (n t)), тому нам потрібно позбутися зовнішньої n. Як каже Олександр С, ми можемо це зробити, якщо маємо підходящий

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

переставляти nнутрощі та joinіншеn .

Слабше "подвійне застосування" визначити набагато простіше

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

тому що між шарами немає перешкод.

Відповідно, добре визнати, коли вам справді потрібна додаткова потужність Monads, і коли ви можете піти з жорсткої структури обчислень, яка Applicativeпідтримує.

Зауважте, до речі, що хоча складати монади складно, це може бути більше, ніж потрібно. Тип m (n v)вказує обчислення з m-ефектами, потім обчислення з n-ефектами до -значення v, де m-ефекти закінчуються до початку n-ефектів (звідси необхідність swap). Якщо ви просто хочете mпереплутати -ефекти з n-ефектами, то композиція, можливо, занадто багато, щоб запитати!

Програми складаються, монади ні.

Монада зробити складати, але результат не може бути монадой. На противагу цьому, склад двох додатків обов'язково є додатком. Я підозрюю, що наміром оригінального твердження було те, що "придатність складається, а монадність - ні". Перефразоване, " Applicativeзакривається під композицію, і Monadні".

Якщо у вас є додатки, A1а A2потім - типdata A3 a = A3 (A1 (A2 a)) також апплікатівен (ви можете написати такий екземпляр в загальному вигляді).

З іншого боку, якщо у вас є монади M1і M2тоді тип data M3 a = M3 (M1 (M2 a))не обов'язково є монадою (немає розумної загальної реалізації для >>=абоjoin композиції для неї).

Одним з прикладів може бути типу [Int -> a](тут ми складаємо конструктор типу []з (->) Int, обидва з яких є монади). Ви можете легко написати

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

І це узагальнює будь-які програми:

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

Але розумного визначення цього поняття немає

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

Якщо ви не переконані в цьому, врахуйте цей вираз:

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

Довжина поверненого списку повинна бути встановлена ​​в камені до того, як буде надано ціле число, але правильна довжина його залежить від цілого числа, яке надано. Таким чином, жодна правильна joinфункція для цього типу не може існувати.

На жаль, наша реальна мета, склад монад, є досить важкою. .. Насправді ми можемо фактично довести, що в певному сенсі немає способу побудувати функцію приєднання з типом, описаним вище, використовуючи лише операції двох монад (див. Додаток до контуру доказу). Звідси випливає, що єдиним способом, на який ми можемо сподіватися сформувати композицію, є наявність додаткових конструкцій, що з'єднують ці дві компоненти.

Складаються монади, http://web.cecs.pdx.edu/~mpj/pubs/RR-1004.pdf

Рішення закону розподілу l: MN -> NM достатньо

гарантувати монадичність НМ. Щоб побачити це, вам потрібен блок і мульти. я зосередиться на мульти (одиниця є unit_N unitM)

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

Це не так гарантує, що MN є монадою.

Однак важливе зауваження грає, коли у вас є рішення щодо розподілу законів

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

таким чином, LM, LN і MN - монади. Виникає питання, чи є LMN монадою (або від

(MN) L -> L (MN) або по N (LM) -> (LM) N

У нас достатньо структури, щоб зробити ці карти. Однак, як зауважує Євгенія Чен , нам потрібна гексагональна умова (що означає подання рівняння Ян-Бакстера), щоб гарантувати одноманітність будь-якої конструкції. Насправді, з шестикутною умовою збігаються дві різні монади.