mtl, transformers, monads-fd, monadLib, and the paradox of choice

A bunch of them are almost completely equivalent:

• mtl uses GHC extensions, but transformers is Haskell 98.
• monads-fd and monads-tf are add-ons to transformers, using functional dependencies and type families respectively, both providing the functionality in mtl that's missing from transformers.
• mtl-tf is mtl reimplemented using type families.

So essentially, mtl == transformers ++ monads-fd, mtl-tf == transformers ++ monads-tf. The improved portability and modularity of transformers and its associated packages is why mtl is uncool these days, I think.

mmtl and mtlx both seem to be similar to and/or based on mtl, with API differences and extra features.

MonadLib seems to have a rather different take on matters, but I'm not familiar with it directly. Also seems to use a lot of GHC extensions, more than the others.

At a glance compose-trans seems to be more like metaprogramming stuff for creating monad transformers. It claims to be compatible with Control.Monad.Trans which... I guess means mtl?

At any rate, I'd suggest the following decision algorithm:

• Do you need standard monads for a new project? Use transformers & co., help us lay mtl to rest.
• Are you already using mtl in a large project? transformers isn't completely compatible, but no one will kill you for not switching.
• Does one of the other packages provide unusual functionality that you need? Might as well use it rather than rolling your own.
• Still unsatisfied? Throw them all out, download category-extras, and solve all the world's problems with a page and a half of incomprehensible abstract nonsense breathtakingly generic code.

For the moment? You should probably use mtl. What is happening is that the transformers library is being factored out of the MTL in a fashion that monads-fd and monads-tf can co-exist peacefully, but at last check that was not yet the case.

When that happens you'll be able to import monads-fd and transformers and get (almost) the same interface, with the exception that State, etc. will be an alias for StateT.

So I'd write to mtl, but not rely on the fact that State, Reader, etc. are currently data as they will be replaced with types.

MonadLib is another alternative that Iavor has been working on, which can be safely used because it doesn't share any module names with the others, but which has a fairly different usage pattern.

The factoring out Edward Kmett mentions in his answer was completed in late 2010. Its end result was monads-fd, built upon transformers, becoming version 2 of mtl. As a consequence of the ubiquitousness of mtl, monads-tf never really caught on. As of early 2017, mtl and transformers are the only monad transformer libraries that see widespread usage.