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

Ivan Lazar Miljenovic

5 Aug 2010 5 Aug '10

2:49 a.m.

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. The three main reasons for such a new top-level namespace are: * Avoid module clashes (ala mtl and monads-{fd,tf}): for my still-vapourware graph classes library I would have to use Data.Graph.Classes or some such due to Data.Graph being used by the containers library; the new library Thomas Bereknyei are working on can then use Graph.Inductive to avoid clashing with FGL's Data.Graph.Inductive. * Reduce the length of module names: this reason might not mean as much and the net benefit would be minimal, but something like Graph.Inductive.Algorithms.Directed is a bit nicer than Data.Graph.Inductive.Algorithms.Directed * Not all graph-related modules are necessarily strictly about data-types, etc. (and I can't find any distinction about what defines the Data.* namespace anyway); e.g. my graphviz library currently uses Data.GraphViz.*, though it should arguably go under Graphics.* instead (it's currently under Data.* because that's how I found it when I took over maintainership). So, am I able to start using Graph as a new top-level namespace? The end goal is that eventually all graph-related libraries will use this namespace (whereas currently most such libraries use Data.Graph.*, graphviz being the notable exception). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Show replies by date

Gwern Branwen

5 Aug 5 Aug

3:41 a.m.

On Thu, Aug 5, 2010 at 2:49 AM, 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.

The three main reasons for such a new top-level namespace are:

* Avoid module clashes (ala mtl and monads-{fd,tf}): for my still-vapourware graph classes library I would have to use Data.Graph.Classes or some such due to Data.Graph being used by the containers library; the new library Thomas Bereknyei are working on can then use Graph.Inductive to avoid clashing with FGL's Data.Graph.Inductive.

* Reduce the length of module names: this reason might not mean as much and the net benefit would be minimal, but something like Graph.Inductive.Algorithms.Directed is a bit nicer than Data.Graph.Inductive.Algorithms.Directed

* Not all graph-related modules are necessarily strictly about data-types, etc. (and I can't find any distinction about what defines the Data.* namespace anyway); e.g. my graphviz library currently uses Data.GraphViz.*, though it should arguably go under Graphics.* instead (it's currently under Data.* because that's how I found it when I took over maintainership).

So, am I able to start using Graph as a new top-level namespace? The end goal is that eventually all graph-related libraries will use this namespace (whereas currently most such libraries use Data.Graph.*, graphviz being the notable exception).

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

Iavor Diatchki

4:14 a.m.

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. -Iavor On Thu, Aug 5, 2010 at 12:41 AM, Gwern Branwen wrote:

...

On Thu, Aug 5, 2010 at 2:49 AM, 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.

The three main reasons for such a new top-level namespace are:

* Avoid module clashes (ala mtl and monads-{fd,tf}): for my still-vapourware graph classes library I would have to use Data.Graph.Classes or some such due to Data.Graph being used by the containers library; the new library Thomas Bereknyei are working on can then use Graph.Inductive to avoid clashing with FGL's Data.Graph.Inductive.

* Reduce the length of module names: this reason might not mean as much and the net benefit would be minimal, but something like Graph.Inductive.Algorithms.Directed is a bit nicer than Data.Graph.Inductive.Algorithms.Directed

* Not all graph-related modules are necessarily strictly about data-types, etc. (and I can't find any distinction about what defines the Data.* namespace anyway); e.g. my graphviz library currently uses Data.GraphViz.*, though it should arguably go under Graphics.* instead (it's currently under Data.* because that's how I found it when I took over maintainership).

So, am I able to start using Graph as a new top-level namespace? The end goal is that eventually all graph-related libraries will use this namespace (whereas currently most such libraries use Data.Graph.*, graphviz being the notable exception).

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.

-- gwern _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Ivan Lazar Miljenovic

5:36 a.m.

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. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Iavor Diatchki

6 Aug 6 Aug

2:48 a.m.

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

Ivan Lazar Miljenovic

5 Aug 5 Aug

5:49 a.m.

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

Bulat Ziganshin

4:37 a.m.

Hello Ivan, Thursday, August 5, 2010, 10:49:49 AM, you wrote:

...

* Not all graph-related modules are necessarily strictly about data-types, etc. (and I can't find any distinction about what defines the Data.* namespace anyway); e.g. my graphviz library currently uses Data.GraphViz.*, though it should arguably go under Graphics.* instead (it's currently under Data.* because that's how I found it when I took over maintainership).

i think that it will be better to use Data.Graph.* for data structures and Graphics.* for GUI functions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Ivan Lazar Miljenovic

5:33 a.m.

Bulat Ziganshin writes:

...

Hello Ivan,

Thursday, August 5, 2010, 10:49:49 AM, you wrote:

...
* Not all graph-related modules are necessarily strictly about data-types, etc. (and I can't find any distinction about what defines the Data.* namespace anyway); e.g. my graphviz library currently uses Data.GraphViz.*, though it should arguably go under Graphics.* instead (it's currently under Data.* because that's how I found it when I took over maintainership).

i think that it will be better to use Data.Graph.* for data structures and Graphics.* for GUI functions

Well, graphviz is dealing with visualising graphs; as such it isn't a general graphics library. If my proposal was approved, I was intending to shift it to "Graph.Visualisation.Graphviz" or some such. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

wren ng thornton

8:56 a.m.

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.

+1.

...

* Not all graph-related modules are necessarily strictly about data-types, etc. (and I can't find any distinction about what defines the Data.* namespace anyway); e.g. my graphviz library currently uses Data.GraphViz.*, though it should arguably go under Graphics.* instead (it's currently under Data.* because that's how I found it when I took over maintainership).

For me, this is the most salient issue (though module clashes are certainly a pragmatic concern). The Data.* namespace seems to have become the default these days, and it seems like many of the things in there aren't data structures--- that is, they aren't data structures first and foremost. Instead, they are often auxiliary structures for supporting some specific algorithm or UI toolkit. Everybody uses data structures, but that doesn't mean everyone's code should end up in Data.*. Graphs are a salient object of study in their own right, above and beyond their status as data structures. They also blur a number of distinctions such as data vs GUI, structures vs algorithms, etc. Thus, I support the new fgl library putting things in Graph.Inductive.*. -- Live well, ~wren

Ivan Lazar Miljenovic

12 Aug 12 Aug

10:32 p.m.

...

From this proposal, I had three responses: one for Graph.*, one against and one to have per-package namespaces.

Does anyone else have an opinion? If not, Thomas and I will probably go forward with using Graph.* for the new set of graph libraries (as it seems not many people really care and in that case we might as well do it this way which lets us avoid the module clashing with FGL). On 5 August 2010 16:49, 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.

The three main reasons for such a new top-level namespace are:

* Avoid module clashes (ala mtl and monads-{fd,tf}): for my still-vapourware graph classes library I would have to use Data.Graph.Classes or some such due to Data.Graph being used by the containers library; the new library Thomas Bereknyei are working on can then use Graph.Inductive to avoid clashing with FGL's Data.Graph.Inductive.

* Reduce the length of module names: this reason might not mean as much and the net benefit would be minimal, but something like Graph.Inductive.Algorithms.Directed is a bit nicer than Data.Graph.Inductive.Algorithms.Directed

* Not all graph-related modules are necessarily strictly about data-types, etc. (and I can't find any distinction about what defines the Data.* namespace anyway); e.g. my graphviz library currently uses Data.GraphViz.*, though it should arguably go under Graphics.* instead (it's currently under Data.* because that's how I found it when I took over maintainership).

So, am I able to start using Graph as a new top-level namespace? The end goal is that eventually all graph-related libraries will use this namespace (whereas currently most such libraries use Data.Graph.*, graphviz being the notable exception).

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

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

Ross Paterson

13 Aug 13 Aug

10:01 a.m.

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

Ivan Lazar Miljenovic

10:18 a.m.

Ross Paterson 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@gmail.com IvanMiljenovic.wordpress.com

5394

Age (days ago)

5402

Last active (days ago)

List overview

Download

11 comments

6 participants

participants (6)

Bulat Ziganshin
Gwern Branwen
Iavor Diatchki
Ivan Lazar Miljenovic
Ross Paterson
wren ng thornton