[Haskell-cafe] Lifting IO actions into Applicatives

[Roman Cheplyaka]

* Tom Ellis <tom-lists-haskell-cafe-2013 at 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 <jwlato at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131001/869b87a2/attachment.pgp>