Translate Haskell into English Manually, Part II

This is part two of a two-part series [see linuxjournal.com/article/9096 for part one]. In this article, I build upon the concept of a parse pipeline with the State monad. Then, with all the pieces in place, I show the complete Haskell program. I also take a step back and consider why Haskell isn't as popular as some other languages and whether it deserves a place in your programmer's toolbox.

In part one of this series, I showed parse pipelines that looked like:

c $ b $ a ctx

Now, there are two problems with basing the whole program around this construct. The first is that everything is written backwards. It's not too hard to work around that by creating an operator that reads left to right, unlike $. However, it's also a pain to pass the ParseContext explicitly to and from every function that acts as a ParseContext transformer. [Note: 1. In an early version of my program, I wrote the following:

-- |> is like a UNIX pipe.
infixl 9 |>
x |> f = f x

Hence, c $ b $ a ctx could be written ctx |> a |> b |> c. I originally wrote the whole program around this construct instead of the State monad, but I like the State monad better because of Haskell's syntactic sugar for monads.]

Purely functional means you have to pass everything to the function (that is, no globals) and you have to return everything from the function (that is, no side effects allowed, not even printing a message to the user). Passing everything explicitly can get tedious, but that's something Haskell has an answer for—monads. Instead of having to piece a pipeline together using $, the do syntax can transform the above into:

do a
   b
   c

Not only does the do syntax “read the right way”, but (and this is a key point) it's also syntactic sugar for saying, “the result of 'a' will be needed to call 'b', and the result of 'b' will be needed to call 'c'.” It's still a pipeline, but now it's syntactically convenient.

The State monad is a monad that comes with Haskell, which is perfectly suited for the current situation. The State monad is a simple monad that simply encapsulates a bit of state. Looking at the example above, a, b and c are all functions that take and modify this implicit state. Because each might modify that state, they must be run in order, which, of course, isn't necessarily the norm in Haskell.

The notion of a ParseContext transformer dovetails perfectly with how the State monad works. Each ParseContext transformer will now have the following signature:

f :: State ParseContext ()

This translates into:

"f" is a function that has type "State ParseContext ()", which is to say
that "f" operates within the "State" monad where the "State" monad is
encapsulating a "ParseContext" object.

In summary, what does the monad buy us?

Lest my reader get bleary eyed, let's see some code! I've updated the makeCool.hs program to use the State monad, thus creating a true Rube Goldberg (en.wikipedia.org/wiki/Rube_Goldberg#Rube_Goldberg_machines) program:

import Control.Monad.State

data TokenType = Identifier | Qualifier | Type | Symbol Char
  deriving (Show, Eq)

data Token = Token {
  tokenType :: TokenType,
  tokenValue :: String
} deriving Show

data ParseContext = ParseContext {
  input :: String,    -- The input that has not been parsed yet.
  output :: String,   -- The output generated so far.
  currTok :: Token,   -- The current token, if defined.
  stack :: [Token]    -- A stack of tokens we haven't dealt with yet.
} deriving Show

makeCool :: State ParseContext ()
makeCool = do
  ParseContext {input = s} <- get
  put (ParseContext {input = "", output = s ++ " is cool!\n"})
  return ()

main = do
  s <- getContents
  let ctx = ParseContext {input = s, output = ""} in
    putStrLn $ output $ execState makeCool $ ctx

Running it:

$ echo -n "Haskell" | runhugs -98 makeCoolState.hs
Haskell is cool!

A few things deserve note. First, in order to use the State monad, you must pass -98 to runhugs, which enables special Hugs extensions. Next, what used to be:

putStrLn $ output $ makeCool ctx

is now:

putStrLn $ output $ execState makeCool $ ctx

The execState function is used to get into and out of the “State monad world”. Occasionally, it's easy to get confused by higher order functions like execState; however, it's easy enough to apply a cookie-cutter approach. That is, execState makeCool $ ctx takes ctx as an initial state and returns a final state. makeCool operates within “the context” of the State monad. Easy enough. If you really want to know the nitty-gritty details of how the State monad works, there's a really fun explanation on Wikipedia (en.wikibooks.org/wiki/Programming:Haskell_monads#The_State_monad).

Notice that makeCool uses the do syntax to tie multiple statements together. First it uses the get function to get the current state. Then it uses the put function to put back an updated state. Then it returns (), which is to say nothing useful. Looking at get and put, at it's heart, the makeCool function is still a ParseContext transformer.

Another thing deserves note. As usual, there are a few convenience functions for interacting with the State monad. For instance, instead of using get and put explicitly, it's also possible to use the modify function, combining the two activities. Hence, the makeCool function could have been written:

makeCool :: State ParseContext ()
makeCool = modify (\ctx ->
  ctx {input = "", output = input ctx ++ " is cool!"})

The modify function takes a callback that takes the state as input and returns state as output. Instead of passing a named function to modify, I'm passing an anonymous function, hence the \ syntax. Translating:

"makeCool" is a "ParseContext transformer".  Modify the "ctx" by setting
"input" to "" and setting "output" to the original input plus the string
" is cool!".

As in other languages, anonymous functions can be either ultra-convenient or ultra-inscrutable, depending on both the author and the reader. Nonetheless, I'll use the convenience functions where, uh, convenient.