[Haskell-cafe] Requesting suggestions for the GraphViz library

[Ivan Lazar Miljenovic]

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 at gmail.com
IvanMiljenovic.wordpress.com