I’m a huge fan of strong static types; it’s one of the reasons I like Haskell so much. Recently I’ve been toying with some F#, which has a typing feature I’m really enjoying: units of measure. I want to explain a few examples of where units of measure can prevent bugs. To do this, let’s start off with some simple F# code for a car moving around the screen. It has a direction and a speed, and you can steer and speed up/slow down using the keys. Here’s some basic code to do this:

type Key = Up | Down | Left | Right let isKeyDown (key : Key) : bool = ... type Position = {x : float32; y : float32} let mutable pos = {x = 0.0f; y = 0.0f} let mutable direction = 0.0f let mutable curSpeed = 1.0f let acc = 0.5f let turnSpeed = 4.0f let update (frameTime : float32) = if isKeyDown Up then curSpeed <- curSpeed + acc elif isKeyDown Down then curSpeed <- max 0.0f (curSpeed - acc) if isKeyDown Left then direction <- direction - turnSpeed elif isKeyDown Right then direction <- direction + turnSpeed pos <- {x = pos.x + cos(direction) * curSpeed * frameTime; y = pos.y + direction * curSpeed * frameTime}

This code looks fairly reasonable, and it compiles and runs. It’s also riddled with mistakes, which we can eliminate through the use of units of measure. To start with, we need to define a few units:

type [<Measure>] second type [<Measure>] pixel type [<Measure>] radian

Units of measure allow easy tagging of numeric types with units. The units are really just arbitrary names. The compiler doesn’t know second means, it just knows that second is distinct from radian. I think most people use single letters for brevity, but I like full names for clarity. You can use them to type a variable like so:

let mutable direction : float32<radian> = 0.0f

But actually this is insufficient; the compiler will complain that you are assigning 0.0f (a literal with no units) to direction, which has units. Much easier is to only type the literal and let the type inference do the rest:

let mutable direction = 0.0f<radian>

Typing our initial variables is pretty straightforward. Positions are in pixels, and we know from school that speed is distance over time, acceleration is distance over time squared:

type Position = { x : float32<pixel>; y : float32<pixel>} let mutable pos = {x = 0.0f<pixel>; y = 0.0f<pixel>} let mutable direction = 0.0f<radian> let mutable curSpeed = 1.0f<pixel/second> let acc = 0.5f<pixel/second^2> let turnSpeed = 4.0f<radian/second>

This alone is enough to show up all the errors in our code. Let’s start with:

if isKeyDown Up then curSpeed <- curSpeed + acc

The units of curSpeed is pixel/second, and we’re trying to add acc[eleration], which has units pixel/second^2. This is a subtle bug. To explain: as you may know, frames in a game or simulation don’t realistically run at completely fixed frame rates. They tend to vary between machines because different machines can maintain different maximum frame rates, and they even vary on the same machine while the program is running because other processes may interrupt to use the CPU. If I add acc to my speed every *frame*, then on a desktop doing roughly 60 frames per second (FPS) I’ll have a car that accelerates twice as fast as on a laptop doing 30FPS, which would make for quite a different game. The units of measure system has pointed this bug out. We shouldn’t just add the acceleration, we need to multiply the acceleration by the frame duration:

if isKeyDown Up then curSpeed <- curSpeed + acc * frameTime

The same type of bug occurs in a few other places, such as here:

if isKeyDown Left then direction <- direction - turnSpeed

Similar to above, turnSpeed is radians per second, but directions is radians, so we must again multiply by frameTime.

### Standard Functions

Here’s another bug, where I have missed out a call to the sin function:

pos <- {x = pos.x + cos(direction) * curSpeed * frameTime; y = pos.y + direction * curSpeed * frameTime}

Previously, the compiler was happy because all the variables were plain float32. Now, I’m trying to add pos.y [pixel] to direction * curSpeed * frameTime [radian*pixel]. Looking at it, the problem is the missing sin call. So we can add that in:

pos <- {x = pos.x + cos(direction) * curSpeed * frameTime; y = pos.y + sin(direction) * curSpeed * frameTime}

However, we still get an error on these lines, complaining that we’ve attempted to pass float32<radian> to a function which takes plain float32. Hmmm. The problem here is that the standard library functions don’t have any units specified on their parameters or return values, so cannot pass a quantity with units to any standard library function. This is a bit of an ugly effect of units of measure arriving after the language’s initial release. One fix is that each time you call sin/cos/tan/atan2/sqrt/oh-my-god-it-goes-on-and-on you have to cast away the units, like so:

pos <- {x = pos.x + cos(float32 direction) * curSpeed * frameTime; y = pos.y + sin(float32 direction) * curSpeed * frameTime}

Eugh. Firstly: this is annoying to have to do every time, especially if you use a particular standard library function a lot. Secondly: this is losing type safety. What if direction wasn’t in radians — which should be an error — but we’re masking the error by casting away the units? Much better is to add your own typed thin wrappers around the functions:

let cosr (t : float32<radian>) : float32 = cos (float32 t) let sinr (t : float32<radian>) : float32 = sin (float32 t)

(Is there already an F# library that does this for all the standard numeric functions? Seems like it would be a sensible thing to do.) Now we can fix our code in a type-safe manner:

pos <- {x = pos.x + cosr(direction) * curSpeed * frameTime; y = pos.y + sinr(direction) * curSpeed * frameTime}

You may question why you can’t pass a float32 to a function expecting float32<radian>. My understanding is that the designers chose float32 to represent a unitless measure, which is not the same as unit-indifferent. Think atheist vs agnostic: float32 is not unit-agnostic in modern F#, it’s unit-atheist. The output of my cosr function really is unitless, so it is specifically [unitless] float32, not [I was just too lazy to give a unit] float32. Even if you are using units of measure in your code, you will still have functions and variables that are unitless, and using units in their place is an error. For example, an acosr (i.e. inverse cosine) function would take a (unitless) float32 and give back a float32<radian>. It should, and would, be an error to pass in a float32<radian> as the parameter.

This also means units of measure aren’t a subtype: much of their advantage comes from the fact that you can’t substitute a plain float32 and a float32<whatever> without using an explicit cast. They’re more like an easy way to clone numeric types.

### Units of Measure: Summary

I really like units of measure. I’ve used types for similar purpose in Haskell in the past, but the way that units of measure effortlessly wrap the existing numerical types make it very easy in F#. If you are doing anything with any arithmetic, not just geometry, units of measure can spot a lot of bugs and provide a lot of automatic safety. Units of measure really come into their own because they track units through arithmetic expressions. **Units of measure are not just about avoiding confusing feet with metres; it’s more about not accidentally adding an office space rent cost per day (pounds/metre^2/day) to a cost per day (pounds/day) without remembering to multiply the first one by the desired floor area.** Think how much easier your secondary school maths/physics (and later calculus) would have been if you had had a automated system like this, checking the units in all your equations.

One final note: this post is more computing than education, but you may be interested in this previous post (and its comments) on the role of types in programming education.

There’s a load of built-in SI types bundled with F# (FSharp.Data.UnitSystems.SI.UnitNames and UnitSymbols). Not sure about conversion functions, but there might be a package for that.

It’s a great idea, and I’d like to claim that I had it first! (I’d like to claim that, but I think it’s very unlikely …)

We wrote a brief ideas note on this for AVoCS 2014 last year, in fact: “Physical Type Tracking through Minimal Source-Code Annotation”, and it’s available here:

Click to access AVoCS2014Proceedings.pdf

I’d very much like to see this tested in environments that don’t require language changes, myself: it would be quite feasible in C, for example. (I’m hesitating to say “easy”, but I really think it would be.)

It looks like it has a long history; this 2008 post references a 1995 thesis discussing the idea. I think it’s a really good idea; the more I use it, the more it saves me from mistakes. I think the main difficulty with doing this without language changes is that without explicit annotations on literals, you will run into trouble. If you multiply metre/second by a literal of unknown units (e.g. 2.0), you don’t know if you’ve ended up with metre, or metre/second; was that 2.0 a factor for doubling the speed, or to find out the distance travelled over 2 seconds? F# would use an explicit annotation in the latter case to differentiate.

That’s a good point, thanks.

I guess the language changes (more intrinsic than one could achieve with C attributes, for example) could easily address that in a similar way to existing C/C++ etc annotations.

But I wonder how much benefit we could achieve from a (deliberately) partial implementation bolted onto an existing language like C. Some, I hope.