On Sat, 21 Mar 2009, Sittampalam, Ganesh wrote:
Henning Thielemann wrote:
We already found out, that compatibility to mtl cannot be achieved with a package based on transformers.
Can you elaborate on this or point me at the past discussion? I can't find anything from a quick look through the archives, apart from the issue that haddock will go wrong if mtl just re-exports things from transformers.
In mtl State is a type with constructor State, whereas in transformers State is a type synonym with no custom constructor. So, if mtl uses the State type synonym from transformers it cannot be compatible with old mtl versions.
So why shall we rewrite mtl in terms of transformers+monad-fd at all? I welcome advertising transformers+transformers+monad-fd, but I don't see the benefits of breaking mtl.
If we don't make mtl and transformers use the same types, we will have some packages with interfaces that use one and some with interfaces that use the other for quite a long time to come.
That's why I think that we should extensively tell people to use 'transformers' instead of 'mtl'.
Also, if mtl stays in extralibs/the Haskell Platform but remains incompatible with transformers, then it will be in some way blessed which will hinder a move to transformers, but if we suddenly remove it then a lot of people will suddenly have to go and find it from hackage when previously they got it with GHC.
I don't like people forcing this way, as I for myself could spend my whole life keeping my Haskell libraries up-to-date without adding any feature or fixing any bug. I think, mtl should be removed from extralibs, but it should not be upgraded in an incompatible way. We would break packages, not more. I think, incompatibility between libraries based on mtl and those based on transformers is enough hassle to make developers think about a move to 'transformers'. I remember this was your motivation, too, right?