monadLib looks nice, indeed, but the major problem with using it resides in the fact that most of the libraries on hackage use MTL. Must be tedious to have to use two monad libraries at the same time... 2010/7/6 Ertugrul Soeylemez

Gregory Crosswhite wrote:

...

What is the current state of opinion regarding transformers versus monadLib versus mmtl versus ... etc.? Transformers seems to be the "blessed" replacement for mtl, so when is it worthwhile to use the other libraries instead?

(It hadn't even occurred to me to look closely at packages other than transformers for this purpose until I read a message earlier today from someone who said that he uses monadLib whenever he needs to use monad transformers, and it has now made me curious about them.)

That would be me. When I was sick of flipping runWhateverT all the time, I had a closer look at the 'transformers' package. But my impression was that the only advantage is that I wouldn't need to flip anymore.

I compared it to monadLib, which does a lot more. It saves me from having to do multi-lifts in complicated monads and it has a generalized MonadIO, called BaseM, which works for other lowest-level-monads, too, like 'ST s'. It includes a ChoiceT monad transformer, which is like ListT, but is not broken.

Further it has very useful monadic functions. For example there is an 'abort' function to escape from a ContT computation, so you don't need to use that ugly callCC, if you just want early exit route. You also get labelled jumps for free, if you ever need them desperately.

As an interesting feature, if you have a monad, which is isomorphic to a known monad, you can derive all the Functor/Monad instance functions from this isomorphism. All you need to do is to tell monadLib how one would turn a computation of the monad in question into a computation of the known monad.

Greets, Ertugrul

-- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Yes but, for instance, every library which provides monad transformers will provides a MTL's MonadTrans instance, not a monadLib's MonadT instance. And since a library hides its types internals, you cannot write the MonadT instances yourself. For instance, I was planning to translate a little program of mine (which uses quite heavily monad transformers) to monadLib. It uses the packages operational which is based on MTL, and I cannot make myself operational's transformers instances of MonadT. How would you solve that? (btw, I like the fact that monadLib provides IdT ^^ (IdentityT)) 2010/7/6 Ertugrul Soeylemez

Yves Parès wrote:

...

monadLib looks nice, indeed, but the major problem with using it resides in the fact that most of the libraries on hackage use MTL. Must be tedious to have to use two monad libraries at the same time...

In general this is a minor problem. Note that when using a monad from another library usually you get provided with a type alias (or even a newtype) and a number of convenience functions, so you don't have to access names from both libraries at the same time.

I can only speak for myself, but I've never had a problem with this, even though my packages often have lots and lots of dependencies.

Greets, Ertugrul

-- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I was wondering : wouldn't it be possible that things like BaseM be implemented on top of MTL? Couldn't just one develop a package, say mtl-missing, that would contain the functionnalities of monadLib, but compatible with MTL?

On Tue, Jul 6, 2010 at 12:05 PM, Ertugrul Soeylemez wrote:

Yves Parès wrote:

...

I was wondering : wouldn't it be possible that things like BaseM be implemented on top of MTL? Couldn't just one develop a package, say mtl-missing, that would contain the functionnalities of monadLib, but compatible with MTL?

I don't know whether they're compatible. Also there is probably nothing to implement from mtl in monadLib, so the more natural choice is not to use mtl at all and just use monadLib.

I'd hate to be forced to go back to mtl. Better update 'operational' to support monadLib. Go forward to a good design instead of trying to keep old, broken designs alive.

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. -Edward Kmett

On Tue, Jul 6, 2010 at 10:01 PM, Ertugrul Soeylemez wrote:

Edward Kmett 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.

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

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

On Thu, Jul 8, 2010 at 12:37 PM, Yitzchak Gale wrote:

Hi Edward,

Edward Kmett wrote:

...

It looks like there is a fairly strong effort to fix most of the most egregious warts in the mtl.

btw, does this overhaul include adding Applicative instances, perchance?

They are already part of monads-fd and would, I presume, come along for the ride when an mtl = monads-fd + transformers release occurs. =) -Edward Kmett

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.

So tell me how you do when you have to use a package which relies on mtl's transformers? You re-develop the package?

G'day all. Quoting Ertugrul Soeylemez :

In its highest level "not fragmenting the user base" means going back to C++ and Windows.

Ha. You wouldn't say that if you were familiar with the current state of C++ on Windows. Since nobody has come out and admitted it, here's the real problem: What constitutes the best API for a monad library is still a research problem. This is evidenced by the fact that a few times a year we get yet another paper which proposes a fundamental change to the API which would improve matters in yet another direction. Transformers, monadLib and MTL all have their respective strengths and weaknesses, but they are all considerably behind the state of the art, if you go by published research. Andrew Bromage

On 8 July 2010 13:36, Ertugrul Soeylemez wrote:

To be honest, I don't know any strength of MTL compared to transformers and monadLib.  Actually even transformers is quite primitive compared to monadLib.  The only real advantage is that it has flipped run functions and a built-in MaybeT.

mtl's advantages: wide pre-existing user base, etc. transformers (especially when used with monads-{fd,tf}) advantage over monadLib: pre-existing type aliases, documentation, easier to port old code that was using mtl. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On 8 July 2010 13:48, Ertugrul Soeylemez wrote:

Ivan Miljenovic wrote:

...

On 8 July 2010 13:36, Ertugrul Soeylemez wrote:

...

To be honest, I don't know any strength of MTL compared to transformers and monadLib.  Actually even transformers is quite primitive compared to monadLib.  The only real advantage is that it has flipped run functions and a built-in MaybeT.

mtl's advantages: wide pre-existing user base, etc.

As said, I don't think this is a valid argument.  Windows has a much larger user base than Linux.  C++ has a much larger user base than Haskell.  We still use Haskell, and many of us use Linux.

My point was, was that if you need to pick a monad transformer library and you've never done any before, then some people are likely to choose mtl because it's currently the most-used library, it comes with the platform and if they need to interact with another package that uses a monad transformer library then it's more likely to be using mtl than anything else.

...

transformers (especially when used with monads-{fd,tf}) advantage over monadLib: pre-existing type aliases, documentation, easier to port old code that was using mtl.

If you don't use monadLib-specific features, then most code will run in monadLib as well as transformers without changes.  The Haddock documentation of monadLib is quite brief, but if you know how to use monad transformers, you won't have any problems.

I for one don't know how to use monad transformers (I mean, I've read the section in RWH and could figure it out, but off the top of my head I can't recall how to do all the lifting stuff, etc.).

And I don't know what you mean by "pre-existing type aliases".

http://hackage.haskell.org/packages/archive/transformers/0.2.1.0/doc/html/Co... -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Ertugrul Soeylemez writes:

Ivan Miljenovic wrote:

...

My point was, was that if you need to pick a monad transformer library and you've never done any before, then some people are likely to choose mtl because it's currently the most-used library, it comes with the platform and if they need to interact with another package that uses a monad transformer library then it's more likely to be using mtl than anything else.

Yes, that's true. And my point is that that doesn't mean you shouldn't use anything else.

You shouldn't, but if someone comes along and has never used one of these before, which are they most likely to use? The one that seems to be most popular and is "recommended" in that it's in the platform or one of the other ones with less publicity but is meant to be technically superior?

...

I for one don't know how to use monad transformers (I mean, I've read the section in RWH and could figure it out, but off the top of my head I can't recall how to do all the lifting stuff, etc.).

They are easy to use and very useful, especially to make code more modular. You should try them out.

I write stuff dealing with graphs; not much monadic stuff happening there ;-)

...

...

And I don't know what you mean by "pre-existing type aliases".

http://hackage.haskell.org/packages/archive/transformers/0.2.1.0/doc/html/Co...

MonadLib has newtypes instead of type aliases for them. But the implementations are the same (M = MT Id). Interestingly I need transformers much more often than ready-made monads.

You can use newtypes instead of aliases with transformers as well (well, actually you'd need monads-{tf,fd} to get the class, but still...). My point is, is that with a type alias it's a lot easier to "get up and go" and start hacking without having to explicitly do "StateT s Identity a" all the time and instead just use "State s a". Whilst technical superiority is good, a low barrier to entry (including good documentation) is just as good, and at times better. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

G'day all. Quoting Ertugrul Soeylemez :

Do you realize at what level we are complaining?

Yes, we're complaining at the level of the frustrated idealist, which is what many Haskell programmers are. Cheers, Andrew Bromage