Last year we worked hard to come up with a good list of projects for the 2010 Google Summer of Code. A list drafted at ZuriHac is here:

http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell-org-gso...

And we ended up with quite a few of those funded,

http://donsbot.wordpress.com/2010/04/26/the-7-haskell-projects-in-the-google...

Now is the time to think hard about student-sized projects that would be valuable this year.

A great place to collect these ideas, and discuss them, is the Haskell Proposals Reddit,

http://www.reddit.com/r/haskell_proposals/

-- Don

I don't have a reddit account, so I'll post here. One thing I would love to see is a "free theorem deriver" integrated into GHC. It would be lovely to have, say, a type class called "Free" or "Glue" which takes in two two types and whose function represents a glue from the first to the second. It would be nice if those injections were derived, say, by Djinn. Consider my comments (which I am reposting here, in abridged form) from http://www.palgorithm.co.uk/2010/05/why-isnt-haskell-popular-in-industry/ : I just ignore the “line noise”. Line noise is nearly always glue code. I don’t want that named. I just want it done. Yes, it can be hard to write from scratch. But any sane Haskell development environment uses an interactive environment like GHCi. If you use the type checker to guide you, writing the glue becomes trivial. Encode logic in data types, and let the glue write itself. If glue code type checks, it works, guaranteed. These are free theorems. Focus on the important things: the stuff you’re gluing together. ... class Glue a b where glue :: a -> b and hide all the line noise in there. And then your client code will look like blah :: StateT (MaybeT IO) (Integer) (Maybe Integer) blah = glue . parseInt . glue . getLine – or blah = glue $ parseInt $ glue $ getLine This is how “line noise” glue code looks to me. Except line noise is more maintainable. *fnord* Note that these glue functions would each require their own distinct type class instance. The nicer the client code looks, the more complexity you have to shovel into the Glue instances. But you are merely transferring complexity — not creating or destroying it. Complexity is created by data type definitions being glued. There is the potential for a combinatorial explosion, since you can have unused Glue instances, whereas you cannot have unused “line noise” glue code. Mathematicians don’t care about mathematical symbols. They care about the things the symbols join, because the semantics of joining “things” is dependent on — and usually determined by — the things being joined.