mtl, transformers, and monads-fd are in an unhappy place

[Don Stewart]

bos:
> Hi, gents -
> 
> I've lately been writing some application code that, by virtue of the libraries
> it uses, depends on both mtl and monads-fd. Alas, this means that I have two
> incompatible versions of some of the most widely used monad transformers in
> scope, and I have to carefully import the right version of Control.Monad.Trans:
> 
> {-# LANGUAGE PackageImports #-}
> import qualified "mtl" Control.Monad.Trans as M
> import qualified "monads-fd" Control.Monad.Trans as F
> 
> Then I have to be equally careful in using the right version of liftIO
> depending on the monad I'm working in.
> 
> This is a really bad situation for some of the platform's core libraries to be
> in, even temporarily, as it puts a solid barrier in place to non-wizardly
> people due to the confusion induced, especially since the kind of code I'm
> writing is the kind of appealing-yet-vanilla stuff that I'd hope would simply
> work (using the Snap web framework and an XMPP library).
> 
> Greg Collins mentioned that there's some kind of plan for mtl to become a shell
> package that depends on transformers and monads-fd. Given my experience, I'd
> consider advancing this plan and getting it into the next Haskell Platform
> release (and ready before GHC 7 ships) to be a matter of the utmost urgency.
> 
> What kind of help can I provide you to rush this along?

There needs to be a maintainer to take over mtl, or
transformers/monads-*, with a roadmap for solving the diversity problem,
and a proposal to put the result in the HP. Ideally without breaking
things.

-- Don