## diagrams slides

Today at Hac φ I gave a short talk about the past and future of the diagrams library. For anyone who is interested, I’ve put the slides up here. For the actual talk the slides had no text on them, so I’ve added a summary of what I said at the bottom of each slide (although I’ve left out some details, so if you’ve any questions feel free to ask in a comment, or via email).

Assistant Professor of Computer Science at Hendrix College. Functional programmer, mathematician, teacher, pianist, follower of Jesus.
This entry was posted in haskell, projects and tagged , , , , , . Bookmark the permalink.

### 21 Responses to diagrams slides

1. Stephen Tetley says:

Hi Brent

Apropos the slides – p22 – TikZ does something similar with the ‘matrix’ command, basically you can do this sort of thing easily if you have addressable cells. In my drawing library Wumpus use a monad to get addressable cells:

mgrid01 :: GridM Width3 u ()
mgrid01 = do

gal_m <- cell1 \$ nil & blank & node "Gal(M)"

(delta,gal_nm) <- cell2 \$ nil & node "/\\" & node "Gal(N/M)"

ee <- cell1 \$ nil & node "(E/E')" & blank

connect gal_m delta
connect gal_m gal_nm
connect delta gal_nm
connect delta ee
connect ee gal_nm

return ()

This techique is derived from Andy Gill's Dot library, with a bit of type level programming to make sure each row has the same width. TikZ has nodes that allows non-regular placings – e.g. in your picture green triangle is half way below blue circle. This could be achieved nodes but it is a bit more cumbersome.

Circa – p14 – with Wumpus, affine transformations transform the bounding box of a picture rather than its contents. This seems to work amicably when I'm composing pictures with 'picture language' operations (eg 2D versions of the ususal pretty print combinators , , hsep, vsep… – I know Diagrams has similar ones).

2. Stephen Tetley says:

Hi Brent – apologies, my previous comment was rather garbled, some of it was typing in small text so I couldn’t see what I was writing, some was special characters got stripped from the post.

What I was meaning in the second part about nodes, is that TikZ still allows adressable elements (nodes) in free form pictures, but while placement of them is more-flexible, it is more cumbersome than in the ‘matrix’ environment. You can still connect nodes with simple commands and this would allow you to have elements that aren’t regularly placed in a grid like the shapes on page 22.

In the last para – the blog stripped out the infix symbols for the pretty print combinators in the last sentence, as they were using angle brackets: ” , , hsep, vsep… “.

The blanks between the commas were the horizontal-concat and horizontal-concat-with-space operators.

3. Surely, in the spirit of higher-order abstract syntax, we should try to represent addressable cells by Haskell variables. :)

• Brent says:

I have spent many hours thinking about and discussing ways to represent addressable cells by Haskell variables, but I haven’t been able to come up with a nice way to do it. I’m open to discussing it though. Maybe I just haven’t hit upon the right idea.

4. Lenny222 says:

Hi Brent,

i’d be interested to port my pure-Haskell rendering backends:

and my highlevel grid-stuff:

How is the rewrite going? Are you “finished”? Sorry if i have missed the relevant heads-ups.

• Lenny222 says:

By the way, do you have a strong opinion about using not so easy to grasp names such as “Prim” instead of “Primitive”, “papply” instead of “applyProjection” etc?

• Brent says:

I do have a strong opinion, and my opinion is that you are right that many of the names do need to be changed. =) I’ll be doing some renaming and cleanup over the next week or so.

• Brent says:

Hi Lenny,

Awesome! That would be fantastic! The rewrite is off to a good start, it got a great jump-start this past weekend when I had some help from people attending Hac phi. It is definitely not finished, however, and there’s still a lot of fundamental work to be done. Feel free to start hacking away, or if you like you may want to wait until things settle down just a bit more (there are still a lot of basic combinators and such I want to add which may be useful to you), but either way I would love to have your contributions.

• Lenny222 says:

My spare-time is a bit limited right, so i think i’ll take the natural wait-and-see approach hoping things will settle down a bit.

Thanks a lot for considering non-Cairo backends.

5. Lenny222 says:

Another question …

have you considered:

– layers/pages, for multi-page documents like PDF or Illustrator/Inkscape documents

– a document model, for keeping layers/pages and meta-data like author, creation date, boundingboxes/views

• Brent says:

I don’t see the need for layers — what would layers give you that you can’t do just by having multiple Diagrams, one for each layer?

I am also not clear on what is gained by embedding meta-data into diagrams. If you want meta-data in the output, why not just provide it on the side?

However, I’m willing to be convinced on both points.

• Lenny222 says:

Layers are quite handy if you need to post-process your graphics in a vector graphic editor.

For example, i did this in Asymptote:
http://lennart.kudling.de/cms/doku.php/electromagnetic_wave
but the colors and positions need some fixing. So i opened it in Illustrator.

Post-processing a flat document is harder than when having layers. Inkscape uses special named groups in SVG files for defining layers.

Meta-data are not strictly necessary. My vision is being able to read and write documents in different formats without losing too much information.

• Brent says:

Sure, I agree layers are useful for post-processing and other things. My point was that I think this can be accomplished just by having (say) an SVG rendering function that takes a list of diagrams, maybe with some associated names or whatever, rather than having the notion of layer built into the diagram type itself.

6. Sebastian says:

Hi Brent,
you mention that you want to support backends like LaTeX. With LaTeX, I think you will get problems because you don’t have a bidirectional communication with the backend (assuming that you don’t run LaTeX itself). So it will be impossible to get, for example, the exact bounding box of a text.
Did you consider this?

• Brent says:

Hi Sebastian,

Well, text is a whole can of worms in itself, without even bringing LaTeX into the picture. The problem is that text is not really scale-invariant, even though diagrams are supposed to be. I have a few thoughts but still haven’t come up with a good solution. Even what the version of diagrams on Hackage currently does for text, with bidirectional communication with Cairo, is quite unsatisfying, since it ends up using unsafePerformIO to ask Cairo for the text bounding box!

I’m quite open to ideas in this area. How should text labels in diagrams be handled? What would users expect out of such a feature?

• Lenny222 says:

My naive thoughts were to have all necessary information at runtime.
I’d imagine to get the font data via a font parser. Either the SVG font parser on HackageDB and/or a Freetype wrapper.

In my simplistic view, the data model should be independent of the representation/backend.

• Lenny222 says:

Oh and that should give answer to the question “given this font, and this text, what would be its size?” Then you could optimize the problem: “give me a font size so that the given text fits the given area”

• Brent says:

Yes, maybe something like this is the way to go. I have always just treated font stuff like a magical black box before, but maybe to do this right will require actually writing some font-handling code.

• Lenny222 says:

I think handling text as a black box is ok for a start.

Getting it right gets messy and complicated. So i’ve succesfully avoided it.

7. Buddha Buck says:

Hi Brent!