MTL vs Transformers. Any status update?

Alexander Dunlap alexander.dunlap at gmail.com
Sun Nov 29 14:37:45 EST 2009


On Sun, Nov 29, 2009 at 11:08 AM, Michael Snoyman <michael at snoyman.com> wrote:
>
>
> On Sun, Nov 29, 2009 at 9:02 PM, Duncan Coutts
> <duncan.coutts at googlemail.com> wrote:
>>
>> On Sun, 2009-11-29 at 13:35 +0000, Ross Paterson wrote:
>> > On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote:
>> > > On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote:
>> > > > On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote:
>> > > > > Could someone remind me why it's better for use to ask everyone to
>> > > > > switch to monads-fd / transformers rather than to mtl-2? Does that
>> > > > > make
>> > > > > the transition easier?
>> > > >
>> > > > The problem is that transformers and mtl use the same module names,
>> > > > such as Control.Monad.Identity.  Unless one of these packages is
>> > > > hidden,
>> > > > people using ghci or ghc --make will have problems.
>> > >
>> > > Right, so having transformers + mtl is bad, but why do we want to end
>> > > up
>> > > with a situation where we have both? If you've all agreed what should
>> > > go
>> > > into the new monad package, can't we call that mtl-2 ? Why would we
>> > > want
>> > > to define things in one package and re-export them in another?
>> >
>> > Because there is not one new monad package, but two.  The idea is to
>> > split the mtl package to decouple monad transformers from functional
>> > dependencies.  The transformers part can then be used in Haskell 98
>> > code,
>> > or with type classes using type functions.  Exposed modules from mtl are
>> > split between the resulting two packages, so neither is a replacement
>> > for
>> > mtl-1.  As I said above, having both would be a transitional
>> > arrangement,
>> > on the way to replacing mtl with the two packages split from it.  mtl-2
>> > is an attempt to smooth that transition, but it would eventually go
>> > away.
>>
>> Ok, how about this:
>>
>> transformers    H98 bits, registered hidden by default
>> mtl 2           re-exports transformers, adds type function stuff
>> mtl-fd          alternative that uses FDs, hidden by default
>>
>> I'm not sure what you agreed, if you chose the FD one as default then
>> use mtl-tf as the alternative. Whichever you have chosen as the
>> recommended stuff should be called mtl 2, because that is the easiest to
>> explain to everyone.
>>
>> So all the packages now using mtl-1, move up to mtl 2. Then for packages
>> that only want transformers, they depend on transformers. Similarly for
>> the mtl-fd alternative (and whether that re-exports transformers or
>> whether such packages should depend on transformers + mtl-fd is up to
>> you).
>>
>> Users of ghci / ghc --make will end up using mtl 2 by default and there
>> will be no module name clashes because transformers and mtl-fd will by
>> hidden by default (Cabal-1.6+ can do that). The hiding does not affect
>> cabal packages of course.
>>
>> Duncan
>>
> Are you saying that mtl-2 would be the equivalent of transformers +
> monads-tf? That might not be a good call; monads-fd is probably more popular
> than monads-tf.
>
> Michael
>

What is the plan for letting the two co-exist? Is everyone going to
have to write instances that work with both monads-{tf,fd} and then
export duplicate functions that have monad classes in their
signatures? It seems like if we can't have a nice way to use both, we
ought to just pick one and deprecate the other.

Alex


More information about the Libraries mailing list