Отношения между функтором, аппликативным функтором и монадой

Question

При чтении классов типов я увидел, что отношения между Функторами, Аппликативными Функторами и Монадами строго связаны. Функторы - это типы, которые можно отображать. Аппликативные функторы могут делать то же самое с определенными эффектами. Монады то же самое с возможно неограниченными эффектами. Кроме того:

Every Monad is an Applicative Functor
Every Applicative Functor is a Functor

Определение Аппликативного Функтора ясно показывает это с помощью:

class Functor f => Applicative f where
  pure  :: a -> f a
  (<*>) :: f (a -> b) -> f a -> f b

Но определение Монада таково:

class Monad m where
  return :: a -> m a
  (>>=)  :: m a -> (a -> m b) -> m b
  (>>)   :: m a -> m b -> m b
  m >> n = m >>= \_ -> n
  fail   :: String -> m a

Согласно великой typeclassopedia Брента Йорги , что альтернативное определение монады может быть:

class Applicative m => Monad' m where
  (>>=) :: m a -> (a -> m b) -> m b

что, очевидно, проще и цементирует этот Functor 2010, стр. 80 отчета 2010, это не изменилось. Почему это?

Answer 1

Каждый хочет, чтобы Applicative стал суперклассом Monad, но он сломал бы столько кода (если исключено return, то каждый текущий экземпляр Monad станет недействительным), что все захотят задержать, пока мы не расширим язык таким образом.способ избежать взлома кода ( см. здесь для одного выдающегося предложения).

Haskell 2010 был консервативным, постепенным улучшением в целом, стандартизировав всего несколько неоспоримых расширений и нарушив совместимость в одна область , чтобы привести стандарт в соответствие с каждой существующей реализацией.Действительно, библиотеки Haskell 2010 даже не включают Applicative - меньше, чем люди ожидают от , стандартная библиотека стандартизирована, чем вы могли ожидать.

Надеемся, мы увидим ситуациюулучшается в ближайшее время, но, к счастью, это обычно лишь незначительное неудобство (необходимость писать liftM вместо fmap в общем коде и т. д.).

Answer 2

Изменение определения Monad на этом этапе может привести к поломке большого количества существующего кода (любой фрагмент кода, который определяет экземпляр Monad).

Подобное нарушение обратной совместимости имеет смысл только в том случае, если есть большие практические выгоды от изменений. В этом случае выгода не так уж велика (и в большинстве случаев теоретическая) и не оправдывает такое количество поломок.