Henning Thielemann wrote:
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.
Oh right, we already discussed that in this thread. Essentially we have the choice of producing full compatibility by keeping the separate type in mtl, in which case State from mtl is not State from transformers, or partial compatibility by re-exporting the transformers one. We can test hackage (which isn't the entire world, but is a lot of it) to decide which to do.
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 that after the relative chaos of the base 2 -> base 3 upgrade, the general policy nowadays is to minimise disruption when changing things. Completely removing a package from extralibs seems quite disruptive to me.
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?
I'm not convinced that individual developers would make this move very quickly, especially since the disruption wouldn't directly manifest in their packages, but only in things that use their packages. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================