To wit, a few judiciously curated sources of visual edification:

for great justice

unhappy hipsters

riot right click

An obvious variant of this technique would be to seed a link farm with statistically improbable phrases, such that an “I’m feeling lucky” search for some innocuous but unlikely term, e.g. “woozy numbat playing kazoo”, would end up with a spammer’s site advertising something rather less wholesome as the number one hit. A spammer could even extend the use of SIPs to provide a canary trap to validate email addresses:if the inbound search term is “feral pet smells linux”, and we only sent that combination to user@domain.com, then the address must be valid.

Clearly, Yahoo has had no idea what to do with their acquisition: almost its first reaction to the grafted del.icio.us antibodies was to roll out a homegrown NIH tagging site, the name of which nobody now remembers. Since then, Yahoo hasn’t even bothered to switch users over to its unified login system as it did with Flickr. Whether you liked that move or not, it was a clear sign that Yahoo had some interest in Flickr.

Prior to the acquisition, I figure that del.icio.us had fulfilled perhaps 5% of its initial promise. In order to grow its user base beyond hardcore power users, the site clearly needed a less hostile user interface; nothing has happened. They could have increased existing user loyalty and retention by making it easier for people to find others with similar interests; nothing has happened. They could have made the site more useful to individuals by helping people understand the evolution of their own interests. Nothing has happened.

It’s a shame to see that potential go unfulfilled. Even from a business perspective, if Yahoo could quite reasonably not figure out how to squeeze some money out of its acquisition, it could at very little cost to itself be improving its image among the nerdiest of the nerdy by investing in del.icio.us and blowing its geek cred trumpet. Instead, I have a notion that Josh Schachter is languishing in some dungeon in Santa Clara, watching the grains of sand fall through his stock option hourglass, and waiting to make good his escape. What a waste.

I suspect that the same thing is also happening with Flickr, though not to quite the same extent. Take a look at the numbers of pre- and post-acquisition changes to the site and you’ll see what I mean. Sure, geotagging is cute, but it’s almost the only significant change in over two years. This sclerosis of small acquisitions doesn’t make me sanguine for Yahoo’s future.

This suggests that I need a small config file of some kind. I’m going to walk through the parser I wrote for this config file, not as a tutorial, but as an example of how to solve a simple pratical problem in Haskell.

The simplest kind of config file format that’s of any real use tends to look like this:

# Haskell blog config.

xmlrpc = http://www.example.com/wordpress/xmlrpc.php
editpost = http://www.example.com/wordpress/wp-admin/post.php?action=edit&post=
user = blogdude  # comments flow to the end of a line
password = h8x

From inspection, we can see a few informal rules. Config items are name/value pairs. Empty lines are okay, and comments start with #, spanning to the end of a line.

This is a format that’s easy to parse by hand or with regular expressions, but I lately prefer to use Parsec for these kinds of jobs. Regexps are difficult to read and debug, and often slower than Parsec parsers. Compared to a handwritten parser, a Parsec parser sacrifices a little performance, but I win in considerably faster development, clearer code, and excellent error messages “for free”.

Here follows the boilerplate for the beginning of the module. We’ll only be exporting two names from ConfigFile.

> module ConfigFile (
>                    Config,
>                    readConfig
>                   ) where

We’ll be needing a few modules.

> import Char
> import Control.Monad
> import qualified Data.Map as Map
> import Text.ParserCombinators.Parsec
> import Data.Either
> import Data.Maybe

The natural result of parsing a config file, at least in my mind, is a finite map from keys to values, where both are represented as strings.

> type Config = Map.Map String String

In my case, I’ll start with the left-hand-side of a config item, which I’d like to be a “C-like” identifier. The first character should be an alphabetic letter or underscore character. There might be only one character in an identifier, but if there are more, I’ll be expansive, and allow them to be digits, too.

> ident :: Parser String

> ident = do c <- letter <|> char '_'
>            cs <- many (letter <|> digit <|> char '_')
>            return (c:cs)
>       <?> "identifier"

This definition provides a clear illustration of how readable Parsec code can be. (By the way, the <?> means “this is the name to use when printing an error message”.)

When I’m developing a parser, I like to work from the bottom up, starting with simple productions and moving “up the food chain” as I debug each production. I’ll typically use Parsec’s parseTest function repeatedly from within ghci to test each production as I go. Testing interactively from within Emacs makes the process even more efficient; I can reload a module and start testing it with just a few keystrokes.

The result of a successful match is as we’d expect:

*ConfigFile> parseTest ident "ok"
"ok"

Compared with "([a-aA-Z_]\w*)" in Perl-like regexp notation, the Parsec description of ident is much longer. But if a match fails, we get a useful error message, which is a good reason to prefer Parsec. (When I use a normal Parsec entry point instead of parseTest, Parsec will give me a file name in its error message, too. Nice!)

*ConfigFile> parseTest ident "7"
parse error at (line 1, column 1):
unexpected "7"
expecting identifier

Comments are easily dealt with.

> comment :: Parser ()

> comment = do char '#'
>              skipMany (noneOf "\r\n")
>         <?> "comment"

We’d like to be agnostic about line endings.

> eol :: Parser ()

> eol = do oneOf "\n\r"
>          return ()
>     <?> "end of line"

Now to parse an actual config item.

> item :: Parser (String, String)

> item = do key <- ident
>           skipMany space
>           char '='
>           skipMany space
>           value <- manyTill anyChar (try eol <|> try comment <|> eof)
>           return (key, rstrip value)
>     where rstrip = reverse . dropWhile isSpace . reverse

The manyTill combinator builds up a result from each match of the parser that is its first argument, until the parser that is its second argument successfully matches. After matching a config item, we return it as a pair, stripping any trailing white space from the value.

A line can either be empty, or contain a comment or a config item. This makes it a good candidate for using the Maybe class. If we match a comment, we’ll return Nothing; if we match a config item, we return Just that item.

> line :: Parser (Maybe (String, String))

> line = do skipMany space
>           try (comment >> return Nothing) <|> (item >>= return . Just)

Note that skipMany space above will happily consume newlines, so we don’t need to explicitly check for empty lines. It also consumes leading whitespace.

Finally, we need to parse an entire file. This is an example of how it helps to spend some time browsing the standard Haskell libraries. In this case, we’ll use catMaybe from Data.Maybe to turn our list of Maybe values into a list of the Just config items (think of it as dropping all of the Nothing entries from the list, and stripping the Just from every other entry).

> file :: Parser [(String, String)]

> file = do lines <- many line
>           return (catMaybes lines)

The readConfig action parses a config file, so it must run in the IO monad. If the parse fails, it returns a parse error; on success, it returns a Config map.

> readConfig :: SourceName -> IO (Either ParseError Config)

> readConfig name =
>     parseFromFile file name >>=
>     return . fmap (foldr (uncurry Map.insert) Map.empty . reverse)

This is a dauntingly dense definition. Rather than jumping in to explain it piecewise, let’s first turn the code into something more like “beginner Haskell”.

> readConf2 :: SourceName -> IO (Either ParseError Config)

> readConf2 name =
>     do result <- parseFromFile file name
>        return $ case result of
>          Left err -> Left err
>          Right xs -> Right (listToMap (reverse xs))

Okay! We get the result of a parse; if the parse was an error, we pass the error along unmodified. Otherwise, we turn the list into a map, and return it.

> listToMap :: [(String, String)] -> Config

> listToMap ((k,v):xs) = Map.insert k v (listToMap xs)
> listToMap []         = Map.empty

A Haskell programmer with a little bit of experience will notice that the above function looks almost like a fold from the right of a list. The only problem is the (k,v) pattern match that we used to “pick apart” the arguments to Map.insert, so that we could pass it the three arguments it wants.

Map.insert :: (Ord k) => k -> v -> Map.Map k v -> Map.Map k v

It would be great if Map.insert took arguments, instead of three. We can fix this problem using uncurry.

uncurry Map.insert :: (Ord k) => (k, v) -> Map.Map k v -> Map.Map k v

So now we can rewrite listToMap in terms of foldr.

> listToMap3 :: [(String, String)] -> Config

> listToMap3 = foldr (uncurry Map.insert) Map.empty

We can eliminate the case expression in readConf2 by noticing that Either is an instance of Haskell’s Functor class. This means that we can use the Functor class’s fmap function. Calling fmap f on Left l will return Left l, but fmap f (Right r) will return Right (f r), which is exactly what we want.

Knowing about fmap and foldr, it’s now easy to go backwards from the relatively chatty definition of readConf2 to the more austere readConfig.

It’s possible to pare readConfig back even further, so that it’s entirely point-free, but this renders the code more confusing, at least to my eyes.

> readConf3 =
>     (return . fmap (foldr (uncurry Map.insert) Map.empty . reverse) =<<) .
>     parseFromFile file

I’m in no way claiming that this parser is the be-all and end-all of config file parsers. It doesn’t care if a value is redefined (it will use the last definition); it doesn’t impose any logical structure or constraints on the contents of a file; and it turns everything into strings. But it was quick to write (about an hour, not including the time to write this article); it doesn’t have any dependencies on third-party libraries; and it perfectly fits the needs of my trivial blog helper.

One substantial aspect of WordPress that I’ve been displeased with is, surprisingly, its support for writing articles. The “WYSIWYG” JavaScript editor repeatedly loses my formatting, and is slow and unresponsive besides. The “plain” editing interface isn’t much better for me; I like to put code snippets in my blog entries, and it doesn’t deal well with these. And the internal text formatting flow is baroque.

Fortunately, WordPress provides a remote API via XML-RPC, so it’s possible to avoid its authoring interface entirely. My goal is to be able to write something like plain text from within Emacs, and have it turn into a nicely formatted blog posting with a minimum of fuss.

To this end, I spent a couple of hours putting together a small “blog helper” in Haskell. It uses John Gruber’s Markdown tool to turn plain text or literate Haskell source into a blog entry, and uses WordPress’s XML-RPC interface to publish it for me.

I’m writing this article as a Markdown-formatted file within Emacs, and publishing it with a few keystrokes. Excellent! Over the next few articles, I’ll detail how I did this.

\mathrm{Ai}(x) = \frac{1}{\pi} \int_0^\infty \cos\left(\frac{t^3}{3} + xt\right) , dt.