Dlaczego wartość powrotu windy nie jest monadą?

Question

Dlaczego nie MonadTrans jest zdefiniowany jako

class MonadTrans t where 
    lift :: (Monad m, Monad (t m)) => m a -> t m a 
--     ^^^^^^^^^^^ 

zamiast obecnego

class MonadTrans t where 
    lift :: Monad m => m a -> t m a 

To Haskell 98 (w przeciwieństwie do sugestii w Why aren't monad transformers constrained to yield monads?) i zapewnia, że ​​wynik będzie zawsze monada. Czy istnieje powód, dla którego transformatory monady mogą wytwarzać coś, co nie jest monadą?

Answer 1

Domyślam się, że MonadTrans przekształca Monad w coś innego, zamiast przekształcania Monad w Monad. Jest bardziej ogólny, ponieważ możesz napisać coś, co przekształca Monad i możesz zdefiniować lift, ale nie możesz zdefiniować >>= i return. Ponieważ większość (jeśli nie wszystkie) instancji MonadTrans kończy się na Monad s, tak naprawdę nie stanowi problemu, ponieważ kompilator nadal go obsługuje.

Answer 2

Odpowiedź bheklilra dała mi przykład, w którym transformator monady wytwarza coś, co nie jest monadą. Dobrze znanym przykładem czegoś, co nie jest monadą, jest ZipList. I możemy stworzyć wariant, który uruchamia monadyczne działanie na każdym poziomie:

import Control.Applicative 
import Control.Arrow ((***)) 
import Control.Monad 
import Control.Monad.Trans 

-- | A list where each step is produced by a monadic action. 
data ListT m a = Nil | Cons (m (a, ListT m a)) 

To jest właściwie monadowy strumień. I może być łatwo przekształcony w Functor i Applicative

instance Monad m => Functor (ListT m) where 
    fmap f Nil  = Nil 
    fmap f (Cons k) = Cons $ (f *** fmap f) `liftM` k 
instance Monad m => Applicative (ListT m) where 
    pure x = Cons $ return (x, pure x) 
    Cons mf <*> Cons mx = Cons $ do 
     (f, fs) <- mf 
     (x, xs) <- mx 
     return (f x, fs <*> xs) 
    _  <*> _  = Nil 

ale oczywiście nie jest to monada. Mamy więc instancję MonadTrans, która konwertuje monadę w coś, co jest tylko Applicative.

instance MonadTrans ListT where 
    lift mx = Cons $ (\x -> (x, lift mx)) `liftM` mx 

(To wszystko uświadomiło mi, że eksperymentalny ZipSink w przewód-extra jest również ładny takich przykładów.)

---

Jednak to rodzi kolejne pytanie: jeśli chcemy takich transformatory, jakie prawa powinny przestrzegać? Przepisy prawne dotyczące MonadTrans są zdefiniowane jako

lift . return = return 
lift (m >>= f) = lift m >>= (lift . f) 

Tak więc w naszym przypadku moglibyśmy chcieć czegoś jak

lift (f `liftM` x) = fmap f (lift x) 

lift . return  = pure 
lift (m `ap` f)  = lift m <*> lift f 

Answer 3

mam zamiar zgadzam się z dwoma pozostałymi odpowiedziami powiedzieć, że wynikiem powinna być monada. Powodem jest to, że w przeciwnym razie nie istnieją rozsądne prawa, które powinny być przestrzegane.

lift ma być morfizmami Monad, co oznacza, że ​​powinien przestrzegać następujących dwóch praw:

lift (return x) = return x 

lift (m >>= f) = lift m >>= \r -> lift (f r) 

Przepisy te bardziej sensowne, kiedy zdajesz sobie sprawę, że są przepisy funktor między dwie kategorie Kleisli:

-- i.e. "fmap id = id" 
(lift .) return = return 

-- i.e. "fmap (f . g) = fmap f . fmap g" 
(lift .) (f >=> g) = (lift .) f >=> (lift .) g 

Jeśli jednak nie ograniczysz wyjścia do monady, prawa te przestaną być poprawne i nie będziesz miał rozsądnego sposobu na sprawdzenie, czy poprawnie zaimplementowano lift.

Podejrzewam, że prawdziwym powodem było uczynienie klasa Haskell98