Extending F# Pipelines with a Tee Function

In functional programming we strive to minimize side-effects but not only are some side-effects desirable, in the largely object-oriented world in which many of us still operate such side-effects are often unavoidable. There are plenty of APIs that rely on side-effects particularly when it comes to initializing types or properties. One example that immediately comes to mind is building up an HttpResponseMessage in Web API 2. Consider the following snippet which creates a response containing the contents of a stream and sets some relevant header values:

member __.GetFile() =
  // ... SNIP ...
  let response = new HttpResponseMessage(HttpStatusCode.OK, Content = new StreamContent(stream))
  response.Content.Headers.ContentType <- MediaTypeHeaderValue("application/octet-stream")
  response.Content.Headers.ContentLength <- Nullable.op_Implicit stream.Length
  response.Content.Headers.ContentDisposition <- new ContentDispositionHeaderValue("attachment", FileName = "test.pdf")
  response

This code is straight-forward but it’s highly imperative. Like side-effects, imperative code isn’t necessarily a bad thing but it would be nice to tame it a bit by initializing the header values as part of a pipeline while still returning the response message. Doing so isn’t hard: just create the HttpResponseMessage instance via the constructor and pipe it to a function that does the initialization before returning, right?

member __.GetFile() =
  // ... SNIP ...
  new HttpResponseMessage(HttpStatusCode.OK, Content = new StreamContent(stream))
  |> (fun response -> response.Content.Headers.ContentType <- MediaTypeHeaderValue("application/octet-stream")
                      response.Content.Headers.ContentLength <- Nullable.op_Implicit stream.Length
                      response.Content.Headers.ContentDisposition <- new ContentDispositionHeaderValue("attachment", FileName = "test.pdf")
                      response)

This is a perfectly acceptable approach and is something I’ve definitely done plenty of times but all it has achieved is moving the explicit return into the function. After doing this a few times, you might start to think there has to be a way to standardize this pattern and you’d be right.

Over the holidays I finally found some time to relax and although I spent a great deal of time glued to Assassin’s Creed: Unity on my Xbox One I managed to read a few more articles than usual. Something that struck me as interesting was that I noticed a theme across several of the code samples: they were using a tee function within a pipeline. The tee function isn’t part of the core F# libraries and I couldn’t recall having encountered it before so I started doing some background investigation.

One of the first sites I found that mentioned the function in the context of F# was Scott Wlaschin’s excellent Railway Oriented Programming article which I’d read previously but clearly not thoroughly enough. In the article Scott says he named the function after a Unix command of the same name. The Unix command, which is named after plumbing tee fittings, splits a pipeline such that input flows to both standard output and a file. This is certainly useful for logging in shell scripts but its possibilities are much more interesting in an F# pipeline.

The tee function is a simple function which essentially says “given a value, apply a function to it, ignore the result, then return the original value.” It’s basic definition is as follows:

let inline tee fn x = x |> fn |> ignore; x

By introducing the tee function into the pipelined version of the GetFile method we can remove the explicit return:

member __.GetFile() =
  // ... SNIP ...
  new HttpResponseMessage(HttpStatusCode.OK, Content = new StreamContent(stream))
  |> tee (fun response -> response.Content.Headers.ContentType <- MediaTypeHeaderValue("application/octet-stream")
                          response.Content.Headers.ContentLength <- Nullable.op_Implicit stream.Length
                          response.Content.Headers.ContentDisposition <- new ContentDispositionHeaderValue("attachment", FileName = "test.pdf"))

Now the pipeline looks more like what we might expect since we’re no longer explicitly returning the response from the lambda expression.

Depending on your style preferences, injecting the tee function explicitly into the pipeline as you would a Seq.filter or other such function might bother you. To me, the tee function is a perfect candidate for a custom operator so let’s define one.

let inline ( |>! ) x fn = tee fn x

Here we’ve defined |>! as the tee operator (this is the same symbol that WebSharper uses). Notice how the parameter order is reversed from the tee function. This is due to the fact that when using our new operator, we’re not relying on partial application to invoke the tee function. Now we can eliminate the explicit reference to the function, making the operation look like a natural part of the F# language.

member __.GetFile() =
  // ... SNIP ...
  new HttpResponseMessage(HttpStatusCode.OK, Content = new StreamContent(stream))
  |>! (fun response -> response.Content.Headers.ContentType <- MediaTypeHeaderValue("application/octet-stream")
                       response.Content.Headers.ContentLength <- Nullable.op_Implicit stream.Length
                       response.Content.Headers.ContentDisposition <- new ContentDispositionHeaderValue("attachment", FileName = "test.pdf"))

Since the tee function/operator is intended to allow side-effects within a pipeline it is ideal for adding logging or other diagnostics into a pipeline (as was the intent in the original Unix command). For instance, to write out a message as each header value is set, we can simply split the tee’d function above into separate functions, inserting a tee’d logging function in between:

member __.GetFile() =
  // ... SNIP ...
  new HttpResponseMessage(HttpStatusCode.OK, Content = new StreamContent(stream))
  |>! (fun _ -> Debug.WriteLine "Created response")
  |>! (fun r -> r.Content.Headers.ContentType <- MediaTypeHeaderValue("application/octet-stream"))
  |>! (fun r -> Debug.WriteLine("Set content type: {0}",
                                [| box r.Content.Headers.ContentType.MediaType |]))
  |>! (fun r -> r.Content.Headers.ContentLength <- Nullable.op_Implicit stream.Length)
  |>! (fun r -> Debug.WriteLine("Set content length: {0}",
                                [| box r.Content.Headers.ContentLength.Value |]))
  |>! (fun r -> r.Content.Headers.ContentDisposition <- new ContentDispositionHeaderValue("attachment", FileName = "test.txt"))
  |>! (fun r -> Debug.WriteLine("Set content disposition: {0}",
                                [| box r.Content.Headers.ContentDisposition.DispositionType |]))

By introducing the tee function and operator you give yourself another tool for taming the imperative code and side-effects that tend to pop up in software projects of any complexity.

Advertisements