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

[Iavor Diatchki]

Hi Ivan,

I think that Graph is a very general top-level name and, as such, it
is likely to result in conflicts.  Why not pick a name for your
package (e.g., FGL or whichever new name was settled upon) and name
the modules FGL.*?  This has the benefit of short names (no need to
prefix everything with the meaningless Data.Graph).  It also avoids
conflicts, as long as developers agree to choose different names for
their packages---something they have to do if they are using Hackage
anyway.  Last, but not least, it makes the relationship between
packages and modules more obvious, which is very helpful when
maintaining or trying to understand code.

-Iavor


On Thu, Aug 5, 2010 at 12:41 AM, Gwern Branwen <gwern0 at gmail.com> wrote:
> 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>