Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
On Thu, Jul 8, 2010 at 12:37 PM, Yitzchak Gale g...@sefer.org 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
On Fri, Jul 09, 2010 at 03:13:19PM -0400, Edward Kmett wrote: On Thu, Jul 8, 2010 at 12:37 PM, Yitzchak Gale g...@sefer.org wrote: 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. =) Actually they're in transformers with the type constructors. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
G'day all. Quoting Ertugrul Soeylemez e...@ertes.de: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
On 8 July 2010 17:07, a...@spamcop.net wrote: G'day all. Quoting Ertugrul Soeylemez e...@ertes.de: 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. So true... :-( /me is still upset that reading a file requires IO... :p -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Transformers versus monadLib versus...
Ivan Miljenovic ivan.miljeno...@gmail.com wrote:
On 8 July 2010 13:48, Ertugrul Soeylemez e...@ertes.de wrote:
Ivan Miljenovic ivan.miljeno...@gmail.com wrote:
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.
Yes, that's true. And my point is that that doesn't mean you shouldn't
use 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.).
They are easy to use and very useful, especially to make code more
modular. You should try them out.
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/Control-Monad-Trans-State-Lazy.html#t%3AState
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.
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
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
Ertugrul Soeylemez e...@ertes.de writes:
Ivan Miljenovic ivan.miljeno...@gmail.com 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/Control-Monad-Trans-State-Lazy.html#t%3AState
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.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Transformers versus monadLib versus...
Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote:
Ertugrul Soeylemez e...@ertes.de writes:
Ivan Miljenovic ivan.miljeno...@gmail.com 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?
A lot of people try the most popular things first, just to find out that
the less popular things can have better quality. Monad transformer
packages are just one example. Another example is the very language
itself. I came from C++ and I wouldn't go back. I came from mtl and I
wouldn't go back. Same story.
After all we've got the choice, so not choosing the way most people go
shouldn't be flagged as something evil. There is nothing wrong with
using packages, which are not in the platform. You'll need one or the
other anyway for most projects. When it comes to conflicting packages
you should choose the one with the highest quality for you.
Caballess portability (i.e. being in the platform) may be a quality
criterion and in some cases even be more important than technical
superiority. However, it is not for my projects. And even if it were,
you get the 'cabal' utility with the platform, so you can install
monadLib easily.
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 ;-)
I don't use monads only when I absolutely need them. I use them almost
everywhere. Note that monads don't necessarily model hidden state.
There are a lot of other useful monads. =)
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/Control-Monad-Trans-State-Lazy.html#t%3AState
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.
Yes, monadLib has 'State s a', but not as a type alias like in
transformers, but as a newtype. I don't know the rationale behind this
design choice. Probably arbitrary. It has one drawback: you need
separate running functions. I don't see any advantages. I'd probably
write my own type aliases instead of using the newtypes.
Whilst technical superiority is good, a low barrier to entry
(including good documentation) is just as good, and at times better.
That's true. However, I as a non-beginner will go with the technical
superiority.
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
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
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? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Transformers versus monadLib versus...
Yves Parès limestr...@gmail.com wrote: 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? So far this has never been a problem. These packages always came along with custom running and access functions. If that wasn't the case, well, I would choose the ugly way through qualified imports, but this has never happened to me: import qualified Control.Monad.Trans as MTL import MonadLib 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
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
G'day all. Quoting Ertugrul Soeylemez e...@ertes.de: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Transformers versus monadLib versus...
a...@spamcop.net wrote: Quoting Ertugrul Soeylemez e...@ertes.de: 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. What's the matter? The more popular languages don't even go that far to implement an advanced concept like monads /at all/. They are slowly adopting what Haskell programmers take for granted. Look at how monads are implemented in F# or even C#. This is WAY behind Haskell. They don't even know about transformers, only about monads, and only in a very modest way. Do you realize at what level we are complaining? We are complaining that a wonderful feature could be implemented in a more elegant, more wonderful way. Programmers in other languages wouldn't even know that this wonderful feature exists. But my point is that not fragmenting the user base means not using Haskell or Linux, because everybody uses Windows and C++. This is not related to quality at all. This is just to show how invalid the argument is that we shouldn't fragment the user base. 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. 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. Iavor S. Diatchki has done a great job. 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
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
On 8 July 2010 13:36, Ertugrul Soeylemez e...@ertes.de 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.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Transformers versus monadLib versus...
Ivan Miljenovic ivan.miljeno...@gmail.com wrote:
On 8 July 2010 13:36, Ertugrul Soeylemez e...@ertes.de 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.
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. And I don't know what
you mean by pre-existing type aliases.
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
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
On 8 July 2010 13:48, Ertugrul Soeylemez e...@ertes.de wrote:
Ivan Miljenovic ivan.miljeno...@gmail.com wrote:
On 8 July 2010 13:36, Ertugrul Soeylemez e...@ertes.de 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/Control-Monad-Trans-State-Lazy.html#t%3AState
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
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 e...@ertes.de Gregory Crosswhite gcr...@phys.washington.edu 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Transformers versus monadLib versus...
Yves Parès limestr...@gmail.com 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
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
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 e...@ertes.de Yves Parès limestr...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Transformers versus monadLib versus...
Yves Parès limestr...@gmail.com wrote: 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? You don't, unfortunately. I would probably use both mtl and monadLib or even rewrite 'operational' to support monadLib. (btw, I like the fact that monadLib provides IdT ^^ (IdentityT)) Haven't found a use for it though. =) 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
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Transformers versus monadLib versus...
Yves Parès limestr...@gmail.com 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. 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
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
On Tue, Jul 6, 2010 at 12:05 PM, Ertugrul Soeylemez e...@ertes.de wrote: Yves Parès limestr...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Transformers versus monadLib versus...
Edward Kmett ekm...@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. 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. 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
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
On Tue, Jul 6, 2010 at 10:01 PM, Ertugrul Soeylemez e...@ertes.de wrote: Edward Kmett ekm...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Transformers versus monadLib versus...
Gregory Crosswhite gcr...@phys.washington.edu 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
