Applicatifs composer, les monades ne sont pas

Si l'on compare les types de

(<*>) :: Applicative a => a (s -> t) -> a s -> a t
(>>=) :: Monad m =>       m s -> (s -> m t) -> m t

nous obtenir un indice sur ce qui sépare les deux concepts. Que (s -> m t) dans le type de (>>=) montre qu'une valeur dans s peut déterminer le comportement d'un calcul dans m t. Les monades permettre l'interférence entre la valeur et les calculs. Le (<*>) opérateur permet pas une telle ingérence: la fonction et argument calculs ne dépendent pas des valeurs. - Ce vraiment des morsures. Comparer

miffy :: Monad m => m Bool -> m x -> m x -> m x
miffy mb mt mf = do
  b <- mb
  if b then mt else mf

qui utilise le résultat d'un effet de décider entre deux calculs (par exemple, le lancement de missiles et de la signature de l'armistice), alors que

iffy :: Applicative a => a Bool -> a x -> a x -> a x
iffy ab at af = pure cond <*> ab <*> at <*> af where
  cond b t f = if b then t else f

qui utilise la valeur de ab de choisir entre les valeurs de les deux calculs at et af, après avoir effectué les deux, peut-être pour effet tragique.

La monadique version s'appuie essentiellement sur la puissance supplémentaire de (>>=) de choisir un calcul à partir d'une valeur, et qui peut être important. Toutefois, en soutenant que le pouvoir monades difficile de composer. Si nous essayons de construire des " double-bind’

(>>>>==) :: (Monad m, Monad n) => m (n s) -> (s -> m (n t)) -> m (n t)
mns >>>>== f = mns >>-{ -m- } \ ns -> let nmnt = ns >>= (return . f) in ???

on en arrive là, mais maintenant nos couches sont tout mélangés. Nous avons une n (m (n t)), de sorte que nous devons nous débarrasser de l'extérieur n. Alexandre C dit, nous pouvons le faire si nous avons adapté

swap :: n (m t) -> m (n t)

de permuter l' n vers l'intérieur et join à l'autre n.

Les plus faibles de la " double-appliquer’ est beaucoup plus facile de définir

(<<**>>) :: (Applicative a, Applicative b) => a (b (s -> t)) -> a (b s) -> a (b t)
abf <<**>> abs = pure (<*>) <*> abf <*> abs

car il n'y a pas d'interférence entre les couches.

En conséquence, il est bon de reconnaître quand vous avez vraiment besoin de la puissance supplémentaire de Monads, et quand vous pouvez vous en tirer avec la rigide calcul structure Applicative prend en charge.

Noter, en passant, que, bien que la composition des monades est difficile, il pourrait être plus que vous avez besoin. Le type m (n v) indique le calcul avec m-effets, puis l'informatique avec nles effets v-valeur, où la m-effets terminer avant le n-effets commencent (d'où la nécessité pour swap). Si vous voulez juste interleave m-effets avec n-effets, puis la composition est peut-être trop demander!

OriginalL'auteur pigworker

Si vous avez des applicatifs A1 et A2, puis le type data A3 a = A3 (A1 (A2 a)) est également applicative (vous pouvez écrire une telle instance de manière générique).

D'autre part, si vous avez des monades M1 et M2, puis le type data M3 a = M3 (M1 (M2 a)) n'est pas nécessairement une monade (il n'est pas raisonnable générique de mise en œuvre de >>= ou join pour la composition).

Un exemple peut être le type [Int -> a] (ici, nous composer un constructeur de type [] avec (->) Int, qui sont tous deux monades). Vous pouvez facilement écrire

app :: [Int -> (a -> b)] -> [Int -> a] -> [Int -> b]
app f x = (<*>) <$> f <*> x

Et qui généralise à toute applicative:

app :: (Applicative f, Applicative f1) => f (f1 (a -> b)) -> f (f1 a) -> f (f1 b)

Mais il n'est pas raisonnable définition de

join :: [Int -> [Int -> a]] -> [Int -> a]

Si vous êtes pas convaincu de cela, envisager de cette expression:

join [\x -> replicate x (const ())]

La longueur de la liste retournée doit être fixé dans la pierre avant un entier est déjà fourni, mais la bonne longueur de celui-ci dépend du nombre entier qui est fourni. Ainsi, il n'y a pas join fonction peut exister pour ce type.

OriginalL'auteur Rotsor

La loi de distributivité de la solution
l : MN -> NM est assez

pour garantir monadicity de NM. Pour voir cela, vous avez besoin d'une unité et d'une mult. je vais me concentrer sur le mult (l'unité est unit_N unitM)

NMNM - l -> NNMM - mult_N mult_M -> NM

Cela ne pas garantir que MN est une monade.

L'observation cruciale cependant, entre en jeu lorsque vous avez distributive de la loi solutions

l1 : ML -> LM
l2 : NL -> LN
l3 : NM -> MN

ainsi, LM, LN et MN sont des monades. La question se pose de savoir si LMN est une monade (soit par

(MN)L -> L(MN)
ou par
N(LM) -> (LM)N

Nous avons assez de structure à faire de ces cartes. Cependant, comme Eugenia Cheng observe, nous avons besoin d'un hexagonal condition (qui équivaut à une présentation de l'équation de Yang-Baxter), afin de garantir monadicity de la construction. En fait, avec la forme hexagonale de la condition, les deux monades coïncident.

OriginalL'auteur user278559