[feature request] Add functions for converting between various graph representations

[CicadaCinema]

Each of these are valid ways to represent a graph:

• https://en.wikipedia.org/wiki/Edge_list
• https://en.wikipedia.org/wiki/Adjacency_list
• https://en.wikipedia.org/wiki/Adjacency_matrix
• https://en.wikipedia.org/wiki/Incidence_matrix

Sometimes one particular representation is well suited to an application/algorithm. Implementing such conversions here will be convenient to save packages/applications from doing this work on a per-package basis.

[CicadaCinema]

Also, it would be good for various packages to be able to rely on one class/data structure for storing graph topology information (as opposed to implementing a graph class themselves), but this might be out of scope for this package given the tagline "Graph algorithms that do not specify a particular approach for representing a Graph".

[freemansoft]

Not sure if you actually mean "convert" representations or "provide implementations" of various representations. The graph library is storage agnostic but it would be nice to have some graph sample implementations.

I was going to submit some sample code to this repo but it wasn't clear what the team's goal is for places like the graph repo. Here are some first pass implementations at three of the models on your list https://github.com/freemansoft/fs-dart-tools

[natebosch]

Yes, defining data structures for graphs is explicitly out of scope for this package, as is defining translations between different structures.

We could accept some brief examples of calling these APIs alongside implementations of various graph structures in the examples/ directory. A fully production quality (for instance including long docs) implementation of any structure is likely too long for an example though.

Overall I think a different package (or more than one if there are different ideas for how to implement) makes sense for specific data structure implementations. The graphs package should slot in nicely alongside any other package since it is agnostic to the representation.

I'll close this as not planned since the Dart team doesn't intend on adding specific data structure implementations or tips.