different flavours of Monad Template Library

[Ross Paterson]

On Mon, Jan 12, 2009 at 04:26:16PM +0100, Wolfgang Jeltsch wrote:
> And we should try to make Applicative a superclass of Monad and drop
> MonadPlus in favor of Alternative + Monad.  It would be probably
> even better to have somethink like Alternative/MonadPlus for functors
> (since functors are the most general concept at this point) and drop
> Alternative and MonadPlus (or use the name 'Alternative' for this
> new class).  It's terrible to explain all this legacy (Applicative not
> being superclass of Monad, two different classes for monoid functors)
> to students and to mention Applicative in a class context which already
> mentions Monad.

The legacy hierarchy is a problem with transformers.  Some of them are
Applicative transformers:

	instance (Monoid w, Applicative m) => Applicative (WriterT w m)
	instance (Applicative m) => Applicative (ReaderT r m)

so they're also defined as Functor transformers:

	instance (Functor m) => Functor (WriterT w m)
	instance (Functor m) => Functor (ReaderT r m)

So far so good.  But some others require the argument to be a Monad:

	instance (Monad m) => Applicative (StateT s m)
	instance (Monad m) => Applicative (ErrorT e m)

but to be Applicative they must also be Functor, so we keep the old
instances:

	instance (Monad m) => Functor (StateT s m)
	instance (Monad m) => Functor (ErrorT e m)

We could change these to assume Functor, but then we'd have to add a
Functor constraint to the Applicative instances.  Hmm, on second thoughts
that's probably the right way to go.