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.
Tom
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
