[Haskell-cafe] Re: Transformers versus monadLib versus...

[Edward Kmett]

On Tue, Jul 6, 2010 at 10:01 PM, Ertugrul Soeylemez <es at ertes.de> wrote:

> Edward Kmett <ekmett at gmail.com> wrote:
>
> > You may want to review the thread here:
> >
> > http://www.haskell.org/pipermail/libraries/2009-November/012833.html
> >
> > The gist of it is, I would recommend sticking with MTL for right now,
> > but confining yourself to the portions of it that transformers +
> > monads-fd export (i.e. using StateT s Identity instead of State, or
> > avoiding the use of the State constructors and instances on State)
> > until transformers is done being refactored and monads-fd +
> > transformers becomes more or less mtl compatible and the mtl shim =
> > monads-fd + transformers shim is introduced in a future haskell
> > platform. At that point in time you should be able to remove mtl and
> > just reference monads-fd (and/or monads-tf) + transformers.  This has
> > the benefit of not fragmenting the user base, letting you link against
> > the large quantities of code that is built on the haskell platform
> > (i.e. HTTP, etc), and provides an upgrade path to bring the code
> > written for use with transformers and the code written for use with
> > mtl into alignment so they can all link some day in the relatively
> > near future without cabal flipping its lid.
> >
> > Of course, adding support for monadLib, which doesn't conflict with
> > any of this is a completely concern.
>
> In its highest level "not fragmenting the user base" means going back to
> C++ and Windows.  So this doesn't appear like a valid argument to me.
> I'll choose the package with the highest quality, not the one, which
> most people use.
>


> Fragmenting Hackage is bad.  But on the other hand I don't see why I
> should stick with the inconvenient mtl.  Open source software is all
> about choice, and as long as the mtl fails to provide the same
> flexibility and convenience, I won't use it.  Combined with the fact
> that fixing it would break existing packages, it appears like I won't go
> back to the mtl ever.
>

It looks like there is a fairly strong effort to fix most of the most
egregious warts in the mtl. The borked Either instance looks likely to be
fixed as it gets moved into Base. The transformers are being split out and
the redundant base types are being turned into type aliases rather than
newtypes to reduce code duplication. Overall, I still have hope that the mtl
can remain relevant. Sadly this doesn't prevent me from working around the
mtl/transformers issue by defining my own monads locally until the conflict
gets resolved.


> MonadLib does conflict with the mtl, because it uses the same function
> and type names almost everywhere with only a few minor differences.  But
> that's seldomly a problem in actual applications.
>
> I did not mean to imply that monadLib is problematic. I think it handles
things the right way. It moves off to the side and defines a competing, well
designed API that can compete on its own merits and be adopted
incrementally. You can import either or both qualified and define instances
for whichever subset of the two tickles your fancy. In that sense monadLib
fares much better off than the current mtl vs. monads-fd+transformers
fiasco.

-Edward Kmett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100706/fb8e68b3/attachment.html