And in the example, you would just have this:

foo :: (InductiveGraph (g a b)) => g a b -> Iterated (g a) b

you might need some explicit type-family constraints in there as well to force/state that NodeLabel (g a b) ~ a and EdgeLabel (g a b) ~ b though. As an example of this, see the (really kludgy due to the afore-mentioned current limitations with Type Families), see the class currently called “MappableGraph” at http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs (once code.haskell.org is back up).

As for examples, anything that uses polymorphic recursion will break:

data Iterated f a = a :- Iterated f (f a)

foo :: Graph g => g a b -> Iterated (g a) b

As I’ve said, we’d be doing our best to ensure that all users of FGL will migrate to the new version to avoid the problems that plagued Parsec, QuickCheck, etc. (though I repeat that I still think this is going to be a much lesser problem than those due mainly to the fewer number of users of FGL).

Finally, I’m not sure what you mean by those programs that won’t be able to be used under the new version of FGL. Care to provide some examples?

I know that there are problems doing large-scale API changes for any library. However, my main goal here is to try and prevent stagnation in the graph-related Haskell libraries, of which FGL is a major part. As it stands, I feel that there’s not much more that can be done with the current layout of FGL that will not result in major API breakage, in which case there’s no point in having anyone replace Martin as maintainer (except for fixing dependency problems when a library such as base changes in a non-backwards compatible fashion). I also think it’s a bit of a minus for FGL if people like Cale Gibbard (who I think is the graph-theoretic guy in the Haskell community, or at least in #haskell) refuse to use it and prefer to roll their own every time they need a graph data structure.

Otherwise you’ll wind up with the mtl/transformers parsec-2/parsec-3 etc probably all over again.

That and there are some programs that can be typed with the existing FGL that will not be able to be typed under the version you’ve described. (Those that use the graph in a polymorphically recursive manner relying on the ability to be parametric in the node or label type.)