transformers versus mtl
ganesh.sittampalam at credit-suisse.com
Sun Mar 22 02:31:08 EDT 2009
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
Please access the attached hyperlink for an important electronic communications disclaimer:
More information about the Libraries