Zum dritten Mal in meinem Leben versuche ich Haskell zu lernen, dieses Mal durch Lerne einen Haskell ... .
Wenn der Autor Wachen erklärt, zeigt er dieses Beispiel:
und sagt
Das erinnert sehr an einen großen if else Baum in Imperativsprachen, nur das ist viel besser und lesbarer. Während groß, wenn sonst Bäume in der Regel verpönt sind, manchmal ein Problem ist so diskret definiert, dass Sie nicht um sie herumkommen können. Wärter sind eine sehr gute Alternative dafür.
Ich kann sehen, dass die Wachen besser lesbar sind, aber ich verstehe nicht, warum diese Syntax "viel besser" ist Es ist flexibler? Es ist stärker? Was ist der große Vorteil von Wachen?
Mein großes Problem ist wahrscheinlich der Satz
Obwohl groß, wenn Bäume sonst verpönt sind, wird ein Problem manchmal so diskret definiert, dass man sie nicht umgehen kann
Kann jemand ein Beispiel dafür geben?
Don gibt die Hauptmotivation für die Verwendung von Wachen, aber zusätzlich dazu kombinieren sie auch schön mit dem Mustervergleich. Wenn alle Wächter eines Musters fehlschlagen, wird das nächste Muster durchlaufen, sodass Sie Muster und Bedingungen gleichzeitig prüfen können, ohne viele doppelte Fall-Through-Fälle zu haben. Hier ist ein (sehr künstliches) Beispiel:
%Vor% Wenn wir an Nothing als unbegrenzt denken, wird ein Element zum Vergleichen verwendet und entweder wird ein negativer Bereich auf nur dieses Element "erweitert", eine untere / obere Grenze wird verschoben, um das Element einzuschließen, oder der Bereich bleibt unverändert Das Element ist bereits enthalten.
Überlege dir jetzt, wie du das oben schreiben würdest, ohne Wachen zu benutzen! Wie oft würden Sie am Ende einen Zweig duplizieren, der konzeptionell derselbe ist, weil sich die Muster unterschieden? Und ja, ich weiß, dass dieses kleine Beispiel neu geschrieben werden könnte, um das Problem vollständig zu vermeiden, aber das ist nicht immer möglich (oder wünschenswert).
Diese Art der Definition ist meines Erachtens das Wichtigste, was man mit Wächtern ausdrücken kann, die, obwohl sie noch möglich sind, schrecklich viel ausführlicher und viel schwerer zu lesen wären, wenn sie als eine Mischung aus (unbewachtem) Muster geschrieben wären Fälle und if -Ausdrücke.
Wächter sind syntaktisch leichter für:
Vergleiche:
%Vor%mit:
%Vor%Der Regelteil ist klarer syntaktisch und einfacher zu pflegen.
Außerdem passen sie gut zu Ansichtsmustern, um eine ansprechende Syntax zu erhalten.
%Vor%zum Beispiel.
Jedes Problem mit vielen if's in der Umgebung könnte gewinnbringend als Entscheidungsdiagramm visualisiert werden. Ein Stück des Entscheidungsdiagramms für das von Ihnen zitierte LYAH-Beispiel würde gehen:
%Vor%Der große Vorteil von Guards ist, dass sie die Struktur der Syntax die Struktur des Entscheidungsdiagramms widerspiegeln lassen. Wenn Sie alles, was Sie hatten, wenn-dann-sonst wäre, dann müssten Sie das obige Entscheidungsdiagramm mit einer Reihe von verschachtelten if implementieren, dh eine Multi-Zweig-Wahl mit einer Kaskade von Zwei-Zweig-Wahlen zu kodieren. Nested if's verdecken die High-Level-Idee Ihres Algorithmus.
Nun, was ich denke, dass der Autor von LYAH in dem von Ihnen zitierten Satz war, ist, dass Sie manchmal mit Wächtern nicht besser umgehen können als mit verschachtelten Wenn-Dann-Anderen. Aber das ist nur wahr, wenn Entscheidungen voneinander abhängig sind, dh wenn Ihr Entscheidungsdiagramm viele Diamantfelder (Auswahlmöglichkeiten) mit jeweils nur zwei Zweigen enthält und nicht anders umgeschrieben werden kann. Beachten Sie, dass in dem Beispiel bmiTell jeder Zweig unabhängig von dem anderen ist, da der BMI nur in die 4 Kategorien fallen kann, von denen sich keine mit anderen überschneiden.
Guards sind nur mehr visuell offensichtlich und sind weniger wortreich / haben weniger "Lärm" über sie.
Vergleiche:
%Vor%(und was C.A. McCann über die Fall-Through-Fälle gesagt hat ). :)
Tags und Links haskell