Los candidatos componen, las mónadas no

Los candidatos componen, las mónadas no.

¿Qué significa la declaración anterior? ¿Y cuándo es preferible uno a otro?

Si comparamos los tipos

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

tenemos una pista de lo que separa los dos conceptos. Que (s -> m t)en el tipo de (>>=)muestra que un valor en spuede determinar el comportamiento de un cálculo en m t. Las mónadas permiten la interferencia entre las capas de valor y de cálculo. El (<*>)operador no permite tal interferencia: los cálculos de la función y el argumento no dependen de los valores. Esto realmente muerde. Comparar

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

que utiliza el resultado de algún efecto para decidir entre dos cálculos (por ejemplo, lanzar misiles y firmar un armisticio), mientras 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

que utiliza el valor de abpara elegir entre los valores de dos cálculos aty af, habiendo realizado ambos, quizás con efecto trágico.

La versión monádica se basa esencialmente en el poder adicional de (>>=)elegir un cálculo a partir de un valor, y eso puede ser importante. Sin embargo, apoyar ese poder hace que las mónadas sean difíciles de componer. Si intentamos construir 'doble vínculo'

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

llegamos hasta aquí, pero ahora nuestras capas están revueltas. Tenemos un n (m (n t)), así que tenemos que deshacernos del exterior n. Como dice Alexandre C, podemos hacer eso si tenemos un

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

permutar el ninterior y joinel otro n.

La 'doble aplicación' más débil es mucho más fácil de definir

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

porque no hay interferencia entre las capas.

En consecuencia, es bueno reconocer cuándo realmente necesita la potencia adicional de Monads, y cuándo puede salirse con la suya con la rígida estructura de cálculo que Applicativeadmite.

Tenga en cuenta, por cierto, que aunque componer mónadas es difícil, puede ser más de lo que necesita. El tipo m (n v)indica computación con m-effects, luego computación con n-effects a un v-valor, donde los m-effects terminan antes de que ncomiencen los -effects (de ahí la necesidad de swap). Si solo desea intercalar m-efectos con n-efectos, entonces la composición es quizás demasiado pedir.

Los candidatos componen, las mónadas no.

Mónadas hacen componer, pero el resultado podría no ser una mónada. Por el contrario, la composición de dos aplicativos es necesariamente un aplicativo. Sospecho que la intención de la declaración original era que "la aplicabilidad compone, mientras que la mónada no". Reformulado, " Applicativeestá cerrado bajo composición y Monadno lo es".

Si tiene aplicativos A1y A2, entonces el tipo data A3 a = A3 (A1 (A2 a))también es aplicativo (puede escribir tal instancia de forma genérica).

Por otro lado, si usted tiene mónadas M1y M2entonces el tipo data M3 a = M3 (M1 (M2 a))no es necesariamente una mónada (no hay una implementación genérica sensato >>=o joinde la composición).

Un ejemplo puede ser el tipo [Int -> a](aquí componimos un constructor de tipos []con (->) Int, los cuales son mónadas). Puedes escribir fácilmente

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

Y eso se generaliza a cualquier aplicativo:

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

Pero no existe una definición sensata de

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

Si no está convencido de esto, considere esta expresión:

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

La longitud de la lista devuelta se debe establecer en piedra antes de que se proporcione un número entero, pero la longitud correcta depende del número entero que se proporcione. Por tanto, no joinpuede existir una función correcta para este tipo.

Desafortunadamente, nuestro objetivo real, la composición de mónadas, es bastante más difícil. .. De hecho, podemos probar que, en cierto sentido, no hay forma de construir una función de unión con el tipo anterior usando solo las operaciones de las dos mónadas (ver el apéndice para un esquema de la demostración). De ello se deduce que la única forma en que podríamos esperar formar una composición es si hay algunas construcciones adicionales que unan los dos componentes.

Composición de mónadas, http://web.cecs.pdx.edu/~mpj/pubs/RR-1004.pdf

La solución de la ley distributiva l: MN -> NM es suficiente

para garantizar la monadicidad de NM. Para ver esto necesitas una unidad y un mult. Me enfocaré en el mult (la unidad es unit_N unitM)

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

Esto no garantiza que MN sea una mónada.

Sin embargo, la observación crucial entra en juego cuando tiene soluciones de ley distributiva

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

por tanto, LM, LN y MN son mónadas. Surge la pregunta de si LMN es una mónada (ya sea por

(MN) L -> L (MN) o por N (LM) -> (LM) N

Tenemos suficiente estructura para hacer estos mapas. Sin embargo, como observa Eugenia Cheng , necesitamos una condición hexagonal (que equivale a una presentación de la ecuación de Yang-Baxter) para garantizar la monadicidad de cualquier construcción. De hecho, con la condición hexagonal, las dos mónadas diferentes coinciden.