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.
On Tue, Oct 1, 2013 at 1:58 AM, Michael Snoyman
I'm wondering if anyone's run into this problem before, and if there's a common solution.
In Yesod, we have applicative forms (based originally on formlets). These forms are instances of Applicative, but not of Monad. Let's consider a situation where we want to get some user input to fill out a blog post datatype, which includes the current time:
data Blog = Blog Title UTCTime Contents
myBlogForm :: Form Blog myBlogForm = Blog <$> titleForm <*> something <*> contentsForm
The question is: what goes in something? Its type has to be:
something :: Form UTCTime
Ideally, I'd call getCurrentTime. The question is: how do I lift that into a Form? Since Form is only an Applicative, not a Monad, I can't create a MonadIO instance. However, Form is in fact built on top of IO[1]. And it's possible to create a MonadTrans instance for Form, since it's entirely possible to lift actions from the underlying functor/monad into Form. So something can be written as:
something = lift $ liftIO getCurrentTime
This works, but is unintuitive. One solution would be to have an ApplicativeIO typeclass and then use liftIOA. My questions here are:
1. Has anyone else run into this issue? 2. Is there an existing solution out there?
Michael
[1] Full crazy definition is at: http://haddocks.fpcomplete.com/fp/7.4.2/20130922-179/yesod-form/Yesod-Form-T...
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe