transformers versus mtl

[Alexander Dunlap]

On Fri, Mar 20, 2009 at 9:47 AM, Ross Paterson <ross at soi.city.ac.uk> wrote:
> On Thu, Mar 19, 2009 at 05:14:22PM -0000, Sittampalam, Ganesh wrote:
>> Would now be a good time to start it, or do we need more experience
>> of transformers?
>
> Perhaps sooner would be better that later, as there are so many packages
> involved (~350, of which over 100 include mtl types and classes in their
> interfaces).
>
> I think it's necessary to split off the multi-parameter type classes
> from the rest, so that the transformers can be used either on their
> own or with type families, and clients of the different configurations
> can be used together.
>
> A transition will be disruptive, as only 30 of the packages have
> upper bounds on their mtl dependencies, but I think we can reduce the
> disruption.
>
> The combination transformers + monads-fd is close to a compatible
> replacement for mtl at the source level, except that State, Writer,
> etc are now type synonyms, which will break some code.  Of course the
> package names are also different.  We can't just rename monads-fd as
> mtl-2.0, because Control.Monad.Identity and Control.Monad.Trans are in
> the transformers package.  But we could make a compatibility version of
> mtl along the lines of base3-compat.  (And we need to rename the modules
> in monads-tf.)
>

The other thing to think about is with regards to
FunctionalDependencies vs. TypeFamilies. If we have two different
libraries, one providing a TF interface and one providing an FD
interface, we will naturally have some developers using one of them
and others using another, based on personal preference. This is all
well and good for application code, but it gets messy for libraries.
If package foo declares some datatypes and makes them instances of
monads-tf classes, and package bar declares some datatypes and makes
them instances of monads-fd classes, then it will be hard for an
application or another library to use both foo and bar in conjunction
with each other because they will not be using the same monad classes.
Would it be best practice for libraries to depend on *both* packages
and declare instances for both classes?

Alex