Hypomnemata

Real World Haskell Chapter 3 is your introduction to the real syntax of Haskell programs.  It’s not entirely complete yet (you need modules and a few other things), but it’s enough to write one-purpose scripts, which is a huge step.

Again, there wasn’t all that much new to me in Chapter 3 here.  The important thing to takeaway was a review of the difference between data and type: data is struct, type is typedef (with type safety).  Other than that, the coverage of guards was nice, and the exercises were good for reinforcing knowledge and expanding horizons a little bit. Ending with the Graham scan algorithm is a little intense, but it’s significantly less evil than some of Knuth’s high-numbered problems.

However, in the exercises, be wary of number 4: there was a ++ operator introduced in the context of strings.  Don’t forget that it exists.  Number 5 is also a bit gnarly; I feel like they’ve totally screwwed the pooch on it.  If you don’t get it within 10 minutes, give up and read the comments on the website (or, if you know a bit about the performance of Lists in functional languages, just accept that your solution is O(n²)).

Notes: not really anything noteworthy for me in these chapters.  I already speak a bit of Haskell.

Quotes:

Because the result of applying a pure function can only depend on its arguments, we can often get a strong hint of what a pure function does by simply reading its name and understanding its type signature. As an example, let’s look at not.

ghci> :type not
not :: Bool -> Bool

Even if we didn’t know the name of this function, its signature alone limits the possible valid behaviours it could have.

• Ignore its argument, and always return either True or False.
• Return its argument unmodified.
• Negate its argument. 

We also know that this function can not do some things: it cannot access files; it cannot talk to the network; it cannot tell what time it is. 

Purity makes the job of understanding code easier. (emphasis mine) The behaviour of a pure function does not depend on the value of a global variable, or the contents of a database, or the state of a network connection. Pure code is inherently modular: every function is self-contained, and has a well-defined interface.

– pp39-40

As a formalist, I’m all about reasoning about type signatures for things.  When I design larger systems, I’m always looking for the type of information being passed around, then looking at how to turn one stage’s input format into the input format of the next stage.  This is partly based on my experience with functional languages, and partly based on an old programming maxim: “Show me your flowcharts and conceal your tales, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; it’ll be obvious.” (Brooks, The Mythical Man-Month, Ch9)

Takeaway:

Reading through the first two chapters of Real World Haskell reminded me just how bizarre learning OCaml was the first time around.

A new coworker recently mentioned Scala as something he enjoyed; I’ll probably give it a go soonish, to see how it fits.  I really like the feel of Haskell, and the community seems to be vibrant and growing.  About two years ago, I stopped using OCaml for anything, and started lurking around Haskell.  After a bit of prodding and coaching by my friend Evan, I mostly came to understand monads, but am still a little rough on the details.  Hopefully the process of reading through Real World Haskell will refine this, and let me knock out some interesting algorithmic code in Haskell.