Was ist das mit KleisliFunctor?

Question

Hier ist, wie wir KleisliFunctor definieren:

class (Monad m, Functor f) => KleisliFunctor m f where 
    kmap :: (a -> m b) -> f a -> f b 
    kmap f = kjoin . fmap f 

    kjoin :: f (m a) -> f a 
    kjoin = kmap id 

Hat diese Typklasse

class (Functor f, Monad m) => Absorb f m where 
    (>>~) :: f a -> (a -> m b) -> m b 
    a >>~ f = ajoin $ fmap f a 

    ajoin :: f (m a) -> m a 
    ajoin a = a >>~ id 

fit irgendwo in der Kategorie Theorie? Was sind die Gesetze? Sind sie

a >>~ g . f  === fmap f a >>~ g 
a >>~ (f >=> g) === a >>~ f >>= g 

?

Answer 1

Dies ist eine spekulative Antwort. Mit Vorsicht fortfahren.

Lassen Sie uns zuerst KleisliFunctor betrachten, auf dem bind artigen Pfeil Mapping konzentriert:

class (Monad m, Functor f) => KleisliFunctor m f where 
    kmap :: (a -> m b) -> f a -> f b 

Damit dies tatsächlich ein Funktor von der Kleisli Kategorie von m zu sein Hask, kmap die relevanten folgen hat Funktors Gesetze:

-- Mapping the identity gives identity (in the other category). 
kmap return = id 
-- Mapping a composed arrow gives a composed arrow (in the other category). 
kmap (g <=< f) = kmap g . kmap f 

Die Tatsache, dass es zwei Functor s beteiligt macht die Sache ein wenig ungewöhnlich, b ut nicht unvernünftig - zum Beispiel gelten die Gesetze für mapMaybe, das ist das erste konkrete Beispiel, das der KleisliFunctor Post darauf anspielt.

Was Absorb, werde ich das bind-ähnliches Verfahren aus Gründen der Klarheit Flip:

class (Functor f, Monad m) => Absorb f m where 
    (~<<) :: (a -> m b) -> f a -> m b 

Wenn wir für etwas analog zu KleisliFunctor suchen, eine Frage, die sofort stellt, ist, welche Kategorie Funktionen haben würde vom Typ f a -> m b als Pfeile. Es kann sicherlich nicht sein Hask, da seine Identität (des Typs f a -> m a) nicht id sein kann. Wir müssten nicht nur Identität, sondern auch Zusammensetzung herausfinden. Für etwas, das nicht ganz im Gegensatz zu Monad ist ...

idAbsorb :: f a -> m a 
compAbsorb :: (f b -> m c) -> (f a -> m b) -> (f a -> m c) 

... die einzige plausible Sache, die ich Recht jetzt denken kann, ist mit einer Monade morphism als idAbsorb und unter Verwendung eines zweiten Monade morphism in der entgegengesetzten Richtung (dh ist, von m zu f), so dass compAbsorb durch Anwendung der ersten Funktion implementiert werden kann, dann zurück zu f gehen und schließlich die zweite Funktion anwenden. Wir müssten das herausfinden, um zu sehen, ob meine Annahmen angemessen sind, ob dieser Ansatz funktioniert und ob er zu etwas führt, das für Ihre Zwecke nützlich ist.