dave^2 = -1

A software development blog by some bloke called Dave

A mad Haskeller runs the same input through a list of functions

Last time I donned my mad Haskeller lab coat we ended up using arrows to pipe the output of two functions into a tuple. This time I’m going to look at piping a single input through a list of functions to get a list of output.

The motivation for this experiment was a small section of a code snippet I found in Chris Wilson’s From Ruby to Haskell, Part 2: Similarity, Refactoring, and Patterns post:

... [eventDescription e, eventName e, eventLocation e, eventType e] ...

As far as I can tell there’s nothing at all wrong with this. It is creating a list of values by passing e to several functions. It did get me thinking though – do we have to explicitly pass in that e argument to every function? To the laboratory!

With apologies to Randall. Original: xkcd store
With apologies to Randall. Original: xkcd store

Side-effect free programming in C#

How can we do inherently side-effecty things like IO when using functional programming, where each call has to be side-effect free?

In this post we’ll look at side-effects and how we could eliminate them from our code (we’ll use C#, but we can apply the idea to many languages). The aim is not to get something enormously practical that we’ll use every day, but instead to explore some ideas and hopefully work out how it is possible to get any useful work done using functional programming where side-effects are forbidden.

Reasoning and mutability

One thing I often hear about functional programming is that its requirement for immutability makes programs easier to reason about. To me this seems intuitively true – it’s got to be easier to work out what a program does without having to keep track of changing state while evaluating programs, right?

I wanted to challenge my assumptions about this. Could I convince myself that one is unambiguously easier to reason about? And if so, what is it about the other that makes it more difficult to reason about?

To do this I tried tracing through some examples of mutable and immutable data structures. I tried to use similar, "object" styles for both, so that the characteristic difference between them was the mutability of their internal data (rather than getting thrown off by differences between functional and OO styles).

I’d love to get your thoughts for and against these ideas. I am especially likely to be the victim of confirmation bias on this one, so I’m counting on you to keep me honest. Leave comments or send me email please! :)

From two functions to tuples with a mad Haskeller

I love finding neat little bits of Haskell that do things in ways I haven’t really thought of before. This usually happens when I come across a simple yet slightly clumsy way of doing something, and embark on some mad experiments to find alternative approaches (usually ending in a trip to #haskell.au on Freenode). These alternatives may not result in anything usable, but they often prove to be fun learning experiences for me.

A recent example of this was the following adventure in passing the same input to two functions, and getting the output as a tuple.

"Stand back… I'm going to try Haskelling!" Original image source: Muppet Wiki
"Stand back… I’m going to try Haskelling!"
Original image source: Muppet Wiki

Lazy<T> monad instance in C#

One of the most surprising and useful things I’ve learned about .NET this year is that it has quite good support for monads as of .NET 3.5 (it’s just missing higher-order polymorphism). What’s more, for those allergic to monads, you don’t need to understand anything in that previous sentence to follow this post. :)

In this post we’ll implement the couple of functions necessary to be able to compose instances of Lazy<T> together in interesting ways using LINQ and LINQ comprehensions.

Threading and Lazy<T>

Xerx and I have been playing around with using Lazy<T> for one-time, asynchronous initialisation of values, and we stumbled across the various threading options that Lazy<T> supports. After puzzling over the documentation for a while I thought it was probably easier just to run a few examples.

Some optional, functional goodness in C#

For this post I wanted to show you a small yet extremely useful bit of functional programming that you can apply right away to your current C# (or VB.NET) project. While there’s solid theory underpinning it, we won’t need any of that to be able to apply it, so we’ll jump straight to the practice. (I love the theory, so this is quite a sacrifice I’m making for you! ;)) As an added bonus, we’ll also get a good stepping stone for starting to apply more of these practical FP ideas in our everyday code.


According to Wikipedia a catamorphism "denotes the unique homomorphism from an initial algebra into some other algebra".

Uh huh. Sure.

I’ve got an admittedly very basic understanding of this concept, but I thought I’d share the small amount I have been able to learn and apply, as I’ve found it to be a useful tool for working with types.