Os candidatos compõem, as mônadas não

Os candidatos compõem, as mônadas não.

O que significa a afirmação acima? E quando um é preferível ao outro?

Se compararmos os tipos

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

temos uma pista do que separa os dois conceitos. Isso (s -> m t)no tipo de (>>=)mostra que um valor em spode determinar o comportamento de um cálculo em m t. Mônadas permitem interferência entre as camadas de valor e computação. O (<*>)operador não permite essa interferência: os cálculos da função e do argumento não dependem de valores. Isso realmente incomoda. 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 usa o resultado de algum efeito para decidir entre dois cálculos (por exemplo, lançar mísseis e assinar um armistício), enquanto

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 usa o valor de abpara escolher entre os valores de dois cálculos ate af, tendo realizado ambos, talvez com efeito trágico.

A versão monádica depende essencialmente do poder extra de (>>=)escolher um cálculo a partir de um valor, e isso pode ser importante. No entanto, apoiar esse poder torna as mônadas difíceis de compor. Se tentarmos construir '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 ???

chegamos até aqui, mas agora nossas camadas estão todas misturadas. Temos um n (m (n t)), então precisamos nos livrar do exterior n. Como diz Alexandre C, podemos fazer isso se tivermos um adequado

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

permutar o ninterior e joino outro n.

O mais fraco 'dupla aplicação' é muito mais fácil de definir

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

porque não há interferência entre as camadas.

Da mesma forma, é bom reconhecer quando você realmente precisa da potência extra de Monads e quando pode se safar com a estrutura de computação rígida que o Applicativesuporta.

Observe, a propósito, que embora compor mônadas seja difícil, pode ser mais do que você precisa. O tipo m (n v)indica computação com m-effects e, em seguida, computação com n-effects para um -value v, em que m-effects termina antes de n-effects iniciar (daí a necessidade de swap). Se você deseja apenas intercalar m-effects com n-effects, então composição talvez seja pedir demais!

Os candidatos compõem, as mônadas não.

Mônadas fazer compor, mas o resultado pode não ser uma mônada. Em contraste, a composição de dois aplicativos é necessariamente um aplicativo. Suspeito que a intenção da declaração original era que "A aplicatividade compõe, enquanto a monadilidade não". Reformulado, " Applicativeestá fechado na composição, e Monadnão está."

Se você tiver aplicativos A1e A2, o tipo data A3 a = A3 (A1 (A2 a))também será aplicativo (você pode escrever uma instância desse tipo de forma genérica).

Por outro lado, se você tiver mônadas M1e M2o tipo data M3 a = M3 (M1 (M2 a))não for necessariamente uma mônada (não há implementação genérica sensata para >>=ou joinpara a composição).

Um exemplo pode ser o tipo [Int -> a](aqui compomos um construtor de tipo []com (->) Int, ambos os quais são mônadas). Você pode escrever facilmente

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

E isso se generaliza para qualquer aplicativo:

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

Mas não há uma definição sensata de

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

Se você não está convencido disso, considere esta expressão:

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

O comprimento da lista retornada deve ser definido em pedra antes que um inteiro seja fornecido, mas o comprimento correto dela depende do inteiro fornecido. Portanto, nenhuma joinfunção correta pode existir para este tipo.

Infelizmente, nosso objetivo real, a composição de mônadas, é bem mais difícil. .. De fato, podemos realmente provar que, em certo sentido, não há como construir uma função de junção com o tipo acima usando apenas as operações das duas mônadas (veja o apêndice para um esboço da prova). Segue-se que a única maneira pela qual podemos esperar formar uma composição é se houver algumas construções adicionais ligando os dois componentes.

Compondo mônadas, http://web.cecs.pdx.edu/~mpj/pubs/RR-1004.pdf

A solução de lei distributiva l: MN -> NM é suficiente

para garantir a monadicidade do NM. Para ver isso você precisa de uma unidade e um mult. Vou me concentrar no mult (a unidade é unit_N unitM)

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

Isso não garante que o MN seja uma mônada.

A observação crucial, no entanto, entra em jogo quando você tem soluções de direito distributivo

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

assim, LM, LN e MN são mônadas. A questão que surge é se LMN é uma mônada (seja por

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

Temos estrutura suficiente para fazer esses mapas. No entanto, como Eugenia Cheng observa , precisamos de uma condição hexagonal (que equivale a uma apresentação da equação de Yang-Baxter) para garantir a monadicidade de qualquer construção. Na verdade, com a condição hexagonal, as duas mônadas diferentes coincidem.