small medium large xlarge

13 Jul 2012, 12:05
paul callaghan (14 posts)


Have you tried programming with Haskell (or similar languages), got so far then run into annoying obstacles? Do you feel that something is missing from the current books or online tutorials? Would you like to see a pragmatic approach to Haskell?

I’m thinking about writing an article or two for PragPub magazine on such issues. It’s a pity if people put in the time to try Haskell etc then - for various reasons - give up or don’t enjoy it as much as they could, and I’d really like to help change that.

I have some ideas about the potential stumbling blocks and missing “aha steps”, but it would be great if people could spare some time and give me a few lines on their experiences of learning Haskell, and say what kind of relevant things they’d like to learn or get a better understanding of.

In my experience (20+ years), it’s too easy to get caught up in the technical details and forget about the bigger picture of programming in a functional style. I want to look at programming with haskell rather than in haskell. You can see some relevant blog posts on

One last point: these articles won’t limit themselves to Haskell - Haskell is just a useful label and starting point. I hope to cover ideas from cutting-edge developments like dependent types (eg Agda, Epigram).

Thanks in advance!


07 Aug 2012, 13:44
Ashley Penney (1 post)

I’ve suggested this elsewhere but I find one of the most productive ways to learn something this complex is to start from the foundation of a fully working (but as simple as possible) program. Not a massive one, maybe 2000-5000 lines of code.

I’d love to see a book that started with this and then took you through a series of enhancements and improvements to the code. One of the hardest things is getting something of a big enough size that it’s no longer just a toy hello world thing when you’re starting out, so this would let the author introduce a real program and touch on the structure and way a haskell program is built, and slowly dive into more specific features. Instead of little exercises at the end of the chapter I would like something along the lines of a feature request or bugfix that is required in the code so that the reader can dive into a working program and experiment and get their hands dirty until they’ve improved some functionality.

Obviously this would be a bit cheesy in the first chapters as core language features are introduced but it would help cement what you are doing with practical work. If it’s integrated nicely with git it would be real easy to fork from the authors “chapter8” branch and then work on solving the problems as well as having a forum to bounce to if you really can’t resolve it.

I just think that I learn best by doing and tinkering with existing code because it gives a skeleton of existing stuff (and normally tests to make sure I’m not destroying core funtionality) and that makes it much easier to play with things.

Hopefully I managed to get over what I’m going at here, a foundation of a real program plus realistic experience as if you are a junior programming trying to take on improving your favorite application. A book written from that stance might help solidify just how you use Haskell in the real world.

08 Aug 2012, 09:21
Rinkashimi Tewmey (1 post)

yes, I also met with many difficulties, but step by step to overcome them.

13 Aug 2012, 03:59
Rein Henrichs (1 post)

Hi Paul,

I’m very excited to see a more pragmatic approach to Haskell instruction. I’ve tried to do my own small part but admittedly I am no expert, so it’s great to see you filling this void a way that I hope is more thorough and comprehensive while maintaining approachability.

Here’s a (not so) short list of some of the topics that I myself found most difficult, and about which I seem to get the most questions:

  1. Type classes, especially those based on the category theoretical properties of Haskell types. I’d especially like to see the journey from Functor to Applicative to Monad presented in the context of an actual, practical use case.

  2. Function application and operator binding. It seems simple, but plenty of people (myself included) get tripped up over the differences between function application (“ “), @($)@ and @(.)@. This is also a good opportunity to explore the benefits of partial application (currying), composition, and point-free style.

  3. Groking type signatures and kinds. Since Haskell is so type-driven, it is a great benefit to be able to grok the essential quality of a function or type simply by reading its type signature or kind. For instance, for someone fluent with type signatures, the difference between @($)@ and @(.)@ would be readily apparent.

  4. Testing. My experience is that testing is less useful as a design tool (since type-driven or data-driven design are so fluent and powerful), but that it is still useful to specify behaviors for which the type system is insufficient (Array bounds, for instance) and, especially, to catch regressions. I’d like an expert to give me a better intuition around when I should be testing and how I should be testing in a language where the tensions seem significantly different from (say) Ruby, and to discuss HUnit versus QuickCheck (perhaps in the context of Test.Framework).

  5. Program structure. Directory and file naming conventions. Module export and import conventions. Properly separating impure (IO) actions like user interaction from the realm of functional purity. How do I structure a non-trivial program?

  6. Do notation. I want a better intuitive understanding of how and when to use do notation for State, IO and other monads. While I think I technically understand the behavior of @»=@ and @return@, I still don’t quite grok how to translate that understanding into do notation.

Again, thanks so much for doing this!

14 Aug 2012, 21:08
paul callaghan (14 posts)

Hi all

Thanks for the comments! I’ve been busy writing the next installment of the series in recent days (on types and TDD). I’ll answer some of the points soon.


12 Sep 2012, 20:55
paul callaghan (14 posts)

Hi Rein

I hope some of the September article answered a few of your queries on the types & testing side - though clearly not all of the questions! Have you had a chance to read it yet? (I see you’re suffering from the flu too…)

My next article will go through some well-known katas and discuss a few more of your points in passing.

Some quick comments here though: * type classes - useful for overloading and definition of interfaces, of course. When it gets to the more abstract stuff, we’re still dealing with overloading but overloading on slightly more complex types. Eg. we overload (==) on Ints, Bools, etc. We want the same overloading for concepts like mapping over container types (ie mapping on lists, mapping on trees) because (a) it’s the same concept and (b) has the same pattern of type. Hence we’re overloading “fmap :: (a -> b) -> f a -> f b” by allowing different underlying code to be chosen depending on what the ‘f’ (type constructor) is. When we declare an instance of Functor for some type (well, type constructor) we’re just saying that the idea of mapping also applies here (and the code says how to do it) - and also saying that we want to use that kind of overloading with our new type, or make use of code that builds upon the overloading. Similar applies to the other weirdy classes - they encapsulate certain useful patterns, and we add the details if those patterns are likely to be useful. (Plus, the type checker will inform us if we’re missing class instances.)

  • dot and dollar - basically, I tend to use (.) when building combinations of functions and use ($) to cut down on parentheses. See examples in the article.

  • groking types etc - mainly a practice thing, learning what the types are saying and then learning how to apply that knowledge.

  • testing - up for debate (-:

  • program structure - most of us seem to collect related types and their main code together, and Haskell provides a simple hierarchical naming scheme for these, plus basic import and export lists. I just go with what seems useful at the time.

  • do notation - I prefer to use which ever seems to give clearer code, so usually go for do notation. I’m sure you know that do-notation is just a bit of syntactic sugar, though you might not trust it yet(!) We’ll have to explore this some more.


ps. everyone else - check out Rein’s site for an interesting resource.

22 Sep 2012, 09:46
paul callaghan (14 posts)

Might also be useful - a minor rant from me about getting monads into perspective: “I remember the time before monads” -


24 May 2013, 18:33
Edward McDowell (5 posts)

I would definitely like a book on Haskell that emphasizes semantics: How do lazy evaluation and monads work under the hood? How can Haskell best be used with multicore hardware? The Haskell Platform provides software transactional memory. How does this work?

04 Jun 2013, 10:14
paul callaghan (14 posts)

On the subject of multicore and STM, there’s a book soon to be published by O’Reilly by one of the key GHC developers, which promises to be excellent!

Monads are just bits of Haskell code, and works like the other bits of Haskell code (-: (You might enjoy “Tackling the Awkward Squad” for some of the lower-level detail on IO and concurrency.)

As to how laziness etc works, then this stack overflow page contains many useful and relevant links -

You must be logged in to comment