How to read Haskell
This stub is intended to become a tutorial on reading Haskell. It's aimed at the non-Haskeller who probably doesn't care too much about trying to write code, but wants to understand it.
1 The tutorial
...needs to be written (actually, Haskell for C Programmers seems to do this job)
-- insert here some horrible (for the non-Haskeller) long example -- something we can work through slowly (and show why we find it beautiful)
1.1 General observations
One thing that can make Haskell hard to read is that Haskell code is extremely succinct. One tiny little piece of code can say a lot, so many times, when you are faced with something you don't understand, the best thing you can do is to think about it for some time. It will usually make sense after a while. The good news is that because of this succinctness, Haskell functions tend to be very small, which means that when you're trying to understand a difficult piece of Haskell, you normally do not have to look very far. It's just two sides of the same coin:
- bad news: high density == spending more time per line of code
- good news: succinctness == fewer lines of code to spend time on
Spending on this time to get one tiny line of code may be frustrating, but it's well worth the effort, because the fact that a very small code is hard to understand probably means that it's very abstract, and the fact that it is abstract probably means that it's going to be used in many places. So understanding that one tiny line code, as painful as it may have been initially, can pay off in a big way.
2 Practical tips and tricks
2.1 General advice
2.1.1 Trick: use the haddock
When reading a long piece of Haskell code, one which is broken up into many modules, you should consider keeping a browser window open with the auto-generated API documentation on the side (if any).
2.2 What does this function do?
2.2.1 Trick: use type signatures
When you see stuff like this
-- example please! foo :: Bar Ping Pong -> Baz Zed Dubya -> IO (DoublePlus Good)
...don't fight it! These are type signatures and they are an incredibly useful way of getting a rough idea what a function is supposed to do.
2.2.2 Tip: a function may be defined in more than one piece
Remember math class, where functions would be defined like abs(x) = x if x >= 0 or -x otherwise? It's a bit like that in Haskell too. Sometimes, rather than writing one big if-then-else, Haskellers find it more convenient to define a function separately for each case, such as...
abs x | x >= 0 = x abs x = -x
What gets confusing is when you look at a definition like this...
foo x | blah = some enormous long thing foo x = some other enourmously long thing
Especially looking at the bottom bit, it's hard to remember that
foo might have a another definition lurking around. Luckily, you never have to look very far, either immediately above or immediately below the other definition.
(Note: some programmers will perhaps write something like
foo x | otherwise = .... The
otherwise is redundant (and equal to
True), but useful as reminder that this isn't the entire definition of
2.3 What the heck is xyz?
One problem you might face when reading Haskell code is figuring out some cryptic entity like
2.3.1 Tip: order doesn't matter
Outside of a monad, it really doesn't matter what order things in Haskell code appear. So if you see something like this...
foo = whatTheHeckIsBar
you should take into account that
whatTheHeckIsBar may be defined somewhere below
- scope in a nutshell
- except for monads? explain
2.3.2 Trick: use grep
(This might seem really obvious, but it's sometimes easy to forget)
Or use the search feature of your favourite text editor. It's probably defined right there before your eyes, and if it's true to Haskell style, the definition is probably so small you blew right through it. In vi, for example, you could do
/= *xyz which searches for =, an arbirtary number of spaces, and then xyz.
xyz might be defined in some different module in the code you downloaded. You can look for telltale signs like
import Manamana (xyz)
But note that sometimes programmers get lazy, and they don't specify that
xyz should be imported. They just let rip with
So solution number 3 would be do something like
grep xyz *.lhs *.hs
(Note that literate programs sometimes use non-literate code, so search in both lhs AND hs)
A fourth idea, if you can't find something, is to look it up in Hoogle
3 What confuses non-Haskellers
Since this tutorial is not yet written, we encourage you to note here the things which confuse non-Haskellers about the code code.
- layout instead of semicolons?
- super-super-concise stuff (things using liftM and liftM2)
- the difference between and
x <- foo
x = foo
4 Scratch pad
You have thirty seconds. Can you understand what
(-1) .+ _ = -1 _ .+ (-1) = -1 a .+ b = a + b
- I was initially going to use this example for saying that you should get used to pattern matching... but now I'm not so sure. It shows you two things really, (1) the pattern matching stuff, and (2) the fact that we like to define our operators in this infixy way.