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

[wren ng thornton]

Ivan Lazar Miljenovic 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.

+1.

> * 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).

For me, this is the most salient issue (though module clashes are 
certainly a pragmatic concern). The Data.* namespace seems to have 
become the default these days, and it seems like many of the things in 
there aren't data structures--- that is, they aren't data structures 
first and foremost. Instead, they are often auxiliary structures for 
supporting some specific algorithm or UI toolkit. Everybody uses data 
structures, but that doesn't mean everyone's code should end up in Data.*.

Graphs are a salient object of study in their own right, above and 
beyond their status as data structures. They also blur a number of 
distinctions such as data vs GUI, structures vs algorithms, etc. Thus, I 
support the new fgl library putting things in Graph.Inductive.*.

-- 
Live well,
~wren