Are you a potential Google Summer of Code student searching for a project to propose? Consider contributing to diagrams! It's an active project with a small, friendly, and knowledgeable developer community. Contributions to diagrams directly improve people's ability to communicate ideas effectively, and raise the profile of the Haskell programming language. Most of all, it's fun---you get to tangibly experience your contributions in the form of beautiful or useful images.
This page collects some suggested project ideas. We're happy to discuss any of the below ideas, or your own ideas, to help you come up with a solid proposal for a project you're excited about---send email to the mailing list.
GTK application for creating diagrams interactively
Having a tight feedback loop between coding and seeing the reflected changes in a diagram is important. Right now some of the backends have a "looped" compilation mode, but it's somewhat clunky and still a lot slower than it could be, probably due to overheads of compilation, linking, etc.
The idea would be to develop a GTK application allowing the user to edit diagrams code (either with an in-application editing pane or in their own editor, perhaps using fsnotify to watch for changes) and see the updated diagram immediately. Additional potential features include:
- the ability to "zoom in" on a selected subcomponent to display, instead of always displaying everything in the entire file
- using sliders, input boxes, etc. to interactively display parameterized diagrams, perhaps in a type-directed way (see craftwerk-gtk for inspiration)
- Interactive editing of diagrams, e.g. dragging a displayed component and having an appropriate translation call automatically added to the code, or some other sort of support for interactively generating points, vectors, scaling factors, etc. using mouse input
- Support for developing animations (e.g. with a slider for moving back+forth in time)
Intersection, union, etc?
See also Diagrams/Dev/Paths.
Tools for backends to remove redundant data?
Constraint Based Diagrams
Generate diagrams that meet some declarative constraint specification. Something along the lines of http://wadler.blogspot.com/2011/06/combinator-library-for-design-of.html
Lots of fun things to do here!
Make Plotting As Easy As Doing It in R
The above code produces four plots: a scatterplot (something you would often see in statistics), a plot of a function and, well, two empty grids. As a statistician, I usually work a lot with R together with a more or less sophisticated plotting package. The currently best plotting system for R is probably ggplot . Now, I started using Bryan O'Sullivan's statistics package for some of my calculations. Once in Haskell mode, you obviously don't want to switch back and forth between languages. So, I was wondering if it is possible to produce professional looking plots with diagrams' DSL, and how difficult it could be to put together a DSL for (statistical) plotting.
I was thinking of something similar to ggplot's functionality. Making it easy to overlay plots, producing and combining legends, etc. Creating scatterplots and histograms and boxplots. Overlaying them with error regions and density estimates respectively. Then do the same for different subsets of the original data. Doing this with diagrams DSL could proof to be extremely powerful. Each "dot" in a plot could potentially be any diagram you want, dots, circles, stars, numbers or characters -- and if plots are nothing but diagrams, you could even plot plots into a plot. A real pain for most plotting systems is to combine multiple plots into one and to generate a common legend for all of them. This, for example, should be trivial to do within diagrams DSL.
I would be more than happy to help in such a project. As the code above probably suggests, I am not the strongest Haskell hacker around. In fact, I am a statistician/mathematician who happens to use Haskell for some of his projects. That's it. Would anyone be interested in picking up such a project? As I said, I would be happy to help and get involved. Because I think there is a real need for something like this, and it would be very powerful to have eDSL for statistical plotting within Haskell.