Guide to Haskell for the Absolute Beginner

In case you got here and you already program in something like Java or Python, you can still read this doc, but skip straight to the stuff that's specific to Haskell and is almost certainly different from what you're used to:

• Turing vs. Church and Why Haskell?
• What is Haskell? (lazy, statically-typed, pure functional)
• SUPER Basic Syntax and running Haskell interactively with ghci
• Comments
• Strings: You can skip this section so long as you know strings (denoted with "") are just lists of characters (denoted with '').
• Lists and everything else to the end of the document.

Everybody's heard of Alan Turing (right?). Father of modern computing or some such. He was a mathematician in the olden days before electronics, so all his thoughts of computers were in his head (or literally on paper). There are a couple of things that make him a big deal:

So, while everybody's going on and on about Alan Turing, there's this other guy, named Alonzo Church, who was roughly contemporary with Turing. He came up with a form of math called "lambda calculus". It's all functions.

So, while Turing is inventing a machine that stores state on a tape (with assignment statements, basically) and computes that way, Church is inventing a form of math that "stores" state in mathematical function results.

So: computing without assignment statements. What's an assignment statement? you ask.

Remember that BASIC code above?

B = 152

That's an assignment statement. We're assigning the value 152 to whatever area of memory B represents. This is like a Turing machine scribbling on its tape.

That's all fine and dandy, but what if you modified the above program to call a subroutine between the time you assigned the value 152 to B and the time you used B, and said subroutine modified B without telling you it would?

A = INPUT 1
B = 152
REMark The following function modifies B but the documentation doesn't say anything about that,
REMark nor can we read the code because we bought it from another company
CALL SPIFYRTN
IF A < B THEN OUTPUT 2

So now, we loaded 152 into B, and we happen to know the input to the program was 12 (because we measured it with a voltmeter), so the OUTPUT 2 statement should have turned on the light, but it didn't! What's wrong?

After screwing around for a day, we finally think to check B at the time of the IF statement, and we find that, lo and behold, it's not 152 as we thought, but 0! Because the SPIFYRTN call changed it behind our backs! (With its own not-easily-visible assignment statement. Not a very spiffy routine at all.) Good thing we found this in testing, because if we had shipped this code, that light not lighting up is the "patient is having a heart attack" light, and we could have killed someone.

This is a big deal, because assignment statements lead to an enormous class of bugs (basically, undocumented subroutine side effects). So, imagine how great it would be if we could write programs without assignment statements, and not even have these sorts of bugs. That's Haskell (and a bunch of other functional languages like OCAML and F# and Scala, but Haskell is kind of the granddaddy).

Haskell doesn't do any computations until it really needs to. You can set up the most monstrously-complex computation and Haskell will only evaluate it when it really needs to, even if it looks like it should evaluate. Seriously, Haskell only waits until it REALLY needs to do the computation.

Suppose I define a function that looks like this:

f x y = if (x < 0) then y else x

Meaning, the function gives the value y if x is negative, otherwise it just gives the value of x.

Then, suppose I define some other horribly complex and expensive function h and call f like this:

f 2 (h 12)

Meaning (you might think), "calculate the value of \(h(12)\) (let's call the result \(z\), for no good reason), even though it's horribly complex, and then call \(f(2, z)\). Since the first argument is 2, we get the 2 back, so… why did we pay the cost of computing \(h(12)\)?

Haskell doesn't do that. It's lazy. It puts off the calculation until it really needs it.

Here's a cool example:

Prelude> :{
Prelude| let g :: Int -> [a] -> Int
Prelude|     g x ys = if (x < 0) then (length ys) else x
Prelude| :}
Prelude> g 2 [1..10]
2
Prelude> g (-2) [1..10]
10

Spiffy, right? If x is negative, it gives the length of the list ys, otherwise it just gives x.

What if we hand it an infinite list (you can do that; see Infinite lists). Now we're expecting it to count the length of an infinite list. That's like that Star Trek episode where Spock asks the Evil Computer to compute the last digit of pi. It ain't never gonna come back.

Except… if we hand the function a positive first argument, it doesn't even need to count the length of the list, and it doesn't.

Prelude> g 2 [1..]
2

Boom.

Just for grins, let's see what happens when I use a negative number:

Prelude> g (-2) [1..]
^CInterrupted.

(I got impatient after, like, 7 seconds, because I knew it wasn't coming back.)

Haskell knows the types of everything before the program starts running. And you can't hand something of the wrong type off to something that expects it to be right type.

This is different from languages that are dynamically typed. In a dynamically-typed language, if I declare a numeric function and hand it a string like "2", we expect the function to Do The Right Thing and convert the "2" to 2 and go from there. If we hand said function a string like "onyx", it'll try to convert "onyx" to a number and almost certainly bomb out, at run time. (Or, worse, decide "onyx" is really 0, and sail merrily on, giving what looks like a correct calculation. What if I gave it "5even"? Too bad, eh?)

Here's where things start to get really interesting. "Pure" means Haskell has no assignment statements. It has no exceptions that say "well, in this special case, you can assign a value to a variable."

And, finally, Haskell does everything with functions, slinging them around pretty much with gay abandon, as in: "here's a function, I don't know what it is (except it's mathematical); call it on each number in this list, please". Or: "here are two functions, I don't know what they are (except they're mathematical), please compose them together and call the composition on this list of numbers".

(You probably remember function composition from your math days: \(f(g(x)) = (f \circ g)(x)\). That "\(\circ\)" is the composition operator you know and love.)

And you can define functions. Haskell functions look different from math functions. Math functions look like this:

Or, for those w/out MathJax:

c(x) = (x - 32) / 1.8

That function converts Fahrenheit to centigrade, if you're interested. The inverse function being:

Haskell functions don't have the parentheses. They just use spaces. In fact, when you see two things separated by spaces in Haskell (that aren't explainable by normal syntax rules), it's almost always a function being applied to an argument.

So, if we were to apply the function c to the value 22 (°F), it would look like this:

Prelude> c 22
-5.555555555555555

So, like, -6 °C. No parentheses. You could use them, but they'd be useless. Parentheses are used like in regular math, to prioritize math operations that would normally be low priorities, as in the definition of the function c above.

Defining that function in Haskell looks kind of the same:

Prelude> c x = (x-32)/1.8

(Try it! I know you already installed Haskell, didn't you?)

And you can convert centigrade back to Fahrenheit, so when Midnight Oil sings "boiling diesels steam in 45°" (https://youtu.be/jpkGvk1rQBI), you can know how hot that is.

Prelude> f x = x * 1.8 + 32
Prelude> f 45
113.0

Ok, that's it. That all. Now you can use Haskell to balance your checkbook. Just fire up ghci and start entering some mathematical expressions.

Prelude> 1800-750
1050
Prelude> 1050-850
200
Prelude> 200-30
170
Prelude> 170-250
-80
Prelude> -80-350
-430

:(

I'm guessing you didn't need Haskell for that, though.

By the way, while we're on the topic of negative numbers, it's best to surround them with parentheses, e.g.

(-80) - 350

We got away with no parens in the example above, but in more-complicated situations, you'll see weird errors:

Prelude> 2 * -3

<interactive>:1:1: error:
    Precedence parsing error
        cannot mix `*' [infixl 7] and prefix `-' [infixl 6] in the same infix expression

Prelude> 2 * (-3)
-6

You can list out the contents of a list as above, but you can also specify the contents of the lists a different way. Essentially, you use a recipe.

[1..10] is a list of all the integers from 1 to 10.

[2,4..10] is a list of all the even numbers from 2 to 10.

Sadly, you can only go by addition (or subtraction), so you can't, for instance, expect [1,2..128] to be a list of all the powers of 2 from 1 to 128. Nor can you give Haskell a hint with something like [1,2,4..128].

However, there are more tricks!

[ 2^x | x <- [1..10]] is the aforementioned "powers of two" list. If you go back to your math days, you can almost read this as:

"THE LIST OF ([) all 2^x SUCH THAT (|) x IS TAKEN FROM (<-) the list of integers from 1 to 10"

You can make the condition more complicated:

[ 2^x | x <- [1..10] , 2^x < 128]= is the same list as above, except we also require 2^x to be les than or equal to 128.

• CLOSING NOTE [2019-02-18 Mon 22:03]

You can do this. This blows more-experienced developers' minds, but you can probably be comfortable with this concept.

[1..] is the infinite list of positive integers. (I don't believe you can have a list be infinite on both ends, but there might be a trick you can pull if you really want something like that. All lists have to have a starting point.)

If you try to print that list out, you'll be waiting for a long time for the printing to stop. (You can hit ctrl-C (hold down the control key and hit the 'C' key) to stop it.)

But you can do something like this:

take 10 [1..] means "take the first ten items from the infinite list of integers".

Which sounds pretty stupid, but it can come in handy sometimes when you have a less-predictable infinite list to deal with.

So, hspec doesn't come with the Haskell Platform, for some reason, so you'll need to install it. You can install with cabal or with stack. The usage of cabal is simple, see below. stack is better if you're going to do something other than write a proof-of-concept toy, and I discuss it a little more in Build System in write-a-haskell-program.org.

For cabal, use the cabal command (which does come with Haskell Platform) to install it. Issue the following command at the command prompt:

cabal install hspec

It'll take a while and install a bunch of stuff.

When you compile the above code with ghc, you'll get some incomprehensible warnings about type defaults, but I'm guessing it's because I used actual integers rather than real code to be tested. It's ok; it still runs fine.

Fire up ghci, load the test module and run its main (or any other test functions (which probably have to have type IO ())):

PS C:\Users\j6l\Documents\AmazonS3\Tarheel-NC\Haskell# ghci .\FooSpec.hs
GHCi, version 8.6.3: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from C:\Users\j6l\.ghci
[1 of 1] Compiling FooSpec          ( FooSpec.hs, interpreted ) [flags changed]
Ok, one module loaded.
*FooSpec> main

Some readable (English) phrase describing what you're testing in general
  Some phrase describing a specific single test you're performing
  Some other phrase for another test FAILED [1]

Failures:

  FooSpec.hs:15:5:
  1) Some readable (English) phrase describing what you're testing in general Some other phrase for another test

  To rerun use: --match "/Some readable (English) phrase describing what you're testing in general/Some other phrase for another test/"

Randomized with seed 1422829174

Finished in 0.0181 seconds
2 examples, 1 failure
*** Exception: ExitFailure 1

You'll see green text for successful tests, and red text for failures (plus the word FAILED).

Here's a super-simple data type. It's really an enumeration of possible values.

data Direction = North | East | South | West

What's going on here? We're defining a new data type, named "Direction". And it can only have four different values. Simple enough, right?

We could do this with a string, but what if we had a function, bearing that takes a compass direction and gives the number of degrees that direction corresponds to? Great, but what if we asked it direction "Esta" is? ERROR. We can avoid that by using this new data type instead. Here's the function signature ("signature": the list of input types and the result type a function has).

bearing :: Direction -> Int

So, the function takes a Direction and gives an Int (an integer).

To be clear about this: we tell Haskell what the type of a function is (its type is its signature) by giving the function name, a double colon, and then the list of input types and the result value type, all separated by (short) arrows ("->").

You might remember, from your days of math in school, that functions are usually specified with arrows. See:

• Wikipedia on function notation, and
• Wikipedia on arrow notation

The big difference between Haskell and "regular" math is that, in Haskell, we put arrows everywhere, not just in front of the function result. More about that later. :)

Ok, here's a much wackier solution (but one you'll see a lot):

bearingPat :: Direction -> Int
bearingPat North  = 0
bearingPat East   = 90
bearingPat South  = 180
bearingPat West   = 270

What the heck? How can you define the same function more than once? (Maybe you think this is completely normal. The "bearing" of North is 0 degrees, the bearing of East is 90 degrees, etc. What's the problem, John?) This is pattern-matching. There are no conditionals here. Conditionals are ok, but sometimes it's clearer to avoid them. What's going on here is that we're saying (obviously, I guess) that if the function is called with the value North, the function's value is 0, and if it's called with the value East, its value is 90, and so on.

You will definitely see more pattern-matching in the future, but it'll be a bit more complex (don't worry, not too crazy).

• CLOSING NOTE [2019-02-21 Thu 22:08]
  Well, mostly done. At least the first pass.

Ok, let's kick it up a notch. There's a built-in data type named "Maybe". It's essentially defined like this:

data Maybe a = Nothing | Just a

(There's probably more to the official definition, but this is about right.)

So, we're saying that, like Direction, a Maybe value can have one of two possible values: Nothing and Just a.

But, wait, what's the "a"?

Well, that is Haskellish for "any old thing, of any old type". (The "a" comes from the beginning of the alphabet, not the first letter of "any".) Remember that whole "lists of any type" thing? Same thing.

So, you can have something that's "Just 2" or "Just North" or "Just "hello"".

Why would you do such a thing?

Imagine a function that divides one number by another. What if we passed it zero? What should we give as a result? Should we just blow up the program?

How about this:

divAbyB x 0 = Nothing
divAbyB x y = Just (x/y)

(Oh, look! More pattern-matching!)

So, now we're saying anything divided by 0 is Nothing, as opposed to 0.

And, if it's not Nothing, it's Just whatever the result is.

*CompassSpec> divAbyB 1 0
Nothing
*CompassSpec> divAbyB 1 2
Just 0.5

• CLOSING NOTE [2019-02-23 Sat 16:56]

You might not be satisfied with a Maybe data type, because when you get a Nothing, there's no info about why you got the Nothing or what went wrong.

Behold, Either!

data Either a b = Left a | Right b

So, now you can return the "right" answer or some sinister error info. ("Left" is always bad; we lefties can't get a break.)

divWithError x 0 = Left "division by zero is undefined"
divWithError x y = Right (x/y)

sillyAdd3 (Left e) _ = Left (e ++ " (sillyAdd3)")
sillyAdd3 _ (Left e) = Left (e ++ " (sillyAdd3)")
sillyAdd3 (Right x) (Right y) = Right (x + y)

*Compass> sillyAdd3 (Right 1) (divWithError 1 0)
Left "division by zero is undefined (sillyAdd3)"

*Compass> sillyAdd3 (Right 1) (divWithError 1 2)
Right 1.5

• CLOSING NOTE [2019-02-23 Sat 17:50]

I'm going to give this short shrift, because a longer discussion would be a lot longer, but there some useful typeclasses you can use (and will probably have to, if you start defining new types). A typeclass is kind of a type of a type, or a category of types, or a class of types.

So, for instance, the typeclass Eq is the set of all types can be compared with each other for equality, and the typeclass Show is the set of all types that can be converted to human-readable strings.

You can't use the "==" operator without being in the Eq class (normally), and you can't display a value using putStr or putStrLn without being in the Show class. Also, you can't decide whether one value is less than another without being in the Ord ("ordinal", "orderable") typeclass.

So, we usually just slap on a deriving statement along with a list of typeclasses we want to invoke.

putStr, by the way, is a function that puts a string to the output. putStrLn puts a string followed by an end-of-line sequence (e.g., a carriage return) to the output. You won't use them much in ghci, but you will definitely use them in a lot of regular Haskell programs after you've compiled them to a runnable executable.

• CLOSING NOTE [2019-02-25 Mon 20:41]
  Not super-proud of this section; just sayin'.

(I want to use "typeclass" instead of just "class", because I think that'll be less confusing.)

About that "any old type" bit I mentioned up above in the Maybe section….

Sometimes, "just any old type" won't do. For instance, you can't do math on strings. And some functions really take only integers, not fractions. And sometimes, data types want to contain only things of certain types, and so on.

In those cases, when you specify function types (which I haven't done much, if any, of so far), you might need to say something like "this function takes any old type so long as it's a number".

f :: (Num a) => a -> a
f x = -x

I really don't have any better examples right because I barely know what I'm doing. Check back with me in a year and see if I've made any progress. :/

The concept of a typeclass constraint applies almost anywhere you'd use a data type or a typeclass, in addition to functions.

But, wait, if those are function definitions, where are the arguments? add3nums has arguments in its definition, but the other two don't!

It turns out that you can sort of "cancel out" the arguments of a function definition, sometimes.

So, for instance, if I want to define some arbitrary function f, and it's really just the square-root function, I can define it two ways:

f x = sqrt x

or

f = sqrt

It's like, "Well, we know the arguments are going to get slapped on to the end, so let's just agree to leave them off. What do you say, old chap?"

You'll see a bunch of that. Like, "+" takes two arguments, so if you specify "(+3)", you've just defined a function of one argument but you didn't even type a placeholder variable for that last argument.

Prelude> f = (+3)

Prelude> f 2
5

• CLOSING NOTE [2019-02-25 Mon 16:40]

You remember that whole "My Dear Aunt Sally" thing to help you remember which operations have priority in a mathematical expression. (Multiplication, division, addition, subtraction.)

Exponentiation is higher-priority than multiplication, so \(\frac{1}{8}\times2^3 = 1\), because first you compute \(2^3\) and then you divide by \(8\).

In the same way, function application (function invocation) is the absolute highest priority (at least, until I remember something that's even higher). So, if you have f 2 + 3, what's going to happen is f will be applied to 2, and then the result will have 3 added to it.

Finally, here's what happens (I believe) when you have an expression like f 2 3 4, where f is a 3-argument function.

First, f gets applied to 2, yielding an unnamed two-argument function via the miracle of currying.

Then, this unnamed two-argument function gets applied to 3, yielding a one-argument function, also unnamed.

Finally, this one-argument function gets applied to 4, yielding whatever is the end result.

(This is conceptual. In real life, probably something even more mysterious involving a tree of "thunks" happens, but let's just close our eyes and pretend my explanation is good enough.)

• CLOSING NOTE [2019-02-25 Mon 17:23]

While we're on the subject of function-application being the highest priority operation, it might be useful to know what the "$" operator does.

Before we do that, though, let's define some more functions:

module ChainOfFunctions where

f x y z = x + y + z

g x y = x * y

h x = 0 - x

main = do
  putStrLn ("h g 2 f 4 6 8 = " ++ show (h (g 2 (f 4 6 8))))

("++" is string concatenation, by the way. Jams two strings together.)

PS C:\Users\j6l\Documents\AmazonS3\Tarheel-NC\Haskell# ghci .\ChainOfFunctions.hs
GHCi, version 8.6.3: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from C:\Users\j6l\.ghci
[1 of 1] Compiling ChainOfFunctions ( ChainOfFunctions.hs, interpreted ) [flags changed]
Ok, one module loaded.
*ChainOfFunctions> main
h g 2 f 4 6 8 = -36

(If you work out all the math, you'll see this is correct.)

That is a ton of parentheses. If you try it without the parentheses, it'll be a glorious mess. This is because function application takes priority, so, when you have "h g 2 f 4 6 8", Haskell tries to apply h to everything that comes after it. So, you have to parenthesize the application of g, so it gets evaluated before h gets applied, and you also have to parenthesize the application of f, so it gets evaluated before g gets applied.

AND you have to parenthesize the whole thing before show gets applied to turn a number into a string, AND you have to parenthesize all that before putStrLn gets applied.

But what's a few dozen parentheses among friends? Especially at the end; you can just hammer the right-parenthesis key until the editor is satisfied; that should do the trick.

OR… (see what I did there?⁴) you could use "$". "$" has a very funny definition:

f $ x = f x

Basically, it does nothing but disappear, so what's the point?

The point is that "$" is defined to have the lowest priority of all the operators. So that means that when Haskell sees something like f $ 3 + 4, it says "hold up, I see you want to apply f to something, but I have to evaluate "3 + 4" before I can evaluate "f $ <whatever>", because "+" has higher priority than "$"."

So, basically, "$" means "hold up and evaluate everything from here to the end of the current expression", which is equivalent to banging in a left parenthesis at this spot and also tacking a right parenthesis on to the end of the line. "$" saves parentheses.

Actually, it turns out that functions are "first class" values in their own right, meaning you can sling them around just like another value. And when I say "functions", I don't mean "function results" or "function invocations" but the functions themselves.

For instance, I can define a function that applies another function to an argument.

applyFunction f = f 2

What's the argument here? A function! We're taking whatever function we're passed as an argument and applying it to the constant 2.

*Add3Nums> applyFunction sqrt
1.4142135623730951

*Add3Nums> applyFunction recip
0.5

The square root of 2 is 1.414. And the reciprocal of 2 is \(\frac{1}{2}\). sqrt and recip are built-in functions (that take a single numeric argument), and we passed the functions as arguments to another function (applyFunction).

So, a function can exist in its own right, just as the value 2 can exist in its own right.

In fact, you don't even have to give a function a name. This is just like you don't have to give a numeric value a name. If I want to use 12 in an expression, I just do it. So, how does an unnamed function exist?

As a lambda expression.

Why, hello, Alonzo Church! Fancy meeting you here!

A lambda expression looks like this:

\y -> 2 * y + 1

This is a function that takes \(y\), and gives \(2y + 1\) back. Note that it doesn't have a name; it's anonymous.

(How we got from "^" to "/\" to "λ" to "\" is a fun little story of the abuse of typography, full of randomness and wonder.⁵ Basically what it means, though, is that "lambda" is utterly meaningless, and you don't need to be intimidated by a Greek letter standing for who knows what abstruse mathematical concept.)

So, we could call applyFunction like this:

*Add3Nums> applyFunction (\x -> x ^ 3)
8

So, we just applied a cubing function to 2, without bothering to name the function f or g or whatever.

Map a function to each element of a list, producing a list of results.

λ Prelude> ns = [1,2,3]

λ Prelude> map (2*) ns
[2,4,6]

So we mapped a function that doubles ((2*)) to a list of numbers, getting a list of doubled numbers.

We could do the same with a lambda function:

λ Prelude> strs = ["hi","there"]

λ Prelude> map (\s -> s ++ " " ++ s) strs
["hi hi","there there"]

(You see the lambda function, right?)

Filter things out of a list.

λ Prelude> ns = [1..10]

λ Prelude> filter (\n -> 0 == (rem n 2)) ns
[2,4,6,8,10]

Quick review: == is the test for equality. rem (which you haven't met before) is the remainder after integer division. So, we're using a boolean lambda expression to filter for numbers whose remainders are 0 when divided by two (that's bad grammar, but I think you know what I mean).

You've already met take in the discussion of infinite lists.

drop is a bit like take, but it drops the first n elements of a list and returns you the rest of the list.

λ Prelude> drop 3 ns
[4,5,6,7,8,9,10]

++ jams two lists together.

λ Prelude> as = [2,4..10]
λ Prelude> bs = [102,104..110]
λ Prelude> as ++ bs
[2,4,6,8,10,102,104,106,108,110]

You've seen it used to jam strings together, but, remember, strings are just lists of characters. ++ works on lists of anything (so long as the two lists are of the same thing).

• CLOSING NOTE [2019-03-09 Sat 22:14]

Ah, fold. This one is trickier. It "folds" a list (or any Foldable) up into a single value. You have to give it a starting value, and an operation to use in folding up the list, and (of course) the list.

There are several variants of fold:

foldl

Folds "from the left". Computes ( … (((x_0 `f` x_1) `f` x_2) `f` x_3) `f`… ). In other words, first applies function f to the leftmost two arguments, then applies f to that result and the third argument, then applies f to the result of that and the fourth argument, and so on. This is the most straightforward, but it's also a little wasteful of memory, especially when you run it over really huge lists.

foldr

Folds "from the right". Computes x_0 `f` (x_1 `f` (x_2 `f` (x_3 `f` …))). In other words, applies f to the rightmost two arguments, then applies f to the next argument to the left and the result of the previous application, and so on. Sometimes this is better if your function can arrive at its final result without having to traverse all of an infinite list (boolean functions or multiplication (maybe) can do this if there's a zero somewhere in the list)

foldl'

Folds from the left like foldl, but is more efficient in memory usage so you can use it on a huge list.

(Here's a bit more discussion, if you're interested: https://qr.ae/TW7XD4.)

Some little notes on syntax

1. A two-argument function (say, f x y) can actually be stuck between its operands by using backquotes.

   Prelude> f x y = x + 2 * y
   
   Prelude> f 1 2
   5
   
   Prelude> 1 `f` 2
   5
   

2. A single quote is a legitimate part of a variable name. You can read it as "prime". So, you can have a function f, and another function f', read as "f prime". Or, you could have a function named o'donnell, if you really want.

   Prelude> o'donnell x = "Top o' the marning to ye, " ++ x ++ "!"
   
   Prelude> o'donnell "Frank"
   "Top o' the marning to ye, Frank!"
   

Suppose we want to sum up a list of numbers:

λ Prelude> ns
[1,2,3,4,5,6,7,8,9,10]

λ Prelude> :t foldl
foldl :: Foldable t => (b -> a -> b) -> b -> t a -> b

λ Prelude> foldl (+) 0 ns
55

Wut… just happened?

First, we verified that ns is a list of the integers from 1 to 10.

Then, we reminded ourselves what foldl wants. And it wants:

• Well, it can only be run over types t that are Foldable, for one thing. A list is foldable.
• Given that, it wants a function that takes as input things that are type b and type a (two inputs), and that returns something of type b. In our case, types b and a are the same: integers, because we're summing a list of integers to an integer. We could be summing up the lengths of a list of stirngs, in which case, b would still be an integer (the result), but a would be the type string, because our inputs (from the list) are strings. I'll show you that in a minute.
• foldl also wants something of type b, our result type. This is the initial value. For summing things, we (usually) start with zero.
• And, finally, foldl wants that Foldable of things that are type a. That's what that t a part means. In our case, that means we have to give a list of integers.
• And, finally finally, foldl returns a thing of type b. An integer, in our case. That's the result of the fold operation.

And then we invoked foldl. The two-argument function of things type b and a is just addition ("(+)"). By putting the "+" in parentheses, we just handed a raw function to foldl. Remember that "functions as first-class values" thing?

Then, the next argument we handed foldl was 0, the initial value.

Finally, we gave it the list we want to sum up.

And… out pops the answer! 55!