Add Applicative instances for MTL types
Bas van Dijk
v.dijk.bas at gmail.com
Wed Jan 14 07:54:47 EST 2009
On Sat, Dec 20, 2008 at 7:09 PM, Bas van Dijk <v.dijk.bas at gmail.com> wrote:
> In a project of mine I needed an Applicative instance for Identity and
> noticed it didn't exist. So I decided to add Applicative (and
> Alternative instances where possible) for all MTL types.
> When I was about to submit a library proposal I saw there already
> existed one. So I added my patch to that ticket.
> My patch I different in that my Applicative instances don't require a
> Monad constraint. This also means that most Functor instances now also
> depend on Applicative rather than on Monad.
> See the ticket for the details:
> Discussion period: 5 weeks (taking the holidays into account)
> This is the old thread about this proposal:
getCurrentTime >>= \c -> print (realToFrac (diffUTCTime c (readTime
defaultTimeLocale "%c" "Sat Dec 20 19:09:00 2008")) / 60 / 60 / 24 /
~ 3.5 weeks ago I sended this previous message ;-)
Can we have some discussion about my patch?
As listed in the ticket I have these questions:
* Does it make sense adding Applicative counterparts to the Monad*
classes? For example:
o class Applicative f => ApplicativeError e g | f -> e where ...
o class Applicative f => ApplicativeState s f | f -> s where ...
o class Applicative f => ApplicativeReader r f | f -> r where ...
o class (Applicative f, Monoid w) => ApplicativeWriter w f | f -> w where ...
o class (Monoid w, ApplicativeReader r f, ApplicativeWriter w f,
ApplicatveState s f) => ApplicativeRWS r w s f | f -> r, f -> w, f ->
s where ...
o class (Applicative m) => ApplicativeCont m where ...
o class ApplicativeTrans t where lift :: Applicative f => f a -> t f a
* Can we get rid of the Monad and MonadPlus constraints in the
Applicative and Alternative instances for StateT and RWST?
More information about the Libraries