
Gwern Branwen
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@gmail.com IvanMiljenovic.wordpress.com