Llaisdy

Real World Haskell
Chapter 3: Defining types, streamlining functions
Section: Parametrised types

On the first few readings, this section (a single page in the dead tree version) flummoxed me completely. Some of the comments on the book’s web site were helpful, and now I’ve worked through it. This post can bear witness to my journey.

Contents:

1. Types
2. Algebraic data types
3. Parametrised types
4. Very Important Note
5. A Use case
6. Maybe, Just and Nothing
7. Note also

Read the rest of this entry »

I’m working my way through Real World Haskell. Haskell is an exciting language. The book is … so near and yet so far: it could be an exciting introduction to an exciting language, as well as showing that you can learn ‘real world’ programming and think deeply about the language at the same time… Unfortunately, the current edition (both print and online versions) is extremely shoddy and consequently very annoying.

For example, Chapter 3 “Defining Types, Streamlining Functions” has a section “Pattern Matching” which describes, among other things, how the ordering of function definitions affects the behaviour of the code.

Unfortunately, the example given (reproduced below) works the same whichever way the definitions are ordered.

-- file: rwh/ch03/add.hs
sumList (x:xs) = x + sumList xs
sumList [] = 0

Why couldn’t the authors provide an example that exemplifies their point?

What’s wrong with good old factorial?

This order works properly:

-- file: fact_good.hs
factorial 1 = 1
factorial n = n * factorial (n - 1) -- brackets necessary

The reverse order doesn’t work at all:

-- file: fact_bad.hs
factorial n = n * factorial (n - 1) -- brackets necessary
factorial 1 = 1

Loading and running fact_bad.hs in ghci causes two interesting things:
Read the rest of this entry »