On 28 April 2010 11:22, Bradford Larsen
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@gmail.com IvanMiljenovic.wordpress.com