Les applicatifs composent, les monades ne le font pas

Les applicatifs composent, les monades non.

Que signifie la déclaration ci-dessus? Et quand l'un est-il préférable à l'autre?

Si nous comparons les types

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

nous avons une idée de ce qui sépare les deux concepts. Cela (s -> m t)dans le type de (>>=)montre qu'une valeur dans speut déterminer le comportement d'un calcul dans m t. Les monades permettent des interférences entre la valeur et les couches de calcul. L' (<*>)opérateur n'autorise pas de telles interférences: les calculs de fonction et d'argument ne dépendent pas de valeurs. Cela mord vraiment. 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 certain effet pour décider entre deux calculs (par exemple le lancement de missiles et la signature d'un 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 abpour choisir entre les valeurs de deux calculs atet af, après avoir effectué les deux, peut-être à un effet tragique.

La version monadique repose essentiellement sur la puissance supplémentaire de (>>=)choisir un calcul à partir d'une valeur, et cela peut être important. Cependant, soutenir ce pouvoir rend les monades difficiles à composer. Si nous essayons de construire une double liaison

(>>>>==) :: (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 ???

nous arrivons jusqu'ici, mais maintenant nos couches sont toutes mélangées. Nous avons un n (m (n t)), donc nous devons nous débarrasser de l'extérieur n. Comme le dit Alexandre C, nous pouvons le faire si nous avons un

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

permuter l' nintérieur et joinlui à l'autre n.

La `` double application '' plus faible est beaucoup plus facile à 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 sortir avec la structure de calcul rigide qui Applicativeprend en charge.

Notez, en passant, que bien que composer des monades soit difficile, cela peut être plus que ce dont vous avez besoin. Le type m (n v)indique le calcul avec m-effects, puis le calcul avec n-effects à une v-value, où les m-effects se terminent avant le ndébut des -effects (d'où la nécessité de swap). Si vous voulez juste entrelacer m-effets avec n-effects, alors la composition est peut-être trop demander!

Les applicatifs composent, les monades non.

Monades font Compose, mais le résultat peut - être pas une monade. En revanche, la composition de deux applicatifs est forcément un applicatif. Je soupçonne que l'intention de la déclaration originale était que «l'applicitation compose, tandis que la monadisme ne le fait pas». Reformulé, « Applicativeest fermé sous la composition, et Monadn'est pas».

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

Par contre, si vous avez des monades M1et que M2le type data M3 a = M3 (M1 (M2 a))n'est pas forcément une monade (il n'y a pas d'implémentation générique sensée pour >>=ou joinpour la composition).

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

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

Et cela se généralise à tout applicatif:

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

Mais il n'y a pas de définition sensée de

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

Si vous n'êtes pas convaincu de cela, considérez cette expression:

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

La longueur de la liste retournée doit être définie dans la pierre avant qu'un entier ne soit fourni, mais la longueur correcte de celle-ci dépend de l'entier fourni. Ainsi, aucune joinfonction correcte ne peut exister pour ce type.

Malheureusement, notre véritable objectif, la composition de monades, est un peu plus difficile. .. En fait, nous pouvons en fait prouver que, dans un certain sens, il n'y a aucun moyen de construire une fonction de jointure avec le type ci-dessus en utilisant uniquement les opérations des deux monades (voir l'annexe pour un aperçu de la preuve). Il s'ensuit que la seule façon dont nous pourrions espérer former une composition est s'il existe des constructions supplémentaires reliant les deux composants.

Composer des monades, http://web.cecs.pdx.edu/~mpj/pubs/RR-1004.pdf

La solution de loi distributive l: MN -> NM suffit

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

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

Cela ne garantit pas que MN est une monade.

L'observation cruciale entre cependant en jeu lorsque vous avez des solutions de droit de la distribution

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 suffisamment de structure pour créer ces cartes. Cependant, comme l' observe Eugenia Cheng , nous avons besoin d'une condition hexagonale (qui équivaut à une présentation de l'équation de Yang-Baxter) pour garantir la monadicité de l'une ou l'autre construction. En fait, avec la condition hexagonale, les deux monades différentes coïncident.