Yesterday, April 9, 2020, I started reading studying Real World Haskell by Bryan O’Sullivan. It is excellent. Most of all, I like the balanced mix of the theoretical and the practical. I am going to learn a lot. (Some homework on GitHub)
Below is an annotated reading log. I am keeping it in order to keep motivated. Also to collect a few notes and nuggets along the way. (Note: a “week” in the terminology of this blog does not necessarily consist of seven contiguous days. That is because stuff happens.)
Day 1, April 9. Chapters 1 and 2.
Why Care About Types, p. 17
Before we launch into a deeper discussion of Haskell’s type system, let’s talk about why we should care about types at all — what are they even for? At the lowest level, a computer is concerned with bytes, with barely any additional structure. What a type system gives us is abstraction. A type adds meaning to plain bytes: it lets us say “these bytes are text,” “those bytes are an airline reservation,” and so on. Usually, a type system goes beyond this to prevent us from accidentally mixing up types. For example, a type system usually won’t let us treat a hotel reservation as a car rental receipt. The benefit of introducing abstraction is that it lets us forget or ignore low-level details. If I know that a value in my program is a string, I don’t have to know the intimate details of how strings are implemented. I can just assume that my string is going to behave like all the other strings I’ve worked with.
Day 2, April 10. Chapter 3
Algebraic data types allow us to distinguish between otherwise identical pieces of information. Two tuples with elements of the same type are structurally identical, so they have the same type.
Consider first the tuples a and b:
a = ("Porpoise", "Grey")
b = ("Table", "Oak")
We can pass b to a function expecting an pair consisting of an cetacean’s name and a color. The compiler will not complain, since a and b have the same type. But there is another way:
data Cetacean = Cetacean String String data Furniture = Furniture String String c = Cetacean "Porpoise" "Grey" d = Furniture "Table" "Oak"
This second way let’s us bring the type system to bear in writing programs with fewer bugs. With the tuples we just defined, we could conceivably pass a description of a whale to a function expecting a chair, and the type system could not help us. With the algebraic data types, there is no such possibility of confusion. (p. 46)
Day 3, April 11, 2020, Chapter 3
Just realized that both of the following are product types:
data Point3Da = Point3Da (Double, Double, Double)
data Point3Db = Point3Db { x :: Double, y:: Double, z:: Double}
But the record syntax gives accessor functions by default, e.g.
Main> b = Point3Db { x = 1, y = 2, z = 3}
Main> x b
1.0
Working through the exercises. Feels good.
Day 4, April 12, 2020, Chapter 4: Functional Programming
On page 72, an 11-line skeleton of a command-line program for working with files. Nice!
Day 5, April 13, 2020
Having fun working the exercises in Chapter 4, page 84. Problem 4, scrambling text is especially nice. View a piece of text as an irregular list of exploded strings, so that “abc” explodes to ["a", "b", "c"]. The core of the problem is to design a function
transpose :: [[String]] -> [[String]]
such that transpose . transpose is the identity, modulo empty lists. From this one the desired function
transposeString :: String -> String
Here is a sample:
> str = "abc\ndef\ngh" > transposeString str "adg\nbeh\ncf" > transposeString $ transposeString str "abc\ndef\ngh"
Day 6: April 15, 2020: Still in Chapter 4
Missed a day yesterday due to pressing real-world obligations as well as a time-sink of a mini-disaster: my usual computer is ill and possibly approaching its final weeks of life. No way to repair it as we are confined to our apartment due to the pandemic. Anyway: onward!
In today’s reading: structural recursion, which the O’Donnell introduces in the humble context of writing a function to convert a string representing an integer to an integer. Also a discussion of tail recursion, constant space versus linear space, and tail call optimization. There is also a good treatment of this X’s book on ML, which, in common with Real World Haskell, has a pleasant mix of the theoretical and the practical.
Following a few more such examples, all done with recursion defined via pattern-matching, the author introduces the map, filter, and foldl functions as a way of capturing common patterns of computation.
Notes
-
- foldl, which is defined recursively by two pattern-matching equations, yields tail-recursive functions. That is good for performance: a smart compiler compiles a foldl into a for loop.
- Ditto for foldr. Functions are expressible via foldr if and only if they are primitive recursive.
- See Ravi Chug’s cs223 course for notes on tail recursion.
See also this code in the Elm compiler (List.foldl is stack-safe and. List.foldr is , according to @Robin, stack-safe-ish: it will consume more and more stack space up to a point, then move to a stack-safe but slower algorithm
Day 7, April 16, 2020. On to Chapter 5, Writing a Library (Working with JSON data)
Still have to do a few of the exercises in Chapter 4, but decided to forge ahead today. Lots of practical advice about designing a library, e.g., this:
Instead of rendering straight to a string, our Prettify module will use an abstract type that we’ll call Doc. By basing our generic rendering library on an abstract type, we can choose an implementation that is flexible and efficient. If we decide to change the underlying code, our users will not be able to tell.
Here is the type signature:
data Doc = Empty | Char Char | Text String | Line | Concat Doc Doc | Union Doc Doc deriving (Show,Eq)
Note that a Doc is really a tree. There is a concatenation operator:
(<>) :: Doc -> Doc -> Doc Empty <> y = y x <> Empty = x x <> y = x `Concat` y
so that Empty is the “zero” element. Actual rendering is done by compact :: Doc -> String. I’ll have to come back to this chapter and reread it when I’m writing a package of my own.
Next “Haskell Week:” on to Type classes!
jxxcarlson's blog 