Diskussion:Monade (Informatik)

message: Einerseits muss der Artikel aufpassen, u.a. folgenden Beispielen nicht zu widersprechen, wenn er versucht, zu sagen, was eine Monade ist.
* IO, State,
* Continuations,
* Maybe und Either als Grenzfälle von Kollektionen,
* Listen,
* Bäume aller Art natürlich,
* Mengen, Multimengen, Wahrscheinlichkeitsverteilungen und Vektoren (in Haskell 98 nicht effizient als Instanzen von Monad umsetzbar, aber mathematisch Monaden).
Andererseits sind alle 3 Möglichkeiten, die Grundfunktionalität und Eigenschaften zu definieren, mal hier, mal da, sinnvoll:
* return & >>= : optimiert für Haskells do-Notation (und imperative Sicht),
* return & >=> : einfache und reguläre Darstellung der Monadengesetze,
* return, fmap & join: Anlehnung an die Definitionen aus der KT.
Das ganze zu einem konsistenten und konzisen Ganzen zu destillieren ist nicht einfach. Ich glaube, das schlecht gewählte safeDivision-Beispiel trägt seinen Teil dazu bei. :D
Stöbern in anderssprachigen Wikipedias brachte auch nur übersimplifizierenden Unsinn hervor:
* it: Una monade è una struttura dati con uno stato associato. Ja ja, klar.
* ca: En programació funcional una Mónada  és un tipus que s'utilitza, no per representar dades sinó per modelar la seqüencialitat mitjançant l'encadenament d'operacions, sobre tot en llenguatges no-estrictes com Haskell on l'ordre de les operacions és indeterminat. Zu viel Betonung auf Reihenfolge, wenn ich das richtig verstehe.
* en: Naja, geht so. Aber: Verwendung des o.g. schlechten Beispiels; später: Ausufern.
* fr: Nahezu gut, aber irgendwie wird nur IO dargestellt.
Mensch, Mensch. Die Benutzung ist soo einfach. Warum die Beschreibung nicht? 
Gedanken, Meinungen, Vorschläge? (nicht signierter Beitrag von Daniel5Ko (Diskussion | Beiträge) 00:35, 11. Mai 2010 (CEST)
replies: text: Damit schlage ich mich auch schon lange herum. Ich fand deinen Vorschlag toll und habe mal versucht den Artikel entsprechend umzuschreiben (hauptsächlich die Definitionen und die Einleitung). Kommentare und Verbesserungen ausdrücklich erwünscht! Sobald der Entwurf stabil ist, werde ich ihn in den Artikel einarbeiten. -- Carsten Milkau (Diskussion) 15:30, 21. Okt. 2012 (CEST)
thread_title:  Hmm, schwierig 

message: Überarbeiten? (nicht signierter Beitrag von 132.199.175.216 (Diskussion | Beiträge) 13:17, 17. Nov. 2009 (CET)
thread_title:  lesbarkeit... 

message: Ist das Beispiel par x y = 1 / ((1 / x) + (1 / y)) wirklich gut gewählt? Ich kenn mich zwar in der Elektrotechnik nicht aus, aber das Ergebnis dieser Formel (ohne Maybe) wird in Haskell so ausgewertet: 
ghci> let x = 0 :: Float
ghci> let y = 2 :: Float
ghci> 1 / ((1 / x) + (1 / y)) :: Float
0.0
ghci> let y = 0 :: Float
ghci> 1 / ((1 / x) + (1 / y)) :: Float
0.0
Sprich: Wenn einer der beiden Parameter 0 ist, ist auch das Ergebnis 0, was sich auch leicht nachrechnen lässt, denn bei Gleitkommazahlen gilt laut IEEE-Standard: 
1/0 = Infinity; Infinity + ... = Infinity;
1/Infinity = 0;
Für den Gesamtwiderstand zweier parallelgeschalteter Widerstände scheint mir die Lösung 0 dabei durchaus zutreffend zu sein (auch soweit es sich aus der Funktion ablesen lässt), und Maybe ist dabei gar nicht nötig. 
Viel besser wäre, hier ein Beispiel mit Integerdivision einzufügen; denn dann löst die Division durch 0 in Haskell einen Laufzeitfehler aus:
ghci> 8 `div` 0
*** Exception: divide by zero
--131.130.238.32 09:05, 28. Jan. 2010 (CET)
replies: text: Stimmt. Unter den Umständen ist das Beispiel schlecht gewählt. Es ist ohnehin auch schlecht, dass das das einzige Beispiel ist. --Daniel5Ko 20:50, 6. Mai 2010 (CEST)
thread_title:  Maybe-Beispiel 

message: "In der objektorientierten Programmierung entspricht die Typkonstruktion der Deklaration des Monadentyps, die Einheitsfunktion übernimmt die Rolle der Konstruktormethode und die Bindeoperation enthält die für die Ausführung notwendige Logik."
Dieser Satz braucht dringend weitere Erläuterung. Ist er überhaupt korrekt? Es klingt erstens danach, als ob Einheitsfunktion und Bindeoperation Elemente der Objektorientierten Programmierung wären (wenn auch umgekehrt gemeint), zweitens impliziert er, dass durch monadisches Binden alle Ausführungslogik, die in OOP in Methoden enthalten ist, ersetzt würde.
Das stimmt m.E. nicht.
--131.130.238.32 09:11, 28. Jan. 2010 (CET)
replies: text: Zustimmung. Sehr problematische Behauptung. --Daniel5Ko 20:50, 6. Mai 2010 (CEST)
thread_title:  Vergleich mit OOP 

message: Ich bin Informatiker, und habe das vielleicht im 1. Semester mal gelernt. Aber nachvollziehen konnte ich das hier nur sehr schwer.
Ob es die Oma verstehen muss, ist fraglich, aber ich hätte erwartet, dass ich es problemlos verstehe.
Gerade die Einleitung, und das erste Beispiel (in dem das Wort Monade gar nicht vorkommt), tragen nicht viel zur Erklärung bei:
>> Programme, die im funktionalen Stil geschrieben wurden, können Monaden benutzen, um Prozeduren zu strukturieren.
--87.178.192.217 10:49, 16. Mär. 2010 (CET)
replies: text: da hast du leider recht. ich denke zwar monaden verstanden zu haben, aber es fällt mir schwer die wesentlichen punkte überhaupt im artikel wiederzufinden. problemlos verstehen wirst du monaden aber wahrscheinlich auch bei einem perfekten artikel nicht; ich hab schon viele gestandene informatiker erlebt die an monaden ganz schön zu knacken hatten. -- 14:42, 16. Mär. 2010 (CET)
replies: text:  Monaden sind wie Burritos! :D --Daniel5Ko 20:50, 6. Mai 2010 (CEST)
thread_title:  Einleitung und Beispiel 

message: Ich hätte ja gerne eine andere Definitionssprache als hier dargestellt verwendet. 
Ich fine dies verwirrend und wenig durchschaubar. Scala wäre hier schön. (nicht signierter Beitrag von 212.79.181.167 (Diskussion) 22:07, 26. Jan. 2014 (CET)
replies: text: Etwas ähnliches habe ich schon (ganz oben auf dieser Seite) früher diskutieren wollen. (Ich habe diesen Diskussionsbeitrag verfasst, als ich noch nicht gesehen habe, dass neues ungünstigerweise unten hingehört. ;) ) Wie dem auch sei: Ich stimme zu, dass alle 3 Definitionen sinnvoll sind. Ich bin aber auch der Meinung, dass es möglich sein sollte, mit einer davon auszukommen. Und wenn das erreicht wäre, wäre das der Nennung aller 3 Definitionen überlegen. --Daniel5Ko 23:56, 15. Jul. 2010 (CEST)
replies: text:  Aber: wenn's hilft und die ideale Lösung in weiter Ferne scheint: Nur zu, und alle Definitionen nennen. Späteres wieder-'raus-Nehmen ist ja immer möglich. --Daniel5Ko 00:26, 16. Jul. 2010 (CEST)

text:  oha, das hab ich glatt übersehen. momentan weiß ich noch nicht so recht wie, aber ich werd's beizeiten mal versuchen alle drei unterzubringen. was mich bei dem thema übrigends auch noch irritiert sind die vielen unterschiedlichen bezeichnungen für die operationen: return/pure/unit, >>=/bind/flatMap, join/flatten, map/fmap/<$>, ap/<*> usw. das würde ich gern unterbringen, aber ich hab auch hier noch keine gute idee wie. -- ∂ 22:11, 16. Jul. 2010 (CEST)
replies: text:  Ein paar Gedanken zur Vereinfachung: Ich würde flatMap überhaupt nicht, oder höchstens in einem Halbsatz im Collections-Beispiel-Abschnitt, erwähnen (zu Collection-spezifisch, zudem gibt es weitere nah-Synonyme, z.B. SelectMany ;) ), map aus ähnlichen Gründen gleichermaßen. flatten (falls es das aus Scala ist) gehört auch in diese Kategorie und hätte zum Beispiel das weitere Synonym concat. ap/<*> würde ich ganz weglassen. Halte ich für ablenkend, und einen Link zu Brents Typklassopedia haben wir ja eh schon. Ich hoffe, das liefert dir ein paar Gründe, deine Liste(n) zu verkleinern und damit die Aufgabe zu vereinfachen. --Daniel5Ko 23:42, 16. Jul. 2010 (CEST)

text: Man kann eine Monade auch mit >=> (dem Kleisli-Kombinator [soweit ich weis]) anstatt >>= definieren, diese Definition ist äquivalent, weil man >>= somit einfach mit a >>= b = const a >=> b $ () definieren kann. Etc blabla
Schlau ist es, diese Definitionen vor die Erläuterung der Gesetze zu stellen, sodass man dann diese verwenden kann. Einfach nur meine 50ct --FUZxxlD|M|B 15:56, 14. Jan. 2011 (CET)

text: Hmm, ich sehe die Gesetze eigentlich als zur Definition gehörend an. Andererseits beschreitet Brent Yorgey in seiner Typeclassopedia ebenfalls den von dir skizzierten Weg. Ich denk' mal 'ne Weile drüber nach. --Daniel5Ko 21:10, 14. Jan. 2011 (CET)

text: Ja das geht mir auch so; ich habe mal versucht den Artikel entsprechend umzuschreiben (hauptsächlich die Definitionen und die Einleitung). Kommentare und Verbesserungen ausdrücklich erwünscht! Sobald der Entwurf stabil ist, werde ich ihn in den Artikel einarbeiten. -- Carsten Milkau (Diskussion) 15:30, 21. Okt. 2012 (CEST)
thread_title:  Definition 

message: Für Haskell-Programmmierer sind die Beispiele sicher leicht verständlich, da sie mit der Syntax vertraut sind. Da ich aber kein Haskell kann, kann ich mit den Beispielen nichts anfangen und steige schon beim 1. Beispiel aus. Was ist nun a? was macht das? was ist m?
Einem Haskell-Programmierer ist sicher auch unverständlich, was es mit  void *(*(**o[][8])())[];  auf sich hat, einem C-Programmierer dagegen bereiten Ausdrücke wie dieser keinerlei Schwierigkeiten. *hust hust* :-) --RokerHRO (Diskussion) 21:36, 3. Mär. 2013 (CET)
thread_title:  {{Anker|Syntax}} Syntax und damit auch die Semantik unklar 

message: Die Umbenennung des Artikels finde ich gut aber es könnte noch so einiges mehr rein. Das sämtliche Codebeispiele in Haskell sind ist zwar konsequent aber ein paar Beispiele in anderen Sprachen IM Artikel wären meiner Meinung nach eine Bereicherung. Die Erwähnung von LINQ und Scalas for-Comprehension  würde dem Artikel "gut tuen". Gerade LINQ gilt als allgemein akzeptierte Technik und in diesem Zusammenhang könnte gezeigt werden das Monade ganz praktischen Nutzen haben und nicht nur ein theoretisches Konstrukt sind.
Besonders interessant finde ich die Komposition von Monaden. Zum einen gibt es das Konzept der Monad Transformer  zum anderen die Komposition von Monaten über  Co-Produkte. Hierzu zwei Referenzen:
http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf
http://isi.uni-bremen.de/~cxl/habil/papers/icfp02.pdf
In den englischen Wikibooks gibt es bereits einen Eintrag zum Thema Monad Transformer. (nicht signierter Beitrag von Wikitester2501 (Diskussion | Beiträge) 21:22, 3. Apr. 2012 (CEST)
thread_title:  Monaden Komposition 

message: ""Der Name Monade stammt aus der Kategorientheorie""
Man muß schon sehr ungebildet sein, um so einen Unsinn zu schreiben. 
Daß der Begriff schon in der Kategorientheorie mißbraucht wurde, 
ist keine Abstammung! Aber wer Leibnitz nur als Keks kennt, ..... (nicht signierter Beitrag von 84.139.124.80 (Diskussion) 09:27, 3. Jan. 2014 (CET)
replies: text: kannst du mir dann vielleicht den zusammenhang zwischen Monade (Philosophie) und Monade (Kategorientheorie) erklären? -- ∂ 16:27, 3. Jan. 2014 (CET)
thread_title:  Bildungsmangel 

message: – GiftBot (Diskussion) 18:10, 17. Jan. 2016 (CET)
thread_title:  {{Anker|deadurl_2015-10}} Defekter Weblink 

message: Der Artikel ist durch die ausschließliche Verwendung von Haskell recht schlecht verständlich.
Vor einer Weile habe ich mal mit Haskell begonnen und wollte jetzt über diese Seite das Thema Monade nochmal auffrischen, bin aber bei State komplett ausgestiegen.
Hier wird zuviel implizites Wissen und kognitive Transformation vorausgesetzt, als dass der Abschnitt für die breite Masse der Leser verständlich wird.
Ich musste mich mit einem Ausdruck hinsetzen und per Bleistift zig Dinge noch mal erschließen, die mir als Erläterung im Text fehlten.
Hab dann doch meine Bibliothek durchforstet und entdeckt, dass ich in "Real World Haskell" vor Jahren ähnliche Anmerkungen an den Rand geschrieben hatte, allerdings war der dortige Text schon hilfreicher.
Was für Einsteiger fehlt: 
* Warum heißt die Monade "State", obwohl sie eine Funktion kapselt, die einen Statusübergang darstellt. Wäre StateTransition nicht korrekter?
Insbesondere für Leser aus der Java OO Ecke, die mal in Scala hineingeschaut haben und inzwischen Optional und List als Container Monade kennen, ist die funktionsorientierte Monade fremd.
* Hinweis, dass Monaden generell M a definiert sind, und wieso wir nun State s a, also zwei Typparameter vorfinden. (Real World Haskell führt hier Typ-Currying vor, und plötzlich wird M a sichtbar).
* Die Implementierung von >>= ist in ihrer jetzigen Form nur schwer zugänglich, weil sie zu viel Haskell voraussetzt. Die Funktionsweise wird einem nicht mit Haskell vertrauten Leser nicht deutlich und auch nicht textuell erklärt.
* Die Hochzähl-Funktion ändert in Folge des Umbaus ihren Charakter von einer Funktion, die zwei Parameter zu einem Resulttupel mappt hin zu einer Funktion, die eine Funktion liefert, die dies tut.
Darauf wird der Leser aber nicht explizit hingewiesen.
* Es fehlt abschließend ein Beispiel, wie das gesamte Konstrukt denn angewendet wird, von der ersten Initialisierung mit einem konkreten Startwert bis hin zum Erhalt und der Auswertung des Endzustands.
State Monad - schöne Theorie, was mach ich jetzt in der Praxis damit? Gemsmith (Diskussion) 11:22, 15. Apr. 2018 (CEST)
thread_title:  State Monad 

message: Folgender Satz ist m.E. falsch. Das ginge doch mit Generics und Typeconstraints, oder habe ich da eine Funktionalität übersehen?
"In allen drei Sprachen ist es nicht möglich, als Benutzer Funktionalität zu definieren, die mit allen Monaden umgehen kann, wie etwa Haskells sequence :: forall m a. Monad m => [m a] -> m [a]."
--Diaspomod (Diskussion) 18:37, 9. Aug. 2019 (CEST)
thread_title:  Monaden außerhalb Haskells 

message: ich bin Entwickler und auch mathematisch sowie philosophisch vorgebildet, aber trotzdem ist der Artikel - besonders im ersten Teil - schwer zugänglich. Das liegt m.E. daran, dass zur Illustration Haskell verwendet wird, das nun nicht jeder kennt. Damit werfen die - sicherlich gut gemeinten - Haskell-Beispiele mehr Fragen auf als sie beantworten. Wenn man schon solche formalen Beispiele bringen möchte, dann bitte allgemeinverständlich, d.h. mathematisch notiert. --88.153.219.221 12:31, 9. Sep. 2019 (CEST)
thread_title:  Sehr unzugänglich