Remember more structure when building diagrams

[fryguybob]

(Imported from http://code.google.com/p/diagrams/issues/detail?id=15. Original issue from byor...@gmail.com on April 2, 2011, 05:58:00 PM UTC)

Currently when composing diagrams, applying transformations, etc. we forget all structure and just flatten everything into a list of primitives paired with attributes. It would be much nicer to retain as much structure as possible, so we end up with a tree where leaves are primitives, and internal nodes correspond to composition of diagrams, transformations, or applications of attributes. The transformation and set of attributes corresponding to any particular leaf node can be reconstructed by computing an appropriate mconcat along the path from the root.

Benefits include:

• the ability to "reach into" a diagram and alter subparts
• better memory + time performance (composition and transformation are O(1) instead of O(n); no need to store duplicate copies of attributes with every primitive)
• ability to handle transformed attributes correctly -- I don't think it can actually be done correctly otherwise.

[fryguybob]

(Imported. Original comment by byor...@gmail.com on April 11, 2011, 12:00:32 AM UTC)

A general model of rose trees with values at the leaves and monoidal annotations traveling both up and down the tree is in UDTree.hs; the basic diagram type is now a UDTree with the monoidal annotations instantiated in a particular way. I also have some additional ideas on how to modularize it even a bit further (to e.g. make it possible to easily add other sorts of monoidal annotations to the basic diagram type).