On Tue, Oct 01, 2013 at 12:11:23PM +0300, Roman Cheplyaka wrote: > > Shouldn't it be an *Applicative* constraint? > > > > class Applicative t => ApplicativeIO t where > > liftIO :: IO a -> t a > > > > and require that > > > > liftIO (pure x) = pure x > > liftIO (f <*> x) = liftIO f <*> liftIO x > > > > Seems like ApplicativeIO makes more sense than MonadIO, which is > > unnecessarily restrictive. With planned Functor/Applicative/Monad shuffle, > > the former could completely replace the latter. > > Agreed, this makes perfect sense. It simply says that liftIO is an > applicative homomorphism.
Indeed. A related question is whether, when m and m' are monads, an applicative homomorphism between m and m' is automatically a monad homomorphism. That seems important in determining if one typeclass is actually enough. In fact we could go crazy and define class Functor f => FunctorIO f where liftIO :: IO a -> f a and require that liftIO . fmap f = fmap f . liftIO i.e. essentially that liftIO is a natural transformation between IO and f. I don't know whether there are simpler sufficient conditions that allow one to determine that such an instance is also an applicative and monad morphism. Tom _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe