Data.Graph

[Milan Straka]

Hi Evan,

> I just fixed a bug in my program that came about because the same
> graph constructed in different orders compared inequal.  E.g.:
> 
> buildG (0, 2) [(0, 1), (0, 2)] /= buildG (0, 2) [(0, 2), (0, 1)]
> 
> It seems to me that these should compare equal.  This was easy for me
> to do since I wrap Graph in a newtype, but it's hard to do for Graph
> itself, since it's defined as a type synonym over Data.Array.
> 
> Do people agree that (==) is incorrect for Data.Graph, or is there a
> legitimate difference between the two graphs?  If people agree, what
> can be done to fix Data.Graph?  Should be add Data.Graph2 that is
> defined as a real type and start anew from there?
> 
> In general, it seems to me Data.Graph is very basic and has not
> received any love for a long time.  It's a thin wrapper over
> Data.Array, which is one of the more error-prone ornery APIs out
> there.  To use it I wound up writing lots of little utility functions
> to do things like add or remove edges which were fiddly and error
> prone.  I just noticed a package graph-wrapper, with the description
> "A wrapper around the standard Data.Graph with a less awkward
> interface", so I guess I'm not the only person to have felt that way.
> 
> Wouldn't it be nice to start taking steps toward having a graph
> library in the stdlib that people actually like?

As far as I know, Data.Graph has not been given any attention in quite
some time. I do not know whether someone is using it. As one of the
maintainers of containers, I can say that no-one is working on it
and you are even the first who had any comments about Data.Graph in
quite some time.

There is widely used library fgl, which is even in Haskell Platform,
and that definitely is being used.

Maybe we should separate Data.Graph (and probably Data.Tree) into
a separate package? Any thoughts?

Cheers,
Milan