Ich arbeite an der Verwendung von Monad-Transformatoren in C #.
Ich würde gerne wissen, ob der folgende Code, den ich präsentiere, zeigt, dass ich das verstanden habe.
Ich bin ziemlich neu, also sind alle Rückmeldungen / Kommentare wirklich willkommen.
Dieses Beispiel dient nur dazu, eine Monade in eine Validierungsmonade einzubinden.
Eine weitere kleinere Unterfrage ist, ob C # höhere kinded Typen hätte, könnte ich diese Klasse nur einmal implementieren (ValidationT) und es funktioniert für alle anderen umhüllten Monaden oder ist das falsch?
Fast, ist die schnellste Antwort. Ihr ValidationMaybeT speichert den Wert von Maybe , während ein echter Monad Transformer das Verhalten der Maybe und der Validation Monade hätte und das Standardverhalten der umhüllten Monade bei Bedarf ändern könnte.
Dies ist eine sehr manuelle Art, es zu tun, was ich nicht unbedingt empfehlen würde, es wird sehr unordentlich, sehr schnell. C # 's Mangel an höher-kinded Polymorphismus wird Sie bei jeder Gelegenheit stolpern.
Das nächste, das ich geschafft habe (auch dann ist es kein richtiges Monodentrafo-System), ist mit meiner Bibliothek: Language-Ext
Es gibt 13 Monaden im Projekt (Option, Map, Lst, Entweder, Versuch, Leser, usw.), und ich implementiere einen Standardsatz von Funktionen für alle von ihnen:
%Vor%Diese Funktionen sind in der funktionalen Programmierung am nützlichsten und ermöglichen es Ihnen, jede erforderliche Operation durchzuführen.
Mit allen Monaden, die diese Standardfunktionen implementieren, werden sie zu einem höheren Typ. Nicht dass der Compiler das weiß, sie sind alle nur ein Teil derselben 'Menge'.
Dann habe ich eine T4-Vorlage geschrieben, um Transformer-Funktionen als Erweiterungsmethoden zu generieren (sie haben ein T -Suffix), für jede Kombination von Monade und Funktion im 'höher-kinkenden Typ'.
Also zum Beispiel:
%Vor% Der obige Code ergibt sich in 6 . Die Definition für SumT lautet:
FilterT zum Beispiel funktioniert auch auf der inneren Monade:
Also ist die Route der Erweiterungsmethode sehr gut. Verwenden Sie statt einen neuen Typ zu erstellen:
%Vor% Geben Sie dann die Maybe Erweiterungsmethoden für IValidation<IMaybe<T>>
Sie können entweder machen, was ich getan habe, und automatisch aus einem Standardsatz generieren, oder sie manuell schreiben. Es hält dann Ihre Maybe und Validation Implementierungen sauber und die maßgeschneiderte Transformator-Funktionalität getrennt.
Wenn Sie interessiert sind, ist dies die T4-Vorlage, die ich verwendet habe, um die Transformationsmethoden zu erzeugen (es ist ziemlich banal, um ehrlich zu sein): LanguageExt.Core/HKT.tt
Und das ist der generierte Code: LanguageExt.Core / HKT.cs
Bevor ich das HKT-Zeug oben gemacht habe, habe ich eine ähnliche Methode wie Sie versucht, ich habe eine Monade namens TryOption<T> , die ein Try und ein Option ist. Aber mit dem neuen HKT-Zeug kann ich jetzt Try<Option<T>> schreiben. Die ursprüngliche Implementierung ist hier :
Wie auch immer, ich hoffe, das hilft!
Tags und Links c# functional-programming higher-kinded-types monads monad-transformers