Разница между Монадой и Аппликатором в Хаскелле

Ответ 1

Моим любимым примером является "чисто аппликативный Либо". Мы начнем с анализа базового экземпляра Monad для Либо

instance Monad (Either e) where
  return = Right
  Left e  >>= _ = Left e
  Right a >>= f = f a

Этот экземпляр имеет очень естественное короткое замыкание: мы исходим слева направо, и как только одно вычисление "терпит неудачу" в Left, тогда все остальное тоже. Также существует естественный экземпляр Applicative, который имеет любой Monad

instance Applicative (Either e) where
  pure  = return
  (<*>) = ap

где ap - это не более чем последовательность слева направо до return:

ap :: Monad m => m (a -> b) -> m a -> m b
ap mf ma = do 
  f <- mf
  a <- ma
  return (f a)

Теперь проблема с этим экземпляром Either обнаруживается, когда вы хотите собирать сообщения об ошибках, которые происходят в любом месте вычислений, и как-то создавать сводку ошибок. Это летит перед лицом короткого замыкания. Он также летает в лицо типа (>>=)

(>>=) :: m a -> (a -> m b) -> m b

Если мы думаем о m a как "прошлом" и m b как "будущем", то (>>=) создает будущее из прошлого, пока оно может запускать "шаговый" (a -> m b). Этот "степпер" требует, чтобы значение a действительно существовало в будущем... и это невозможно для Either. Поэтому (>>=) требует короткого замыкания.

Поэтому вместо этого мы реализуем экземпляр Applicative, который не может иметь соответствующий Monad.

instance Monoid e => Applicative (Either e) where
  pure = Right

Теперь реализация (<*>) - это особая часть, которую стоит тщательно рассмотреть. Он выполняет некоторое количество "короткого замыкания" в первых трех случаях, но делает что-то интересное в четвертом.

  Right f <*> Right a = Right (f a)     -- neutral
  Left  e <*> Right _ = Left e          -- short-circuit
  Right _ <*> Left  e = Left e          -- short-circuit
  Left e1 <*> Left e2 = Left (e1 <> e2) -- combine!

Заметим еще раз, что если мы рассмотрим левый аргумент как "прошлое" и правый аргумент как "будущее", то (<*>) является особым по сравнению с (>>=), поскольку он позволил "открыть" будущее и прошлое параллельно, а не обязательно нуждаются в результатах от "прошлого", чтобы вычислить "будущее".

Это означает, что мы можем использовать наш чисто Applicative Either для сбора ошибок, игнорируя Right, если в цепочке21 > ​​существует Left

> Right (+1) <*> Left [1] <*> Left [2]
> Left [1,2]

Итак, дайте флип этой интуиции на голову. Что мы не можем делать с чисто аппликативным Either? Ну, так как его работа зависит от изучения будущего до запуска прошлого, мы должны уметь определять структуру будущего, не завися от ценностей в прошлом. Другими словами, мы не можем писать

ifA :: Applicative f => f Bool -> f a -> f a -> f a

которая удовлетворяет следующим уравнениям

ifA (pure True)  t e == t
ifA (pure False) t e == e

в то время как мы можем написать ifM

ifM :: Monad m => m Bool -> m a -> m a -> m a
ifM mbool th el = do
  bool <- mbool
  if bool then th else el

такое, что

ifM (return True)  t e == t
ifM (return False) t e == e

Эта невозможность возникает, потому что ifA воплощает в точности идею вычисления результата в зависимости от значений, встроенных в вычисления аргументов.

Ответ 2

Just 1 описывает "вычисление", чей "результат" равен 1. Nothing описывает вычисление, которое не дает результатов.

Разница между Монадой и Аппликатором заключается в том, что в Монаде есть выбор. Ключевым отличием Monads является способность выбирать между разными путями при вычислении (а не просто рано выходить). В зависимости от значения, полученного на предыдущем этапе вычисления, остальная структура вычислений может измениться.

Вот что это значит. В монадической цепочке

return 42            >>= (\x ->
if x == 1
   then
        return (x+1) 
   else 
        return (x-1) >>= (\y -> 
        return (1/y)     ))

if выбирает, какое вычисление нужно построить.

В случае применения, в

pure (1/) <*> ( pure (+(-1)) <*> pure 1 )

все функции работают "внутри" вычислений, нет возможности разбить цепочку. Каждая функция просто преобразует значение, которое оно подает. "Форма" вычислительной структуры полностью "снаружи" с точки зрения функций.

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

С монадами, сами функции строят вычисления по своему выбору.

Ответ 3

Вот мой взгляд на @J. Пример Абрахамсона относительно того, почему ifA не может использовать значение внутри, например, (pure True). По сути, это все еще сводится к отсутствию функции join от Monad в Applicative, которая объединяет две различные точки зрения, приведенные в typeclassopedia, чтобы объяснить разницу между Monad и Applicative.

Так что используя @J. Абрахамсон пример чисто аппликативного Either:

instance Monoid e => Applicative (Either e) where
  pure = Right

  Right f <*> Right a = Right (f a)     -- neutral
  Left  e <*> Right _ = Left e          -- short-circuit
  Right _ <*> Left  e = Left e          -- short-circuit
  Left e1 <*> Left e2 = Left (e1 <> e2) -- combine!

(который имеет эффект короткого замыкания для Either Monad), и функция ifA

ifA :: Applicative f => f Bool -> f a -> f a -> f a

Что если мы попытаемся достичь упомянутых уравнений:

ifA (pure True)  t e == t
ifA (pure False) t e == e

?

Ну, как уже указывалось, в конечном счете, содержание (pure True) не может быть использовано для более поздних вычислений. Но с технической точки зрения это не правильно. Мы можем использовать содержимое (pure True) поскольку Monad также является Functor с fmap. Мы можем:

ifA' b t e = fmap (\x -> if x then t else e) b

Проблема заключается в типе возврата ifA', который является f (fa). В Applicative невозможно объединить два вложенных Applicative в один. Но эта свертывающая функция - именно то, что выполняет join в Monad. Так,

ifA = join . ifA' 

будет удовлетворять уравнениям для ifA, если мы сможем реализовать join соответствующим образом. В данном случае Applicative не хватает именно функции join. Другими словами, мы можем каким-то образом использовать результат из предыдущего результата в Applicative. Но выполнение в Applicative среде будет включать в себя увеличение типа возвращаемого значения до вложенного аппликативного значения, которое у нас нет средств для возврата к одноуровневому аппликативному значению. Это будет серьезной проблемой, потому что, например, мы не можем составлять функции, используя Applicative надлежащим образом. Использование join решает проблему, но само введение join продвигает Applicative к Monad.

Ответ 4

Ключ разницы можно наблюдать в типе ap vs type =<<.

ap :: m (a->b) -> (m a->m b)
=<< :: (a->m b) -> (m a->m b)

В обоих случаях существует m a, но только во втором случае m a может решить, применяется ли функция (a->m b). В свою очередь, функция (a->m b) может "решить", будет ли применена функция bound next - путем создания такого m b, который не содержит "b (например, [], Nothing или Left)).

В Applicative нет возможности для функций "внутри" m (a->b) делать такие "решения" - они всегда выдает значение типа b.

f 1 = Nothing -- here f "decides" to produce Nothing
f x = Just x

Just 1 >>= f >>= g -- g doesn't get applied, because f decided so.

В Applicative это невозможно, поэтому нельзя показать пример. Самое близкое:

f 1 = 0
f x = x

g <$> f <$> Just 1 -- oh well, this will produce Just 0, but can't stop g
                   -- from getting applied

Ответ 5

Но следующее описание выглядит неопределенным для меня, и я не мог понять, что именно подразумевается под "результатом" монадического вычисления/действия.

Ну, эта неопределенность несколько преднамеренная, потому что то, что "результат" имеет монадическое вычисление, зависит от каждого типа. Лучший ответ - немного тавтологический: "результат" (или результат, поскольку может быть больше одного) - это любое значение (-ы), реализация экземпляра (>>=) :: Monad m => m a -> (a -> m b) -> m b вызывает аргумент функции с.

Итак, если я поместил значение в Maybe, что делает монаду, что является результатом этого "вычисления"?

Монада Maybe выглядит следующим образом:

instance Monad Maybe where
    return = Just
    Nothing >>= _ = Nothing
    Just a >>= k = k a

Единственное, что здесь квалифицируется как "результат" , это a во втором уравнении для >>=, потому что это единственное, что когда-либо получает "питание" ко второму аргументу >>=.

Другие ответы углубились в разницу ifA vs. ifM, поэтому я подумал, что выделил бы еще одну значительную разницу: составления аппликаций, монады не. Если Monad s, если вы хотите сделать Monad, который объединяет эффекты двух существующих, вы должны переписать один из них в качестве монадного трансформатора. Напротив, если у вас есть два Applicatives, вы можете легко сделать более сложный из них, как показано ниже. (Код копируется с transformers.)

-- | The composition of two functors.
newtype Compose f g a = Compose { getCompose :: f (g a) }

-- | The composition of two functors is also a functor.
instance (Functor f, Functor g) => Functor (Compose f g) where
    fmap f (Compose x) = Compose (fmap (fmap f) x)

-- | The composition of two applicatives is also an applicative.
instance (Applicative f, Applicative g) => Applicative (Compose f g) where
    pure x = Compose (pure (pure x))
    Compose f <*> Compose x = Compose ((<*>) <$> f <*> x)


-- | The product of two functors.
data Product f g a = Pair (f a) (g a)

-- | The product of two functors is also a functor.
instance (Functor f, Functor g) => Functor (Product f g) where
    fmap f (Pair x y) = Pair (fmap f x) (fmap f y)

-- | The product of two applicatives is also an applicative.
instance (Applicative f, Applicative g) => Applicative (Product f g) where
    pure x = Pair (pure x) (pure x)
    Pair f g <*> Pair x y = Pair (f <*> x) (g <*> y)


-- | The sum of a functor @[email protected] with the 'Identity' functor
data Lift f a = Pure a | Other (f a)

-- | The sum of two functors is always a functor.
instance (Functor f) => Functor (Lift f) where
    fmap f (Pure x) = Pure (f x)
    fmap f (Other y) = Other (fmap f y)

-- | The sum of any applicative with 'Identity' is also an applicative 
instance (Applicative f) => Applicative (Lift f) where
    pure = Pure
    Pure f <*> Pure x = Pure (f x)
    Pure f <*> Other y = Other (f <$> y)
    Other f <*> Pure x = Other (($ x) <$> f)
    Other f <*> Other y = Other (f <*> y)

Теперь, если добавить в функтор Constant функтор/аппликатив:

newtype Constant a b = Constant { getConstant :: a }

instance Functor (Constant a) where
    fmap f (Constant x) = Constant x

instance (Monoid a) => Applicative (Constant a) where
    pure _ = Constant mempty
    Constant x <*> Constant y = Constant (x `mappend` y)

... мы можем собрать "аппликативный Either" из других ответов из Lift и Constant:

type Error e a = Lift (Constant e) a

Ответ 6

Я хотел бы поделиться своим мнением об этой "странной вещи", так как я понимаю, что все внутри контекста применяется, например, так:

iffy :: Applicative f => f Bool -> f a -> f a -> f a
iffy fb ft fe = cond <$> fb <*> ft <*> fe   where
            cond b t e = if b then t else e

case 1>> iffy (Just True) (Just "True") Nothing ->> Nothing

Уппс должен быть просто "True"... но

 case 2>> iffy (Just False) (Just "True") (Just "False") ->> Just "False" 

("хороший" выбор делается внутри контекста). Я объяснил это себе таким образом, незадолго до конца вычисления, в случае, если >> 1 мы получаем что-то подобное в "цепочке":

Just (Cond True "True") <*> something [something being "accidentaly" Nothing]

который согласно определению Аппликатив оценивается как:

fmap (Cond True "True") something 

который, когда "что-то" равно Nothing, становится Nothing в соответствии с ограничением Functor (fmap over Nothing дает Nothing). И невозможно определить Функтор с концом истории "fmap f Nothing = кое-что".