
From this proposal, I had three responses: one for Graph.*, one against and one to have per-package namespaces.
Does anyone else have an opinion? If not, Thomas and I will probably
go forward with using Graph.* for the new set of graph libraries (as
it seems not many people really care and in that case we might as well
do it this way which lets us avoid the module clashing with FGL).
On 5 August 2010 16:49, 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).
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com