Haskell Design Patterns: Take your Haskell and functional programming skills to the next level by exploring new idioms and design patterns

The IO Monad provides the context in which side effects may occur, and it also allows us to decouple pure code from I/O code. In this way, side effects are isolated and made explicit. Let's explore the ways in which I/O participates as a first-class citizen of the language:

import System.IO
import Control.Monad
import Control.Applicative

main = do
  h <- openFile "jabberwocky.txt" ReadMode
  line  <- hGetLine h
  putStrLn . show . words $ line
  hClose h

This code looks imperative in style: it seems as if we are assigning values to h and line, reading from a file, and then leaving side effects with the putStrLn function.

The openFile and hGetLine functions are I/O actions that return a file handle and string, respectively:

  openFile :: FilePath -> IOMode -> IO Handle
  hGetLine ::             Handle -> IO String

The hClose and putStrLn functions are I/O actions that return nothing in particular:

  putStrLn :: String -> IO ()
  hClose   :: Handle...

Even though Haskell I/O code is purely functional, this does not prevent us from writing imperative style I/O code. Let's start by printing all the lines of the file:

import System.IO
import qualified Data.ByteString as B
import qualified Data.ByteString.Char8 as B8
import Data.Char (chr)

main = do
  h <- openFile "jabberwocky.txt" ReadMode
  loop h
  hClose h
  where
    loop h' = do   
     isEof <- hIsEOF h'
     if isEof
      then putStrLn "DONE..."
      else do
        line  <- hGetLine h'
        print $ words line
        loop h'

Instead of the hGetLine function, let's use a Data.ByteString.hGet function to read from the file in chunks of 8 bytes:

  chunk  <- B.hGet h' 8
  
  print . words $ show chunk
  –- vs
  –- line  <- hGetLine h'
  –- print $ words line

The splitting of a chunk into words is not meaningful anymore. We need to accumulate the chunks until we reach the end of a line and then capture the accumulated line and possible remainder:

data...

Of the three main glues of Haskell (HOFs, the type system, and laziness), laziness is different in that it is not a concrete thing in the language, but is instead related to the way the code will be evaluated in the runtime. Laziness is something that we have to know about rather than something we can always see in the code.

Of course, laziness does show in the language, for example, wherever we want to enforce strict evaluation, as with the sequence function:

main = do
  –- lazy IO stream
  let ios = map putStrLn ["this", "won't", "run"]
  
  putStrLn "until ios is 'sequenced'..."
  sequence_ ios –- perform actions

Where:

  sequence_  :: [IO ()] -> IO ()
  sequence_  =  foldr (>>) (return ())

The sequence_ function discards the action results because the (>>) operator discards the results of the its firsts argument action.

In contrast, the sequence function retains the results:

main = do
  h <- openFile "jabberwocky.txt" ReadMode
  line1 <- hGetLine h            ...

Why Functional Programming Matters [REF 1990, John Hughes] has been described as the manifesto for lazy programming, written at a time when enthusiasm for this style was running very high. Less than 20 years later, Oleg Kiselyov published the obituary of Lazy I/O in a series of writings; for more information, visit http://okmij.org/ftp/Streams.html.

In the late 2000s, Kiselyov championed a new way of doing I/O that combines the best of Handle-based I/O (precise control over resources and predictable space requirements) with the best of lazy I/O (decoupling of producers and consumers, high level of abstraction).

Let's get to the root of this style of programming by rephrasing the example we saw earlier. Recall the Chunk data type and the parseChunk function:

data Chunk = Chunk {chunk :: String}
                    | LineEnd {chunk :: String,
                               remainder :: String}

  deriving Show
parseChunk :: ByteString -> Chunk
parseChunk chunk
 = if rightS =...

Let's compare the 3 styles of I/O we have encountered from a few perspectives:

We explored three styles of doing I/O in Haskell: imperative I/O, lazy I/O, and Iteratee I/O. While imperative I/O gave us fine control over resource management and space requirements, it had to be written at a low level of abstraction.

In contrast to this, lazy I/O stood out as elegant and written at a high level of abstraction, giving us great decoupling between producers and consumers. Then we explored the high price we pay for relinquishing control of when side effects occur.

Finally, we found that Iteratee I/O gives us the best of both worlds, fine control over resource management and usage, and written at a very high level of abstraction.

While looking at the three styles, we paid close attention to who was driving evaluation. We looked at the means of decoupling producers and consumers of data and also the extent to which producers and consumers can communicate in the midst of data processing.

In the next chapter, we will focus on patterns for composition with a focus on the fundamental...