Gli applicativi compongono, le monadi no

Gli applicativi compongono, le monadi no.

Cosa significa la dichiarazione di cui sopra? E quando è preferibile l'uno all'altro?

Se confrontiamo i tipi

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

abbiamo un'idea di cosa separa i due concetti. Quello (s -> m t)nel tipo di (>>=)mostra che un valore in spuò determinare il comportamento di un calcolo in m t. Le monadi consentono l'interferenza tra il valore e gli strati di calcolo. L' (<*>)operatore non consente tale interferenza: i calcoli di funzioni e argomenti non dipendono dai valori. Questo morde davvero. Confrontare

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

che utilizza il risultato di un effetto per decidere tra due calcoli (ad esempio il lancio di missili e la firma di un armistizio), mentre

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

che usa il valore di abper scegliere tra i valori di due calcoli ate af, avendoli effettuati entrambi, forse con effetto tragico.

La versione monadica si basa essenzialmente sul potere extra di (>>=)scegliere un calcolo da un valore, e questo può essere importante. Tuttavia, supportare quel potere rende le monadi difficili da comporre. Se proviamo a costruire un "doppio legame"

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

siamo arrivati ​​fin qui, ma ora i nostri strati sono tutti confusi. Abbiamo un n (m (n t)), quindi dobbiamo sbarazzarci dell'esterno n. Come dice Alexandre C, possiamo farlo se ne abbiamo uno adatto

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

permutare l' ninterno e joinquesto verso l'altro n.

La "doppia applicazione" più debole è molto più facile da definire

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

perché non c'è interferenza tra gli strati.

Di conseguenza, è bene riconoscere quando hai davvero bisogno della potenza extra di Monads e quando puoi farla franca con la rigida struttura di calcolo che Applicativesupporta.

Nota, a proposito, che sebbene comporre le monadi sia difficile, potrebbe essere più del necessario. Il tipo m (n v)indica il calcolo con m-effects, quindi il calcolo con -effects na v-value, dove gli m-effects terminano prima che ninizino gli -effects (da qui la necessità di swap). Se vuoi solo intercalare m-effetti con n-effetti, allora la composizione è forse troppo da chiedere!

Gli applicativi compongono, le monadi no.

Monadi fanno comporre, ma il risultato potrebbe non essere una monade. Al contrario, la composizione di due applicativi è necessariamente un applicativo. Sospetto che l'intenzione dell'affermazione originale fosse che "l'applicatività compone, mentre la monadità no". Riformulato, " Applicativeè chiuso in composizione, e Monadnon lo è".

Se hai applicativi A1e A2, allora il tipodata A3 a = A3 (A1 (A2 a)) è applicativo (puoi scrivere un'istanza del genere in modo generico).

D'altra parte, se si hanno le monadi M1e M2il tipo data M3 a = M3 (M1 (M2 a))non è necessariamente una monade (non esiste un'implementazione generica sensata per >>=o joinper la composizione).

Un esempio può essere il tipo [Int -> a](qui componiamo un costruttore di tipi []con (->) Int, entrambi monadi). Puoi scrivere facilmente

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

E questo generalizza a qualsiasi applicativo:

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

Ma non esiste una definizione sensata di

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

Se non sei convinto di questo, considera questa espressione:

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

La lunghezza della lista restituita deve essere impostata prima che venga fornito un numero intero, ma la sua lunghezza corretta dipende dal numero intero fornito. Pertanto, non joinpuò esistere alcuna funzione corretta per questo tipo.

Sfortunatamente, il nostro vero obiettivo, la composizione delle monadi, è piuttosto più difficile. .. In effetti, possiamo effettivamente dimostrare che, in un certo senso, non c'è modo di costruire una funzione di join con il tipo precedente usando solo le operazioni delle due monadi (vedi l'appendice per uno schema della dimostrazione). Ne consegue che l'unico modo in cui potremmo sperare di formare una composizione è se ci sono alcune costruzioni aggiuntive che collegano i due componenti.

Composizione di monadi, http://web.cecs.pdx.edu/~mpj/pubs/RR-1004.pdf

La soluzione di legge distributiva l: MN -> NM è sufficiente

per garantire la monadicità di NM. Per vederlo hai bisogno di un'unità e di un mult. Mi concentrerò sul mult (l'unità è unit_N unitM)

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

Ciò non garantisce che MN sia una monade.

L'osservazione cruciale, tuttavia, entra in gioco quando si hanno soluzioni di diritto distributivo

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

quindi, LM, LN e MN sono monadi. Sorge la domanda se LMN sia una monade (o di

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

Abbiamo una struttura sufficiente per creare queste mappe. Tuttavia, come osserva Eugenia Cheng , abbiamo bisogno di una condizione esagonale (che equivale a una presentazione dell'equazione di Yang-Baxter) per garantire la monadicità di entrambe le costruzioni. Infatti, con la condizione esagonale, le due diverse monadi coincidono.