Bewerber komponieren, Monaden nicht

Bewerber komponieren, Monaden nicht.

Was bedeutet die obige Aussage? Und wann ist einer dem anderen vorzuziehen?

Wenn wir die Typen vergleichen

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

Wir bekommen einen Hinweis darauf, was die beiden Konzepte trennt. Das (s -> m t)in der Art von (>>=)zeigt, dass ein Wert in sdas Verhalten einer Berechnung in bestimmen kann m t. Monaden ermöglichen Interferenzen zwischen der Wert- und der Berechnungsebene. Der (<*>)Operator lässt keine derartigen Störungen zu: Die Funktions- und Argumentberechnungen hängen nicht von Werten ab. Das beißt wirklich. Vergleichen Sie

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

Dabei wird das Ergebnis eines Effekts verwendet, um zwischen zwei Berechnungen zu entscheiden (z. B. Raketen abschießen und Waffenstillstand unterzeichnen)

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

Dabei wird der Wert von verwendet ab, um zwischen den Werten zweier Berechnungen atund zu wählenaf nachdem beide ausgeführt wurden, möglicherweise mit tragischer Wirkung.

Die monadische Version beruht im Wesentlichen auf der zusätzlichen (>>=)Fähigkeit, eine Berechnung aus einem Wert auszuwählen, und das kann wichtig sein. Die Unterstützung dieser Kraft macht es jedoch schwierig, Monaden zu komponieren. Wenn wir versuchen, 'Doppelbindung' zu erstellen

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

wir kommen so weit, aber jetzt sind unsere Schichten alle durcheinander. Wir haben eine n (m (n t)), also müssen wir das Äußere loswerden n. Wie Alexandre C sagt, können wir das tun, wenn wir einen geeigneten haben

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

das Innere nund joines zum anderen zu permutierenn .

Die schwächere Doppelanwendung ist viel einfacher zu definieren

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

weil es keine Interferenz zwischen den Schichten gibt.

Dementsprechend ist es gut zu erkennen, wann Sie wirklich die zusätzliche Leistung von Monads benötigen und wann Sie mit der starren Rechenstruktur davonkommen können, die Applicativeunterstützt.

Beachten Sie übrigens, dass das Komponieren von Monaden zwar schwierig ist, aber möglicherweise mehr als nötig ist. Der Typ m (n v)gibt an m, mit n-Effekten zu rechnen und dann mit -Effekten zu einem -Wert zu rechnen v, wobei die m-Effekte enden, bevor die n-Effekte beginnen (daher ist dies erforderlich swap). Wenn Sie nur m-Effekte mit n-Effekten verschachteln möchten , ist die Komposition vielleicht zu viel verlangt!

Bewerber komponieren, Monaden nicht.

Monaden tun compose, aber das Ergebnis könnte nicht eine Monade sein. Im Gegensatz dazu ist die Zusammensetzung von zwei Applikativen notwendigerweise ein Applikativ. Ich vermute, die Absicht der ursprünglichen Aussage war, dass "Anwendbarkeit komponiert, Monadität nicht". Umformuliert: "Wird Applicativeunter Komposition geschlossen und Monadnicht."

Wenn Sie Anwendungen haben A1und A2dann den Typdata A3 a = A3 (A1 (A2 a)) auch anwendbar (Sie können eine solche Instanz generisch schreiben).

Wenn Sie dagegen Monaden haben M1und M2der Typ data M3 a = M3 (M1 (M2 a))dann nicht unbedingt eine Monade ist (es gibt keine sinnvolle generische Implementierung für >>=oderjoin für die Komposition).

Ein Beispiel kann der Typ sein [Int -> a](hier erstellen wir einen Typkonstruktor, []mit dem (->) Intbeide Monaden sind). Sie können leicht schreiben

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

Und das verallgemeinert sich auf jede Anwendung:

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

Aber es gibt keine vernünftige Definition von

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

Wenn Sie davon nicht überzeugt sind, betrachten Sie diesen Ausdruck:

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

Die Länge der zurückgegebenen Liste muss in Stein gemeißelt werden, bevor jemals eine Ganzzahl angegeben wird. Die richtige Länge hängt jedoch von der bereitgestellten Ganzzahl ab. Daher joinkann für diesen Typ keine korrekte Funktion existieren.

Leider ist unser eigentliches Ziel, die Zusammensetzung der Monaden, etwas schwieriger. Tatsächlich können wir tatsächlich beweisen, dass es in gewissem Sinne keine Möglichkeit gibt, eine Verknüpfungsfunktion mit dem obigen Typ nur mit den Operationen der beiden Monaden zu konstruieren (eine Übersicht über den Beweis finden Sie im Anhang). Daraus folgt, dass wir nur hoffen können, eine Komposition zu bilden, wenn es einige zusätzliche Konstruktionen gibt, die die beiden Komponenten verbinden.

Monaden komponieren, http://web.cecs.pdx.edu/~mpj/pubs/RR-1004.pdf

Die Verteilungsgesetzlösung l: MN -> NM reicht aus

Monadizität von NM zu garantieren. Um dies zu sehen, benötigen Sie eine Einheit und ein Mult. Ich werde mich auf das Mult konzentrieren (die Einheit ist unit_N unitM)

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

Das geht nicht garantiert , dass MN eine Monade ist.

Die entscheidende Beobachtung kommt jedoch ins Spiel, wenn Sie verteilungsrechtliche Lösungen haben

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

Somit sind LM, LN und MN Monaden. Es stellt sich die Frage, ob LMN eine Monade ist (entweder von

(MN) L -> L (MN) oder durch N (LM) -> (LM) N.

Wir haben genug Struktur, um diese Karten zu erstellen. Wie Eugenia Cheng jedoch bemerkt , benötigen wir eine hexagonale Bedingung (die einer Darstellung der Yang-Baxter-Gleichung entspricht), um die Monadizität beider Konstruktionen zu gewährleisten. Tatsächlich fallen mit der hexagonalen Bedingung die zwei verschiedenen Monaden zusammen.