Add Applicative instances for all MTL Monads

[sjanssen]

This is a proposal to add Applicative instances corresponding to each Monad instance in the MTL. Note that mtl will now depend on base >= 2.0.

[guest]

If base-2 is not available you can import:

 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/special-functors

[basvandijk]

Without checking for similar proposals I also made a patch that adds Applicative and Alternative instances for all types in mtl. Next time I will look and save me the work.

Differences

There are differences however, between the original and my patch.

• I don't write pure and <*> in terms of return and ap. Instead I define them directly. Maybe this is a bit more efficient.

• I try not to require Monad as a superclass for the Applicative instances for all the transformer types. This also means that some Functor instances now have an Applicative instead of a Monad constraint. I don't know if this is really important but I found it clearer and more flexible.

Summary of my changes

Here's a summary of my changes:

• Cont
  • Added instance Applicative (Cont r)
  • Replaced: instance (Monad m) => Functor (ContT r m) with: instance Functor (ContT r m)
  • Added instance Applicative m => Applicative (ContT r m)

• Error
  • Added: instance Applicative (Either e)
  • Added: instance (Error e) => Alternative (Either e)
  • Replaced: instance (Monad m) => Functor (ErrorT e m) with: instance Applicative m => Functor (ErrorT e m)
  • Added: instance Applicative m => Applicative (ErrorT e m)
  • Added: instance (Alternative m, Error e) => Alternative (ErrorT e m)

• Identity
  • Added: instance Applicative Identity

• List
  • Replaced: instance (Monad m) => Functor (ListT m with: instance Applicative m => Functor (ListT m)
  • Added: instance Applicative m => Applicative (ListT m)
  • Added: instance Alternative m => Alternative (ListT m)

• RWS (both lazy and strict) (Unfortunately I couldn't get rid of the Monad constraints)
  • Added: instance Monoid w => Applicative (RWS r w s)
  • Addedd: instance (Monad m, Monoid w) => Applicative (RWST r w s m)
  • Added: instance (MonadPlus m, Monoid w) => Alternative (RWST r w s m)

• Reader
  • Added: instance Applicative (Reader r)
  • Replaced: instance (Monad m) => Functor (ReaderT r m) with: instance (Applicative m) => Functor (ReaderT r m)
  • Added: instance Applicative m => Applicative (ReaderT r m)
  • Added: instance Alternative m => Alternative (ReaderT r m)

• State (both lazy and strict) (Unfortunately I couldn't get rid of the Monad constraints)
  • Added: instance Applicative (State s)
  • Added: instance Monad m => Applicative (StateT s m)
  • Added: instance MonadPlus m => Alternative (StateT s m)

• Writer (both lazy and strict)
  • Added: instance Monoid w => Applicative (Writer w)
  • Replaced: instance (Monad m) => Functor (WriterT w m) with: instance (Applicative m, Monoid w) => Functor (WriterT w m)
  • Added: instance (Applicative m, Monoid w) => Applicative (WriterT w m)
  • Added: instance (Alternative m, Monoid w) => Alternative (WriterT w m)

Questions

I also had some questions:

• Does it make sense adding Applicative counterparts to the Monad* classes? For example:
  • class Applicative f => ApplicativeError e g | f -> e where ...
  • class Applicative f => ApplicativeState s f | f -> s where ...
  • class Applicative f => ApplicativeReader r f | f -> r where ...
  • class (Applicative f, Monoid w) => ApplicativeWriter w f | f -> w where ...
  • class (Monoid w, ApplicativeReader r f, ApplicativeWriter w f, ApplicatveState s f) => ApplicativeRWS r w s f | f -> r, f -> w, f -> s where ...
  • class (Applicative m) => ApplicativeCont m where ...
  • 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?

[basvandijk]

Adds Applicative and Alternative instances for all MTL types

[basvandijk]

Here are the relevant discussions at libraries@…:

 http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9140  http://thread.gmane.org/gmane.comp.lang.haskell.libraries/10432

[basvandijk]

Adds Applicative and Alternative instances for all MTL types

[igloo]

Looks like an abandoned proposal

[Eelis-]

Replying to igloo:

Looks like an abandoned proposal

I'm puzzled by this rationale.

Yes, there has been no activity for a full year, but it looks like this is simply a consequence of MTL not having an active maintainer who can review and apply Bas's patch. I don't see how it follows that people are no longer interested in this proposal.

Since maintainer approval of patches is the final step in any proposal, this policy combined with the absence of an active MTL maintainer implies that all proposed MTL improvements, no matter how widely supported or soundly implemented in a patch, will inevitably receive the dreaded "wonfix, abandoned" classificiation. Needless to say this seems terribly cynical, so surely this can't be the intent?

[igloo]

The proposer is supposed to summarise the discussion (in particular, whether there was a consensus for or against applying the patch, or a variant thereof) after the discussion period is over. If the consensus was to apply the patch, then we'll apply it.

See  http://www.haskell.org/haskellwiki/Library_submissions for more details.

[simonpj]

I would much prefer that there was a maintainer for MTL, who takes the lead on reviewing the patch, evaluating the discussion, and leading contributors towards a consensus. The GHC HQ team are supposed to have gotten out of the libraries business.

If there is no one actually willing to play the maintainer role for MTL, then who is going to coordinate the discussion, and evaluate the pros and cons in an even-handed way? Ian suggests that it might be the person proposing the change; very well, but that makes them the de-facto maintainer.

This isn't cynical. It's just that there's a job to do, and someone has to step up to do it. Lacking such a person the job doesn't get done. Eelis, perhaps you'd be willing?

Simon

[ross]

The idea of the library submissions process was to get decisions about changes to key packages decided by consensus, rather than by an individual. These packages list libraries@… as their maintainer. As Ian says, the onus is on the proposer (who is presumably keen on this particular change) to prepare the patch and respond to feedback until agreement is reached. Applying the proposer's patch is then trivial. That doesn't make the proposer the de-facto maintainer, because they don't make the decision and there will likely be a different proposer for the next patch. It's not perfect, but it generally works well.