Différence entre la Monade et Applicative en Haskell

Mon exemple préféré est le "purement applicative Soit". Nous allons commencer par l'analyse de la base de Monade instance, Soit

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

Cette instance intègre un très naturelle de court-circuit notion: on procède de gauche à droite et une fois un calcul unique "échoue" dans le Left puis tout le reste à faire ainsi. Il y a aussi le naturel Applicative exemple que tout Monad a

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

où ap n'est rien de plus que de gauche à droite et de séquençage de l'avant un return:

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

---

Maintenant, le problème avec cette Either instance vient à la lumière lorsque vous souhaitez collecter les messages d'erreur qui se produisent n'importe où dans un calcul et d'une certaine façon de produire un résumé des erreurs. Cela va à l'encontre de court-circuit. Il vole également dans le visage du type de (>>=)

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

Si nous pensons à m a que "le passé" et m b comme "l'avenir" alors (>>=) produit de l'avenir à partir du passé, tant qu'il peut exécuter le "pas à pas" (a -> m b). Ce "pas à pas" exige que la valeur de a existe vraiment dans le futur... et c'est impossible pour Either. Donc (>>=) demandes de court-circuit.

Donc, au lieu de cela, nous allons mettre en œuvre une Applicative instance qui ne peut pas avoir un correspondant Monad.

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

Désormais la mise en œuvre de (<*>) est la partie la peine d'examiner attentivement. Il effectue une certaine quantité de "court-circuit" dans sa première 3 cas, mais quelque chose d'intéressant, dans la quatrième.

  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!

Nouveau, remarquez que si on pense à la gauche de l'argument que "le passé" et le droit de l'argument de "l'avenir" alors (<*>) est spécial par rapport à (>>=) que c'est permis "d'ouvrir" l'avenir et le passé, en parallèle au lieu de nécessairement besoin de résultats à partir de "le passé" afin de calculer "l'avenir".

Cela signifie, directement, que nous pouvons utiliser notre purement Applicative Either de recueillir des erreurs, ignorant Rights si tout Lefts existent dans la chaîne

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

---

Donc, nous allons retourner cette intuition sur sa tête. Que pouvons-nous pas faire avec un purement applicative Either? Eh bien, puisque son fonctionnement dépend de l'examen de l'avenir avant l'exécution du passé, nous devons être en mesure de déterminer la structure de l'avenir sans selon les valeurs du passé. En d'autres termes, on ne peut pas écrire

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

qui satisfait les équations suivantes

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

alors que nous pouvons écrire 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

tels que

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

Cette impossibilité résulte de ce que ifA incarne exactement l'idée du résultat du calcul en fonction des valeurs ancrées dans l'argument des calculs.

Voici mon point de vue sur @J. Abrahamson est pourquoi ifA ne peut pas utiliser la valeur à l'intérieur par exemple (pure True). En substance, il encore se résume à l'absence de la join fonction de Monad dans Applicative, qui unifie les deux points de vue différents donnée dans typeclassopedia pour expliquer la différence entre Monad et Applicative.

Donc, à l'aide de @J. Abrahamson exemple purement applicative 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!

(qui a même court-circuiter l'effet de la Either Monad), et le ifA fonction

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

Que faire si nous essayons d'atteindre le mentionné équations:

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

?

Bien, comme l'a déjà souligné, en fin de compte, le contenu de (pure True), ne peut pas être utilisé par un plus tard calcul. Mais techniquement parlant, ce n'est pas le bon. Nous peut utiliser le contenu de (pure True) depuis un Monad est aussi un Functor avec fmap. Nous pouvons faire:

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

Le problème est avec le type de retour de ifA', qui est f (f a). Dans Applicative, il n'y a aucun moyen de s'effondrer imbriquées ApplicativeS en un seul. Mais cet effondrement de la fonction est précisément ce que join dans Monad effectue. Donc,

ifA = join . ifA' 

de satisfaire les équations pour ifA, si nous pouvons mettre en œuvre join de façon appropriée. Ce Applicative qui manque ici est exactement le join fonction. En d'autres termes, nous pouvons en quelque sorte le résultat de la précédente résultat dans Applicative. Mais le faire dans un Applicative cadre impliquera augmentant le type de la valeur de retour d'une imbriqués applicative de valeur, qui nous ont aucun moyen de les ramener à un seul niveau applicatif valeur. Ce sera un sérieux problème parce que, par exemple, on ne peut pas composer des fonctions à l'aide de ApplicativeS de façon appropriée. À l'aide de join résout le problème, mais bien l'introduction de join favorise la Applicative à un Monad.

Mais la description suivante semble vague pour moi et je ne pouvais pas comprendre ce que signifie exactement "le résultat" d'un monadique de calcul/de l'action.

Bien, que le flou est un peu délibérée, parce que ce "résultat" est d'une monadique de calcul est quelque chose qui dépend de chaque type. La meilleure réponse est un peu tautologique: le "résultat" (ou résultats, car il peut y avoir plus d'un) est n'importe quelle valeur(s) de l'instance de mise en œuvre de (>>=) :: Monad m => m a -> (a -> m b) -> m b invoque l'argument de fonction avec.

Donc, si je mets une valeur dans Maybe, ce qui rend une monade, quel est le résultat de ce "calcul"?

La Maybe monade ressemble à ceci:

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

La seule chose ici qui se qualifie comme un "résultat" est le a dans la seconde équation pour >>=, parce que c'est la seule chose qui n'est jamais "nourris" au deuxième argument de >>=.

D'autres réponses ont disparu dans la profondeur sur la ifA vs ifM différence, donc, j'ai pensé mettre en évidence une autre différence importante: applicatifs composer, les monades ne sont pas. Avec Monads, si vous voulez faire un Monad qui combine les effets de deux existantes, vous devez réécrire l'un d'entre eux comme une monade transformateur. En revanche, si vous avez deux Applicatives vous pouvez facilement faire de plus en plus complexes, l'un d'entre eux, comme illustré ci-dessous. (Le Code est copypasted de transformateurs.)

-- | 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 @f@ 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)

Maintenant, si nous ajoutons dans la Constant foncteur/applicative:

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)

...on peut assembler le "applicative Either" de l'autre des réponses de Lift et Constant:

type Error e a = Lift (Constant e) a