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

Question

Hackage has several packages for monad transformers:

• mtl: Monad transformer library
• transformers: Concrete functor and monad transformers
• mon

Answer 1

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.