mtl, transformers, and monads-fd are in an unhappy place
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? Regards, Bryan.
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
On Fri, Sep 10, 2010 at 12:32:38PM -0700, Bryan O'Sullivan wrote:
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.
The plan is to rename the current monads-fd (which depends on transformers) as version 2.0 of mtl. Now does seem to be the time to propose it. On Fri, Sep 10, 2010 at 12:37:12PM -0700, Don Stewart wrote:
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.
Someone needs to push this proposal, and I'm happy to do it. After that, I think these packages should be community managed, with changes via the library submission process (as for mtl now). There will be some breakage (two dozen packages in my most recent test). I will work up a library+HP proposal.
Bryan O'Sullivan schrieb:
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
In transformers-0.2 the module Control.Monad.Trans was split into Control.Monad.Trans.Class and Control.Monad.IO.Class. Thus if the transformers-dependent packages switch to transformers-0.2 you do not need PackageImports.
participants (4)
-
Bryan O'Sullivan -
Don Stewart -
Henning Thielemann -
Ross Paterson