For review: changes to graph.m

[Lee Naish]

A few thoughts:

It would be nice to be able to get some idea of what kind of representation
is used (and hence the likely complexity of various operations) by looking at
the header comments.

Graphs are an excellent example of data which you may want to represent in
different ways at different times/places.  Perhaps some extra thought should
be put into how a collection of graph manipulation libraries could be managed
wrt names, conversion between different representations etc.  One possibility
would be to have a single library which uses several representations internally.
The init predicate could specify which representation to use and other predicates
could inspect the top level wrapper to determine what representation is used.

I also encourge some though about higher order predicates and graphs.  A couple
of examples: what higher order predicates would be useful with graphs and what
graph operations can be generalised.  One useful HO predicate is a version of
foldr for paths.  Path can be implemented by using cons and nil as the arguments.
The path predicate can be generalised to accept an edge relation rather than a
whole graph representation - that way I can have my own data structure which
includes the representation of a graph, implement an edge relation for it and
reuse the path code from the graph library.

	lee