Які проблеми програмування вирішує Monads? [зачинено]

Я читав багато постів, які пояснюють, що таке монади, як unitі як bindпрацюють, деякі з них занурюються прямо в теорію категорій настільки абстрактні (для мене, принаймні, для мене), що змушують кровоточити очі, деякі ігнорують це взагалі і торкаються дивних аналогій буріто, коробки і що ні.

Після декількох тижнів навчання і багато смажених нейронів, (я думаю) я розумію, як працюють Монади. Але все-таки є одне, що уникає мого розуміння, те, що насправді зачіпає кілька постів (крім IO та держави):

ЧОМУ?

Чому монади мають значення? Чому вони такі важливі? Які проблеми вони вирішують? Чи можна вирішити ці проблеми лише з монадами, чи існують інші способи?

Ви цього не робите потрібні монади, щоб щось вирішити. Вони просто спрощують певні речі. Багато людей виходять занадто абстрактними та теоретичними, коли пояснюють монади. Здебільшого, монади - це зразок, який виникає знову і знову в програмуванні. Розпізнаючи цей шаблон, ми можемо спростити наш код і уникнути повторного виконання певних функцій.

Для Хаскелла, з конкретної точки зору, найвідоміше, що монади дозволяють - це позначення . Ознайомлення зі списками в Хаскелл та інших мовах також сильно користуються монадами. Ви також можете створювати такі бібліотеки Control.Monad .

Усі вони надають корисні спрощення, і коли ви реалізуєте його за одну монаду, ви автоматично отримаєте її для всіх монад. Це одна з основних причин повторного використання коду для функціонального програмування набагато простіше, ніж інші парадигми.

Легше зрозуміти, якщо подивитися на конкретні монади і побачити, які проблеми вони вирішують. Наприклад, у Haskell:

• IO: Дозволяє представляти IO у системі типів, тому ви можете очистити окремі функції від функцій, що виконують IO.

• Список: Дозволяє робити розуміння списку та недетерміновані обчислення.

• Можливо: краща альтернатива нулю та підтримка чогось порівнянного з оператором з’єднання нулів C #.

• Парсек: зручний DSL для написання парсерів.

Тож легко (сподіваюсь) побачити обґрунтування окремих монад, оскільки всі вони дуже корисні. Але проблеми, які вони вирішують, також є зовсім різними, і, маючи на увазі, вони, схоже, не мають багато спільного, за винятком того, що вони пов'язані з деякою логікою ланцюгових операцій. Монади корисні, оскільки дозволяють будувати таку різноманітність інструментів.

Чи можна вищенаведені приклади реалізувати без монад? Безумовно, вони можуть бути реалізовані спеціально, але монади, вбудовані в мову, дозволяють підтримувати пряму мову, як do-нотація, яка працює з усіма монадами.

Одне, що робить це заплутаним, - це те, що "популярні" функції, як bindі<*> орієнтовані на практику. Але для розуміння понять простіше спочатку подивитися на інші функції. Варто також зазначити, що монади виділяються, оскільки вони трохи завищені в порівнянні з іншими пов'язаними поняттями. Тому я почну замість цього функторів.

Функціонери пропонують функцію (у позначенні Haskell) fmap :: (Functor f) => (a -> b) -> f a -> f b. Іншими словами, у вас є контекст, в fякий ви можете підняти функцію. Як ви можете собі уявити, майже все є функтором. Списки, може бути, або функції, введення / виведення, кортежі, парсери ... Кожен представляє контекст, в якому може з’являтися значення. Таким чином, ви можете написати надзвичайно універсальні функції, які працюють практично в будь-якому контексті, використовуючи fmapабо його вбудований варіант <$>.

Які ще речі ви хочете робити з контекстами? Ви можете поєднати два контексти. Отже, ви можете отримати узагальнення, zip :: [a] -> [b] -> [(a,b)]наприклад, подібне:pair :: (Monoidal f) => f a -> f b -> f (a,b) .

Але оскільки це ще корисніше на практиці, бібліотеки Haskell натомість пропонують Applicative, що є комбінацією Functorта Monoidal, а також Unit, що просто додає, що ви можете фактично поставити значення "всередині" свого контексту unit.

Ви можете написати надзвичайно загальні функції, просто вказавши ці три речі про контекст, в якому ви працюєте.

Monadце лише інша річ, яку ви можете стверджувати над цим. Те, про що я раніше не згадував, - це те, що у вас вже є два способи поєднання двох контекстів: Ви можете не тільки pairїх, але також можете складати їх, наприклад, ви можете мати список списків. У контексті вводу-виводу прикладом може бути дія вводу-виводу, яка може читати інші дії вводу-виводу з файлу, тож у вас буде тип FilePath -> IO (IO a). Як ми можемо позбутися цієї укладання для отримання виконуваної функції IO a? Ось звідки входить Monads join, це дозволяє нам поєднувати два складених контексти одного типу. Те саме стосується парсерів, може бути і т. Д. І bindце просто більш практичний спосіб використанняjoin

Отже, монадичний контекст повинен пропонувати лише чотири речі, і він може бути використаний майже з усіма механізмами, розробленими для вводу / виводу, для парсерів, відмов тощо.

Monads дозволяє виражати різні нечисті обчислення, а також спрощує код

• обчислювальний стан (отримати / встановити стан через монаду)
• I / O (журнал, користувальницький інтерфейс, файл або просто створюють / споживають список X)
• Також "нелінійний" контрольний потік (тобто винятки, можливо, тощо)

І, що важливо, не роблячи компромісів із чистими мовними конструкціями та не отримуючи з нього чистішої мови