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

[Ertugrul Soeylemez]

Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> wrote:

> Ertugrul Soeylemez <es at ertes.de> writes:
>
> > Ivan Miljenovic <ivan.miljenovic at 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/