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

[Ivan Lazar Miljenovic]

Ross Paterson <ross at soi.city.ac.uk> writes:

> On Thu, Aug 05, 2010 at 04:49:49PM +1000, Ivan Lazar Miljenovic 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.
>
> Graphs aren't a huge application area, and can be viewed as a data type,
> so I think the question being raised here amounts to: shall we abandon
> the original idea of a strictly limited number of top-level nodes in
> the module hierarchy, and move to a much flatter hierarchy?  That would
> obviously make for shorter module names and make it easier to avoid
> name clashes, but I think there's also value in having more structure
> in module names, particularly at the top level.

True.

> In this particular case, the name-clash benefit would be a one-off.
> And wouldn't it be better to take over FGL and evolve it rather than
> forking?

I agree, but a lot of other people don't (but not enough according to my
recent survey to make it obvious what the preferred option is).

My main reason for "forking" is that as it currently stands, people may
choose to keep the current version of FGL that is in the platform rather
than upgrade to the new version.  As such, I'm hoping that by having a
separate package this might reduce the hostility and encourage people to
not treat this as a Parsec 2 vs 3 thing.

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