Practical Haskell: ByteString, Text, and Strict Data

The problem with String

Every earlier chapter used String freely, because for teaching, its simplicity is exactly the point: String really is just [Char], an ordinary list, with every trick from Chapter 6 onward — map, filter, pattern matching on (x:xs) — applying to it directly. That simplicity has a real cost the moment text stops being a toy example.

A five-character String needs ten separate heap objects — five cons cells for the list spine, five boxed Chars for the letters — scattered wherever the garbage collector happened to put them, each one requiring its own pointer to be followed to read the next letter. Data.Text and Data.ByteString store the same five characters in one contiguous block of memory: one allocation, no pointer-chasing, and — for Text specifically — genuinely correct Unicode handling that String’s “just a list of Char” model doesn’t get for free either.

Text: strings, done properly

Data.Text is the type to reach for whenever String was standing in for “human-readable text” — names, messages, file contents meant to be read, anything Unicode-aware.

import qualified Data.Text as T
import qualified Data.Text.IO as TIO

greeting :: T.Text
greeting = T.pack "Hello, world!"   -- String -> Text

shout :: T.Text -> T.Text
shout = T.toUpper

main :: IO ()
main = TIO.putStrLn (shout greeting)   -- Text-aware IO, not the String-based putStrLn

T.pack/T.unpack convert between String and Text at the boundary; most Text-using code stays in Text throughout, only converting at the edges (parsing command-line arguments, formatting a final String for a library that demands one). OverloadedStrings (covered properly in the next chapter’s extension field guide) lets string literals like "Hello, world!" be Text directly, skipping T.pack almost everywhere.

ByteString: bytes, not characters

Data.ByteString packs the same way Text does, but for raw bytes (Word8), with no notion of “character” or encoding at all. Reach for it when the data genuinely isn’t text — binary file formats, network protocol payloads, image data — or when it’s ASCII-only text where Unicode correctness would be pure overhead.

import qualified Data.ByteString as BS
import qualified Data.ByteString.Char8 as BSC   -- ASCII-only convenience functions

readHeader :: FilePath -> IO BS.ByteString
readHeader path = BS.take 4 <$> BS.readFile path   -- first 4 bytes, e.g. a magic number

isGzip :: BS.ByteString -> Bool
isGzip bs = BS.take 2 bs == BS.pack [0x1f, 0x8b]    -- gzip's magic bytes

Strict data: the tuple trap, generalized

Chapter 6’s “tuple trap” showed that foldl' alone doesn’t stop a lazy field inside an otherwise-forced structure from leaking. The general-purpose fix — data types whose fields are strict by construction, so this class of leak becomes structurally impossible — comes from two directions:

{-# LANGUAGE BangPatterns #-}

-- hand-rolled strict fields, one type at a time (Chapter 6's fix)
data Pair a b = Pair !a !b

-- Data.Strict provides ready-made strict versions of the usual suspects
import qualified Data.Strict.Maybe as SMaybe
import qualified Data.Strict.Tuple as STuple

-- SMaybe.Maybe and STuple.Pair guarantee their contents are never a lazy thunk

strict, the package Data.Strict.Maybe and Data.Strict.Tuple come from, exists so nobody has to hand-write Pair a b = Pair !a !b — style strict variants of Maybe, Either, and tuples for every accumulator in every hot loop. Two GHC extensions go a step further and change the default rather than requiring bangs everywhere by hand:

{-# LANGUAGE StrictData #-}
-- every field of every data type declared in this module is strict by default,
-- as if every field had a ! in front of it, without writing the bangs

data Stats = Stats { total :: Int, count :: Int }   -- both fields strict, no ! needed

StrictData flips the default for fields; Strict (a separate, more aggressive extension) flips the default for ordinary let/where bindings too, module-wide. Both exist because the standard advice — “add bangs where you find a leak” — requires first finding the leak, and a module dealing entirely in small, hot-path accumulators is often better served by strict-by-default with occasional ~ (lazy annotation) for the rare field that genuinely benefits from staying lazy, rather than the reverse.

IORef: everyday mutable state in IO

Purity’s ST monad (Chapter 8) gave mutation a scoped, provably-pure escape hatch — genuine in-place writes, but only ever visible inside one runST computation, never leaking out. Ordinary IO code frequently wants something simpler: a single mutable cell, alive for as long as the program needs it, with no runST boundary to manage. IORef is exactly that:

import Data.IORef

main :: IO ()
main = do
  counter <- newIORef (0 :: Int)
  writeIORef counter 5
  modifyIORef counter (+1)
  final <- readIORef counter
  print final   -- 6

newIORef, readIORef, writeIORef, and modifyIORef are the whole interface — genuinely just a mutable box, with no purity trick hiding underneath the way ST’s state token has one. That’s precisely why IORef lives in IO rather than getting ST’s special treatment: reading and writing it is a real side effect, visible to anything else sharing the same reference, and the type honestly says so.

Handling exceptions without losing your footing

Maybe and Either (Chapters 5 and 11) handle expected failure — a lookup that might miss, a parse that might fail — as an honest part of a function’s own type. Real IO code also has to deal with unexpected failure: a file that doesn’t exist, a network call that times out, division by zero. Control.Exception is where that lives:

import Control.Exception

safeDiv :: Int -> Int -> IO Int
safeDiv x y = evaluate (x `div` y) `catch` \e -> do
  putStrLn ("Caught: " ++ show (e :: ArithException))
  return 0

ghci> safeDiv 10 2
5
ghci> safeDiv 10 0
Caught: divide by zero
0

catch takes an IO action and a handler, running the handler if the action throws an exception matching the handler’s argument type — ArithException here, so catch only intercepts arithmetic-related exceptions, letting anything else propagate normally.

A second, equally common need is guaranteeing cleanup happens even when something goes wrong partway through — closing a file handle whether reading it succeeded or crashed halfway:

import System.IO

withFileSafely :: FilePath -> (Handle -> IO a) -> IO a
withFileSafely path = bracket (openFile path ReadMode) hClose

bracket acquire release use runs acquire, then use on the result, and guarantees release runs afterward — whether use finished normally, returned early, or threw an exception. This is the same resource-safety instinct C++‘s RAII or Python’s with blocks reach for, expressed as an ordinary higher-order function rather than new syntax.

Choosing, in practice

Situation	Reach for
Human-readable text, Unicode matters	Text
Binary data, network payloads, ASCII-only bytes	ByteString (strict)
Streaming a large file without loading it all	ByteString.Lazy or Text.Lazy
An accumulator in a hot loop (tuple, record)	strict fields (!, StrictData, or strict’s ready-made types)
Everything else — small scripts, teaching, glue code	String is still completely fine

None of Text, ByteString, or strict data change what a program computes — every example in this chapter could, in principle, be rewritten with plain String and lazy tuples and produce the identical answer. What changes is how much the machine has to do, and how much memory it holds onto, to get there — the exact gap this book has been calling “clarity first, performance once it’s earned its place” since the very first Pearls chapter.