How often have you had a few data elements that you wanted to keep together in an ordered manner without going through the trouble of creating a custom type because they were only going to be used in one or two places?  If the data was guaranteed to always be the same type an array or other collection type might suffice but we really have no guarantee about its size and we generally want the data contained in one object.

Most of the time I find myself in this situation, I find that I want something more than an array.  Sometimes that means I end up abusing KeyValuePair<TKey, TValue> for simple pairs or resorting to creating a class or struct that has no use outside of one small area.

.NET 3.0 introduced anonymous types but those are only useful in a few situations without jumping through a bunch of coding hoops.  .NET 4 gave the traditional .NET developer some relief by introducing the generic, immutable Tuple classes that are intended to address this very issue. Unfortunately, using them in a traditional .NET language isn’t particularly convenient.

Tuples in C#

Using Tuples in a language like C# is pretty cumbersome to say the least. To Microsoft’s credit, they provided an overloaded factory method to make them a bit easier to create but it doesn’t address their verbosity in other areas. Consider a function that calculates some measurements for a circle:

Tuple<double, double, double> GetCircleMeasurements(double radius)
{
  var diameter = radius * 2.0;
  var area = Math.PI * Math.Pow(radius, 2.0);
  var circumference = 2.0 * Math.PI * radius;

  return Tuple.Create(diameter, area, circumference);
}

Aliasing

The Create method saves us from having to type full tuple definition when creating one but we need to be more explicit virtually everywhere else. Depending on the number of members in a tuple I sometimes find it helpful to alias the type with a meaningful name. It’s still a bit verbose but to me it’s a good balance of leveraging an existing type while reducing potential points of failure. If we had another Tuple in the same context (say, another method that wanted to do something with the values) and we wanted to change the tuple elements we’d only need to change the alias to affect each place.

// With other using directives
using CircleMeasurements = System.Tuple<double, double, double>;

CircleMeasurements GetCircleMeasurements(double radius)
{
  var diameter = radius * 2.0;
  var area = Math.PI * Math.Pow(radius, 2.0);
  var circumference = 2.0 * Math.PI * radius;

  return new CircleMeasurements(diameter, area, circumference);
}

Accessing Tuple Members

Accessing tuple items in C# is pretty straightforward; we simply access each item via a property:

var measurements = GetCircleMeasurements(2.5);
var diameter = measurements.Item1;
var area = measurements.Item2;
var circumference = measurements.Item3;

Tuples in F#

Given that this is actually a post about tuples in F# you’ve probably guessed by now that using tuples is much simpler in F#. Not only do we get the benefits of type inference, F# has a built-in tuple syntax! In F# tuples are represented by a comma-delimited list and generally enclosed in parenthesis.

Here is the first example above reproduced in F#:

> let GetCircleMeasurements radius =
	let diameter = radius * 2.0
	let area = Math.PI * (radius ** 2.0)
	let circumference = 2.0 * Math.PI * radius

	(diameter, area, circumference)
	
val GetCircleMeasurements : float -> float * float * float

Don’t forget an open System;; line if trying this through FSI.

Although the bulk of the function body is the same you can see that we don’t have to concern ourselves with anything related to the framework itself – we simply use a language construct.

Representing Tuples

Tuples can be thought of as the product of two or more data types so they are represented by delimiting the items with the * character. For example, the tuple returned by the GetCircleMeasurements function would be represented as float * float * float.

Accessing Tuple Members

Accessing tuple members in F# is generally also be significantly easier than in C#. F# provides two built-in functions, fst and snd, for accessing the first and second items in a pair ('a * 'b). An error will be generated if you try to use these functions with a tuple containing more than two items so we something else for our example.

A primary way we can extract values from a tuple is through let bindings. We can easily extract all three values from the tuple returned by GetCircleMeasurements into separate variables. Compare this to the C# example above:

> let (diameter, area, circumference) = GetCircleMeasurements 2.5;;

val diameter : float = 5.0
val circumference : float = 15.70796327
val area : float = 19.63495408

The number of names defined in the binding must match the number of values in the tuple. If they don’t match we’ll get an error. If we only care about some of the values we can simply replace the names we don’t care about with underscores. For instance, if we only care about the area we could write this:

> let _, area, _ = GetCircleMeasurements 2.5;;

val area : float = 19.63495408

We can even easily define a function to return the third value from a triple (tuple with three items):

> let third (_, _, c) = c;;

val third : 'a * 'b * 'c -> 'c

> let circumference = third (GetCircleMeasurements 2.5);;

val circumference : float = 15.70796327

Language Interoperability

If you intend to use tuples across languages it’s important to keep in mind which version of the language you’re using. The tuple classes described in the C# section above were originally located in FSharp.Core.dll. When targeting a framework version prior to 4.0 the compiler uses the versions from this assembly rather than the ones in mscorlib.

Tuples also play a role when calling functions from other languages. Within F# most functions are curried (calling a function with fewer than the specified number of arguments results in creating a new function that accepts the remaining arguments) but outside of F# is a different story. Calling functions from other languages requires what is referred to as a syntactic tuple. Syntactic tuples look like the tuple types but as their name implies, they’re merely a mechanism of the syntax.

Next Steps

Tuples are convenient constructs that are available throughout the .NET Framework as of v4.0 yet cumbersome to use outside of F#. F#’s built-in tuple support makes using them virtually effortless. Despite their convenience, sometimes tuples aren’t enough. What if we want to name the values or extend functionality with custom functions? In those cases we can turn to the next topic in this series – an F# construct called a record type.

Having provided a basic introduction to F#, a discussion over its primitive types, and an in-depth look at units of measure I thought now would be a good time to take a step back and look at one of the helpful tools used when developing F# applications – F# Interactive, or FSI. FSI is a REPL-like (read-evaluate-print loop) utility that’s especially useful for experimenting with the language.

FSI is considered REPL-like because although it fills the same role as a traditional REPL tool it actually compiles the code rather than interpreting it. This distinction is important because it impacts the tool’s behavior. Types and values are commonly redefined in REPL tools but because FSI is compiling the code into new assemblies it only offers an illusion of redefinition. Everything already defined is still available and instances defined against previous definitions aren’t affected as long as they were defined in the same session.  FSI does enforce that if a type changes any new instances are created against the new definition but it’s important to be aware that those changes will not be reflected in any instances created before the change.

FSI is available as both a window within Visual Studio or as a console application. If you’re actively developing an application in Visual Studio you’ll probably find the F# Interactive window more helpful because you can select snippets of code and send them to the window for execution by pressing ALT + ENTER. The console version is especially well suited for running F# scripts (.fsx files).

You can open the F# Interactive window in Visual Studio by pressing CTRL + ALT + F or through the View/Other Windows menu.

Whether running under Visual Studio or the console, operation is the same. Expressions are entered at the prompt and terminated with double semicolons (;;). FSI then attempts compilation and, if successful, prints the result of the expression evaluation.

For every new name introduced by the input, the FSI output will include a val entry. Anything that returns a value but does not have a name are represented as “it.”

Example of the FSI window in Visual Studio 2010.

You can easily reset an FSI session in Visual Studio by right-clicking the window and selecting the Reset Session option.

Common FSI Directives

FSI includes some directives that aren’t available with the compiler. A few of these are especially useful for scripting.

More Reading

• F# Interactive (FSI) Reference
• F# Interactive Options

In my last post we looked at how F# units of measure can help add an extra layer of safety to your code by enforcing the use of correct measurements.  We also saw how we can define relationships between units of measure to provide easy conversions and keep code intuitive.  Of course, there’s still plenty to talk about.

In this post we’ll look at increasing the power of units of measure by adding static members, using generic units of measure, and defining custom measure-aware types.  I recognize that I haven’t written anything about custom types or generics in F# yet so if you’re learning along with my posts I encourage you to read-up some of these concepts on MSDN before going any further.  Don’t worry though, I’ll be visiting those topics soon enough.

Static Members

Formulas are just one way we can define relationships between units of measure and they will often be more than sufficient.  Sometimes we need a little more power than formula expressions offer.  In some cases it may be more appropriate to define static members on the units of measure themselves.  Static members also have the advantage of keeping the logic with the measures they affect.

Static members on units of measure can be values or functions.  Naturally, the complexity of the measure definition varies according to the complexity of the member.  If we’re only defining a conversion factor on one of the related measures the definition will closely resemble a basic definition.  If we need conversion functions on both of the related measures then the definition will be much more complex with the types defined together so they can reference each other.  Let’s take a look at both.

Conversion Factor

Let’s say we have need to convert between inches and feet (I’m American, I’m allowed to use these units!).  We can easily define the measures to include a static conversion factor:

[<Measure>] type ft
[<Measure>] type inch = static member perFoot = 12.0<inch/ft>

Any code that needs to use to that conversion factor can simply refer to the static member by name:

> let inches = 1.0<ft> * inch.perFoot;;
val inches : float<inch> = 12.0

> let feet = 12.0<inch> / inch.perFoot;;
val feet : float<ft> = 1.0

Conversion Functions

When more logic than a conversion factor is required we can define a static function in a measure. To illustrate how complex measure definitions can get we’ll return to converting between inches and pixels by defining a conversion function on both the inch and px measures. In order for type inference to work we’ll need to define the measure types at the same time with the and keyword. The dpi measure will be defined independently but before the other two.

[<Measure>] type dpi
[<Measure>]
type inch =
  static member ToPixels (inches : float<inch>) (resolution : float<dpi>) =
    LanguagePrimitives.FloatWithMeasure<px> (float inches * float resolution)
and
  [<Measure>]
  px =
    static member ToInches (pixels : float<px>) (resolution : float<dpi>) =
      LanguagePrimitives.FloatWithMeasure<inch> (float pixels / float resolution)

There should be very little surprising in the conversion functions themselves. All they’re doing is stripping the units from the parameters, multiplying or dividing the floats and converting the resulting value to a measured float.

Just like with the conversion factor, any code that needs to convert can simply refer to the static member:

let resolution = 150.0<dpi>
let pixels = inch.ToPixels 8.0<inch> resolution
let inches = px.ToInches pixels resolution

Generic Units of Measure

Everything function we’ve looked at so far in this post and the last has relied on specific measure types. We’ve seen how measure-aware functions add an extra level of safety when working across multiple units of measure. We’ve also briefly discussed how many functions are not written to accept measured values as arguments so any units must be dropped. Although many functions that aren’t measure-aware are outside of our control, we can take advantage of generic units of measure in our code to maintain that extra level of safety.

To use generic units of measure we just need to alter the type annotation in the function signature a little bit by replacing the concrete measure with an underscore:

> let square (x : float<_>) = x * x
val square : float<'u> -> float<'u ^ 2>

As you can see, the type inference engine has changed the underscore to 'u ('u being F#’s way to denote generics) and identified the return value as float<'u ^ 2>. We can now call this with any float value and get a result in the proper units.

> let squaredInches = square 3.0<inch>;;
val squaredInches : float<inch ^ 2> = 9.0

> let squaredPixels = square 450.0<inch>;;
val squaredPixels : float<inch ^ 2> = 202500.0

> let squaredUnitless = square 9.0;;
val squaredUnitless : float = 81.0

What’s more is that once we have a function defined to use generic units of measure, the type inference engine can infer the type for other functions that consume it.

> let cube x = x * square x;;
val cube : float<'u> -> float<'u ^ 3>

Even though we didn’t give the compiler any hints about x in the cube function it was able to infer by virtue of calling the square function that it should accept float<'u> and return float<'u ^ 3>!

> let cubedInches = cube 3.0<inch>;;
val cubedInches : float<inch ^ 3> = 27.0

> let cubedPixels = cube 450.0<inch>;;
val cubedPixels : float<inch ^ 3> = 91125000.0

> let cubedUnitless = cube 9.0;;
val cubedUnitless : float = 729.0

Custom Measure-Aware Types

The last thing we’ll examine in regards to units of measure is defining custom measure-aware types. The way we make a custom type measure-aware is to include a measure parameter as part of the type’s generic type list.

Let’s consider a simple Point type. This type will include the standard X and Y coordinates and a function for calculating the distance between two points. One way we could define this type is as a measure-aware record type:

type Point< [<Measure>] 'u > = { X : float<'u>; Y : float<'u> } with
  member this.FindDistance other =
    let deltaX = other.X - this.X
    let deltaY = other.Y - this.Y
    sqrt ((deltaX * deltaX) + (deltaY * deltaY))

Because we’re actually referencing the measure type in our value definitions we need to be sure to give it a name in the generic type list rather than using underscore as we saw earlier. All other usages of the measure are actually inferred. With this type defined we can consume it like any other type:

> let point1 = { X = 10.0<inch>; Y = 10.0<inch> };;
val point1 : Point<inch> = {X = 10.0;
                            Y = 10.0;}

> let point2 = { X = 20.0<inch>; Y = 15.0<inch> };;
val point2 : Point<inch> = {X = 20.0;
                            Y = 15.0;}

> let distance = point1.FindDistance point2;;
val distance : float<inch> = 11.18033989

We’re not restricted to record types when making custom types measure aware either. We can define a measure-aware class almost as easily:

type Point< [<Measure>] 'u >(x : float<'u>, y : float<'u>) =
  member this.X = x
  member this.Y = y

  member this.FindDistance (other : Point<'u>) =
    let deltaX = other.X - this.X
    let deltaY = other.Y - this.Y
    sqrt ((deltaX * deltaX) + (deltaY * deltaY))

  override this.ToString() =
    sprintf "(%f, %f)" (float this.X) (float this.Y)

Consuming the class is naturally a bit more verbose as well:

> let point1 = Point<inch>(10.0<inch>, 10.0<inch>);;
val point1 : Point<inch> = (10.000000, 10.000000)

> let point2 = Point<inch>(20.0<inch>, 15.0<inch>);;
val point2 : Point<inch> = (20.000000, 15.000000)

> let distance = point1.FindDistance point2;;
val distance : float<inch> = 11.18033989

Wrapping Up

Over the last two posts we’ve taken a pretty comprehensive tour of F#’s units of measure and seen how powerful the feature is. Annotating values with measures truly helps ensure code correctness by enforcing that calculations are performed against the correct measurements.

We may have finished with units of measure but there’s still plenty more to explore in F#. Over the coming weeks I’ll be taking a close look into other topics like tuples, records, discriminated unions, and pattern matching among other things. Thanks for reading!

As I’ve been outlining the things I want to write about in regards to F# there are only a few topics that excite me more than units of measure.  If you’ve ever had to write code that deals with different measurement units (and who hasn’t?) this feature can quickly become one of your best friends. I really struggled with where to include this in the series but ultimately decided that it made the most sense to keep it near primitive data types since they’re so closely related.

The Case for Units of Measure

My current project at work involves a bit of image manipulation.  If we were only working with pixels this wouldn’t be an issue but we actually need to translate some values between inches and pixels.  This, of course, means we have three distinct units of measure: inches, pixels, and dots per inch for conversion.  Keeping track of which types and methods require pixels versus those that require inches can be troublesome to say the least.  We can mitigate the problem a bit through naming conventions but simply calling something widthInInches does not guarantee that the supplied value is actually in inches.

This example is pretty insignificant in terms of impact on the world but using the wrong unit of measure can have devastating consequences.  Wouldn’t it be nice if the compiler could enforce using the correct measurement?  Units of measure in F# do just that.

Before we dive in to defining units I think it’s helpful to start from an example that doesn’t have them. Consider the following:

let convertToPixels inches resolution =
	inches * resolution
	
let convertToInches pixels resolution =
	pixels / resolution

let resolution = 150.0
let pixels = convertToPixels 8.0 resolution
let inches = convertToInches pixels resolution

In this simple example we have functions to convert between inches and pixels. The parameter names guide us but there’s nothing enforcing any rules about the values. How can we be sure that 8.0 and 150.0 are actually inches and dots per inch? The answer, of course, is to define and apply some units.

Introducing Units of Measure

Units of measure are simply specially annotated types that can be associated with numeric (both signed integral and floating point) values. Defining a basic unit of measure is easy; just define an opaque (memberless) type and decorate it with the Measure attribute. For instance, we can define dpi, inches, and pixels as follows:

[<Measure>] type dpi
[<Measure>] type inch
[<Measure>] type px

If your application requires SI units (International System of Units) you can save yourself some time as these units are already defined. For F# versions prior to 3.0 you can find them in the F# PowerPack on CodePlex. In F# 3.0 they are included in the FSharp.Core assembly and found under the Microsoft.FSharp.Data.UnitSystems.SI.UnitNames and Microsoft.FSharp.Data.UnitSystems.SI.UnitSymbols namespaces.

Identifying values of a particular unit is similarly trivial:

let dpiValue = 150.0<dpi>
let inchValue = 8.0<inch>
let pxValue = 1200.0<px>

Microsoft recommends using only using units of measure with floating point expressions to avoid potential conversion problem. I’ll be following that convention throughout this article.

In the above example, each value is qualified by a particular measure. With this knowledge we can modify our conversion code to enforce that only properly qualified values can be supplied.

[<Measure>] type dpi
[<Measure>] type inch
[<Measure>] type px

let convertToPixels (inches : float<inch>) (resolution : float<dpi>) =
  float(inches * resolution) * 1.0<px>

let convertToInches (pixels : float<px>) (resolution : float<dpi>) =
  float(pixels / resolution) * 1.0<inch>

let resolution = 150.0
let pixels = convertToPixels 8.0 resolution
let inches = convertToInches pixels resolution

The function signatures have been updated with type annotations to qualify the parameters with the required unit of measure. If we attempt to run this code though the compiler will raise an error because the values being passed to the functions haven’t been qualified. To continue we just need to update the value definitions with the correct units:

let resolution = 150.0<dpi>
let pixels = convertToPixels 8.0<inch> resolution
let inches = convertToInches pixels resolution

Changing Units of Measure

Not all code is aware of measures so there will be plenty of occasions when we’ll need to either add or remove units of measure from an existing value and there are a couple of approaches to both.

Adding Units of Measure

If your data is coming from an external source you’ll need to add units to it to use it with your measure aware code. The easiest way to add units is to take the raw value and multiply it by some value with the desired unit.

> 150.0 * 1.0<dpi>
val it : float<dpi> = 150.0

Alternatively we can use a library function from the LanguagePrimitives module in FSharp.Core.

> LanguagePrimitives.FloatWithMeasure<dpi> 150.0
val it : float<dpi> = 150.0

Removing Units of Measure

If your data needs to be used by something that isn’t measure aware you’ll need to strip away the units. Like with adding units, removing units can be done with a simple mathematical operation. To easily remove units just multiply the measured value by another value of the same units.

> 150.0<dpi> / 1.0<dpi>;;
val it : float = 150.0

We can also remove units by passing the measured value to the conversion function that corresponds to it’s underlying type.

> float 150.0<dpi>;;
val it : float = 150.0

Relating Units of Measure

In the physical world there is often a correlation between different units of measures. F# allows us to express those relationships naturally. Continuing with the theme of image processing let’s look at dots per inch. So far we’ve used a unit named dpi to define dots per inch. On it’s own this is already a huge improvement over a naming convention but we can express the concept much more eloquently by adding another measure and defining relationships between them.

[<Measure>] type px
[<Measure>] type inch
[<Measure>] type dot = 1 px
[<Measure>] type dpi = dot / inch

We added in the dot measure with a formula that identifies a dot as being equivalent to a pixel (the 1 is optional, see the rules section below for more information). We also modified the dpi measure with a formula defining it as being dots divided by inches. These two changes have a profound impact on our conversion code. By defining the formulas and including a type annotation for the function return value the compiler has enough information to convert the return values from float<dpi inch> and float<px/dpi> to float<px> and float<inch>, respectively.

let convertToPixels (inches : float<inch>) (resolution : float<dpi>) : float<px> =
  inches * resolution

let convertToInches (pixels : float<px>) (resolution : float<dpi>) : float<inch> =
  pixels / resolution

Measure Formula Rules

There are some rules to keep in mind when writing unit formulas. Some highlights:

• Positive and negative integral powers are supported
• Spaces (or *) between measures indicate a product
• A / character between measures indicates a quotient
• 1 is allowed to express a dimensionless quantity or with other units

Runtime Implications

Units of measure are a feature of F#’s static type checking logic and are not included in the compiled code. The implication is that except in certain scenarios we can’t write anything to detect units of measure at runtime.

Next Steps

This article introduced units of measure and demonstrated how they can improve the quality of your code but we’ve only examined how to apply them to simple values and pass specific units to functions. In the next article in this continuing series we’ll look at some other ways to use units of measure including:

• Adding static members to measures
• Using generic measures
• Defining custom measure-aware types