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