Incompatibility of different (monad transformer) libraries

Hi, ==== Problem instance ==== In my code, I use some monad transformers. I used to use the "mtl" package, but I recently switched to the combination "transformers"/"monads-tf" (mainly for the Applicative instances). The same code also uses the "haskeline" library, for line reading. Haskeline allows to edit the user's history (previously entered lines), but only through a Control.Monad.State interface, and that happens to be the Control.Monad.State from "mtl". So now, my package also needs to import "mtl". This combination of package dependencies gives import conflicts: whenever I import some Control.Monad.{State,Error,Cont,...} module, there is more than one package providing such a module. ==== Solution? ==== For now, I resolve the ambiguity by using "Package imports", i.e. annotate the ambiguous imports by the right package name. Is this the best solution? The ghc manual states, that the package import extension should not be necessary. I can think of another solution, by creating a dedicated package, which imports mtl:Control.Monad.* and re-exports them under another name, but that's even less elegant than package imports. What is the recommended way to deal with module name conflicts, such as this one? Regards, Arie BTW: how can I let the user edit a line of text, from a non-empty starting value for the text? (In other words, actually *edit* a line, not enter a new one.) I currently do this by adding the starting value to the user's history, so he/she can get it by pressing the up arrow key. This is clearly not optimal.

On Tue, 10 Mar 2009, ariep wrote:
==== Problem instance ====
In my code, I use some monad transformers. I used to use the "mtl" package, but I recently switched to the combination "transformers"/"monads-tf" (mainly for the Applicative instances).
The same code also uses the "haskeline" library, for line reading. Haskeline allows to edit the user's history (previously entered lines), but only through a Control.Monad.State interface, and that happens to be the Control.Monad.State from "mtl". So now, my package also needs to import "mtl".
This combination of package dependencies gives import conflicts: whenever I import some Control.Monad.{State,Error,Cont,...} module, there is more than one package providing such a module.
I think 'transformers' exports Control.Monad.Trans.State. This should not conflict with MTL. However, MTL's State type is different from transformer's one. Is that your problem?
==== Solution? ====
For now, I resolve the ambiguity by using "Package imports", i.e. annotate the ambiguous imports by the right package name.
Is this the best solution? The ghc manual states, that the package import extension should not be necessary. I can think of another solution, by creating a dedicated package, which imports mtl:Control.Monad.* and re-exports them under another name, but that's even less elegant than package imports.
Since the 'cabal' tool became better and better, today I use a cabal file even for small programs. Cabal automatically calls GHC with the right package exposing and hiding options.

On Sat, 14 Mar 2009 02:14:53 +0100 (CET), Henning Thielemann
I think 'transformers' exports Control.Monad.Trans.State. This should not
conflict with MTL. However, MTL's State type is different from transformer's one. Is that your problem?
No. The immediate problem is, that a module named Control.Monad.State is exported by both mtl and monads-tf (and my code needs both packages). It is indeed unfortunate that mtl:State is a different type from transformers:State, but that is not biting me right now.
Since the 'cabal' tool became better and better, today I use a cabal file
even for small programs. Cabal automatically calls GHC with the right package exposing and hiding options.
I already use cabal; my own package has mtl, transformers and monads-tf among its dependencies. Regards, Arie

On Mon, Mar 16, 2009 at 9:26 AM, Arie Peterson
It is indeed unfortunate that mtl:State is a different type from transformers:State, but that is not biting me right now.
If the type problem does ever become an issue, could the MTL use the types from the transformers package? Antoine
participants (4)
-
Antoine Latter
-
Arie Peterson
-
ariep
-
Henning Thielemann