The main problem of what you are asking is that a more general solution is not the best for a specific problem. This is just average for everyone, but not the best.
Well, you can keep the list on the chart, assuming its degeneration, but why should you do something like that? And how would you save the hash map inside the chart? Why do you need such a structure?
And do not forget that the implementation of the graph should be selected in accordance with the operations that you are going to do with it, otherwise it will be like using a hash table to store a list of values or a list to store an ordered collection, instead a tree. You know that you can use an adjacency matrix, a list of edges, or an adjacency list .. every other implementation with its own strengths and weaknesses.
Then the graphs can have really many properties compared to other data sets, cyclic, acyclic, directional, non-oriented, dicotyledonous, etc. ... and for any particular case you can implement them differently (assuming some hypothesis about the graph you need), so having them in your own syntax will be excessive, because you still have to configure them (and the language should provide many implementations / optimizations).
If everything is already done, you remove the pleasure of development :) By the way, just look for a language that allows you to write your own DSL schedule and live with it!
Jack
source share