Ich habe einen Coroutine-Transformator
%Vor% mit Monad instance
Wenn ich eine MFunctor Klasse mit Monad m und Monad n Einschränkungen definiere, kann ich hoist
Aber mmorph s hoist hat nur eine Monad m Einschränkung. Kann ich mein hoist ohne es definieren, oder ist das ein Mangel an Allgemeinheit von MFunctor ?
EDIT: Ich habe herausgefunden, dass es möglich ist ist ! Aber meine Frage steht immer noch: Sind wir sicher, dass es hier an Allgemeingültigkeit nicht mangelt?
%Vor% mmorph wurde im Kontext der pipes-3.* -Serie entwickelt (früher war es ein internes pipes Modul ), das Funktionen wie folgt hatte:
Wenn Sie die Monad n Einschränkung zu hoist hinzufügen, müssen Sie eine Monad (t2 m) Einschränkung zu raise hinzufügen. Ich versuche generell Einschränkungen in meinen Bibliotheken zu minimieren und ich konnte keine MFunctor Instanzen finden, die die Monad n Einschränkung benötigen, also habe ich sie entfernt.
Randnotiz: CoT y m a ist dasselbe wie Producer y m a von pipes , die bereits eine MFunctor -Instanz hat.
Sie können einen beliebigen Typ t verwenden, für den Sie hoist' :: (Monad m, Monad n) => (forall t. m t -> n t) -> t m a -> t n a als MFunctor definieren können. Sie können das resultierende t n a jedoch nur verwenden, wenn Sie eine Monad -Instanz für n haben. Wir tun dies, indem wir die Anwendung der natürlichen Transformation aufschieben. Oder eine phantastische Art, dies zu sagen, wäre die Anwendung des Coyoneda-Lemmas.
Ich denke also nicht, dass wir die Allgemeinheit verlieren, denn wenn Sie keine Instanz für MFunctor implementieren können, geht nichts verloren durch die Monad Einschränkung für lowerMCoyoneda' .
Ich entdeckte, dass dies in ein ähnliches Problem mit RVarT
Tags und Links haskell