[Haskell-cafe] What do _you_ want to see in FGL?

[Ivan Lazar Miljenovic]

Since I've volunteered myself to help maintain/upgrade FGL, what do the
people in the community want to see happen with it?

Here are some ideas that I have regarding FGL:

* I had already started working on a new generic graph class [1] (with
  initial draft at [2]) to act as a wrapper around FGL and other graph
  implementations.  However, if I'm going to be updating FGL anyway I
  might as well combine the two and generalise/update FGL instead.
  Generally speaking, this will involve the following items:

    - Splitting and expanding the typeclasses involved; most class
      methods would have default definitions but this will allow people
      to override the defaults if there's a more efficient way for their
      datatype.

    - Having a separate parameter (using associated types?) for the node
      type rather than just using Int.

    - Providing more "fundamental" graph operations that may be of use.

  However, the downside of this is that datatypes such as Data.Graph in
  containers won't match this anymore due to the lack of node and edge
  labels.  I think this fair price to pay, especially if the mapping
  aspects are split off into another typeclass.

  [1]: http://www.haskell.org/pipermail/haskell-cafe/2009-June/063402.html
  [2]: http://code.haskell.org/~ivanm/Graph.hs

* Better fundamental data structures: one of the things that has always
  annoyed me about FGL is how much it uses tuples; I propose re-defining
  the Context type to be a record-based data structure.  Also, usage of
  Sets, Maps, etc. where applicable.

* Proper instances: make graphs instantiate Eq, Ord, Show and Read
  (where read . show == id).  The Show and Read instances will probably
  usually be like how Data.Map has them, so helper functions can be
  defined to help out with this.

* Split off the instances: maybe keep one basic graph datatype in FGL,
  but then have separate packages for others (which means its easier to
  add new datatypes without needing a new release, etc.).

* Split off the various Data.Graph.Inductive.Query functions/algorithms,
  and merge in the ones I have defined in Graphalyze [3].

  [3]: http://hackage.haskell.org/package/Graphalyze

* Scrap Data.Graph.Inductive.Graphviz and recommend usage of my graphviz
  library [4] instead.

  [4]: http://hackage.haskell.org/package/graphviz

* Data.Graph.Inductive.Monad: does anyone actually use this?

* Benchmarks and tests.

What do other people think?  Any other suggestions?

Also, once I release the next version of graphviz (hopefully later
today), I was going to work on improving SourceGraph [5] by providing
command line options, etc. to it; would people prefer I work on FGL
instead?

[5]: http://hackage.haskell.org/package/SourceGraph

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