* Tom Ellis <tom-lists-haskell-cafe-2...@jaguarpaw.co.uk> [2013-10-01 09:20:23+0100] > On Tue, Oct 01, 2013 at 09:29:00AM +0200, Niklas Haas wrote: > > On Tue, 1 Oct 2013 02:21:13 -0500, John Lato <jwl...@gmail.com> wrote: > > > It's not a solution per se, but it seems to me that there's no need for > > > the > > > Monad superclass constraint on MonadIO. If that were removed, we could > > > just have > > > > > > class LiftIO t where > > > liftIO :: IO a -> t a > > > > > > and it would Just Work. > > > > One concern with this is that it's not exactly clear what the semantics > > are on LiftIO (is liftIO a >> liftIO b equal to liftIO (a >> b) or not?) > > and the interaction between LiftIO and Applicative/Monad would have to > > be some sort of ugly ad-hoc law like we have with Bounded/Enum etc. > > 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. Roman
signature.asc
Description: Digital signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
