Detecting Unmounted Partitions With Blkid

Did you know that you can instantly check all partitions on your system (including USB thumb drives), and see if they’re mounted or not? The hero command of the day is sudo blkid -o list:

$ sudo blkid -o list
device       fs_type label    mount point      UUID
-----------------------------------------------------------------------------------
/dev/sda1    ntfs             /mnt/windows-xp  XXXXXXXXXXXXXXXX
/dev/sda2    ext4             /                XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
/dev/sda3    ext4             /home            XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
/dev/sda6    swap             <swap>           XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
/dev/sda5    ext4             /mnt/data        XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
/dev/sdb1    ext2             (not mounted)    XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
/dev/sdc1    vfat             (not mounted)    XXXX-XXXX

As you can see, I have two USB drives (one in ext2 and the other in vfat format) plugged in, but not mounted, and blkid detects this for me. Pretty useful, don’t you think? There’s no need to parse /proc/mounts or fiddle with the (very) verbose output of sudo fdisk -l. I stumbled upon blkid’s obscure “-o list” option while trying to write a shell script to automatically mount unmounted USB drives.

The only troublesome aspects of “-o list” are that you can’t customize which columns are displayed (e.g., for me, I’d like to drop the label column), and also you can’t separate the columns by whitespace because of how there is a space inside the (not mounted) mount point. Looking at the sources for blkid, it seems that there are also two other descriptions with whitespace in them: (in use) and (mounted, mtpt unknown) (see http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=blob_plain;f=misc-utils/blkid.c;hb=HEAD). These deficiencies make it hard to easily and reliably parse the output with just a shell script.

I actually ended up writing a 300 line Haskell program that uses Parsec to reliably parse the output of blkid. It took a while to write, considering my newbie Haskell skills (aren’t most Haskellers late bloomers?). Anyway, it also leverages the CmdArgs library, and automatically mounts/unmounts USB devices with ease and grace. Speaking of Haskell, I’m slowly in the process of converting my various error-prone shell scripts into robust, mini Haskell programs, and I’ve been very satisfied with the results. And porting shell scripts into Haskell is a great way to learn more Haskell, too!

UPDATE December 1, 2011: Here is a convenience link to said ~300 line program for you Googlers: Parsec and CmdArgs in Action: A Small Example.

UPDATE December 11, 2011: Fixed broken link. Also, the recent kernel.org fiasco has changed the home of util-linux-ng to: https://github.com/karelzak/util-linux/, and the blkid source is at https://github.com/karelzak/util-linux/blob/master/misc-utils/blkid.c.

Xmonad.hs: The Joy of Refactoring

The more I use Haskell, the more I learn to appreciate its beauty. The thesis of this post is: Haskell code is so easy to refactor. What follows is an account of my experience the other day with extending my XMonad configuration file, and how easy/fun it was for me. It’s written in a very newbie-friendly way for all XMonad users who don’t know much Haskell, if at all.

The other day, I ended up writing something like the following into my xmonad.hs file:

myManageHook :: ManageHook
myManageHook = composeAll
    [
    ...
    , resource  =? "atWorkspace0" --> doShift "0"
    , resource  =? "atWorkspace1" --> doShift "1"
    , resource  =? "atWorkspace2" --> doShift "2"
    , resource  =? "atWorkspace3" --> doShift "3"
    , resource  =? "atWorkspace4" --> doShift "4"
    , resource  =? "atWorkspace5" --> doShift "5"
    , resource  =? "atWorkspace6" --> doShift "6"
    , resource  =? "atWorkspace7" --> doShift "7"
    , resource  =? "atWorkspace8" --> doShift "8"
    , resource  =? "atWorkspace9" --> doShift "9"
    , resource  =? "atWorkspaceF1" --> doShift "F1"
    , resource  =? "atWorkspaceF2" --> doShift "F2"
    , resource  =? "atWorkspaceF3" --> doShift "F3"
    , resource  =? "atWorkspaceF4" --> doShift "F4"
    , resource  =? "atWorkspaceF5" --> doShift "F5"
    , resource  =? "atWorkspaceF6" --> doShift "F6"
    , resource  =? "atWorkspaceF7" --> doShift "F7"
    , resource  =? "atWorkspaceF8" --> doShift "F8"
    , resource  =? "atWorkspaceF9" --> doShift "F9"
    , resource  =? "atWorkspaceF10" --> doShift "F10"
    , resource  =? "atWorkspaceF11" --> doShift "F11"
    , resource  =? "atWorkspaceF12" --> doShift "F12"
    ]

Even if you don’t know Haskell, you can tell that the above is very repetitive. It looks a bit stupid. Vim’s visual block mode makes editing the above lines in bulk pretty easy, but your xmonad.hs file is a program’s source code, and source code must obey the Do not Repeat Yourself rule. It will make life easier down the road.

Let’s first consider what the code above means. First, we observe that myManageHook is a function, of type ManageHook. The composeAll function’s type signature is as follows:

composeAll :: [ManageHook] -> ManageHook

(I loaded up XMonad from GHCi to figure this out.) So composeAll merely “compresses” a list of ManageHook types into a single ManageHook. Great! Now we know exactly what each element in the list really means:

myManageHook = composeAll
    [ a ManageHook
    , a ManageHook
    , a ManageHook
    , a ManageHook
    ]

So to covert the various “atWorkspace0”, “atWorkspace1”, etc. lines we just need to create a function that generates a list of ManageHook types, and append this list to the one that already exists! Like this:

myManageHook :: ManageHook
myManageHook = composeAll $
    [ ... existing MangeHook items
    ]
    ++ workspaceShifts
    where
        workspaceShifts = another list of ManageHooks

Notice how we had to add in a “$” symbol, because:

myManageHook = composeAll [list 1] ++ [list 2]

means

myManageHook = (composeAll [list 1]) ++ [list 2]

which means

myManageHook = ManageHook ++ [list 2]

which is definitely not what we want. We want this:

myManageHook = composeAll ([list 1] ++ [list 2])

which is

myManageHook = composeAll [lists 1 and 2 combined]

and we can do this with the “$” dollar symbol. We could just use the explicit parentheses instead; ultimately it is a matter of style/taste.

So, let’s keep going. The workspaceShifts function needs to generate a list of ManageHooks. From the first code listing, it’s clear that all the generated ManageHooks need only vary slightly from each other:

    [
    ...
    , resource  =? "atWorkspace0" --> doShift "0"
    , resource  =? "atWorkspace1" --> doShift "1"
    , resource  =? "atWorkspace2" --> doShift "2"
    , resource  =? "atWorkspace3" --> doShift "3"
    , resource  =? "atWorkspace4" --> doShift "4"
    , resource  =? "atWorkspace5" --> doShift "5"
    , resource  =? "atWorkspace6" --> doShift "6"
    , resource  =? "atWorkspace7" --> doShift "7"
    , resource  =? "atWorkspace8" --> doShift "8"
    , resource  =? "atWorkspace9" --> doShift "9"
    , resource  =? "atWorkspaceF1" --> doShift "F1"
    , resource  =? "atWorkspaceF2" --> doShift "F2"
    , resource  =? "atWorkspaceF3" --> doShift "F3"
    , resource  =? "atWorkspaceF4" --> doShift "F4"
    , resource  =? "atWorkspaceF5" --> doShift "F5"
    , resource  =? "atWorkspaceF6" --> doShift "F6"
    , resource  =? "atWorkspaceF7" --> doShift "F7"
    , resource  =? "atWorkspaceF8" --> doShift "F8"
    , resource  =? "atWorkspaceF9" --> doShift "F9"
    , resource  =? "atWorkspaceF10" --> doShift "F10"
    , resource  =? "atWorkspaceF11" --> doShift "F11"
    , resource  =? "atWorkspaceF12" --> doShift "F12"
    ]

So the only thing that really changes is the suffix after “atWorkspace”; it goes from “0” to “F12”. Let’s express this idea in code:

myManageHook :: ManageHook
myManageHook = composeAll $
    [ ...
    ]
    ++ workspaceShifts
    where
        workspaceShifts = genList (s1 ++ s2)
        genList :: [String] -> [ManageHook]
        genList ss = map (\s -> resource =? ("atWorkspace" ++ s) --> doShift s) ss

We create a new genList function, which needs an argument (a [String], or “list of strings” to be exact). We creatively call them ss in the code above. The map function simply modifies each item in a list in the same way. So here, we modify every string (s) to become a MangeHook, by giving map‘s first argument as:

(\s -> resource =? ("atWorkspace" ++ s) --> doShift s)

The backslash followed by s binds a single string from the ss list as the variable s. The right arrow (->) signals the start of the function definition. Do you see the resemblance?

    ...
    , resource  =? "atWorkspace0" --> doShift "0"
    , resource  =? "atWorkspace1" --> doShift "1"
    , resource  =? "atWorkspace2" --> doShift "2"
    , resource  =? "atWorkspace3" --> doShift "3"
    ...

    vs.

    resource =? ("atWorkspace" ++ s) --> doShift s

Nice, clean, and succinct.

Now we just need to define those strings to feed into genList. Here’s s1:

        s1 :: [String] -- a list of strings
        s1 = map show [0..9]

Again, we use the map function. It’s such a handy little function! Haskell is very much built around such useful little named primitives (by convention, most things that look like “operators” such as multi-punctuation arrows, ampersands, and colons are part of some niche library, and not Haskell the core language). The show function merely converts its argument (here, a list of Ints), into strings, so the

s1 = map show [0..9]

part really means: [“0″,”1″,”2″,”3″,”4″,”5″,”6″,”7″,”8″,”9”].

So that’s s1. The second list, s2, is almost identical:

s2 = map (("F" ++) . show) [1..12]

The only difference is that it adds “F” as a prefix, so that we get “F1” instead of “1”, “F2” instead of “2”, and so on.

So, that’s it! The complete code is as follows:

myManageHook :: ManageHook
myManageHook = composeAll $
    [ ...
    ]
    ++ workspaceShifts
    where
        workspaceShifts = genList (s1 ++ s2)
        genList :: [String] -> [ManageHook]
        genList ss = map (\s -> resource =? ("atWorkspace" ++ s) --> doShift s) ss
        s1, s2 :: [String]
        s1 = map show [0..9]
        s2 = map (("F" ++) . show) [1..12]

We can actually shorten it even more:

myManageHook :: ManageHook
myManageHook = composeAll $
    [ ...
    ]
    ++ map (\s -> resource =? ("atWorkspace" ++ s) --> doShift s) (s1 ++ s2)
    where
        s1 = map show [0..9]
        s2 = map (("F" ++) . show) [1..12]

In the end, we’ve reduced 22 lines of stupid, repetitive code prone to human error and typos down to 4 lines of smart, modular code. I really enjoy this kind of refactoring: reduction of human-error-prone code.

What’s more, the whole experience was quite easy and enjoyable. I did not need to know what exactly a ManageHook type represented; instead, all I needed to know were the type signatures of the various existing parts. And that’s why Haskell is so fun to refactor: type signatures, combined with industrial-strength type checking, makes things safe. Plus, if you look at the code, everything matters. It’s really hard to write spaghetti code in Haskell (even for relative newbies like myself).

For the curious, here is a list of type signatures for composeAll, resource, doShift, (–<), and (=?):

Prelude XMonad> :t composeAll
composeAll :: [ManageHook] -> ManageHook
Prelude XMonad> :t resource
resource :: Query String
Prelude XMonad> :t doShift
doShift :: WorkspaceId -> ManageHook
Prelude XMonad> :t (-->)
(-->) :: Query Bool -> ManageHook -> ManageHook
Prelude XMonad> :t (=?)
(=?) :: Eq a => Query a -> a -> Query Bool

UPDATE July 3, 2011: Hendrik mentions a more concise approach using list comprehensions (arguably more Haskell-y, and simper):

myManageHook :: ManageHook
myManageHook = composeAll $
    [ ...
    ]
    ++ [resource =? ("atWorkspace" ++ s) --> doShift s 
       | s <- map show [0..9] ++ map (('F':) . show) [1..12] ]

UPDATE November 8, 2011: Fixed typo.

Haskell: Using CmdArgs (Single and Multi-Mode)

I use the CmdArgs module all the time for all of my personal Haskell projects. CmdArgs is really the one-stop solution for all of your command-line option handling needs. Its “killer” feature is the ability to support multi-mode options (e.g., “myprog mode1 [mode1 options]”, “myprog mode2 [mode2 options]”, etc.). Unfortunately, not many people know about CmdArgs, it seems. So, I’m writing this post to help spread its popularity among fellow newbie/intermediate Haskellers. I’m including two sample programs — a traditional single-mode program, and a multi-mode program, for your tinkering pleasure. They are hereby released into the PUBLIC DOMAIN.

The following is a simple single-mode program, singleMode.hs.

-- singleMode.hs
-- License: PUBLIC DOMAIN
{-# LANGUAGE DeriveDataTypeable, RecordWildCards #-}

import System.Console.CmdArgs
import System.Environment (getArgs, withArgs)
import System.Exit
import Control.Monad (when)

data MyOptions = MyOptions
    { color :: Bool
    , first_name :: String
    , age :: Int
    , directory :: FilePath
    } deriving (Data, Typeable, Show, Eq)

-- Customize your options, including help messages, shortened names, etc.
myProgOpts :: MyOptions
myProgOpts = MyOptions
    { color = def &= help "use color"
    , first_name = def &= help "your first name"
    , age = def &= explicit &= name "g" &= name "age" &= help "your age"
    , directory = def &= typDir &= help "your first name"
    }

getOpts :: IO MyOptions
getOpts = cmdArgs $ myProgOpts
    &= verbosityArgs [explicit, name "Verbose", name "V"] []
    &= versionArg [explicit, name "version", name "v", summary _PROGRAM_INFO]
    &= summary (_PROGRAM_INFO ++ ", " ++ _COPYRIGHT)
    &= help _PROGRAM_ABOUT
    &= helpArg [explicit, name "help", name "h"]
    &= program _PROGRAM_NAME

_PROGRAM_NAME = "myProg"
_PROGRAM_VERSION = "0.1.2.3"
_PROGRAM_INFO = _PROGRAM_NAME ++ " version " ++ _PROGRAM_VERSION
_PROGRAM_ABOUT = "a sample CmdArgs program for you tinkering pleasure"
_COPYRIGHT = "(C) Your Name Here 2011"

main :: IO ()
main = do
    args <- getArgs
    -- If the user did not specify any arguments, pretend as "--help" was given
    opts <- (if null args then withArgs ["--help"] else id) getOpts
    optionHandler opts

-- Before directly calling your main program, you should warn your user about incorrect arguments, if any.
optionHandler :: MyOptions -> IO ()
optionHandler opts@MyOptions{..}  = do
    -- Take the opportunity here to weed out ugly, malformed, or invalid arguments.
    when (null first_name) $ putStrLn "--first-name is blank!" >> exitWith (ExitFailure 1)
    when (age < 5) $ putStrLn "you must be at least 5 years old to run this program" >> exitWith (ExitFailure 1)
    -- When you're done, pass the (corrected, or not) options to your actual program.
    exec opts

exec :: MyOptions -> IO ()
exec opts@MyOptions{..} = do
    putStrLn $ "Hello, " ++ firstname ++ "!"
    putStrLn $ "You are " ++ showAge ++ " years old."
    where
        firstname = if color
            then "\x1b[1;31m" ++ first_name ++ "\x1b[0m"
            else first_name
        showAge = if color
            then "\x1b[1;32m" ++ show age ++ "\x1b[0m"
            else show age

Screenshot:

Don’t you just love how CmdArgs handles all the formatting and line breaking for you automagically? Anyway, onto the discussion.

You first specify your program’s options by declaring a data type (in this case, MyOptions). Pretty self-explanatory. The myProgOpts function is where you specify your program’s options. You can pass in “annotations” (as CmdArgs calls them) to your options. Here, I used the explicit annotation to prevent CmdArgs from auto-generating the shorter name for the age option. The typ &= “NAME” makes it so that we get “NAME” in the help message for the –first-name option. typDir is just a shortcut for typ &= “DIR” because it’s so common.

The def function is just a sane default type for many data types, such as Bool (False), String (“”), Int (0), and others. Generally, you should use def unless you really want a different default value for an option.

Notice how the option full_name turned into –full-name? The use of underscores in your options is converted into dashes by CmdArgs. Neat!

The getOpts function has some customizations: we use -v for –version instead of -V (the default), and also use -h for the short name for –help (-? is the default). We also specify the program’s metadata (copyright info, etc.).

In the main function, if no arguments are given, we display the default help message (and exit). It took me a while to figure this one out, so take heed!

If you don’t want the –verbose or –quiet options, then just remove the line “&= verbosityArgs …”.

The RecordWildCards pragma makes the code extremely concise and easy to use. I must admit, ever since stumbling upon this pragma, I’ve used it everywhere in my own code in other projects as well.

OK, so that’s what a simple single-mode program looks like. How about multi-mode programs? Here is one, multiMode.hs:

-- multiMode.hs
-- License: PUBLIC DOMAIN
{-# LANGUAGE DeriveDataTypeable, RecordWildCards #-}

import System.Console.CmdArgs
import System.Environment (getArgs, withArgs)
import System.Exit
import Control.Monad (when)

data MyOptions =
    Mode1   { first_name :: String
            , last_name :: String
            }
    |
    Mode2   { height :: Double
            , weight :: Double
            } deriving (Data, Typeable, Show, Eq)

mode1 :: MyOptions
mode1 = Mode1
    { first_name = "FIRSTNAME" &= help "your first name"
    , last_name = "LASTNAME" &= help "your last name"
    }
    &= details  [ "Examples:"
                , "Blah blah blah."
                ]

mode2 :: MyOptions
mode2 = Mode2
    { height = def &= help "your height, in centimeters"
    , weight = def &= help "your weight, in kilograms"
    }
    &= details  [ "Examples:"
                , "Blah blah blah again."
                ]

myModes :: Mode (CmdArgs MyOptions)
myModes = cmdArgsMode $ modes [mode1, mode2]
    &= verbosityArgs [explicit, name "Verbose", name "V"] []
    &= versionArg [explicit, name "version", name "v", summary _PROGRAM_INFO]
    &= summary (_PROGRAM_INFO ++ ", " ++ _COPYRIGHT)
    &= help _PROGRAM_ABOUT
    &= helpArg [explicit, name "help", name "h"]
    &= program _PROGRAM_NAME

_PROGRAM_NAME = "myProg"
_PROGRAM_VERSION = "0.1.2.3"
_PROGRAM_INFO = _PROGRAM_NAME ++ " version " ++ _PROGRAM_VERSION
_PROGRAM_ABOUT = "a sample CmdArgs program for you tinkering pleasure"
_COPYRIGHT = "(C) Your Name Here 2011"

main :: IO ()
main = do
    args <- getArgs
    -- If the user did not specify any arguments, pretend as "--help" was given
    opts <- (if null args then withArgs ["--help"] else id) $ cmdArgsRun myModes
    optionHandler opts

optionHandler :: MyOptions -> IO ()
optionHandler opts@Mode1{..}  = do
    when (null first_name) $ putStrLn "warning: --first-name is blank"
    when (null last_name) $ putStrLn "warning: --last-name is blank"
    exec opts
optionHandler opts@Mode2{..}  = do
    when (height == 0.0) $ putStrLn "warning: --height is 0.0"
    when (weight == 0.0) $ putStrLn "warning: --weight is 0.0"
    exec opts

exec :: MyOptions -> IO ()
exec opts@Mode1{..} = putStrLn $ "Hello, " ++ first_name ++ " " ++ last_name ++ "!"
exec opts@Mode2{..} = putStrLn $ "You are " ++ show height ++ "cm tall, and weigh " ++ show weight ++ "kg!"

Screenshot:

The program uses 2 modes, mode1 and mode2. If you use modes without overlapping letters, then you can invoke them with the least amount of unambiguous letters. E.g., if the modes were named foo and bar, you could just do “multiMode f …” and foo mode would be in effect. CmdArgs does this for us.

If your modes have lots and lots of options, then calling “multiMode -h” would give a brief summary, instead of giving each mode’s detailed help message. Here, the modes have only a couple options each, so that’s why the default help message is very detailed.

You might have noticed that I included a details annotation for both modes. This annotation is useful if you want to give examples on which options to use in what way.

Happy coding!

UPDATE April 26, 2011: Victor from the comments asked a question about including a custom type as an option parameter. I never needed this option, but, it’s do-able (with the new CmdArgs 0.6.9). Anyway, here is my minimal example:

instance Default MyComplexType where
    def = MyComplexType { brand = "BRAND"
                        , eggs = 0
                        , flowers = 0
                        , nest = Nestor { books = 0, tag = "TAG", author = "AUTHOR" }
                        }

data MyComplexType = MyComplexType
    { brand :: String
    , eggs :: Int
    , flowers :: Integer
    , nest :: Nestor
    } deriving (Data, Typeable, Show, Eq)

data Nestor = Nestor
    { books :: Int
    , tag :: String
    , author :: String
    } deriving (Data, Typeable, Show, Eq)

data MyOptions = MyOptions
    { color :: Bool
    , first_name :: String
    , age :: Int
    , directory :: FilePath
    , custom :: MyComplexType
    } deriving (Data, Typeable, Show, Eq)

Can you believe it? CmdArgs can even handle nested, custom complex types! Here’s how CmdArgs renders the above, in the help message:

CmdArgs will automatically expect a string of comma-separate values (CSVs). If you don’t like the auto-generated “ITEM,INT,INT,INT,ITEM,…” description, you could easily replace it with a custom string, with a &= typ “X,Y,Z,…” annotation.

If you don’t like the CSV format that CmdArgs imposes on your custom complex type, you’re out of luck. Your best option is to just use a single String type as the option argument, and then parse that with Parsec on your own (probably in the optionHandler function, in case of any errors) and then pass on the parsed data into your main program.

UPDATE July 21, 2011: I tried out CmdArgs with a custom algebraic datatype (something like “data Color = Red | Green | Blue | ColorNone”) and it still works! Your argument for this sort of data type will be, e.g., “–color-rgb red” and the “red” argument will be interpreted as the “Red” type. Actually, CmdArgs is very lenient and will accept any non-ambiguous argument, so here, “–color-rgb r” will also be interpreted as “Red”. Here is an example of the relevant portions:

instance Default Color where
    def = ColorNone

data Color = Red
           | Green
           | Blue
           | ColorNone
    deriving (Data, Typeable, Show, Eq)

myProgOpts = MyOptions
    { ...
    , color_rgb = def &= help "select an RGB color (Red, Green, or Blue)"
    ...
    }

UPDATE August 5, 2011: You can even specify an option as a list:

data Format     = Text
                | TeX
                | HTML
                | FNone
    deriving (Data, Typeable, Show, Eq)

data MyOptions = MyOptions
    { ...
    , format :: [Format]
    , ...
    } deriving (Data, Typeable, Show, Eq)

myProgOpts = MyOptions
    { ...
    , format = [] &= help "format of output"
    , ...
    }

Here, you can do something like “-f TeX -f HTML -f Text” to set the format option to the value [TeX, HTML, Text]. This possibility to use a list as an option parameter is quite useful (such as the example here, where you want to specify multiple output targets).

My Newbie Experience With Haskell’s IO Monad

So I’ve been on the Haskell train for about two and a half months now, and wrote 1804 lines of Haskell code according to cloc. There are oodles of articles out there extolling the virtues of Haskell, so I want to limit this post to just one thing: the I/O Monad (with a discussion on bind operators, do-notation, and the return function) and what I’ve learned about them through many lines of trial and error. As you bump into do-notation more and more, you’ll have to eventually learn what it really means, and how the return and bind ((>>) and (>>=)) functions play a big role in any monadic operation. This post is meant for Haskell newbies, like myself two and a half months ago.

DISCLAIMER: Before I start, I must warn you: I don’t have a “true” understanding of Monads, even after a couple thousand lines! I’ve greatly simplified everything down so that even an ultra-beginner-newbie would understand what I’ve written here. Some of my explanations are probably not “correct,” but hey, there’s no wrong in trying, right? Besides, it’s probably better to understand things imperfectly, like a child, and then slowly refine things over time. If you insist on at least a preview of the true understanding behind Monads, go to this page first (but if you really are a Haskell newbie I seriously doubt you’d benefit from it).

In a simple “Hello World” program, you have something like this:

main :: IO ()
main = putStrLn "Hello world!"

The type signature above looked very scary to me for a long time. Not any more. The type “IO ()”, in plain English, means: “This is a function that does some I/O stuff at some point, and in the end, does not return any value to the calling function.” The () (aka “unit”) is Haskell’s rough equivalent of a NULL value in C.

An equivalent (as far as types are concerned) way to write the above function is:

main :: IO ()
main = do   {
            ; putStrLn "Hello world!"
            ; return ()
            }

or (since do-notation in the above example is a little clunky, even without the braces and semicolons)

main :: IO ()
main = putStrLn "Hello world!" >> return ()

But, the putStrLn function already results in a “IO ()” by itself:

putStrLn :: String -> IO ()

so doing

main :: IO ()
main = do   {
            ; putStrLn "Hello world!"
            ; return ()
            }

is redundant. It’s like doing this:

main :: IO ()
main = do   {
            ; putStrLn "Hello world!"
            ; return ()
            ; return ()
            ; return ()
            ; return ()
            ; return ()
            }

Which is still valid, but obviously redundant. If the above code’s validity surprised you, then you are in good shape. (See the discussion about the return function below.) Anyway, sorry for the detour. Let’s focus on this example:

main :: IO ()
main = putStrLn "Hello world!" >> return ()

The (>>) operator just means “I don’t care what is on the left side; just compute what’s on the right hand side.” In this case, we explicitly force the computation of “return ()”, after computing the “putStrLn” portion. But the use of a “return ()” explicitly is often unnecessary and wordy in actual practice, at least with the IO monad, because functions like putStrLn (as I stated above), and putStr already give back a “IO ()”.

Here is a funny example: you could do something (meaningless) like this:

main :: IO (Int)
main = putStrLn "Hello world!" >> return 123

And the code will compile and work just as well as the preceding example. The only conceptual flaw is that since main is the only function, no other function actually uses the main function’s (return 123) computation, so it becomes absolutely meaningless.

Let’s look at something a little more complicated.

import IO

main :: IO ()
main = do   {
            ; hSetBuffering stdout NoBuffering
            ; hSetBuffering stdin NoBuffering
            ; putStr "Press a number key: "
            ; c <- getChar
            ; putStrLn ""
            ; natureOfC <- isThisADigit c
            ; if natureOfC == True
                    then putStrLn "You pressed a number key."
                    else putStrLn "You pressed something other than a number key."
            }

isThisADigit :: Char -> IO Bool
isThisADigit c = if elem c ['0'..'9']
                    then return (True)
                    else do {
                            ; putStrLn "Error: non-number character detected."
                            ; return (False)
                            }

I want you to understand the “isThisADigit” function. Here, the “IO Bool” type tells us that this function, at some point, does some IO, before resulting in a “IO Bool” value. The caller must “extract” the pure Bool value out of this “tainted” IO Bool type, with the left arrow <-. In the example above, the variable “natureOfC” captures this extracted Bool value.

The key about the IO Monad (like all other monads) is that they sort of act as a warning sign for all of the rest of your program’s pure code. Any function with a monad in its type signature is a big red flag that says, “Hey! I’m a dangerous function that results in lots of side effects/changed state! Be careful when calling me!” This is great because now we can easily tell, based on a function’s type signature alone, whether it’s pure or not. Hiding impure code in Haskell is thus impossible to do, as long as you explicitly write down your functions’ type signatures.

Here’s another example (just to illustrate the separation of pure vs. impure code in a real example):

import IO

main :: IO ()
main = do   {
            ; hSetBuffering stdout NoBuffering
            ; hSetBuffering stdin NoBuffering
            ; putStr "Press a number key: "
            ; c <- getChar
            ; putStrLn ""
            ; natureOfC <- isThisADigit c
            ; if natureOfC == True
                    then putStrLn "You pressed a number key."
                    else putStrLn "You pressed something other than a number key."
            ; putStrLn $ "You get " ++ (show $ handleBool natureOfC) ++ " points for your answer."
            }

isThisADigit :: Char -> IO Bool
isThisADigit c = if elem c ['0'..'9']
                    then return (True)
                    else do {
                            ; putStrLn "Error: non-number character detected."
                            ; return (False)
                            }

handleBool :: Bool -> Int
handleBool b = if b == True
                    then 100
                    else 0

The new handleBool function is the only pure function above, and its job is to convert a bool value into a single Int value, of either 100 or 0. The fact that the line “natureOfC <- isThisADigit c” extracts the pure value out of the impure “IO Bool” allows us to use the handleBool function with it.

It may help to write “IO (Bool)” instead of “IO Bool” if you want to get the visual image of a pure value being “wrapped” inside the IO monad.

Here’s another example (a rather contrived, un-idiomatic Haskell example), using lots of if/then/else statements just to illustrate the notion that the function return used in the context of a monad does NOT mean the same thing as “return” in C.

import IO
import qualified System.Exit as SE

main :: IO ()
main = do   {
            ; hSetBuffering stdout NoBuffering
            ; hSetBuffering stdin NoBuffering
            ; putStr "Press a lowercase character key that is between 'h' and 'o' (inclusive): "
            ; c <- getChar
            ; putStrLn ""
            ; isLower <- isThisLowercase c
            ; if isLower == True
                    then return ()
                    else SE.exitWith $ SE.ExitFailure 1
            ; isLessThanH <- isThisLessThanH c
            ; if (not isLessThanH)
                    then return ()
                    else SE.exitWith $ SE.ExitFailure 2
            ; isGreaterThanO <- isThisGreaterThanO c
            ; if (not isGreaterThanO)
                    then return ()
                    else SE.exitWith $ SE.ExitFailure 3
            ; putStrLn $ "You pressed `" ++ [c] ++ "'! Congrats!"
            }

isThisLowercase :: Char -> IO Bool
isThisLowercase c = if elem c ['a'..'z']
                        then return True
                        else do {
                                ; putStrLn $ "Error: char `" ++ [c] ++ "' not lowercase"
                                ; return False
                                }

isThisLessThanH :: Char -> IO Bool
isThisLessThanH c = if elem c ['a'..'g']
                        then do {
                                ; putStrLn "Error: char less than `h'"
                                ; return True
                                }
                        else return False

isThisGreaterThanO :: Char -> IO Bool
isThisGreaterThanO c = if elem c ['p'..'z']
                            then do {
                                    ; putStrLn "Error: char greater than `o'"
                                    ; return True
                                    }
                            else return False

I want you to focus on the series of if/then/else statements in the main function. Here, we can see that we test 3 properties for the user-given character, c: if it is lowercase, if it is less than ‘h’, and if it is greater than ‘o’. If any three of these conditions are met, we immediately exit the program with an error, using the System.Exit module. Otherwise, we just “return ()” for this stage of the overall do-notation computation. Here’s some pseudocode (with the exception of the (>>) operator, which retains its meaning) to explain:

TEST WAS PASSED, so:
return () >> carry on with the next computation that follows…

Maybe that made it a little clearer. The big idea with monadic code (and do-notation) is this: every step of the computation needs to be monadic! So in the main function above, if we pass a test, we have to sort of “glue” the remaining function together by “injecting” a “return ()” if we pass the test. Or, more accurately, we “inject” the unit value “()” into the IO monad with the “return” function. This allows us to carry on with the rest of the do-notation.

Why do we have to have monadic values at each step of a monadic operation (do-notation)? Well, it’s because do-notation is syntactic sugar for a series of computations requiring the use of the bind (>> or >>=) operators. And the bind operators’ type signatures are mandated as:

(>>=) :: m a -> (a -> m b) -> m b
(>>)  :: m a -> m b -> m b

So in the case of the IO monad (hooray Haskell typeclasses!), the bind operators mean:

(>>=) :: IO something -> (something -> IO something_else) -> IO something_else
(>>)  :: IO something -> IO something_else -> IO something_else

Notice how both bind operators requires that its left-side value (they are used as infix operators) be a monadic value, “m a” or in our example, IO something. So that’s why we are required to put in the “return ()” in the if/then/else statements in our last big example: the do-notation that we use in there requires that every step of the do-notation results in a monadic value, be it () or whatever. The return function allows us to meet this requirement: it injects a pure value into a monad:

return :: a -> m a

If the meaning of return still eludes you, you can think of it as a train conductor: a “return (140)” means “I, return, as train conductor of the Monad typeclass train, now allow you, pure value 140, to enter this train. The only way for you to get off the Monad train is with the (<-) operator, understood?”

Here is another example to illustrate this last point:

main :: IO ()
main = do   {
            ; pureNum <- boardTrain (140)
            ; putStrLn $ show pureNum
            }

boardTrain = return

So now you know what the return function is all about: injecting pure values into the Monad typeclass, so that you can use them as part of (larger) monadic operations, be it a big do-notation function or a simple monadic function that figures out a pure value, like the isThisLowercase function.

Here are some more explanations of the bind operator (using the IO monad) in plain English:

(>>=) :: IO something -> (something -> IO something_else) -> IO something_else

Plain English: Take a (IO) monadic value, and a function that takes a pure version of this value and converts it into some new monadic value, and give back this new monadic value. The (>>=) operator is thus useful if you want to “pass along” the results of one monadic computation to another monadic computation.

(>>)  :: IO something -> IO something_else -> IO something_else

Plain English: Take a (IO) monadic value, and another monadic value, and give back this latter monadic value. I.e., compute the first value, but we don’t care what the result of this first monadic operation is; just continue on with the second monadic value (IO something_else) after we’re done with the first one (IO something). The (>>) operator is thus just like (>>=), except that we do not pass along any values from one monadic operation to the next.

The reason why the (>>) and (>>=) operators are called “bind” operators might have dawned upon you now: they allow you to “chain” together multiple monadic computations together! This is why some Haskellers like to think of Monads as just another form of function composition, but for impure functions. Indeed, do-notation is just syntactic sugar for these two bind operators that allow you to easily “glue” together small, impure functions into a larger *sequence*.

There is also a “flipped” or “reverse” bind operator, (=<<), but with the arguments switched around. It’s useful if, for syntactic reasons you want to pass along a monadic value in the opposite “direction.” Usually, you use it when you want to visualize one monadic operation as an “argument” for another, to aid reading from left to right. For example:

teamWork :: IO ()
teamWork = putStrLn =<< getLine

Here, the contents of getLine act as an argument to the function putStrLn. Here’s another example:

C version:
        x = get_x_value();
        printf("%f\n", (round(abs(sqrt(x)))));

Haskell version:
teamWork :: IO ()
teamWork = putStrLn =<< round =<< abs =<< sqrt =<< get_x_value

See how the reverse bind operator allows us to mimic what C looks like? The reverse bind operator lets us write things in a more natural way, mimicking the syntax of pure function composition, such as “e . d . c . b $ a”, where the order of computation reads right-to-left. Personally, I rarely use the (=<<) operator because I use do-notation whenever I need to do some serious monadic computations — but, it's there when you need it.

Here's an example using a bunch of bind operators to give you their feel.

import IO

main :: IO ()
main     = putStr "Tell me your name: "
        >> hFlush stdout
        >> getLine
        >>= greet1
        >> putStr "Tell me your age: "
        >> hFlush stdout
        >> (greet2 =<< getLine)
        >> putStrLn "Bye!"
        where   greet1 str = putStrLn ("Hello, " ++ decorate str ++ "!")
                greet2 str = putStrLn ("You are " ++ decorate str ++ " years old!")

decorate :: String -> String
decorate xs = "-=xX" ++ xs ++ "Xx=-"

Notice how avoiding do-notation obviates the need to use the left arrow (<-) operator for getLine.

Let us revisit do-notation one more time:

import IO

main :: IO ()
main = do   {
            ; putStr "Tell me your name: "
            ; hFlush stdout
            ; name <- getLine
            ; putStrLn ("Hello, " ++ decorate name ++ "!")
            }

decorate :: String -> String
decorate xs = "-=xX" ++ xs ++ "Xx=-"

The point I want to make in this example is, believe it or not, the main function’s type signature. After everything I told you about how bind-operator-this and do-notation-that all work together to chain together sequences of monadic operations, I want you to reflect back on main‘s type signature: after all the fancy work that it does in the example above, main‘s type signature is just “IO ()”! The type signature of main is the type signature of the last monadic operation: in this case, the type signature for putStrLn.

Here’s a contrived example just for kicks, to encourage you to avoid do-notation for simple functions:

everyManForHimself :: SomeMonad (func4's return type)
everyManForHimself = func1 >> func2 >> func3 >> func4

The function above shows how the weak bind operator (>>) merely sequences independent monadic operations together, who all refuse to interact with each other. The component functions func1, func2, etc. may or may not have meaningful return types; i.e., func1 may be a “return ()” type, or a “return (Bool)” or something else — but the point is that the (>>) operator forcefully discards whatever is on the left and just moves on to the next operation.

Hopefully, this post shed some light into some non-intuitive examples on the IO monad. I hope things like IO Char, IO Int, IO Bool, IO String, and other types feel more natural now to you.

Reference: The “Gentle Introduction to Haskell, Version 98” has a good discussion of do-notation here.

UPDATE April 7, 2011: Apparently, the use of if/then (some monadic operation)/else (no monadic operation) pattern is so common that there is a shorter way. Simply import the when function from the Control.Monad module. So instead of

if (blah blah)
    then putStrLn "OK"
    else return ()

you can just do

when (blah blah) $ putStrLn "OK"

Moral of the story: if you ever feel like you are repeating yourself too much, look into the standard libraries (like Control.Monad).

UPDATE August 4, 2011: Edited discussion of the reverse bind operator.

Simple Haskell Data Pretty-printing

A couple years ago when I was knee-deep in Ruby, there was this really neat module called ‘pp’ that you could use to print out, in prettified format, any data structure.

#!/usr/bin/ruby

require 'pp'

a = {0 => [1, 2, 3, [4, 5], 6], 1 => "hello", 2 => ["foo", "bar", "quux", "toto", "tata"], 3 => "this is a long sentence"}

pp(a)

Would result in something like this (depending on your window width):

{0=>[1, 2, 3, [4, 5], 6],
 1=>"hello",
 2=>["foo", "bar", "quux", "toto", "tata"],
 3=>"this is a long sentence"}

Today I discovered that you can do basically the same thing in Haskell with minimum fuss. All you need is the Text.Show.Pretty module (fellow Archers can grab the haskell-pretty-show package on AUR). The github page for the module is here. Here is how you’d use it:

import IO
import qualified Text.Show.Pretty as Pr

data VeryComplexNestedType = VeryComplexNestedType
    { foo :: Foo
    , bar :: Bar
    , quux :: Quux
    }

someData = VeryComplexNestedType ......

main = putStrLn $ Pr.ppShow someData 

It took me quite a while to figure out that the module I needed was Text.Show.Pretty. All the web searches I did for pretty-printing led me to gigantic/industrial libraries like Text.PrettyPrint.HughesPJ or Language.Haskell.Pretty. Those libraries are there to let you customize your own pretty printing function on some arbitrary data type of your choice. But for super-simple, generic pretty-printing like Ruby’s ‘pp’ module, there’s Text.Show.Pretty. For some reason, it remains relatively unknown (the AUR page shows just 1 vote for it as of this writing).

Spread the word!

UPDATE March 13, 2011: In the comments, Neill pointed out that you can also optionally use the “ppsh” executable, which comes with the Text.Show.Pretty module (/usr/bin/ppsh on Arch Linux). Thus, you don’t have to change all of your existing code that uses “show”; all you have to do is pipe the output into ppsh, like “./myprogram | ppsh”. This method is arguably superior because now you don’t have to include Text.Show.Pretty as a dependency in your project.

Update October 30, 2012: To install Text.Show.Pretty (aka pretty-show on Hackage) on Arch Linux, just use cblrepo. The all AUR Haskell packages are pretty much dead at this point.