Bryan OSullivan - Real World Haskell

This easy-to-use, fast-moving tutorial introduces you to functionalprogramming with Haskell. You'll learn how to use Haskell in avariety of practical ways, from short scripts to large anddemanding applications. Real World Haskell takes youthrough the basics of functional programming at a brisk pace, andthen helps you increase your understanding of Haskell in real-worldissues like I/O, performance, dealing with data, concurrency, andmore as you move through each chapter.With this book, you will:

• Understand the differences between procedural and functionalprogramming

• Learn the features of Haskell, and how to use it to developuseful programs

• Interact with filesystems, databases, and network services

• Write solid code with automated tests, code coverage, and errorhandling

• Harness the power of multicore systems via concurrent andparallel programming

You'll find plenty of hands-on exercises, along with examples ofreal Haskell programs that you can modify, compile, and run.Whether or not you've used a functional language before, if youwant to understand why Haskell is coming into its own as apractical language in so many major organizations, Real WorldHaskell is the best place to start.

The name of netpbm's grayscale file format is PGM (portable gray map). It is actually not one format, but two; the plain (or P2) format is encoded as ASCII, while the more common raw (P5) format is mostly binary.

A file of either format starts with a header, which in turn begins with a "magic" string describing the format. For a plain file, the string is P2 , and for raw, it's P5 . The magic string is followed by whitespace, and then by three numbers: the width, height, and maximum gray value of the image. These numbers are represented as ASCII decimal numbers, separated by whitespace.

After the maximum gray value comes the image data. In a raw file, this is a string of binary values. In a plain file, the values are represented as ASCII decimal numbers separated by single-space characters.

A raw file can contain a sequence of images, one after the other, each with its own header. A plain file contains only one image.

For our first try at a parsing function, we'll only worry about raw PGM files. We'll write our PGM parser as a pure function. It's won't be responsible for obtaining the data to parse, just for the actual parsing. This is a common approach in Haskell programs. By separating the reading of the data from what we subsequently do with it, we gain flexibility in where we take the data from.

We'll use the ByteString type to store our graymap data, because it's compact. Since the header of a PGM file is ASCII text but its body is binary, we import both the text- and binary-oriented ByteString modules:

For our purposes, it doesn't matter whether we use a lazy or strict ByteString, so we've somewhat arbitrarily chosen the lazy kind.

We'll use a straightforward data type to represent PGM images:

Normally, a Haskell Show instance should produce a string representation that we can read back by calling read. However, for a bitmap graphics file, this would potentially produce huge text strings, for example, if we were to show a photo. For this reason, we're not going to let the compiler automatically derive a Show instance for us; we'll write our own and intentionally simplify it:

Because our Show instance intentionally avoids printing the bitmap data, there's no point in writing a Read instance, as we can't reconstruct a valid Greymap from the result of show.

Here's an obvious type for our parsing function:

This will take a ByteString, and if the parse succeeds, it will return a single parsed Greymap, along with the string that remains after parsing. That residual string will be available for future parses.

Our parsing function has to consume a little bit of its input at a time. First, we need to assure ourselves that we're really looking at a raw PGM file; then we need to parse the numbers from the remainder of the header; and then we consume the bitmap data. Here's an obvious way to express this, which we will use as a base for later improvements :

This is a very literal piece of code, performing all of the parsing in one long staircase of case expressions. Each function returns the residual ByteString left over after it has consumed all it needs from its input string. We pass each residual string along to the next step. We deconstruct each result in turn, either returning Nothing if the parsing step fails, or building up a piece of the final result as we proceed. Here are the bodies of the functions that we apply during parsing (their types are commented out because we already presented them):