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.
blog :: Brent -> [String] 
Not really a suggestion for the contents, but I would like typeclassopedia to become a website instead of just a static document.
Maybe not yet full wiki style where anyone can edit, but at least with a place to comment so people can suggest changes or post more in-depth explanations about certain parts.
Probably splitting the text, examples and exercises to separate “tabs” per subject.
Thanks for your work on the first edition, looking forward for the second.
It would be really nice if this could become published in HTML, with every individual concept linkable.
I think that more example instances would help me understand more intuitively.
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.
Thank you for your great Typclassopedia! As a student it helped me a lot to understand the philosophy of Haskell, especially what it meant to have a “computational context” :)
I’m really looking forward to the new version and more details about Arrows.
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 really liked them commenting function from RealWorldHaskell. The comment system is described here: http://www.realworldhaskell.org/blog/2008/02/10/about-our-comment-system/
I wouldn’t mind helping out with getting a commenting system working. I am over at Drexel in case you wish to meet as well to discuss it in person.
Thanks! Maybe you could take a look at the recently released doc-review package (http://hackage.haskell.org/package/doc-review) and see what would be necessary to get up and running with that?
as an haskell beginner i would really enjoy two improvments:
– a use case for each concept.
– a solution for each exercise.
the first point is coming from reading each section and i keep telling myself “ergh .. so what? how can i used it in real world”. i can’t go to the next step.
the second is because i’m learning haskell by myself and i can’t do any of the suggested exercises. :-p
nonetheless your first version is really appreciable once read LYAH and RWH.
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.
To understand my difficulty, look at the type of fmap fmap:
> :t fmap fmap
fmap fmap
:: (Functor f1, Functor f) => f (a -> b) -> f (f1 a -> f1 b)
From this, it’s not even obvious that passing fmap as an argument is valid! But indeed it is.
> :t fmap fmap fmap
fmap fmap fmap
:: (Functor f, Functor f1) => (a -> b) -> f (f1 a) -> f (f1 b)
Given this, it’s easy to guess that the ‘f’ in the must be ((->) e) of some kind, but guessing e was harder. Of course _now_ it’s kind of obvious.
An error report – rechecked in http://code.haskell.org/~byorgey/typeclassopedia/typeclassopedia.lhs (which I hope is the last version, but dunno).
You write that:
MaybeT (State s) a is isomorphic to s -> Maybe (a, s)
however lambdabot says:
@unmtl MaybeT (State s) a
[23:09] lambdabot: s -> (Maybe a, s)
Moreover, after seeing lambdabot’s type I understand why “the state of a MaybeT (State s) a computation may continue to be modified even after the computation has failed”.
You’re absolutely right! Thanks very much for the correction!
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!
Would a section on lenses be in scope for typeclassopedia?
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.
Pingback: Typeclassopedia v2: moving my efforts to the Haskell wiki « blog :: Brent -> [String]