MTL vs Transformers. Any status update?

[Michael Snoyman]

On Sun, Nov 29, 2009 at 9:37 PM, Alexander Dunlap <
alexander.dunlap at gmail.com> wrote:

> 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
>

Sounds reasonable to me. Shall we take a vote on which one it'll be? If
FunDeps is really being deprecated, it would appear that tf is the way
forward...

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20091129/299a1789/attachment.html