Edward Kmett - Typeclasses vs. the World

This month we're going to reschedule Ed Kmett's 'Typeclasses vs. the World' talk that was canceled a few months back, and then do something a little different. After the talk we'll just hang out, talk about what talks we want for the rest of the year, how we can improve the group, and just talk shop.

Edward Kmett - Typeclasses vs. the World

I've decided to do a few "get off my lawn" talks on somewhat more polemic issues, mostly so I can get them off my chest online and in one place, and not have to re-articulate myself from scratch every time I'm asked.

There is an oft-repeated notion that implicits a la Scala (confusingly called typeclasses in Coq, Agda, and Idris), module systems, or even object oriented programming techniques are somehow "just better" than Haskell's notion of typeclasses; they let you locally create and pass anything you want at the use site. Strangely, nobody seems to take the other side of the debate -- except to take a cheap shot at Scala now and again!

We'll look at the differences between typeclasses, implicits and ML-style modules. I'll try to tease apart the use cases for making dictionaries first class and see how to recover the safe implicit use cases with typeclasses without giving up coherence, and what you (and your compiler) give up to get the rest.

I'm also often asked if I'd trade in typeclasses for a real module system™ and draw shocked reactions when I say no. Here matters are less clear cut, modules are good for a remarkable number of things, but I hope to articulate a way to think about typeclasses vs. modules that at least drives home the costs and limitations of purely module-based reasoning in terms of refactoring. Along the way I'll showcase how we might look at the role of a better module system (e.g. Backpack) in Haskell.

Lest I come off completely biased, I'll be taking a few shots at the limitations of typeclasses, and talking about the inherent abstraction ceiling and costs of Haskell's current approach. Haskell is bad at abstraction; everyone else is worse.

Finally, we'll also talk about the space of properties for which these tools are equivalent in expressive power, just in case you don't get to write Haskell for your day job and yet still want to reason about your code.

Afterwards 1:

Last year we had a session to talk about what talks we wanted for the year, and we will do the same. But, I also want to field questions about how to make the group better. For example, I know some people liked the 'old school' Boston Haskell which was unstructured and we just sat around and played with ideas. Maybe we could do that once every two months? Or maybe just have one talk per month, and then hang out and talk free form? Or maybe someone else will come up with a glorious new idea.

Logistics:

If you can, please plan on arriving between 6:45pm and 7pm, but there will be someone in the lobby to greet stragglers.

Food:

Pizzas, salad and soda.

Afterwards 2:

If you'd like to stick around, a number of us tend to head down to the CBC (http://www.cambrew.com/) or another pub afterwards to socialize. If you would like to give a talk or if you have any questions or concerns, please feel free to follow up here or email one of the organizers.