Viability of having a new top-level "Graph" module namespace

[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 at gmail.com
IvanMiljenovic.wordpress.com