Re: Add Applicative instances for MTL types

On Wed, 2009-01-14 at 13:54 +0100, Bas van Dijk wrote:

On Sat, Dec 20, 2008 at 7:09 PM, Bas van Dijk wrote:

...

Hello,

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:

http://hackage.haskell.org/trac/ghc/ticket/2316

Discussion period: 5 weeks (taking the holidays into account)

This is the old thread about this proposal:

http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9140/focus=9154

~ 3.5 weeks ago I sended this previous message ;-)

Can we have some discussion about my patch?

Yes please! I think we all want all the MTL monads to be instances of Applicative. I'm not sure if I am qualified to comment on the details of the patch however. If we don't get enough reviewers, we should try pinging people, like the original MTL authors, authors of similar mtl-esque packages etc.

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

That sounds like it wants to be an independent proposal. Duncan