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

Ivan Lazar Miljenovic ivan.miljenovic at gmail.com
Thu Aug 5 05:49:18 EDT 2010


Gwern Branwen <gwern0 at gmail.com> writes:

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

Well, the latest plan was to have inductive-graphs be a new library and
FGL act as a wrapper upon it once its API has stabilised.  However, to
try and preserve FGL's current API this means that one of the two
following solutions has to be chosen:

1) Use something other than Data.Graph.Inductive.* for inductive-graphs.
   I have as yet not seen any good alternate module namespace to use
   that's under Data.Graph.

2) Have inductive-graphs use Data.Graph.Inductive.*, and then use
   PackageImports for FGL.  This is a rather hacky solution and even
   less portable.

In this case, it's very simple for maintainers to co-ordinate with each
other, since Thomas and I are the maintainers for both (at least for the
Data.Graph.Inductive case) :p

I could live with Data.Graph.Classes for graph-classes though.

Also, the difference between what I'm proposing and say Monads is that
Monads are an abstraction on flow; graphs are a classification of a type
of data structure.

My basis for proposing such a new top-level namespace is that whilst I
can go ahead with my original intention of using FGL for the new
package, etc. I'd much rather reach a consensus that everyone (or at
least a majority) is happy with such that the FGL package itself is
still maintained (and I don't want to have to look after two libraries
that are basically the same but implemented completely differently).  As
such, how to deal with the namespace clash between the two (if they're
kept separate) is currently the biggest stumbling block.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
IvanMiljenovic.wordpress.com


More information about the Libraries mailing list