On Thu, Aug 5, 2010 at 2:49 AM, Ivan Lazar Miljenovic
As part of an attempt at resolving the FGL vs inductive-graphs naming mess, one solution that Edward Kmett and I thrashed out will involve utilising a new top-level module namespace of Graph.* instead of using Data.Graph.* as currently found in FGL. However, Don Stewart recommended that I ask of the collective wisdom that is the libraries mailing list before moving ahead with this proposal.
The three main reasons for such a new top-level namespace are:
* Avoid module clashes (ala mtl and monads-{fd,tf}): for my still-vapourware graph classes library I would have to use Data.Graph.Classes or some such due to Data.Graph being used by the containers library; the new library Thomas Bereknyei are working on can then use Graph.Inductive to avoid clashing with FGL's Data.Graph.Inductive.
* Reduce the length of module names: this reason might not mean as much and the net benefit would be minimal, but something like Graph.Inductive.Algorithms.Directed is a bit nicer than Data.Graph.Inductive.Algorithms.Directed
* Not all graph-related modules are necessarily strictly about data-types, etc. (and I can't find any distinction about what defines the Data.* namespace anyway); e.g. my graphviz library currently uses Data.GraphViz.*, though it should arguably go under Graphics.* instead (it's currently under Data.* because that's how I found it when I took over maintainership).
So, am I able to start using Graph as a new top-level namespace? The end goal is that eventually all graph-related libraries will use this namespace (whereas currently most such libraries use Data.Graph.*, graphviz being the notable exception).
Personally, I dislike this proposal. Yes, there are an awful lot of modules a well-developed graph ecosystem will have. But this is true of lists, or arrays, or any other extremely common and useful abstraction. (Should we have a toplevel Monad.* namespace because there are so ridiculously many monad libraries and transformers and whatnot?) Clashes are more an argument for merging and improving libraries, or at least maintainers coordinating with each other. -- gwern