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