Two clarifications I'd like to add to my previous announcement (both of which were prompted by Zsolt :p ):
1. Some Attribute values take something like (Either Bool String); this is used when upstream indicates that two different types of values are allowed. Typically in this kind of situation, the allowed String values are limited to a few specific values, so the usage of Either typically indicates that they should be replaced with a custom value type. 2. When considering the new representation of DotGraph, this isn't limited to just people who wish to parse Dot code: if you want to do anything out of the ordinary/fancy, then unfortunately you will need this imperative usage (as the indicated way to have global attributes to a graph but not to its subgraphs is to list all the subgraphs, and then define the graph attribute). For an example of this, consider the layout of Andy Gill's dotgen library [1]. If you look at the internals, he does consider graphs to be a list of statements. This amongst other things allows him to have a monadic interface for building graphs with much greater flexibility in what you can do, whereas graphviz limits you to either converting a pre-existing graph or else creating one within the limits of specifying it as a list of global attributes, a list of nodes/clusters and a list of edges between the nodes. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dotgen What I'm considering is that if I internally represent DotGraph as a list of statements, then I will have getNodes and getEdges functions to extract the nodes and edges (with their attributes) out. This also simplifies some of the definitions, as a subgraph/cluster is then also just a list of statements. Zsolt Dollenstein <[email protected]> writes: > Hi, > > On Sat, Jul 18, 2009 at 10:23 AM, Ivan Lazar Miljenovic < > [email protected]> wrote: > >> I am pleased to announce a new release of the graphviz package for >> Haskell, which provides bindings to the GraphViz [1] suite of tools. >> > > Nice work! > > As the way of defining an attribute for a specific grouping of >> > nodes/edges/subgraphs is to have them all listed after the attribute >> definition (whereas those beforehand do not have this attribute), the >> imperative nature of the Dot language does not allow us to split these >> statements up as we currently do. >> >> [3] http://graphviz.org/doc/info/lang.html >> >> As such, I'm asking which of the following two choices people would >> prefer: >> 1. Follow upstream so that it can fully parse a Dot graph >> 2. Keep it as it is, so that it is possible to consider all edges, >> etc. easily. > > > I would vote for the second one since I think that is the most widely used > feature of this package. > > Cheers, > Zsolt -- Ivan Lazar Miljenovic [email protected] IvanMiljenovic.wordpress.com _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
