[Haskell-cafe] Re: mtl design (was ``What do _you_ want to see in
ivan.miljenovic at gmail.com
Tue Apr 27 21:41:49 EDT 2010
On 28 April 2010 11:22, Bradford Larsen <brad.larsen at gmail.com> wrote:
> Could you elaborate on what you mean regarding the mtl approach &
> design? What makes them bad?
Neil seems to have summed up the detractors opinions of mtl quite well
at http://chplib.wordpress.com/2010/04/09/removing-mtl-dependency/ .
Short version: mtl isn't Haskell98, uses some extensions (notably
Functional Dependencies) and has some bugs/design flaws. Several
people have written competing libraries such as transformers, but no
one library has emerged as the "successor" to mtl yet, which is why
mtl is still the Platform.
The problem is partially self-fulfilling:
1) No clear successor to mtl (which is still widely used), so keep mtl
in the Platform.
2) Someone wants to write some code using monad transformers; mtl
comes with the Platform (and is widely used) so they stick with it
2a) Someone searching on Hoogle for transformers, State monad, etc.
finds links to mtl so they use it.
3) mtl gets used by more packages than other libraries, and so we go back to 1).
Note that I too have fallen into stage 2): for SourceGraph, I wanted a
RWS monad so I stuck with mtl because it's been around, used so much,
no clear successor, etc. (the only argument that didn't apply to me
was "it's in the Platform" since I personally don't use the Platform).
This is what I want to avoid for FGL: developing a better, more modern
version (though differing from the mtl case in that I plan on using
extensions for FGL) only to find that people don't use it because
they're used to FGL being the de-facto graph library for Haskell and
hence don't use the new library with a different name.
Also, if it gets called FGL', what happpens when it fully takes over
and FGL is no longer used? The prime becomes redundant...
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
More information about the Haskell-Cafe