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

[Iavor Diatchki]

Hello,

On Thu, Aug 5, 2010 at 2:36 AM, Ivan Lazar Miljenovic
<ivan.miljenovic at gmail.com> wrote:
> Iavor Diatchki <iavor.diatchki at gmail.com> 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