Whilst I've apparently been on holidays overseas, I was bored enough (and frustrated enough with it) to re-write large parts of the GraphViz library. In particular, I now use a pretty-printing class and a new parsing class so I think the problem with quotes is over \o/ However, there are some design decisions I'd like advice on from users of this library; these are items that I can implement either way but I'm not sure what other people would prefer: * I have re-written large parts of the overall DotGraph and associated data structures, with one difference being that they are polymorphic in the node type; this should make the eventual change to the generic graph class (whenever we get around to doing it) simpler. However, I have left the ID of the DotGraph and the new DotSubGraph data structures as being the GraphID type (which is an algebraic type with number, string and URL support to match the official types of values understood by GraphViz); should I leave it as this or make them polymorphic in the Graph ID type as well? That is, you would have something like "DotGraph l n", with `l' being the type of the GraphIDs and `n' being the type of the node IDs. * With parsing of Dot code, the new data structure layout now more fully/correctly supports upstream by specifying a "DotStatements" data structure for use with DotGraph and DotSubGraph; DotStatements contains a list of (Global) Attributes, a list of DotSubGraphs, a list of Nodes and a list of Edges. At the moment, the parser expects these four types of statements to indeed be listed in that order, though it would be feasible to have the parser accept them in any order and then split them into these four types. Note that this could change the behaviour of how the graph is drawn (specifically in terms of where the Attributes are listed). Do people want a fully-fledged/capable parser or is the current setup sufficient? * The FGL <-> DotGraph functions now have the option to take a Bool parameter which indicates whether the specified graph is directed or undirected (with primed versions attempting to automatically determine this). If the graph is indicated to be undirected, then an edge (n1,n2) is kept if n1 <= n2; should I replace this Bool with a ternary algebraic type that allows the user to indicate that the graph is undirected but to keep all edges? * In the current available release, I had rudimentary error detection support for misuse of attributes. I have re-written this to an extent, and can do so even more to find even more possible errors (e.g. duplicate node IDs); do people actually care about this type of error detection? Am I just wasting my time on this? * With Color values (and since the issue seems to have re-arisen about spelling regarding Russell O'Connor's colour package, I use the American spelling because that's what upstream uses), I do not as yet bother matching up String color names with the colorset being used, etc. Something like this would require a State-based parser; does anyone care enough about this that they want it? The same thing goes for LayerSep, etc. Note that the user would then have to check themselves to make sure that they are using these correctly (that is, they have previously set which colorset they are using). If you're interested in seeing exactly what I've done, the darcs repo is at http://code.haskell.org/graphviz. Han Joosten has already asked me to implement record-based shapes, which I'll be looking at at some point to see how I can implement it into the current system. Otherwise, out of the 7 items on the TODO list I had from the previous version, this as-yet unreleased version has fixed 4 of them. If there's any other requests on what to do, please let me know. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com