On 05/08/2013 09:14 AM, qznc wrote: > I am thinking about something like this as well, but finishing things is > not my strength. ;)
Oh, tell me about it. :-P > What I desired were probably quite different requirements to other graph > libraries. My background is compiler optimizations, where the programs are > represented as a graph: libFirm [0]. > > 1) A transaction mechanism. In debug mode, libfirm runs some checks on > every graph change. However, sometimes a sequence of changes must be > completed until the graph is in a valid state again. A transaction > mechanism could be used to run the verifier after a complete transaction. > > 2) Node maps. Compiler optimizations sometimes rely on multiple analyses, > which usually compute information for each node in the graph. While a hash > map can be used to annotate nodes, a graph specific map should be more > efficient. Additionally, a graph might know about its corresponding maps > and update them implicitly, if the graph changes. That would be a great perspective to have. I should add that the use of things like hash maps etc. for efficient data storage/retrieval is something I'm really not that familiar with, so it would be good to be able to get concrete advice on those aspects. So, your thoughts and insights may still be very important even if you can't commit to a lot of programming time. I suspect that where effective hashmaps and other container types are concerned, it may be necessary to either make (or push for) some quite extensive additions to Phobos and/or druntime. We could of course use Steve Schveighoffer's excellent work, but I have a strong preference for avoiding 3rd-party dependencies in cases where the functionality clearly _should_ be available in standard libraries. > [0] http://pp.info.uni-karlsruhe.de/firm/Main_Page I love that you provided a brainfuck frontend ... :-)
