Wer hat zuerst folgendes gesagt?
Eine Monade ist nur ein Monoid in der Kategorie der Endofunktoren. Was ist das Problem?
Und in einem weniger wichtigen Punkt, ist dies wahr und wenn ja, könnten Sie eine Erklärung geben (hoffentlich eine, die von jemandem verstanden werden kann, der nicht viel Erfahrung mit Haskell hat)?
haskell
monads
category-theory
monoids
Roman A. Taycher
quelle
quelle
Antworten:
Diese spezielle Formulierung stammt von James Iry aus seiner höchst unterhaltsamen kurzen, unvollständigen und meist falschen Geschichte der Programmiersprachen , in der er sie fiktiv Philip Wadler zuschreibt.
Das Originalzitat stammt von Saunders Mac Lane in Categories for the Working Mathematician , einem der Grundlagentexte der Kategorietheorie. Hier ist es im Kontext , was wahrscheinlich der beste Ort ist, um genau zu lernen, was es bedeutet.
Aber ich werde einen Stich machen. Der ursprüngliche Satz lautet:
X hier ist eine Kategorie. Endofunktoren sind Funktoren von einer Kategorie zu sich selbst (was für funktionale Programmierer normalerweise alles ist
Functor
, da es sich meistens nur um eine Kategorie handelt; die Kategorie der Typen - aber ich schweife ab). Sie können sich aber auch eine andere Kategorie vorstellen, nämlich die Kategorie "Endofunktoren auf X ". Dies ist eine Kategorie, in der die Objekte Endofunktoren und die Morphismen natürliche Transformationen sind.Und von diesen Endofunktoren könnten einige Monaden sein. Welche sind Monaden? Genau diejenigen, die in einem bestimmten Sinne monoidal sind . Anstatt die genaue Zuordnung von Monaden zu Monoiden zu formulieren (da Mac Lane dies weitaus besser macht, als ich es mir erhoffen könnte), werde ich einfach ihre jeweiligen Definitionen nebeneinander stellen und Sie vergleichen lassen:
Ein Monoid ist ...
... diese Gesetze erfüllen:
Eine Monade ist ...
* -> *
mit einerFunctor
Instanz)join
in Haskell).return
in Haskell)... diese Gesetze erfüllen:
Mit ein wenig Schielen können Sie möglicherweise erkennen, dass beide Definitionen Instanzen desselben abstrakten Konzepts sind .
quelle
S
es sich um einen Typ handelt, beim Schreiben einer Funktionf :: () -> S
nur einen bestimmten Typbegriff auswählen könnenS
(ein "Element" davon, wenn Sie so wollen) und zurückkehren it ... Sie haben mit dem Argument keine wirklichen Informationen erhalten, daher gibt es keine Möglichkeit, das Verhalten der Funktion zu variieren. Esf
muss also eine konstante Funktion sein, die jedes Mal dasselbe zurückgibt.()
("Einheit") ist das Endobjekt der Kategorie Hask , und es ist kein Zufall, dass es genau 1 (nicht divergierenden) Wert gibt, der es bewohnt.Intuitiv denke ich, dass das ausgefallene Mathematikvokabular Folgendes sagt:
Monoid
Ein Monoid ist eine Menge von Objekten und eine Methode, sie zu kombinieren. Bekannte Monoide sind:
Es gibt auch komplexere Beispiele.
Außerdem hat jedes Monoid eine Identität , dh das "No-Op" -Element, das keine Wirkung hat, wenn Sie es mit etwas anderem kombinieren:
Schließlich muss ein Monoid sein assoziativ sein . (Sie können eine lange Folge von Kombinationen beliebig reduzieren, solange Sie die Reihenfolge der Objekte von links nach rechts nicht ändern.) Die Addition ist OK ((5 + 3) +1 == 5+ (3+) 1)), aber Subtraktion ist nicht ((5-3) -1! = 5- (3-1)).
Monade
Betrachten wir nun eine spezielle Art von Menge und eine spezielle Art, Objekte zu kombinieren.
Objekte
Angenommen, Ihr Set enthält Objekte einer besonderen Art: Funktionen . Und diese Funktionen haben eine interessante Signatur: Sie tragen keine Zahlen zu Zahlen oder Zeichenfolgen zu Zeichenfolgen. Stattdessen überträgt jede Funktion in einem zweistufigen Prozess eine Nummer in eine Liste von Nummern.
Beispiele:
Objekte kombinieren
Auch unsere Art, Funktionen zu kombinieren, ist etwas Besonderes. Eine einfache Möglichkeit, Funktionen zu kombinieren, ist die Komposition : Nehmen wir unsere obigen Beispiele und komponieren jede Funktion mit sich selbst:
Ohne sich zu sehr mit der Typentheorie zu befassen, besteht der Punkt darin, dass Sie zwei Ganzzahlen kombinieren können, um eine Ganzzahl zu erhalten, aber Sie können nicht immer zwei Funktionen zusammensetzen und eine Funktion desselben Typs erhalten. (Funktionen mit Typ a -> a werden komponiert, a-> [a] jedoch nicht.)
Definieren wir also eine andere Art, Funktionen zu kombinieren. Wenn wir zwei dieser Funktionen kombinieren, möchten wir die Ergebnisse nicht doppelt umbrechen.
Hier ist was wir tun. Wenn wir zwei Funktionen F und G kombinieren wollen, folgen wir diesem Prozess ( Bindung genannt ):
Zurück zu unseren Beispielen: Kombinieren (binden) wir eine Funktion mit sich selbst, indem wir diese neue Art der "Bindung" von Funktionen verwenden:
Diese ausgefeiltere Art, Funktionen zu kombinieren, ist assoziativ (nach der Assoziationszusammensetzung, wenn Sie nicht das ausgefallene Wrapping-Zeug machen).
Alles zusammenbinden,
Anmerkungen
Es gibt viele Möglichkeiten, Ergebnisse zu "verpacken". Sie können eine Liste oder einen Satz erstellen oder alle bis auf das erste Ergebnis verwerfen, während Sie feststellen, ob keine Ergebnisse vorliegen, einen Seitenwagen mit Status anhängen, eine Protokollnachricht drucken usw. usw.
Ich habe ein bisschen locker mit den Definitionen gespielt, in der Hoffnung, die wesentliche Idee intuitiv zu vermitteln.
Ich habe die Dinge ein wenig vereinfacht, indem ich darauf bestanden habe, dass unsere Monade Funktionen vom Typ a -> [a] ausführt . Tatsächlich arbeiten Monaden an Funktionen vom Typ a -> mb , aber die Verallgemeinerung ist eine Art technisches Detail, das nicht die Haupterkenntnis ist.
quelle
a -> [b]
undc -> [d]
(Sie können dies nur tun, wennb
=c
), beschreibt dies kein Monoid. Es ist eigentlich die von Ihnen beschriebene Abflachungsoperation und nicht die Funktionszusammensetzung, die der "Monoidoperator" ist.a -> [a]
, wäre dies ein Monoid (da Sie die Kleisli-Kategorie auf ein einzelnes Objekt und jede Kategorie von nur einem Objekt reduzieren würden ist per Definition ein Monoid!), aber es würde nicht die volle Allgemeinheit der Monade erfassen.Zunächst die Erweiterungen und Bibliotheken, die wir verwenden werden:
Von diesen
RankNTypes
ist die einzige, die für das Folgende absolut notwendig ist. Ich habe einmal eine Erklärung dafür geschrieben,RankNTypes
dass einige Leute es nützlich gefunden haben , also werde ich darauf verweisen.Wir zitieren Tom Crocketts ausgezeichnete Antwort und haben:
Wie übersetzen wir das in Haskell-Code? Beginnen wir mit der Vorstellung einer natürlichen Transformation :
Ein Typ der Form
f :-> g
ist analog zu einem Funktionstyp, aber anstatt ihn als eine Funktion zwischen zwei Typen (von Art*
) zu betrachten, betrachten Sie ihn als einen Morphismus zwischen zwei Funktoren (jeder Art* -> *
). Beispiele:Grundsätzlich sind in Haskell natürliche Transformationen Funktionen von einem Typ
f x
zu einem anderen Typ,g x
so dass diex
Typvariable für den Aufrufer "unzugänglich" ist. So kann zum Beispielsort :: Ord a => [a] -> [a]
nicht zu einer natürlichen Transformation gemacht werden, weil es "wählerisch" ist, für welche Typen wir instanziieren könnena
. Eine intuitive Art, wie ich oft daran denke, ist die folgende:Lassen Sie uns nun, da dies nicht im Weg ist, die Klauseln der Definition angehen.
Die erste Klausel ist "ein Endofunktor, T: X -> X. " Nun, jeder
Functor
in Haskell ist ein Endofunktor in der sogenannten "Hask-Kategorie", deren Objekte Haskell-Typen (von Art*
) und deren Morphismen Haskell-Funktionen sind. Das klingt nach einer komplizierten Aussage, ist aber eigentlich eine sehr triviale. Alles was es bedeutet ist, dass aFunctor f :: * -> *
Ihnen die Möglichkeit gibt, einen Typf a :: *
für jedena :: *
und eine Funktionfmap f :: f a -> f b
aus jedem zu konstruierenf :: a -> b
, und dass diese den Funktorgesetzen gehorchen.Zweite Klausel: Der
Identity
Funktor in Haskell (der mit der Plattform geliefert wird, sodass Sie ihn einfach importieren können) wird folgendermaßen definiert:Die natürliche Transformation η: I -> T aus Tom Crocketts Definition kann also für jeden
Monad
Fall so geschrieben werdent
:Dritte Klausel: Die Zusammensetzung von zwei Funktoren in Haskell kann folgendermaßen definiert werden (was auch mit der Plattform geliefert wird):
Die natürliche Transformation μ: T × T -> T aus Tom Crocketts Definition kann also folgendermaßen geschrieben werden:
Die Aussage, dass dies ein Monoid in der Kategorie der Endofunktoren ist, bedeutet dann, dass
Compose
(teilweise nur auf die ersten beiden Parameter angewendet) assoziativ ist und dass diesIdentity
sein Identitätselement ist. Das heißt, dass die folgenden Isomorphismen gelten:Compose f (Compose g h) ~= Compose (Compose f g) h
Compose f Identity ~= f
Compose Identity g ~= g
Diese sind sehr leicht zu beweisen , da
Compose
undIdentity
beide definiert alsnewtype
und die Haskell Reports definieren die Semantiknewtype
als ein Isomorphismus zwischen dem Typ definiert ist und den Typ des Arguments an dienewtype
‚s Daten Konstruktor. Lassen Sie uns zum Beispiel beweisenCompose f Identity ~= f
:quelle
Natural
Newtype kann ich nicht herausfinden, was die(Functor f, Functor g)
Einschränkung bewirkt . Könntest du erklären?Functor
Einschränkungen entfernt , da sie nicht notwendig erscheinen. Wenn Sie nicht einverstanden sind, können Sie sie wieder hinzufügen.join
definiert ist, wenn es definiert ist. Und dasjoin
ist der Projektionsmorphismus. Aber ich bin mir nicht sicher.Hinweis: Nein, das stimmt nicht. Irgendwann gab es einen Kommentar zu dieser Antwort von Dan Piponi selbst, der sagte, dass Ursache und Wirkung hier genau das Gegenteil waren, dass er seinen Artikel als Antwort auf James Irys Scherz schrieb. Aber es scheint entfernt worden zu sein, vielleicht durch einen zwanghaften Aufräumer.
Unten ist meine ursprüngliche Antwort.
Es ist gut möglich, dass Iry gelesen hat From Monoids to Monads , einen Beitrag, in dem Dan Piponi (sigfpe) Monaden von Monoids in Haskell ableitet, mit viel Diskussion über Kategorietheorie und expliziter Erwähnung von "der Kategorie der Endofunktoren auf Hask ". In jedem Fall könnte jeder, der sich fragt, was es für eine Monade bedeutet, ein Monoid in der Kategorie der Endofunktoren zu sein, davon profitieren, diese Ableitung zu lesen.
quelle
:-)
.Ich bin zu diesem Beitrag gekommen, um die Schlussfolgerung des berüchtigten Zitats aus Mac Lanes Kategorietheorie für den Arbeitsmathematiker besser zu verstehen .
Bei der Beschreibung, was etwas ist, ist es oft gleichermaßen nützlich, zu beschreiben, was es nicht ist.
Die Tatsache, dass Mac Lane die Beschreibung verwendet, um eine Monade zu beschreiben, könnte bedeuten, dass sie etwas Einzigartiges für Monaden beschreibt. Trage es mit mir. Um ein breiteres Verständnis der Aussage zu entwickeln, muss meines Erachtens klargestellt werden, dass er nicht etwas beschreibt, das nur für Monaden gilt. Die Aussage beschreibt unter anderem Applicative und Arrows gleichermaßen. Aus dem gleichen Grund können wir zwei Monoide auf Int (Summe und Produkt) haben, wir können mehrere Monoide auf X in der Kategorie der Endofunktoren haben. Aber die Ähnlichkeiten haben noch mehr zu bieten.
Sowohl Monad als auch Applicative erfüllen die Kriterien:
(zB Tag für Tag
Tree a -> List b
, aber in KategorieTree -> List
)Tree -> List
nur habenList -> List
.Die Anweisung verwendet "Kategorie von ...". Dies definiert den Umfang der Anweisung. Als Beispiel beschreibt die Funktorkategorie den Umfang
f * -> g *
, das heißtAny functor -> Any functor
, zum BeispielTree * -> List *
oderTree * -> Tree *
.Was eine kategoriale Aussage nicht spezifiziert, beschreibt, wo alles und jedes erlaubt ist .
In diesem Fall ist innerhalb der Funktoren
* -> *
akaa -> b
nicht angegeben, was bedeutetAnything -> Anything including Anything else
. Wenn meine Fantasie zu Int -> String springt, schließt es auch einInteger -> Maybe Int
oder sogarMaybe Double -> Either String Int
woa :: Maybe Double; b :: Either String Int
.Die Aussage lautet also wie folgt:
:: f a -> g b
(dh ein beliebiger parametrisierter Typ zu einem beliebigen parametrisierten Typ):: f a -> f b
(dh jeder parametrisierte Typ zum gleichen parametrisierten Typ) ... anders gesagt,Wo liegt also die Kraft dieses Konstrukts? Um die volle Dynamik zu erkennen, musste ich sehen, dass die typischen Zeichnungen eines Monoids (einzelnes Objekt mit einem Identitätspfeil
:: single object -> single object
) nicht veranschaulichen, dass ich einen Pfeil verwenden darf, der mit einer beliebigen Anzahl von Monoidwerten parametrisiert ist. von dem einem Typ Objekt erlaubte in Monoid. Die endo, ~ Identität Pfeil Definition der Gleichwertigkeit ignoriert die von Funktors Typwert und sowohl die Art und den Wert der innersten „Nutzlast“ Schicht. Somit kehrt die Äquivalenztrue
in jeder Situation zurück, in der die Funktionstypen übereinstimmen (z. B.Nothing -> Just * -> Nothing
ist äquivalent zu,Just * -> Just * -> Just *
weil sie beide sindMaybe -> Maybe -> Maybe
).Seitenleiste: ~ außerhalb ist konzeptionell, aber das Symbol ganz links in
f a
. Es beschreibt auch, was "Haskell" zuerst einliest (großes Bild); Typ ist also "außerhalb" in Bezug auf einen Typwert. Die Beziehung zwischen Ebenen (einer Referenzkette) bei der Programmierung ist in der Kategorie nicht einfach zu beschreiben. Die Kategorie des Satzes wird verwendet, um Typen (Int, Strings, Vielleicht Int usw.) zu beschreiben, die die Kategorie des Funktors (parametrisierte Typen) enthalten. Die Referenzkette: Funktortyp, Funktorwerte (Elemente des Funktorsatzes, z. B. Nothing, Just) und alles andere, auf das jeder Funktorwert verweist. In der Kategorie wird die Beziehung anders beschrieben, z. B.return :: a -> m a
wird sie als natürliche Transformation von einem Funktor zu einem anderen Funktor angesehen, anders als alles, was bisher erwähnt wurde.Zurück zum Hauptthema: Alles in allem beschreibt die Aussage für jedes definierte Tensorprodukt und einen neutralen Wert ein erstaunlich leistungsfähiges Rechenkonstrukt, das aus seiner paradoxen Struktur hervorgeht:
:: List
); statischfold
das sagt nichts über die Nutzlast aus)In Haskell ist es wichtig, die Anwendbarkeit der Aussage zu klären. Die Kraft und Vielseitigkeit dieses Konstrukts hat absolut nichts mit einer Monade an sich zu tun . Mit anderen Worten, das Konstrukt beruht nicht darauf, was eine Monade einzigartig macht.
Bei dem Versuch herauszufinden, ob Code mit einem gemeinsamen Kontext erstellt werden soll, um voneinander abhängige Berechnungen zu unterstützen, im Vergleich zu Berechnungen, die parallel ausgeführt werden können, ist diese berüchtigte Aussage, so viel sie beschreibt, kein Kontrast zwischen der Wahl von Anwendbar, Pfeile und Monaden, sondern beschreibt, wie sehr sie gleich sind. Für die vorliegende Entscheidung ist die Aussage umstritten.
Dies wird oft missverstanden. In der Erklärung wird
join :: m (m a) -> m a
das Tensorprodukt für den monoidalen Endofunktor beschrieben. Es wird jedoch nicht dargelegt, wie im Rahmen dieser Aussage(<*>)
auch auch gewählt werden könnte. Es ist wirklich ein Beispiel für sechs / ein halbes Dutzend. Die Logik zum Kombinieren von Werten ist genau gleich. Dieselbe Eingabe generiert jeweils die gleiche Ausgabe (im Gegensatz zu den Summen- und Produktmonoiden für Int, da sie beim Kombinieren von Ints unterschiedliche Ergebnisse erzeugen).Um es noch einmal zusammenzufassen: Ein Monoid in der Kategorie der Endofunktoren beschreibt:
(<*>)
und(>>=)
beide bieten gleichzeitigen Zugriff auf die beidenm
Werte, um den einzelnen Rückgabewert zu berechnen. Die zur Berechnung des Rückgabewerts verwendete Logik ist genau dieselbe. Ohne die unterschiedlichen Formen der Funktionen, die sie parametrisieren (f :: a -> b
versusk :: a -> m b
), und die Position des Parameters mit dem gleichen Rückgabetyp der Berechnung (dha -> b -> b
versusb -> a -> b
für jeden), hätten wir vermutlich die monoidale Logik parametrisieren können, die Tensorprodukt zur Wiederverwendung in beiden Definitionen. Versuchen~t
Sie als Übung, den Punkt zu verdeutlichen, ihn umzusetzen , und Sie erhalten(<*>)
und(>>=)
hängen davon ab, wie Sie ihn definierenforall a b
.Wenn mein letzter Punkt konzeptionell mindestens wahr ist, erklärt er den genauen und einzigen rechnerischen Unterschied zwischen Applikativ und Monade: die Funktionen, die sie parametrisieren. Mit anderen Worten, der Unterschied liegt außerhalb der Implementierung dieser Typklassen.
Nach meiner eigenen Erfahrung lieferte Mac Lanes berüchtigtes Zitat ein großartiges "goto" -Mem, ein Wegweiser, auf den ich mich beim Navigieren durch die Kategorie beziehen konnte, um die in Haskell verwendeten Redewendungen besser zu verstehen. Es gelingt ihm, den Umfang einer leistungsstarken Rechenkapazität zu erfassen, die in Haskell wunderbar zugänglich gemacht wird.
Es ist jedoch ironisch, wie ich die Anwendbarkeit der Aussage außerhalb der Monade zum ersten Mal missverstanden habe und was ich hoffe, hier vermittelt zu werden. Alles, was es beschreibt, stellt sich als ähnlich zwischen Applikativ und Monaden (und Pfeilen unter anderem) heraus. Was es nicht sagt, ist genau die kleine, aber nützliche Unterscheidung zwischen ihnen.
- E.
quelle
Die Antworten hier leisten hervorragende Arbeit bei der Definition von Monoiden und Monaden, scheinen jedoch die Frage immer noch nicht zu beantworten:
Der Kern der Sache, die hier fehlt, ist der andere Begriff des "Monoids", genauer gesagt die sogenannte Kategorisierung - die des Monoids in einer monoidalen Kategorie. Leider macht Mac Lanes Buch selbst es sehr verwirrend :
Hauptverwirrung
Warum ist das verwirrend? Weil es nicht definiert, was "Monoid in der Kategorie der Endofunktoren" von ist
X
. Stattdessen schlägt dieser Satz vor, ein Monoid innerhalb der Menge aller Endofunktoren zusammen mit der Funktorkomposition als binäre Operation und dem Identitätsfunktor als monoidale Einheit zu nehmen. Das funktioniert einwandfrei und verwandelt sich in ein Monoid jeder Untergruppe von Endofunktoren, die den Identitätsfunktor enthält und unter Funktorkomposition geschlossen ist.Dies ist jedoch nicht die richtige Interpretation, die das Buch zu diesem Zeitpunkt nicht klar macht. Eine Monade
f
ist ein fester Endofunktor, keine Teilmenge von Endofunktoren, die unter Zusammensetzung geschlossen sind. Eine übliche Konstruktion besteht darinf
, ein Monoid zu erzeugen, indem der Satz allerk
Kompositionenf^k = f(f(...))
vonf
sich genommen wird, einschließlichk=0
derjenigen, die der Identität entsprechenf^0 = id
. Und jetzt ist die MengeS
all dieser Kräfte für allek>=0
in der Tat ein Monoid, "wobei das Produkt × durch die Zusammensetzung der Endofunktoren und die vom Identitätsendofunktor festgelegte Einheit ersetzt wird".Und doch:
S
kann für jeden Funktorf
oder sogar wörtlich für jede Selbstkarte von definiert werdenX
. Es ist das Monoid, das von erzeugt wirdf
.S
der Funktorkomposition und des Identitätsfunktors hat nichts damit zu tunf
, eine Monade zu sein oder nicht.Und um die Sache noch verwirrender zu machen, wird die Definition von "Monoid in monoidaler Kategorie" später in diesem Buch veröffentlicht, wie Sie dem Inhaltsverzeichnis entnehmen können . Das Verständnis dieser Vorstellung ist jedoch absolut entscheidend für das Verständnis der Verbindung mit Monaden.
(Strenge) monoidale Kategorien
Wenn wir zu Kapitel VII über Monoide gehen (das später als Kapitel VI über Monaden erscheint), finden wir die Definition der sogenannten strengen monoidalen Kategorie als dreifach
(B, *, e)
, wobeiB
eine Kategorie,*: B x B-> B
ein Bifunktor (Funktor in Bezug auf jede Komponente mit einer anderen festen Komponente) ist ) unde
ist ein Einheitsobjekt inB
, das die Assoziativitäts- und Einheitsgesetze erfüllt:für alle Objekte
a,b,c
ausB
, und die gleichen Identitäten für alle Morphismena,b,c
mite
Fassungid_e
, die Identität Morphismuse
. Es ist jetztB
aufschlussreich zu beobachten, dass in unserem Fall von Interesse, wo sich die Kategorie der EndofunktorenX
mit natürlichen Transformationen als Morphismen,*
die Funktorkomposition unde
der Identitätsfunktor befindet, alle diese Gesetze erfüllt sind, wie direkt überprüft werden kann.Was im Buch folgt, ist die Definition der "entspannten" monoidalen Kategorie , in der die Gesetze nur einige feste natürliche Transformationen modulo enthalten , die sogenannte Kohärenzbeziehungen erfüllen , was jedoch für unsere Fälle der Endofunktorkategorien nicht wichtig ist.
Monoide in monoidalen Kategorien
Schließlich wird in Abschnitt 3 "Monoide" von Kapitel VII die tatsächliche Definition gegeben:
3 Diagramme kommutativ machen. Denken Sie daran, dass es sich in unserem Fall um Morphismen in der Kategorie der Endofunktoren handelt, bei denen es sich um natürliche Transformationen handelt, die genau
join
undreturn
für eine Monade entsprechen. Die Verbindung wird noch deutlicher, wenn wir die Komposition deutlicher machen*
undc * c
durch ersetzenc^2
, woc
sich unsere Monade befindet.Beachten Sie schließlich, dass die 3 kommutativen Diagramme (in der Definition eines Monoids in einer monoidalen Kategorie) für allgemeine (nicht strenge) monoidale Kategorien geschrieben sind, während in unserem Fall alle natürlichen Transformationen, die als Teil der monoidalen Kategorie auftreten, tatsächlich Identitäten sind. Dadurch sind die Diagramme genau die gleichen wie in der Definition einer Monade, wodurch die Korrespondenz vollständig wird.
Fazit
Zusammenfassend ist jede Monade per Definition ein Endofunktor, daher ein Objekt in der Kategorie der Endofunktoren, wobei die Monade
join
und diereturn
Operatoren die Definition eines Monoids in dieser bestimmten (strengen) monoidalen Kategorie erfüllen . Umgekehrt ist jedes Monoid in der monoidalen Kategorie der Endofunktoren per Definition ein Tripel,(c, mu, nu)
das aus einem Objekt und zwei Pfeilen besteht, z. B. natürlichen Transformationen in unserem Fall, die die gleichen Gesetze wie eine Monade erfüllen.Beachten Sie schließlich den Hauptunterschied zwischen den (klassischen) Monoiden und den allgemeineren Monoiden in monoidalen Kategorien. Die beiden Pfeile
mu
undnu
höher sind keine binäre Operation und keine Einheit in einer Menge mehr. Stattdessen haben Sie einen festen Endofunktorc
. Die Funktorkomposition*
und der Identitätsfunktor allein bieten trotz dieser verwirrenden Bemerkung im Buch nicht die vollständige Struktur, die für die Monade benötigt wird.Ein anderer Ansatz wäre, mit dem Standardmonoid
C
aller Selbstkarten einer Menge zu vergleichenA
, wobei die binäre Operation die Zusammensetzung ist, in die das kartesische Standardprodukt abgebildetC x C
werden kannC
. Beim Übergang zum kategorisierten Monoid ersetzen wir das kartesische Produktx
durch die Funktorkomposition*
, und die binäre Operation wird durch die natürliche Transformationmu
vonc * c
nach ersetztc
, dh eine Sammlung derjoin
Operatorenfür jedes Objekt
T
(Programmierung eingeben). Und die Identitätselemente in klassischen Monoiden, die mit Bildern von Karten aus einem festen Einpunktsatz identifiziert werden können, werden durch die Sammlung derreturn
Operatoren ersetztAber jetzt gibt es keine kartesischen Produkte mehr, also keine Elementpaare und somit keine binären Operationen.
quelle