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

[Gwern Branwen]

On Thu, Aug 5, 2010 at 2:49 AM, Ivan Lazar Miljenovic
<ivan.miljenovic at gmail.com> wrote:
> 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