The Typeclassopedia, by all accounts, has turned out to be a popular and useful resource for Haskell programmers. I’ve been thinking for a while about putting out a revised and expanded second edition, and it’s finally time. Planned changes include:

making suggested exercises stand out typographically and adding many more;

updating information about various standard packages (mtl, transformers, etc.) to match the current state of affairs;

switching away from Pointed as a stepping stone to Applicative in favor of a more semigroupoid-based approach;

expanding the sections on comonads and arrows, which were a bit rushed in the first edition;

many other small additions, clarifications, and corrections.

However, the first edition was immeasurably improved by suggestions and contributions from many readers, and I hope the same will be true for the second. So, what would you like to see in the second edition? Some prompts to help you think of ways to contribute:

Is there a section you find confusing? Do you have a suggestion to improve its clarity?

Do you have a suggestion for a good exercise?

Do you know of an error, whether technical or typographical?

Do you know of a good resource that could be added to the bibliography — an explanation, example, original/historical source, relevant humor, … ?

Are you able and willing to contribute some text explaining some aspect of a more advanced type class (Category, Comonad, Arrow, …) in more depth, or more intuitively, than the existing text?

To contribute, you can send me email (byorgey at cis dot upenn dot edu). I’ll also be keeping this darcs repository up to date, so you’re welcome to send me darcs patches as well.

I completely second the “Make it a wiki like website idea” but also make sure that it maintains all of the cohesion of the original article. And the next version will be great, I will be interested in seeing what has changed but do not know what suggestions to make myself.

Thanks for the suggestions and encouragement! Publishing a hyperlinked HTML version alongside the PDF version should be easy thanks to pandoc. Giving people the ability to leave comments sounds like a great idea, but I would need help with that part from someone experienced in getting that sort of thing set up — offers welcome!

I am enjoying reading Typeclassopedia; I second the request for commenting, if possible.
Moreover, I solved last night the “fmap fmap fmap” puzzle from the introduction. Since it was somewhat tricky to get from “fmap fmap” to the result, I guess having a solution for that might be helpful.

Another thing I find myself struggling with, is that most functor instances are also instances of monad. So I find it hard to get a feeling for the capabilities/power these typeclasses posses.
Also, I feel that “power” itself is relative. Monad is said to be the most powerful, but in “Generalising Monads to Arrows” (the part about Swierstra and Duponcheel’s Parser), I learned that chipping away some of that power can be benefitial for performance and reasoning about combinators. Also, I learned (don’t know the source anymore) about combining 2 applicative instances into 1, which isn’t possible for monads. So there is quite some power in going for something “less than monad”.
In “Idioms are oblivious, arrows are meticulous, monads are promiscuous” (chapter 4, example), I got some feeling for reverse way. It nicely explains what computations gain when going from applicative to arrow to monad.

So basically, for me these differences seem very important to get a better understanding. Either different capabilities for types that implement all/most typeclasses, or looking at types that _do_ implement 1, but not the other (and reasoning why they can’t).
So maybe, instead of just having “chapters” per typeclass, some text can be devoted to what we gain and lose when transitioning and why some types can’t come along past it.

Monad is indeed more powerful than Functor or Applicative, in the technical sense that every Monad is both Applicative and Functor. But you are correct that it is often helpful to use *as little power as you need, and no more*. I agree a better discussion of these issues ought to be added. Thanks for the feedback!

I’ve only played with data-lens and friends, but I’ve found them to be really useful

I’ve also found data-lens-fd has been really useful when working with the State Monad, although I don’t know enough about the other lens packages to know if that’s generalizable enough to be discussed.