mtl, трансформатори, monads-fd, monadLib та парадокс вибору


92

Hackage має кілька пакетів для монадних трансформаторів:

  • mtl : Бібліотека трансформаторів монад
  • трансформатори : Бетонні функторні та монадні трансформатори
  • monads-fd : Класи монад , що використовують функціональні залежності
  • monads-tf : Класи монад з використанням сімейств типів
  • monadLib : колекція монадних трансформаторів.
  • mtl-tf : Бібліотека трансформаторів Monad з використанням сімейств типів.
  • mmtl : Бібліотека модульних трансформаторів Monad
  • mtlx : Бібліотека трансформаторів Monad з індексами типів, що надає "безкоштовні" копії.
  • compose-trans : Складаються монадні трансформатори

(і, можливо, я щось пропустив)

Який із них ми використаємо?

mtl - це платформа Haskell, але я постійно чую на reddit, що це не круто.

Але що все-таки погано у виборі, чи не просто це добре?

Ну, я бачив, як, наприклад, автори програми доступу до даних повинні були зробити все це, щоб задовольнити лише популярний вибір:

  • data-accessor-monadLib бібліотека: функції доступу для монад monadLib
  • data-accessor-monads-fd бібліотека: Використовуйте Accessor для доступу до стану в класі монад monads-fd State
  • data-accessor-monads-tf бібліотека: Використовуйте Accessor для доступу до стану у сімействі типів монад monads-tf State
  • data-accessor-mtl бібліотека: Використовуйте Accessor для доступу до стану в класі монади mtl State
  • data-accessor-transformers library: Використовуйте Accessor для доступу до стану в монаді стану трансформаторів

Я думаю, що якщо це триватиме і, наприклад, кілька конкуруючих пакетів Arrow розвинуться, ми можемо побачити щось на зразок: spoonklink-arrows-transformers, spoonklink-arrows-monadLib, spoonklink-tfArrows-transformers, spoonklink-tfArrows-monadLib, ...

І тоді я переживаю, що якщо spoonklink роздвоїться, у Hackage закінчиться дисковий простір. :)

Запитання:

  • Чому так багато пакетів монадних трансформаторів?
  • Чому mtl [вважається] нехолодним?
  • Які ключові відмінності?
  • Більшість із цих, здавалося б, конкуруючих пакетів були написані Енді Гіллом і підтримуються Россом Патерсоном. Чи означає це, що ці пакети не конкурують, а певним чином працюють разом? І чи вважають Енді та Росс якісь власні пакунки застарілими?
  • Який з них ми з вами повинні використовувати?

2
Це посилання допомогло мені зрозуміти mtl vs transformers haskell.org/haskellwiki/Monad_Transformer_Library
Brandon Cook

2
Прокрутіть вниз для коментаря @jberryman ! Використовуйте mtl або трансфомери, вони стали сумісними!
Софі

Відповіді:


70

Купа з них майже повністю еквівалентна:

  • mtlвикористовує розширення GHC, але transformersє Haskell 98.
  • monads-fdі monads-tfє доповненнями transformers, використовуючи відповідно функціональні залежності та сімейства типів, обидва забезпечуючи функціональність, mtlякої немає transformers.
  • mtl-tfє mtlпереписана з використанням сімей типу.

Отже, по суті, mtl== transformers++ monads-fd, mtl-tf== transformers++ monads-tf. Поліпшена портативність та модульність transformersта пов’язані з ними пакети - ось чому mtl, на мою думку, сьогодні непросто.

mmtlі mtlxобидва схожі на і / або базуються на них mtl, з різницями API та додатковими функціями.

MonadLibмабуть, досить різний погляд на справи, але я з цим безпосередньо не знайомий. Також, схоже, використовує багато розширень GHC, більше, ніж інші.

На перший погляд compose-trans, це більше схоже на метапрограмування для створення монадних трансформаторів. Він стверджує, що сумісний з Control.Monad.Transяким ... я здогадуюсь означає mtl?

У будь-якому випадку, я б запропонував такий алгоритм прийняття рішень:

  • Вам потрібні стандартні монади для нового проекту? Use transformers& co., Допоможіть нам mtlвідпочити.
  • Ви вже використовуєте mtlвеликий проект? transformersне повністю сумісний, але ніхто не вб’є вас за те, що ви не перейшли.
  • Чи надає один з інших пакетів незвичну функціональність, яка вам потрібна? Можна також скористатися нею, а не прокатувати власну.
  • Все ще не задоволений? Викиньте їх усіх, завантажте category-extrasта вирішіть усі світові проблеми за допомогою півтора сторінок незрозумілого абстрактного безглуздя, що захоплює загалом загального коду.

2
якщо mtl == трансформатори ++ monads-fd, чи не можна це просто реалізувати таким чином? (як етап до його заміни), який позбавив би необхідності мати такі речі, як data-accessor-mtl
yairchu

2
@yairchu: Ну так, але що ти очікуєш від мене? :) Підтримка зворотної сумісності ніколи не буває настільки простою, як здається, а зміна ключових бібліотек вимагає часу, зусиль та певного рівня підтримки громади. Ситуація з трансформатором монади - це відома проблема, але я не думаю, що це чийсь головний пріоритет.
CA McCann,

5
@yairchu: це в основному те, що робиться. наступною основною версією mtl має стати заглушка, яка імпортує трансформатори + monads-fd, і вирішальним фактором буде сумісність з цією версією. Потім бібліотеки зможуть індивідуально оновлюватись, щоб вони були сумісними як з mtl 1.1, так і з 1.2, а потім програми отримуватимуть змогу переглядати будь-яку версію, яку встановлено, або це вимагається їхньою найбільш обмеженою бібліотечною залежністю.
Едвард КМЕТТ,

2
В даний час у списку розсилки бібліотек обговорюється питання переміщення MonadIO (і, можливо, MonadTrans з mtl в базову базу. Хоча, про це було сказано, витягувати MonadIO або більш загальний MonadBase, незважаючи на те, що "MonadBase" потребує MPTC, фундації тощо). .
Едвард KMETT

27
Оскільки я знайшов цей пост надзвичайно інформативним. Я думав оновити інших googlers: mtl тепер залежить від трансформаторів, monads-fd тепер є заглушкою навколо mtl. Тому використовуйте mtl, якщо вам потрібні додаткові смаколики, або просто імпортуйте трансформатори, якщо він має все необхідне.
jberryman

20

В дану хвилину? Вам, мабуть, слід скористатися mtl. Те , що відбувається в тому , що transformersбібліотека бути винесена з MTL в моді , що monads-fdі monads-tfможе мирно співіснувати, але в останній перевірки , який не був ще випадок.

Коли це станеться, ви зможете імпортувати monads-fdта transformersотримати (майже) один і той же інтерфейс, за винятком того State, що для псевдонімів тощо буде використано псевдонім StateT.

Тому я писав би mtl, але не покладався на той факт, що State, Reader тощо в даний час є dataтакими, якими вони будуть замінені на types.

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


4
У якому сенсі співіснувати? Використовується одним пакетом? Імпортували в той самий модуль? Об’єднані в один і той же стек трансформаторів? Змішування фундапсів і ФТ здається мені загалом поганою ідеєю. Як би там не було, я широко не використовував transformers& co. ще, але не помітив жодних проблем, крім незначних відмінностей API порівняно з mtlпереключенням деякого (досить простого) коду.
CA McCann,

4
Проблема зводиться до того, що ви можете завантажити лише один пакет, який надає даний модуль. Отже, якщо ви використовуєте бібліотеку, яка використовує mtl, навіть внутрішньо, ви не можете імпортувати альтернативу. В даний час здоровий відсоток злому використовує mtl певним чином. Багато людей вважають за краще використовувати сімейства типів, і monads-tf дає їм це, але майте на увазі, що на даний момент, поки не буде завершено трансформатори + monads-fd рефакторинг, це блокує код, який не використовує будь-які бібліотеки, які транзитивно вимагають MTL . Це включає в себе досить великі предмети квитків.
Едвард КМЕТТ,

1
Використання трансформаторів + монад- (tf | fd) в довгостроковій перспективі дозволить уникнути цього розсолу, але нас там ще немає. Тим часом переважання використання на користь mtl. Шлях оновлення полягає в тому, що наступна основна версія mtl буде перевизначена як заглушка, яка імпортує monads-fd та трансформатори. Основний розрив версії забезпечує хороший спосіб стверджувати у вашому файлі cabal, що вам байдуже, яку версію ви отримаєте (тобто ви не дбаєте про те, щоб держава була псевдонімом типу або типом даних), і як тільки ця головна версія відбудеться, тоді тобі не важливо, чи всі бібліотеки, якими ти користуєшся, мають однакові упередження.
Едвард КМЕТТ,

1
Отже, зрештою ваш досвід - це саме те, що трансформатори / монади- (tf | fd) призначені для підтримки. Але після того, як вони були написані, зрозуміли, що спільнота досить безправно погано переключається між бібліотеками, коли немає вагомих причин стрибати і маса застарілих причин залишатися. Звідси необхідність перевизначити mtl та зробити шлях оновлення чітким.
Едвард КМЕТТ,

Чудово, дякую за докладні роз'яснення! Очевидно, що переключений мною код мав мало зовнішніх залежностей - я думаю, здебільшого прив'язки FFI. Я також не усвідомлював, що конфлікти назв модулів були такими ... інвазивними, я думаю? Це справді робить речі незручними. :(
CA McCann,

16

Виділення факторів, згаданих Едвардом Кметтом, у своїй відповіді було завершено наприкінці 2010 року. Його кінцевий результат був monads-fd , побудована на трансформаторах , яка стала версією 2 mtl . Як наслідок всюдисущості mtl , monads-tf ніколи насправді не встигали. На початку 2017 року mtl та трансформатори - єдині бібліотеки монадних трансформаторів, які бачать широке використання.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.