Simple Observers in Haskell

I’ve just uploaded version 0.0.1 of the simple-observer package to hackage, the Haskell package repository.

This is an implementation of the Observer design pattern in Haskell. I am not the originator or even main author of the code in this package; that is Dutch computer scientist Bastiaan Heeren, who wrote the original as part of an exercise for some students. But recently I was doing some GUI programming with wxHaskell (which I’ve found to be great, by the way) and found myself hankering for an observer or something MVC-ish, and my googling led me to his code. I used it, and then thought it might be worth releasing to the world at large — particular as it’s not wx-specific, or even GUI-specific, really. Bastiaan tells me he’s happy for me to do so, so here it is. I’ve changed names, separated it into two modules, and replaced IORef with MVars in order to better support multi-threaded use — but at heart it’s identical to Bastiaan’s code.

The basic idea is that an observable is a piece of mutable state, and when it’s changed, a list of observer functions are called in sequence, and passed the new value. For wx programming – which is anyway quite stateful and not very idiomatically functional – I’ve found it to be quite effective. Here’s a small example which illustrates basic use…

My GUI has a start/stop button, which toggles a running flag. When running is true, the button says “stop”, and certain things happen in the app’s idle handler (to run whatever is supposed to be running); when running is false, the button says “start”, and certain other things happen in the app’s idle handler. So here’s how we set it up:

In my app’s setup phase, I create running, which is initially false, using createSub :: a -> IO (Sub a):

    running <- createSub False

Later on (actually in a different function, which receives running as a parameter), I create the start/stop button and use running‘s current value to initialise its appearance:

     r <- getValue running
     btnRunStop <- button p [text := runStopBtnTxt r, on command := runStopClicked running]

Here, runStopBtnTxt :: Bool -> String just returns “start” or “stop” appropriately. We use it elsewhere, which is why it’s factored out. When the button is clicked, runStopClicked toggles the state of running (and does other stuff not shown here):

    runStopClicked :: Sub Bool -> -> IO ()
    runStopClicked running = do r <- getValue running
                                running `setValue` not r

(This would actually be neater using changeValue :: Sub a -> (a -> a) -> IO (), but in the real version I use r later on, so this I need the getValue anyway.)

So this setValue call will cause all of running‘s observers to be called with not r. The last thing we should do, then, is attach an observer:

    addObserver running (\x -> btnRunStop `set` [text := runStopBtnTxt x])

addObserver :: Sub a -> (a -> IO ()) -> IO () takes an observable subject and an observer function, and attaches that function to the subject’s list of observers. Here, the observer function just updates the text.

(It’s worth noting that the observer’s type is a -> IO () not Sub a -> IO () — i.e. observers receive values, not subjects. The subtext is that an observer shouldn’t modify the subject it’s observing, lest ye loop infinitely; you can get round this by passing the subject proper as an earlier argument, and provided it used setValue' not setValue you’d be fine — but I don’t know of any reason why you’d want to do this.)

The first win here is that the button’s on command function doesn’t need the button as a parameter, because it’s not directly updating the button text. The deeper win is relatively cheap and clean separation of concerns: the button only toggles the running value, and (separately) stuff happens when running changes. If some other mechanism (eg some network event) could also cause running to change, we’d already be dealing with it The Right Way: just add another observer. Without observers, if our reaction code was in the button’s on command handler, we’d need to call that, or factor the reaction code out, in order to deal with it then. This way’s clearly nicer. But hey, you’re reading a blog post containing type signatures, so I presumably don’t really need to explain separation of concerns, or the observer pattern, to you. :-)

I’m aware that there are more sophisticated approaches to this problem. I’m reliably informed that Functional Reactive Programming (FRP) subsumes observer quite naturally, but I don’t understand it enough to comment. Tom Lokhorst tells us that Erik Meijer & Co. at Microsoft have a good handle on this, as discussed in this entertaining video. Alternatively, if we like message-passing as our basic computational model, an implementation in CHP might be just the ticket — and that certainly looks like an impressively powerful approach. However, in my case, I wanted to keep things in a single thread as much as possible, because Haskell’s GUI frameworks (and indeed wx across all languages?) seem to interact with multi-threading in non-simple manners. This is also pretty much why I decided against implementing Neil Brown’s suggestion that the observers should be run in their own threads. Of course, if an observer wants to fork a thread, it absolutely can, and I may find myself doing this in my app soon — but I didn’t quite see the utility of baking it in. That’s probably my sequential imperative background showing through, and hopefully one day I’ll shake it off and welcome our new, multi-threaded masters. To conclude, everything mentioned in this paragraph is why I decided to release this as simple-observer.

Anyway, hopefully somebody will find this useful.

Maintenance time

I’m going to be doing some Gimboland maintenance over the next couple of days/weeks, so if things disappear or go doolally, that’s why. Ta!

Coders At Work: Simon Peyton Jones

I see it as, when the limestone of imperative programming is worn away, the granite of functional programming will be observed.

Simon Peyton Jones

(I’m still not quite sure why I wrote this. You should just go and buy the book. But maybe someone will be interested.)

I got my copy of Peter Seibel’s new book Coders At Work yesterday, and the first chapter I turned to was, naturally, the interview with Simon Peyton Jones. I found it to be excellent and informative; of course, as anyone who’s seen him in action can testify, SPJ’s a careful and entertaining communicator of ideas, so that’s no surprise — if the other chapters are as good as this one, well, it’s a winner of a book.

Here’s a summary of the interview. Hopefully it contains enough to tantalise/encourage purchase, but not enough to give away the farm. :-) (And remember, this is just one chapter of the book.)

Seibel starts as he seems to start every chapter (modulo small variations), by asking “When did you learn to program?”. SPJ tells us about his school days, and his time as an undergraduate at Cambridge, through into industry and back to academia at UCL, and then on to a Professorship at Glasgow. Along the way we hear about some of the machines he programmed, and impressive things he did on them — such as “a program to extract 24-digit square roots” on his school’s computer with 100 8-digit memory locations, entered directly in machine code, because that’s all it had. Hearing about heroic stuff like this always makes me feel a bit bad, for having merely human levels of curiousity and drive as a schoolchild, and for a while I was worried the interview would be dominated by this historical stuff, since it went on for a few pages. Then I realised quite how long the chapter is (35 pages), and felt better. :-)

One thing I didn’t know was that SPJ doesn’t have a PhD. (Another thing I didn’t know was that neither does Robin Milner, apparently. Wow.) He discusses how that happened, and why one does a PhD, what its value is, etc., and also some personal philosophy of his approach to research. As someone who enrolled on a PhD just last week, I found this bit quite inspirational:

He [John Washbrook] said, “Just start something, no matter how humble.” This is not really about programming, this is about research. But no matter how humble and unoriginal and unimportant it may seem, start something and wroite a paper about it. So that’s what I did. It turned out to be a very significant piece of advice.

I’ve told that to every research student I’ve ever had since. Because it’s how you get started. Once you start the mill turning then computer science is very fractal — almost everything turns out to be interesting, because the subject grows ahead of you. It’s not like a fixed thing that’s there that you’ve got to discover. It just expands.

This leads into a few pages about functional programming in general, its popularity in the research community, its practicality, and the ways this research is feeding ideas back into the mainstream. There’s a bit of discussion of the vexed question of how to do experiments on programmer productivity/experience: how do you verify, other than anecdotally, that such-and-such a language (or feature) actually benefits the programmer or program? He mentions some interesting sounding work at Microsoft (“Steve Clarke and his colleagues at Redmond”) on this, at the API level. Then it’s back to how SPJ got into FP; he says he was influenced by being taught by Arthur Norman at Cambridge, where seeing a doubly-linked list implemented without side-effects was an ‘aha’ moment, and that David Turner‘s work on S-K combinators was also really inspiring and exciting to him — and says a bit about what that means for FP implementation.

Then laziness comes up: it was another interesting thing which motivated him, and has turned out to be a big idea, not least because it kept the focus on purity, which is the Big Win, he now realises. He talks about the old embarassing I/O situation, and the stream-based approach to ‘solving’ this, and just mentions monads here before being steered elsewhere by Seibel, never to return… :-)

He discusses his work on compiler writing (and GHC in particular of course), and the pros and cons of type-checking and static checks, including the problems of generic programming in a statically-typed world. This leads to a discussion of how he thinks about and designs software (unsurprisingly, its driven by types), and his “terribly primitive” programming environment (about the same as mine, except I’m one of the people he mentions that “just live their whole lives in ghci”), and his approaches to debugging. (Here he mentions some work Pepe Iborra did on debugging for Haskell — could he mean this? Pepe’s blog mentions that in 2006, but SPJ says he did the work “earlier this year”. So has Pepe done something more recent, or did the interview take place in 2006/7? I suspect the latter?)

On the subject of writing correct software, Seibel asks what he thinks about formal proofs, and his replies are as sensible as you’d expect — skeptical about ‘big up front’ specification/proof for (now) well-rehearsed reasons, but hopeful about “partial specifications” of program properties, e.g. in the style of QuickCheck.

Then we get six pages about STM. :-) Seibel starts by passing on a question from Guy Steele: “Is STM going to save the world?”. The typically sensible answer is of course not: No Silver Bullet, there are various ways to skin the concurrency cat, but that compared to locks & variables STM is a clear win every time. He talks about problems of starvation, and why that’s particularly problematic with optimistic approaches to concurrency, and comes back to the partial specification idea, discussing how STM lets you think more compositionally in terms of pre- and post-conditions than some other approaches. The STM discussion ends with him telling how he came to it via a talk by Tim Harris about STM in Java, and the realisation that STM could be made to fly so much more easily in Haskell than Java — leaving implementor brainspace free to invent mechanisms such as orElse which the Java guys hadn’t spotted (and example of FP research feeding back into the mainstream). “There was less crap, basically, so the cool idea stood out in high relief.”

Seibel then asks, “What’s your desert-island list of books for programmers?” I don’t want to give it away here (buy the book! It’s great!), but I’m sad to say I only own one of the books mentioned.

For the last six pages of the interview, discussion turns to SPJ’s everyday programming practice (he still loves it), programming as craft vs engineering (a false dichotomy, to SPJ), programming in the large, what it means for code to be beautiful, and code longevity. SPJ discusses how working in research allows you to put more time and energy into keeping things beautiful, and the tensions in industry that lead to ‘big systems full of goop’, and broad (rather than beautiful) APIs. It’s all insightful stuff, and his preferences, likes and dislikes echo my own so strongly that I’m glad I’m still working in research too, at least for now.

Overall, as I said, I really enjoyed it. I learnt a lot about the man, and a few things about programming I didn’t know (I haven’t really looked at STM yet, in particular). Cool.

Oh, and for a nice perspective on the relative longevities of limestone and granite alluded to in the quote I opened this with, check out this 1986 documentary taking a 30-minute tour round the entire British coastline: Round Britain Whizz. :-)

(Also, if you haven’t seen it yet, this is good, too.

Generating an index of Haskell haddock docs automatically

Haskell’s great, and has a lovely documentation generation system called haddock. Even better, if you install one of Haskell’s many third-party libraries using the excellent cabal install, it will (if you configure it to do so) generate these docs for you. Having local copies of documentation like this is always good for when you’re offline, so this is A Good Thing.

Sadly, there’s no master index of what’s installed. I’ve got it configured to install globally, so the docs go into /usr/local/share/doc, and each (version of each) package gets a folder of its own there; if you’ve got cabal calling haddock, that folder will contain an html folder with the docs in, but it’s tedious to click through an (otherwise empty) folder to get to it each time, and the whole setup’s not very pretty or informative (and the lexicographic sorting is case-senstivie, which I don’t much like). Eg:

Bare index of Haskell docs

People have attacked this problem before, but PHP makes my skin itch, and I can’t be bothered with apache, so a simpler, static solution seemed right for me.

Thus, I’ve knocked up a (quick, dirty, nasty) python script to generate the index. As a happy side-effect, I’ve pointed it at the hackage CSS file, so it’s pleasingly pretty and familiar:

Pretty index of Haskell docs

I did it in python because that’s still my go-to “hack stuff together in a hurry” language, I guess; but I was very nearly did it in Haskell. Mainly it was library knowledge that drove me. Also perhaps I fancied a break. Hmmm. Next time, for sure.

If anyone’s interested in the code (the doc path is hardcoded, so if you’re installing user docs, change it), you can view it pretty/download it via this link, or just check it out here. Oh, and what about the “automatically” part? Well, just stick it in a cron job… ;-)

Update: I realised I wasn’t linking to the actual index.html file, which kinda defeated the point of the script! However, it’s an easy fix. The line that says:


                s.write('<a href="file://%s">' % package.path)
</a>

should actually say:


                s.write('<a href="file://%s">' % os.path.join(package.path, 'html', 'index.html'))
</a>

Aaaanyway…

Read the rest of this entry »

Really nice git cheatsheet

Here’s a nice git cheatsheet, with examples: Everyday GIT With 20 Commands Or So [via brunns]. Really good — and to think that I didn’t know about git fsck and git gc!

A Haskell shell for computing musical scales, in 58 lines of code.

On my way home from work I had an idea for something I thought I’d find handy. Two hours later, I’ve written it — in Haskell of course. :-)

Context: I occasionally make what might kindly be called music, using computers and the like, and I don’t have any formal musical training. Consequently, I sometimes run into trouble regarding keys and scales. The idea I had was for something which would tell me, given a set of notes (ie the ones I’ve already used in a piece), what scales those notes are in — and consequently what other notes might also fit well with them. Long ago when I used Bars & Pipes on the Amiga, it had a tool for doing this. I could buy one for my Mac for about 8UKP (I may yet — it has a pretty GUI, which I might not be bothered to do), but it seemed I should be able to knock something up. The data types aren’t exactly complicated.

So I did it. I’ll put the code at the end of this post, or you can easily download it from here, in 133 lines of literate Haskell (58 lines of actual code). Here’s a screenshot showing typical use:

Haskell scale finder screenshot

Once again, I’ve been super impressed by how easy Haskell made this — and I’m particularly loving the Shellac library which gives me an interactive shell with history and graceful recovery from errors — all in 4 lines of code!

> react = mapM_ (uncurry printScale) . checkFit . parseNotes
>     where printScale :: String -> [Note] -> Sh () ()
>           printScale n ns = shellPutStrLn (n ++ ": " ++ ppNotes ns)
> main = runShell (mkShellDescription [] react) haskelineBackend ()

OK, I’m not using any of its juicier features like completion, state, automatic help, etc., but even so, it’s a great little library.

I could wrap it in a GUI, but to be honest, this’ll probably do the trick for me, assuming I haven’t made any big screw-ups, or got the scale definitions wrong. If anyone’s looking for a minimal Shellac example, maybe it’ll be useful.

(Update 2009-09-16 13:37: To get this up and running, if you’re not already a Haskeller, the following should suffice: 1. Download and install The Haskell Platform – nice ‘n’ easy. 2. Open a shell and issue cabal install Shellac-haskeline or possibly sudo cabal install --global Shellac-haskeline. 3. Download the code (from hpaste.org) and (still in a shell) issue ghci Scales, and when that’s loaded issue main. Or if you want to compile an executable, try ghc --make -main-is Scale.lhs Scale.lhs, just like in the screenshot. That should do it — I’d love to know if I’ve missed anything and/or if that works!)

Here’s the code (but, again, it’s prettier and easier to download from hpaste):

Read the rest of this entry »

On the money

My life. :-)

An official apology to Alan Turing

An official apology to Alan Turing. Win.

Why is there peace?

Why is There Peace? — violence is declining, over history, at least in relative terms, though not, one suspects, absolute ones.

A “Monte Hall” problem solved in Haskell

I’ve just written a solution to today’s Programming Praxis puzzle, which requires you, essentially, to write a Monte Carlo attack on the Monty Hall problem. Thus, the awful pun in this post’s title, in case you missed it. ;-)

Here’s my solution.

It was a lot of fun. I started out feeling like I should be able to do it, but not quite knowing what direction to take, so first of all I was writing some data types for things like Door = Car | Goat, etc. but pretty quickly realised it was just a matter of door numbers. My first working solution was actually a bit longer, because of some intermediate steps (for example the first thing I figured out, in its own function, was how to compute which goat door would get shown to the player given a (car, choice) pair). Then hlint gave me a couple of hints, like using replicateM, and I compacted it down to what we see here. I’m sure it has naive aspects, but I’m pretty happy with it — and I’m loving doing the Praxis problems.

DIY magnetic spice rack

I love this idea [via lifehacker].

Shake a shake a shake a tail feather

You haven’t experienced true joy until you’ve watched this cockatoo dancing to Ray Charles [via nicolas].

Alan Dix on “Language and Action: sequential associative parsing”

Alan Dix on the difference between how humans parse language, and how machines do so — and associated impacts on interaction. Interesting stuff, as ever.

Eastside Roots

Heading to Cornwall on a train last Friday, I spotted something interesting as we neared Bristol Temple Meads: Eastside Roots, a community gardening project — look out for it by Stapleton Road station.

I once told her…

I am that man.

(Shame the sound quality on the video’s so poor though.)

“Believe Me, It’s Torture”

Christopher Hitchens gets waterboarded [via Dawkins].

The evolution of the eye

Anti-evolutionists sometimes use the human eye as an argument for a creator; here’s David Attenborough explaining why that’s tosh [via frosty].

If Philosophers Were Programmers

If Philosophers Were Programmers [brunns].

Nice to see that Wittgenstein (or at least, one of the Wittgensteins) is also a Haskell man…

Cassini’s continued mission

Some truly incredible pictures of Saturn and its friends.

Best gimboland blog comment yet

Um… what? Thanks for that, Ravi.

Sir Clement on good form

He will be missed [via rhodri].

Typogridphy

Typogridphy — A Typographical and Grid Layout CSS Framework [via hacker newspaper via raganwald].

Strunk and White Considered Harmful

50 Years of Stupid Grammar Advice from Strunk & White — fascinating. (Author’s homepage.)

Fake People Tell Fake Stories About The Threat Of Gay Marriage

Fake People Tell Fake Stories About The Threat Of Gay Marriage [brunns].

Modelling lightning with Haskell

Cool: Modelling lightning with Haskell [via dons].

Sign here, please

If you think it shouldn’t be illegal to photograph police officers, please sign here. If you don’t think so, please watch this and then tell me why not. Thanks!

Edwardian Callington photos on the BBC, courtesy of the Gimblett boys

This morning, my Dad opened an exhibition in the museum in my home town, of ninety photos taken by my great-grandfather, found (on glass plates) when Dad retired, and recently restored by him via digital photography. Here’s an article on the BBC, including an audio interview with Dad, in which (I think) he sounds fab. Rich voice, Terrence!

“The Doctor Will Sue You Now”

If you’re ever looking for a warning sign that you’re on the wrong side of an argument, suing Medecins Sans Frontieres is probably a pretty good clue.

Video of Ian Tomlinson assualted from behind without provocation by a police officer

The Guardian have published video footage of Ian Tomlinson, a bystander caught up in last week’s G20 protests in London, being struck from behind in the leg with a baton and pushed to the ground by a police officer as he walked away peacably with his hands in his pockets. He died of a heart attack a little while later.

It becomes clearer that the purpose of riot police is not only to protect the public at large by controlling riots, but also to protect the status quo by discouraging dissent and protest — if you know that even protesting peacefully (or being in the area of a protest but not participating, as in Tomlinson’s case) you are at risk of unprovoked attack by armed, armoured and aggressive large males, you will tend to be discouraged from doing so. I know I am. :-/

ToneMatrix: funnnn!

Much fun to play with: ToneMatrix, a Tenori-on-like Flash jobbie [via rhodri]. Go! Now! Play!

How to grow your own fresh air

How to grow your own fresh air.

Gimbobread: loaves eight and nine

Loaf 8 was dedicated to the eight limbs of ashtanga yoga. Coincidentally, I forgot to go to my ashtanga yoga class the next day.

Loaf 8-4: after second rise Loaf 8-8: and the other side Loaf 8-9: slices!


Loaf 9 was dedicated to Ganesha. Ironically, it was the smallest loaf I’ve yet made (except for the first one, which wasn’t intentional). I reduced the amounts by a third to try to avoid the “blooming mushroom” shape of earlier loaves, and ended up with a nice regular-shaped loaf with good sandwich and toasting properties.

Loaf 9-1: 2/3 the usual size Loaf 9-2: good size for sandwiches & toasting

workmugs

workmugs.com — absolute genius of an idea [via emmaljones, bash].

Literate Haskell with Markdown and Syntax Highlighting

Last one today, I expect: Literate Haskell with Markdown and Syntax Highlighting.

Strength in weakness: judo design

The bin purge continues: Strength in weakness: judo design. Alan’s a clever and interesting fellow.

Years ago I also read about a programme to strengthen bridges as lorries got heavier. The old arch bridges had an infill of loose rubble, so the engineers simply replaced this with concrete. In a short time the bridges began to fall down. When analysed more deeply the reason become clear. When an area of the loose infill looses strength, it gives a little, so the strain on it is relieved and the areas around take the strain instead. However, the concrete is unyielding and instead the weakest point takes more and more strain until eventually cracks form and the bridge collapses. Twisted ropes work on the same principle.

David Byrne at Fallingwater

David Byrne visited Fallingwater— nice.

We tried to imagine the parties. Given that this was 75 miles from town, many of the evenings must have been sleepovers. The questions culminated in someone asking if Junior ever married. When the answer came back no, someone in our group shouted “bingo!” Our poor guide put her hand to her face as if this was all too much.

Old news, I realise. I’m going through stuff which has been languishing in my Read It Later bin, emptying it and moving some to the more iPhone-friendly InstaPaper.

The Algorithmic Beauty of Plants

The Algorithmic Beauty of Plants.

Malc’s coat recommendations

Malc’s coat recommendations — had this link lying around for a while, and it’s about time I archived it here.

How to use git and svn together

How to use git and svn together — or more properly, how to use git on an svn repository. I’ve been doing this for a couple of things, having switched my brain and day-to-day work patterns from svn to git, and it works nicely. I haven’t tried anything nontrivial such as branching, mind. Anyway, putting it here because some friends were asking about it.

The Day the Saucers Came

The Day the Saucers Came, by Neil Gaiman.

Stone Buddha on my bedroom wall

Stone Buddha, rasterbated

Original, rasterbated.

Sir Ken Robinson: Do schools kill creativity?

Fantastic, hilarious, insightful and inspiring talk on education and creativity: Sir Ken Robinson: Do schools kill creativity? (20 minutes, from TED 2006.) Absolutely on the money, top to bottom.

Gimbobread: The First Seven Loaves

I recently started baking my own bread. I’ve always been slightly in awe of people who did so, partially because I had no idea how it was done. Of course, it’s actually quite straightforward and, having been encouraged by friends I met last summer, I finally got cracking back in January. I’m doing it by hand: no bread machine — it’s easy and satisfying. I can see the appeal of a bread machine if you’re mainly interested in the end product, i.e. “I want fresh home-made bread”, but I’m just as interested in the process, in taking out three hours to make this thing, in pummelling it with my hands, in seeing the loaf evolve through the steps. I love it!

Since January I’ve made seven loaves in total, and pretty much each one has been better than the last. While it’s easy to bake bread, you of course learn little tricks and details as you go, I guess. Here’s a retrospective, then, on my first seven loaves.


First loaf, Sunday 25th January 2009: as I tweeted, it was smaller than I’d expected, but when I made the next loaf I realised that I’d simply not made enough dough! I was following the recipe on the flour bag, and it targetted two loaf tins, whereas I only had one, so I halved the quantities; however, my loaf tin is in fact quite large, so that was unnecessary. Thus, the lesson of loaf one is how much dough to make. I just used a plain wholemeal flour, which was worthy but a little dull, and only a single rise, which may have made it a little dense. Still, pretty good for the first attempt.

First loaf First loaf, interior


Second loaf, Saturday 7th February 2009: certainly an improvement, largely thanks to some really good advice from my friend Ann. She cleared a few things up for me, and also encouraged me to give it two rises: one long one, then punch it down to expel CO2, then a shorter rise in the loaf tin before ovenating. Using an appropriate amount of ingredient probably helped too! This served as the template for every other loaf since then. The end result was much more like I expected a loaf to look, although a bit charred on the top; thus, the lesson of loaf two is to lower the shelf in the oven.

Second loaf and stew Second loaf and stew (2) Second loaf


Third loaf, Friday 20th February 2009: “a bit hurried, slightly odd, probably fine“. It was fine. I really hurried the latter stages, because I had to go out and time was running short. Thus, I didn’t pay much attention to shaping before putting it in the loaf tin — I just “whacked it in”. So the shape was a bit weird. I’d bought some white flour, and fixed it with the remaining wholemeal to produce this hybrid. No interior shots, sadly, but I’m sure it tasted fine. The lesson of loaf three is to plan ahead more, so you can take it easy, enjoy yourself, and not hurry; also, that if you fail to do that, it’s still bread: win.

Third loaf


Fourth loaf, Sunday 1st March 2009: I made this rounding off a lovely weekend of singing and being sung at in Narberth, which concluded with a Bulgarian singing workshop with Dessislava Stefanova of the London Bulgarian Choir. I should blog about that too but oh, my blogging skills are far from mad these days. This loaf was all white, and all right, although had some strangely shattered geometry. Looking back, I think I just didn’t pay attention to where the fractures were in the dough before I put it in the loaf tin, and probably ended up with one on the side, which then stretched up leading to this strange shape. To confuse matters further, I turned this loaf round in the oven after 15 minutes, to try to not burn it (and in the naive hope that the other side would rise: I have since learnt that heat kills yeast, so all rising happens outside the oven). So, the lesson of loaf four is to be careful where the seams are in the dough when you put it in the loaf tin: put them on the bottom! However, sometimes we don’t learn lessons the first time we meet them; when that happens, life just keeps on patiently giving you the lesson until you get it…

Fourth loaf: odd Fourth loaf, pretending to be normal Fourth loaf: still a bit charred Fourth loaf: actually really good to eat


Fifth loaf: Thursday 5th March 2009: I’m not sure, and historical records are inconclusive, but this may have been made entirely using Allinson’s “seed & grain”, which is rather nom — or it may have been a hybrid. Not sure. Anyway, it came out very well, although once again was quite strangely shaped thanks to not learning the seam-placing lesson of loaf four. I think the reason was that I was concentrating, at this time, on solving the burnt-on-top problem, and experimenting with turning after 15 minutes; I don’t think it really helped, so it was after this loaf that I thought that maybe the oven was too hot and I should try a lower temperature. Thus, the lesson of loaf five is honestly, pay attention to where that seam is; also, pay attention to oven temperature.

Fifth loaf: before rise Fifth loaf: after second rise Fifth loaf: pretending to be normal Fifth loaf: bags of character Fifth loaf: bread inside Fifth loaf: crumbs!


Sixth loaf: Thursday 12th March, 2009 — “the one that got away”. There are two innovations here: carefully putting the seam at the bottom, and not turning the oven quite so high. I had baked everything with the oven at 230C so far; for this one I put it more like 210C. Success, I think: it’s a nice round smooth loaf, and it’s not too crispy. However, I didn’t get to taste any of this one, or even see its insides, because I gave it to my friend and colleague Markus for his birthday. I haven’t received any feedback yet; hopefully he’s still alive. The lesson of loaf six: yes, turning the oven down seems to help.

Sixth loaf: the one that got away Sixth loaf: most normal looking yet! Sixth loaf: wish I'd got some


Seventh loaf: Saturday 14th March, 2009. Now you’re talking: I have never enjoyed bread more than this loaf. It’s absolutely delicious. I really feel like I’m getting into stride now…

Seventh loaf: new tin! Seventh loaf: best yet Seventh loaf: can't stop eating it

Having given away the last loaf, I needed to make another. I’d decided to look for another loaf tin — initially thinking a smaller one would be good, but the more I thought about it, the more I realised that what I needed was a deeper one, to try to get a more “classic sandwich” shape rather than the florid cross-section seen on loaf five (say). Thus, a new tin, and a non-stick one to boot. The mix is about half strong white, about a third seed/grain, and the rest wholewheat — with the surprise addition of a few pinches of thyme, as suggested by Carys, peering over my shoulder admiringly. A fantastic idea! I also put some on top, which entailed glazing it gently with olive oil so they’d stick; that didn’t exactly work, in that they fall off easily (I should have pushed them in more) but the crust on this loaf is deliciously chewy, like, just right, so I wonder if the glaze helped that.

However, this loaf also involved another “innovation” which may have contributed there. The spot in the airing cupboard where I put it to rise is up high, and a little precarious. After the second rise, when I opened the cupboard door to get it out, the tin and loaf fell down, because they’d slipped (with the growth of the dough) to rest against the door. I caught them but they’d collapsed, and I feared I’d ruined the loaf. Carys thought I should just put it in the oven and hope, but I knew it wouldn’t rise again, so thought I should knead it again, and try for a third rise — the very idea! After a few minutes it didn’t look like it was rising, but after 10 it clearly was, so with professions of love for the loaf we left it to do its work. I have to say, the end product was absolutely no worse for it, and possibly better. I shall have to think about this. Thus, the lessons of loaf seven are twofold: first, don’t drop it! Second, if you do, all is not lost. :-)

There’s one thing I’m still a bit dubious about. The bread is delicious, but it is quite yeasty smelling, and tasting, I guess. I quite like that in fact, but I wonder how to get rid of it. I bought an oven thermometer yesterday, and it turns out the oven is in fact colder than it says it is, not hotter as I thought: loaf seven was baked at about 190C, whereas the recipe calls for 230C. So perhaps there’s some tweaking still to do there… But aha, according to some handy troubleshooting tips, it’s more likely the bread over-rose, which makes sense: I am leaving it a long time anyway, even without a third rise! OK, next time I’ll try a 60 minute first rise and not dropping it after the second. :-)


The recipe (since some people have asked): for every loaf except the first I’ve followed this same basic recipe, given to me my friend Ann Huehls, as she answered my questions about what might have gone “wrong” with the first loaf. I’m sure she has forgotten more about baking than I will ever know, and has much else to tell me. Anyway, approximately:

  1. In a big bowl mix 7g of baker’s yeast, 1tsp of sugar or a good squeeze of honey, and 420ml of water in a 1:2 boiling/cold mix (that’s 140ml boiling, topped up to 420ml with cold: mix the water before adding to the yeast). Let it stand for about 10 minutes and it should go foamy: that’s the yeast activating. If it doesn’t, your yeast is dead, so buy some more!
  2. Gradually add 650g of suitable flour (see below), along with 2tsp salt and 15g of butter. On Ann’s advice, I add about a quarter of the flour first, mix it well, then mix in the salt and butter, then the rest of the flour. (I keep my butter in the fridge, so I melt the 15g in a pyrex dish lid sat on a small saucepan of boiling water.) Mix well, with a wooden spoon.
  3. Once it’s reasonably well mixed, or the spoon no longer seems effective, start mixing it with your hands too; at some point turn the mix out onto a lightly floured surface and segue from mixing to kneading. If the mix is too wet, just keep going, possibly adding a little more flour to the surface as you go, which the dough will then pick up and assimilate. Knead it for 7-10 minutes; its getting good when the texture is sorta earlobe-like.
  4. Lightly oil the bowl (I use olive oil), put the dough in it, cover it with a tea towel, and put is somewhere warm for 60-90 minutes (for wheat flour, anyway). This is the first rise. I’ve been using the airing cupboard, and turning the heating on to make sure it gets nice and warm in there. After the rise it should have doubled in size or more. Look online for more advice on rising locations, and times: varies with the flour used, and it’s possible to overdo it, apparently. Some people do cold rises too, though I haven’t tried that yet.
  5. Lightly dust your fists with flour and “punch down” the risen dough, to expel built-up carbon dioxide. You should hear it hiss and see it collapse. Nice. Turn it out onto a lightly floured surface again for a second knead: shorter and more gentle than before. You really don’t want to be ripping it at all at this stage. After a couple of minutes, start getting the dough into approximately the shape of your loaf tin, i.e. rectangular. The knead cycle goes “fold, pummel”: it’s good to end on a fold, and have the seam you’ve just created at the bottom — this contributes to a nice clean surface up top, avoiding the weirdness of loaves four and five.
  6. When it’s a good shape, pop it into your loaf tin and maybe gently push it into place, but don’t overdo it because you don’t want to tear it, and it will expand anyway. Depending on your loaf tin, you might need to lightly oil it before putting the dough in. My first six loaves used this non-stick tin where that wasn’t necessary, but number seven used a more traditional one where it was (and I’ve a hunch the oil helped condition the surface of the bread).
  7. Put the loaf tin back into your warm place for 20-30 minutes: this is the second rise. The rising should be visible after a few minutes, and by the end it should really be in its final shape. Pre-heat the oven now, too — about 210-230 Celsius, though I’m still kinda working out what’s best here. Experience has shown that you might need to put a post-it note on the oven saying “do not switch off” if you have zealous housemates who assume empty ovens have been forgotten (though now I’ve got an oven thermometer, which might help).
  8. After the second rise, put the loaf in the oven, not too high up (don’t want it burn on top), and bake for about 30 minutes. Then turn it out onto a wire cooling rack and wait for it to cool down before enjoying, lest thy tummy be upset.

Flour: lots to choose from, and I’ve been doing a lot of hybridising. I really like mixing the Allinson’s “seed and grain” flour with white, I must say. I don’t think I’ve tried it on its own, so I should probably do that some time. I should use wholemeal more as well, I think. I did for the first couple, but was a little disappointed; not sure if that was the flour or my technique, so I should revisit. Newbies: make sure you get “strong” flour, not regular white flour, say. Mmmkay?

Weapons of choice

Jared Diamond on Collapse

One of the best books I’ve read in the last few years was Collapse by Jared Diamond. It’s meaty, well researched, well argued, systematic, fascinating, and fairly terrifying (though with the possibility of hope, at least).

In this 20 minute video, Diamond pretty much summarises the whole book. If you think it’s something you might want to read, watch the vid, because everything he talks about is explored in much more depth in the book — and all the book’s major themes are touched upon.

If still unsure, check out Diamond’s Long Now seminar (audio here), which is where I first came across him.

Here we stand, at the cusp

Fantastic Bruce Sterling: 2009 will be a year of panic, but the good news is the true 21st century begins here.

When life hands you Stanislaw Lem, make Stanislaw Lemonade

Some great Twtter bons mots here [via pwb].

It’s just another (possibly even manic?) Monday

Lovely write-up by Ben Goldacre on why the whole Blue Monday most-depressing-day-of-the-year stuff is utter bullshit. In essence:

  1. It apparently originates with a travel firm’s PR company feeding a formula to a not-very-distinguished scientist, who publishes it.
  2. If you dig into the scientific literature and actually look for evidence of any seasonal variation in, say, suicide or depression, you find nothing conclusive whatsoever — lots of contradictory reports, many of which point to the spring or summer as being worse, in fact.

Classic stuff. Welcome to the Delusional Race.

Star Wars as explained by someone who hasn’t seen it

Epic win: Star Wars as explained by someone who hasn’t seen it [grantjames]. Lovely.

“…, Paper disproves Spock, …”

Rock Paper Scissors Spock Lizard [shepherdnick] — though the visual distinction between paper and lizard seems a little ill-defined, perhaps?

Possibly the best £20 I ever spent

Spread the word: Jaipur Foot [via Rhodri].

Social Security vs Ponzi Schemes

Good Math, Bad Math has a nice post today drawing a distinction between Social Security and Ponzi Schemes; some interesting discussion in the comments, too – always good to see Life of Brian brought into the fray. :-)

Creating/consuming JSON in Haskell, with the help of pattern guards

I’m going to write about two Haskell things I’ve used today, both of which were new to me: first, creating/consuming JSON using Sigbjorn Finne‘s json library; second, using pattern guards to make the “consuming” part prettier than my first butt-ugly attempts.

Earlier today I googled a bit looking for examples of using the JSON library, but didn’t find any clear or immediately useful ones. There were a few examples of people rolling their own JSON stuff in Haskell, but obviously that wasn’t what I was after. (I’ve just noticed that Real World Haskell talks about JSON, but doesn’t appear to immediately answer my questions — though there is loads of good stuff there of course.) I just wanted something to get me going quickly with the problem at hand, really.

The context is this: I’m working on some code which represents models of devices’ user interfaces as finite automata and tries to do some analysis on that. I want to use JSON to pump FA models between implementations in at least two, and maybe more, languages. None of that is really relevant to the rest of this post, except perhaps in the next paragraph. :-)

I have an abstract data type representing what I call actions, which are essentially lists of transitions, which are just integers (the destination state). Actions may be deterministic (in which case each transition is just an integer) or nondeterministic (then each transition is a list of integers). Again, the meaning isn’t so important; what’s important is that my ADT looks like this:

data Action = DAction [Int] | NAction [[Int]]
  deriving (Eq, Ord, Show)

Now, having imported the appropriate JSON module…

import Text.JSON

… I need to make this type an instance of the JSON type class by defining showJSON and readJSON functions for creating and consuming JSON, respectively:

instance JSON Action where
    showJSON (DAction xs) = showJSON ("DAction", xs)
    showJSON (NAction xs) = showJSON ("NAction", xs)
    readJSON = Error "not yet implemented" -- See below!

Let’s start by thinking about showJSON. It’s important to note that showJSON doesn’t produce a serialised JSON string directly. Instead, there’s an intermediate representation: the JSValue ADT; you serialise values of that type using the JSON module’s encode or encodeStrict functions. This extra layer of abstraction is a big win, because when we’re consuming JSON, we don’t have to write any code to parse the serialised string: we just call decode (or decodeStrict) to turn the string (whose contents should never be very exotic: that’s the whole point) into a JSValue. Then, readJSON‘s job is to turn that JSValue back into our domain-specific representation, whatever that is. That was the bit I was having trouble with (which is why I haven’t shown it yet), but I recognise that doing it this way was a lot easier than parsing the serialised string representation would have been, so I’m thankful for the extra abstraction layer.

In my case (and, I suspect, in most), showJSON is rather straightforward, thanks to some already-existing JSON type class instances. I simply construct a pair whose first element is a string identifying the action type, and whose second element is the action’s transition list. The JSON module already defines instances of the JSON type class for pairs, Strings, lists, and Ints, so the corresponding showJSON functions (which I’ve never seen) do all the work for me. Win.

Time for an example; let’s define a simple Action value…

da :: Action
da = DAction [0,1,2]

and take a look at its JSValue and string representations in ghci:

*Data.FA.JSON> showJSON da
JSArray [JSString (JSONString {fromJSString = "DAction"}),JSArray [JSRational (0%1),JSRational (1%1),JSRational (2%1)]]
*Data.FA.JSON> putStrLn $ encode $ showJSON da
["DAction",[0,1,2]]

The JSValue is quite verbose, but if you compare it with the encoded string, you can comprehend its structure easily enough. JSON doesn’t have tuples, so the pair we fed showJSON has been turned into a two-element list (a JSArray). The string “DAction” is wrapped in a JSONString (a more efficient representation of String) inside a JSString constructor. The list of integers is a JSArray, but each Int is represented as a Rational: the JSON module doesn’t know how to serialise integers directly (AFAICS JSON can, in general?)

So far, so good: serialising my data structure to JSON is pretty easy. Lists of Actions, maps from Ints to Actions, etc. all “just work” too, out of the box: handy.

Extraction of an Action from a JSValue is trickier, and I am by no means confident that I’m doing it in the most sensible manner — though what I’m doing does work, at least! The type signature of readJSON is:

readJSON :: JSValue -> Result a

where Result is a bit like Maybe or Either: it’s either Ok a (it worked) or Error String (fail!). readJSON takes a JSValue, and depending on what the contents of our decoded JSON string were, this could be pretty much anything! So we have a pseudo-parsing situation: we need to match it against what we’re expecting, and if it doesn’t fit, we raise an error. In other words, we have to unpack it, layer by layer. Here’s what I came up with initially:

readJSONAction' :: JSValue -> Result Action
readJSONAction' value =
    case value of
      JSArray [a,b] ->
          case a of
            JSString jsTag -> 
                case (fromJSString jsTag) of
                  "DAction" ->
                    case (readJSONs b)::Result [Int] of
                      Ok xs -> Ok (DAction xs)
                      _ -> Error "can't decode deterministic actions"
                  "NAction" ->
                    case (readJSONs b)::Result [[Int]] of
                      Ok xs -> Ok (NAction xs)
                      _ -> Error "can't decode nondeterministic actions"
                  _ -> Error "Incorrect action tag"
            _ -> Error "can't decode action tag"
      _ -> Error "not an action" 

It sure does look ugly, as you’ll no doubt agree. It unpacks the JSValue bit by bit, using a case distinction to catch unexpected content, which is translated into an Error value. Note the explicit type-tagging in the deeply-nested calls to readJSONs: there are many instances of readJSONs and we need to be explicit about which one we want to call — and they’re different for the two different kinds of action.

This works…

*Data.FA.JSON> readJSON (showJSON da) :: Result Action
Ok (DAction [0,1,2])

… (again, we need to explicitl specify which readJSON we want), but it’s ugly as hell. My friend and colleage pwb suggested “pattern guards might make it prettier”. So I checked them out, and came up with this:

readJSONAction :: JSValue -> Result Action
readJSONAction value
  | JSArray [a,b] <- value
  , JSString jsTag <- a = checkContents jsTag b
  | otherwise = Error "not an action"
    where checkContents tag cargo
              | "DAction" <- (fromJSString tag)
              , Ok xs <- ((readJSONs cargo)::Result [Int])
                      = Ok (DAction xs)
              | "NAction" <- (fromJSString tag)
              , Ok xs <- ((readJSONs cargo)::Result [[Int]])
                      = Ok (NAction xs)
              | otherwise = Error "not an action"

The main disadvantage over the previous version is that we get less detailed error messages, but I think I can live with that for more readable code. It’s still fairly ugly though, and I’m not 100% sure why I need to break out the checkContents part (I did write it in a hurry).

I just can’t shake the nagging suspicion that I’m missing some clever and elegant way of doing this. So if anyone has any pointers, I’d love to hear them. Otherwise, I can at least testify that the above techniques work: maybe that’ll be useful for another JSON adventurer in a hurry, one day. :-)