dave^2 = -1

A software development blog by some bloke called Dave

F# assertion libraries

There are a few different libraries that provide test assertions for F#. I went through a couple today and tried a trivial example in each.

Digitising hand drawn sketches

Every so often I want to quickly sketch out what should be a simple diagram. Irrespective of what drawing program I use, I always seem to take much more time than I intend for a result that does not even remotely resemble what I want.

So I decided to give up and find a way to use hand-drawn sketches instead. Here’s the method I ended up with, based almost entirely on Marc Liberatore’s "Whiteboard Diagrams as PDFs" post and the wonderful ImageMagick and Potrace utilities.

My drawings still look fairly terrible, but at least they convey what I want them to and are quick to produce! :)

A hasty introduction to the Either type

The Either type, also called Choice in F# parlance, is a way of representing a value that can be either one of two types. This can be extremely useful. For example, retrieving a date of birth from a textbox could be expressed as Either<ParseException, DateTime>. In other words, the result is a value that is either a valid DateTime, or is a ParseException.

Being a hasty introduction this post is not going to do justice to how useful this type is, but hopefully some of its goodness will shine through despite my rambling prose. :)

Stayin’ alive with .NET GC

Most of the time .NET GC just works. Occasionally when dealing with things like interop with unmanaged code, things go wrong. Things I learned today from this aforementioned going wrong include:

  • Variable scope can be greater than the lifetime of the object it points to
  • Mark-and-sweep GC marks objects for survival, not for collection
  • GC.KeepAlive(object) is a no-op
  • Finalisers from collected objects can break active objects
  • Use a release configuration build for reproducing GC issues, running without the debugger attached
  • Non-deterministic finalisation makes me confused
One does not simply reason about .NET Garbage Collection
One does not simply reason about .NET Garbage Collection

Splitting responsibilities by abstracting type details

One thing I’ve battled with in my OO, TDD adventures is useless abstractions. I find it very easy to churn out class like the PaddedSingleWidgetList described below in an attempt to follow the Single Responsibility Principle and write testable code, but in doing so I end up with lots of classes that don’t really make much sense in isolation, and that are not inherently reusable. (Just me?)

Instead of my usual approach of splitting a problem in terms of somewhat arbitrarily chosen responsibilities, what if we divided it into the parts that need knowledge of specific types, and the parts that can have the specific types abstracted away?

Terminal IO example in Haskell

Last post we looked at using a less general form of the Free monad to purely represent side-effects in F#. Because Haskell supports higher-order polymorphism it makes using this approach much easier. Here is the complete example from that post, rewritten in Haskell:

More freedom from side-effects (F#)

Previously we looked at using IO without side-effects in C# by deferring the execution of side-effects. Rather than immediately performing IO, we wrapped up side-effecting operations in an IO type and used combinators like Select, Then and SelectMany to work within that type, so we could use IO values without having to give up the benefits of pure functions by executing the side-effect.

This is a useful technique, but it has the drawback that the IO instances assembled with these combinators are opaque – there is no way for us to inspect them and work out what the represent. We know an IO<String> is some IO operation that will result in a string, but is it readLine, or launchMissilesAndShowStatus?

In this post we’ll look at another way of representing side-effecting (and other) operations that addresses this drawback.