Has anyone ever encountered a Monad Transformer in the wild?

Question

In my area of business - back office IT for a financial institution - it is very common for a software component to carry a global configuration around, to log its progress, to

Answer 1

The concept behind monad transformers is quite tricky and hard to understand, monad transformers lead to very complex type signatures

I Think this is a bit of an exaggeration:

• To use a particular Monad stack of a transformer is no more difficult to use than a plain Monad. Just think about layers\stacks and you'll be fine. You almost always never need to lift a pure function (or specific IO action) more than once.
• As mentioned already hide your Monad stack in a newtype, use generalized derive and hide the data constructor in a module.
• Try not to use a particular Monad stack in function type signature, write general code with Monad type classes like MonadIO, MonadReader and MonadState (use flexible contexts extension which is standardized in Haskell 2010).
• Use libraries like fclabels to reduce boilerplate actions which access parts of record in a Monad.

Monad transformers are not your only options, you could write a custom Monad, use a continuation Monad. You have mutable references/arrays in IO (global), ST (local and controlled, no IO actions), MVar (synchronizing), TVar (transactional).

I've heard that the potential efficiency issues with Monad transformers could be mitigated just by adding INLINE pragmas to bind/return in the source of mtl/transformers library.