Kurze Erklärung zu Monaden (kurzer Blog-Artikel)

[iblech]

Ich assigne mich selbst: Werde morgen oder so ein paar kurze Zeilen zu Monaden schreiben, damit die Teilnehmenden unseres Workshops leichter die Aufgaben des letzten Kapitels bearbeiten können. (Ja, ich kenne die Monad Tutorial Fallacy.) Inhalt soll nur sein:

• Ein Wert vom Typ IO a ist eine Beschreibung einer IO-Aktion, welche durch die Laufzeitumgebung ausgeführt werden könnte (und dabei dann irgendwelche Nebenwirkungen verursachen und schließlich einen Wert vom Typ a produzieren würde).
• Der Sinn eines Haskell-Programms besteht darin, die Beschreibung einer IO-Aktion main festzulegen. Diese wird dann von der Laufzeitumgebung ausgeführt. Andere Beschreibungen werden nicht ausgeführt. Zum Beispiel wird die Auswertung von seq (putStrLn "foo") 42 nichts auf dem Bildschirm ausgeben.
• Beschreibungen von IO-Aktionen kann man mit >> und >>= bzw. do-Notation miteinander kombinieren. Beispiele für Entzuckerung. Der Operator >> ist wie ; aus anderen Sprachen.
• Wenn man nur veränderlichen Zustand möchte, benötigt man nicht IO. Man muss nur Zustand per Hand durchfädeln. Beispiel. Gründe, wieso das manuell schlecht ist. Dann Abstraktion zur State-Monade.
• Was macht eine Monade aus? Unterstützung von return und >>=. Warnung vor dem Begriff return.
• Allgemeine Kontrollstrukturen wie forever oder replicateM.

[Profpatsch]

+1

Bezeichne es aber besser nicht als Monad Tutorial, sondern vllt. eher als “IO & State Primer”, gerade wegen der Fallacy. Aber eine Definition der Typklasse und Gesetze kann bestimmt auch nicht schaden.

[iblech]

Ein Entwurf ist online. Bitte kritisiert ihn! Verbesserungsvorschläge entweder direkt commiten oder mir schreiben.

[timjb]

Du hast die Monaden super verständlich erklärt und motiviert! Zwei Kleinigkeiten:

• Für die Beschreibung der Reader-Monade finde ich "globale Konfigurationswerte" gut; in der Cont-Monade kann man den Kontrollfluss beeinflussen
• Seit GHC 7.10 (Implementierung des AMP) ist Applicative m eine Voraussetzung für Monad m. Das ist natürlich nicht so im offiziellen Haskell Standard, aber in der praktischen Definition ist Haskell ja das, was GHC implementiert.

[iblech]

• Dieselbe Reader-Metapher finde ich auch gut. Sollen wir sie noch erwähnen? Wenn ja: Nur kurz? Oder wollen wir separate Artikel über andere Monaden schreiben?
• Ja, ein Hoch aufs AMP! Sollen wir Applicative noch erwähnen? Wenn ja, stellt sich wieder dieselbe Frage. Übrigens habe ich auch fail in der Definition weggelassen.

[Profpatsch]

Übrigens habe ich auch fail in der Definition weggelassen.

fail ist wie Matrix 2 & 3. Man ignoriert es besser. :p

[timjb]

• Auf jeden Fall erwähnen (in Klammern)
• Ja, ich würde Applicative noch erwähnen, fail ebenso, aber nur kurz darauf eingehen. Eine nette Übungsaufgabe wäre, ap und liftM zu implementieren, und so zu zeigen, dass jede Monade auch ein Funktor bzw. Applicative ist.

[timjb]

Wir brauchen auch nicht über alle Einsteigerthemen selbst schreiben! Wenn es bereits einen guten (deutschen) Artikel zu einem Thema gibt, so sollten wir diesen einfach verlinken. Bei funktionale-programmierung.de gibt es etwa bereits zwei Artikel, die andere Monaden außer IO und praktische Einsatzzwecke von Monaden beschreiben.

[larsrh]

Kann das hier geschlossen werden? Ein Artikel existiert ja jetzt.

[iblech]

Ja, denke schon. Wenn @timjb oder jemand anderes den Artikel noch ergänzen möchte, ist sie oder er herzlich eingeladen, das zu tun. :-)