In dem Edx Haskell Kurs erklärt Erik Meijer wiederholt, dass co_de% type für fehlgeschlagene Berechnungen ist nicht etwas, was man tun sollte; stattdessen sollte man die leere Liste dafür verwenden.
Ich verstehe, dass der Maybe -Typ eine gute Sache ist und dass wir ihn verwenden sollten. Es scheint jedoch, dass eine Liste alles modellieren kann, was ein Maybe modellieren kann und mehr ... Also, warum brauchen wir überhaupt den Typ Maybe ?
Eine Liste kann eine beliebige Anzahl von Ergebnissen modellieren. Auf der anderen Seite, Maybe Modelle genau eins Ergebnis oder kein Ergebnis .
Denken Sie über die folgenden Funktionen nach:
%Vor% Es ist nicht klar, wie viele Elemente f1 , f2 , f3 oder f4 return. Was passiert also, wenn Sie sie sequenzieren?
Wie viele Elemente sollte das Ergebnis enthalten? Ein? Null? Haben wir versehentlich eine Liste mit n ^ n (n ~ input length) -Elementen erstellt?
Wenn die Berechnungen jedoch genau einen Wert oder keinen Wert zurückgeben, gibt uns der richtige Typ sofort alle notwendigen Informationen:
%Vor%Also das ist es. Nun zurück zu Meijers Aussage:
Erik Meijer stellt wiederholt fest, dass die Verwendung des Maybe-Typs für fehlgeschlagene Berechnungen nichts ist, was man tun sollte; stattdessen sollte man die leere Liste dafür verwenden.
Ohne zusätzliche objektive Gründe ist dies nur eine persönliche Präferenz. Ich könnte jedem sagen, dass fmap besser ist als map , es ist etwas, was wir tun sollten. Und an diesem Punkt glaubst du mir entweder oder stellst Fragen. Wenn er es in seinem Vortrag nicht klarstellte, frage ihn direkt.
Es scheint jedoch, dass eine Liste alles modellieren kann, was ein Maybe modellieren kann und mehr
Das "und mehr" ist ein guter Grund, Maybe zu verwenden. Als Verbraucher einer Liste müssen Sie null, einen oder mehrere Werte verarbeiten können. Als Konsument eines Maybe müssen Sie nur in der Lage sein, mit null oder einem Wert umzugehen. In Fällen, in denen mehrere Werte keinen Sinn ergeben, ist es besser, Maybe zu verwenden, damit Sie statisch wissen, dass Sie keine unsinnigen Werte erhalten.
zugunsten von Listen:
Die zusätzlichen Werte sind kein Problem. Der Client kann immer wählen, den Rest der Liste zu ignorieren, wenn mehr als ein Ergebnis vorhanden ist.
Die Verwendung von Listen vermeidet langwierige Konvertierungen zwischen Maybe und Listen, wenn wir beide mischen müssen. Keine Notwendigkeit für listToMaybe oder maybeToList .
catMaybes wird nur concat (oder join ).
Eine mögliche Sorge ist, dass wiederholte Verwendung von (>>=) für die Listenmonade wirklich große Listen erstellen kann. Haskell ist jedoch faul. Wenn wir nur das erste Element verwenden, wird der Rest der Liste nicht berechnet.
Ich denke, ich würde hier dem Chor beitreten und sagen, dass ich Meijers Empfehlung nicht bewerten kann, wenn mir nicht alle Einzelheiten seines Arguments dafür vorgelegt werden. Mir scheint es einfach zu sein:
Maybe für Funktionen, die 0 oder 1 Ergebnisse zurückgeben. [] für Funktionen, die 0 oder mehr Ergebnisse zurückgeben. listToMaybe :: [a] -> Maybe a und maybeToList :: Maybe a -> [a] von Data.Maybe , um Funktionen, die in einem Stil geschrieben wurden, an den anderen anzupassen. Maybe oder [] verwendet werden soll, verschieben möchten, können Sie die Klassen Alternative oder MonadPlus verwenden. Beispiel für Punkt 4:
%Vor%Ein weiterer wichtiger Punkt von Maybe ist, dass es nur der einfachste Fall von Fehlerbehandlungs-Monaden ist, die verwendet werden können, um "brechbare" Berechnungen auf bequeme und konsistente Weise darzustellen und zu bilden (ein anderes Beispiel sind Entweder und reine Ausnahmen). Die Listen-Monade ist semantisch verschieden (sie repräsentiert nicht-deterministische Berechnungen) und hat ein ähnliches Verhalten nur im Leer- / Singleton-Fall, wie oben gezeigt.