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

Hello, On Thu, Aug 5, 2010 at 2:36 AM, Ivan Lazar Miljenovic wrote:

Iavor Diatchki writes:

...

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.

Well, the idea was to call the new library inductive-graphs, so the library would be in Graph.Inductive.  This would then fit in nicely and be obviously connected to the overall graph-classes library which would be in the "Graph" module itself.

So, if the package is called "inductive-graphs" place everything in "InductiveGraphs.*". Then, to use the library I simply need to write "import InductiveGraphs" (unless I wanted more control over names, and then I could import individual modules). In this way, when someone else decides to write another graph library, they could put it in their own package namespace, and there would be no need to have this same discussion again. This naming convention even supports a single project using multiple graph libraries, which may be useful if the different implementations provide different performance trade-offs. -Iavor