Mark Needham

Thoughts on Software Development

Archive for the ‘F#’ Category

C#: A failed attempt at F#-ish pattern matching

with 2 comments

A few weeks ago we had some C# code around calcuations which had got a bit too imperative in nature.

The code looked roughly like this:

public class ACalculator
	public double CalculateFrom(UserData userData)
		if(userData.Factor1 == Factor1.Option1)
			return 1.0;
		if(userData.Factor2 == Factor2.Option3)
			return 2.0;
		if(userData.Factor3 == Factor3.Option2)
			return 3.0
		return 0.0;

I think there should be a more object oriented way to write this code whereby we push some of the logic onto the ‘UserData’ object but it struck me that it reads a little bit like pattern matching code you might see in F#.

I decided to drive the code to use a dictionary which would store functions representing each of the conditions in the if statements:

public class ACalculator
	private Dictionary<Func<UserData, bool>, double> calculations;
	public ACalculator()
    		calculations = new Dictionary<Func<UserData,bool>,double>
                           {u => u.Factor1 == Factor1.Option1, 1.0},
                           {u => u.Factor2 == Factor2.Option3, 2.0},                                       
                           {u => u.Factor3 == Factor3.Option2, 3.0}                                 
	public double CalculateFrom(UserData userData)
    		var calculation = calculations.Keys.FirstOrDefault(calc => calc(userData));
    		if(calculation != null)
        		return calculations[calculation];
    		return 0.0;

It’s less readable than it was before and it’s not obvious that the adding of the functions to the dictionary needs to be in that order in order for it to work.

I’ve simplified the real example a bit to show the idea but I don’t think it works as the best abstraction in this situation either way although it was an interesting experiment.

Written by Mark Needham

June 13th, 2010 at 10:35 pm

Posted in .NET,F#

Tagged with ,

F#: Tacit programming

with one comment

I recently came across the idea of tacit programming which is described as such:

Tacit programming is a programming paradigm in which a function definition does not include information regarding its arguments, using combinators and function composition (but not λ-abstraction) instead of variables.

The simplicity behind this idea allows its use on several programming languages, such as J programming language and APL and especially in stack or concatenative languages, such as PostScript, Forth, Joy or Factor. Outside of the APL and J communities, tacit programming is referred to as point-free style.

I realised that this approach quite closely describes what I’ve been trying to drive towards in my most recent playing around with F# and it’s actually quite fun trying to drive any intermediate state or storing of data in variables out of a program and just relying completely on function composition and higher order functions.

It seems like we need to define the signatures of some of the functions more explicitly but once we have a group of these functions we can combine them quite effectively elsewhere in our program.

Moving towards function composition

I’ve been trying to do this with the F# test builder that I’ve been working on and in a few cases it’s helped to reduce the amount of code required.

The build function originally read roughly like this:

and build (t:Type) = 
     let shortestConstructor = getShortestConstructor t
     shortestConstructor |>
     invokeWith (fun c -> getParameters c |> (fun p -> valueFor { Type = p.ParameterType; Name = p.Name })) |>
     andApply (fun t -> getWriteableProperties t |> Array.iter(setValueOn t))

In order to drive that code toward a ‘point-free style’ we need to make use of the function composition operator which allows us to get the code to the stage where we don’t need to specify the signature of ‘build’, it can be inferred:

and build = getShortestConstructor >>
            invokeWith (getParameters >> (fun p -> valueFor { Type = p.ParameterType; Name = p.Name })) >>
            andApply (fun t -> getWriteableProperties t |> Array.iter(setValueOn t))

I think that code is pretty much identical to the first version but I’m getting the following warning message pointing to the ‘valueFor’ call on line 2:

Warning	1	This and other recursive references to the object(s) being defined will be checked for initialization-soundness at runtime through the use of a delayed reference. This is because you are defining one or more recursive objects, rather than recursive functions. This warning may be suppressed by using #nowarn "40" or --nowarn 40.	C:\Playbox\yab\yab\Builder.fs	40	66	yab

I can’t figure out how I can change the code to get rid of that warning. I also haven’t worked out whether it’s possible to fix the ‘andApply’ line so that we can use functional composition throughout.

It would be cool if it could written in such a way that ‘t’ wouldn’t have to be explicitly specified. I can’t quite figure out how to do it because I need to call ‘getWriteableProperties’ and then iterate through that sequence and set a value on ‘t’ using each one.

Is there a way to write that bit of code so that ‘t’ could be inferred?

Some functions need to define signatures?

In order to write a ‘build’ function which heavily uses functional composition I’ve pulled out several helper functions which all currently explicitly define their signatures:

    let getWriteableProperties t = t.GetType().GetProperties() |> Array.filter (fun p -> p.CanWrite)
    let invokeWith f (aConstructor:ConstructorInfo) = f(aConstructor) |> aConstructor.Invoke

If we want to call C# libraries like this then I don’t think we have a choice but to explicitly define function signatures. It is possible to push the place at which we need to do this by writing F# functions to wrap those C# method calls but at some stage we’ll explicitly define a function signature:

let getWriteableProperties = getTypeProperties >> Array.filter writeableProperty

where the extra helper functions are defined like so:

let getTypeProperties t = t.GetType().GetProperties()
let writeableProperty (p:PropertyInfo) = p.CanWrite

I can’t see a way around this so again I’d be interested if there is one. I don’t think it’s a problem anyway, just intrigued how far their programming approach can be taken.

Written by Mark Needham

May 10th, 2010 at 11:24 pm

Posted in F#

Tagged with

F#: My current coding approach

with 2 comments

I spent a bit of time over the weekend coding a simple generic builder for test objects in F# and I noticed that although there were similarity with the ways I drive code in C# or Java my approach didn’t seem to be exactly the same.

I’ve previously written about the importance of getting quick feedback when programming and how I believe that this can often be achieved faster by using the REPL rather than unit testing.

Still driving from the outside in

This time I decided to apply some of my recent learnings on the value of driving from the outside in so I started by writing an acceptance test which described the fluent interface of the code at a high level.

I want to use the builder from C# code so I was driving the code from C# tests:

public void ShouldCreateAFoo()
	var foo = Build.A<Foo>().Build();
	Assert.That(foo.Bar, Is.EqualTo("Bar"));

I wrote enough code to make that test compile at which stage the test was failing with a null reference exception because I hadn’t instantiated ‘Foo’ yet.

At this stage if I was coding in C# I would probably work out what object I needed to create to do that and then I would write a test directly against that object and then write the code to make that pass.

In this case I didn’t do that but instead I had a rough idea of the functions that I needed to glue together to get that test to pass. I just wrote those functions and combined them together without writing any tests against those individual functions.

I extended my initial test to cover all the different types that are being used by the objects in our code base and then I added the code to make the new type pass.

Approach to learning an API

Since it’s reflection code and I don’t know those APIs that well I spent a bit of time tinkering in the REPL until I knew which methods I needed to call.

If I was writing C# then I’d have probably spent less time trying out different methods and more time reading through the list of available methods before choosing the one that I wanted.

I wrote quite messy code initially until I had the first test passing and then I went back and tidied it up so that it was a bit more readable.

At this stage common functions started to reveal themselves and it made sense to have some unit tests directly against those as documentation if nothing else. The tests were all immediately green so those bits of code weren’t test driven at that level.

Do we need really granular tests in F#?

My overall feeling at the moment is that while it’s useful to have tests around code written in F#, we don’t need to go as granular with our tests as we might do in C#.

Due to the conciseness of the language it’s often so obvious that the code written is correct that I don’t think tests at the functional level would add that much value. Equally I’m not necessarily convinced that the design would be any different if the individual functions were test driven.

I found the high level test gave me enough protection for any changes that I wanted to make and it did protect me a couple of times when I made breaking changes.

Having said all that, I’m still only writing toy code so it would be interesting to see if my approach would be any different if I was working on an F# application with a team of other developers.

Written by Mark Needham

May 6th, 2010 at 11:36 pm

Posted in F#

Tagged with

F#: The Kestrel Revisited

with 3 comments

A couple of days I wrote about a ‘returning’ function that I’d written to simplify a bit of F# code that I’ve been working on.

It’s defined like so:

let returning t f = f(t); t

And can then be used like this:

let build (t:Type) =
    returning (Activator.CreateInstance(t)) (fun t -> 
        t.GetType().GetProperties() |> Array.iter (fun p -> p.SetValue(t, createValueFor p, null)))

While I quite like this function it didn’t quite feel like idiomatic F# to me.

With idiomatic F# we would tend to design our functions in such a way that we can pipe data through a series of them by making use of the forward or function composition operators.

With that idea in mind I decided to try switching the arguments to ‘returning’ around and renaming it so that the code would read more naturally:

let andApply f t = f(t); t
let build (t:Type) =
    Activator.CreateInstance(t) |>
    andApply (fun t ->  t.GetType().GetProperties() |> Array.iter (fun p -> p.SetValue(t, createValueFor p, null)))

We partially apply the ‘andApply’ function to create a new function which takes in a type which is provided on the left hand side of the ‘|>’ operator.

I think this now reads better than the original version.

What I find interesting is that when writing functions which I intend to be used like this the way I name them is different and the name only makes sense if it’s used in that context.

Using the ‘andApply’ function on its own without making use of partial function application wouldn’t read as cleanly as it does at the moment.

Written by Mark Needham

May 4th, 2010 at 6:36 pm

Posted in F#

Tagged with

F#: The ‘defaultArg’ function

with one comment

While reading through an old blog post by Matthew Podwysocki about writing F# code in a functional rather than imperative way I came across the ‘defaultArg’ function which I haven’t seen previously.

It’s quite a simple function that we can use when we want to set a default value if an option type has a value of ‘None’:

The type signature is as follows:

> defaultArg;;
val it : ('a option -> 'a -> 'a) = <fun:clo@0>

And the definition is relatively simple:

let defaultArg x y = match x with None -> y | Some v -> v

We could then use it if we were looking up a key in a dictionary but wanted to return a default value if there wasn’t an entry for that key.

For example:

let myMap = Map.add "key" "value" Map.empty                
let result = defaultArg (Map.tryFind "nonExistentKey" myMap) "default"     
> val result : string = "default"

This is just another of the utility functions we can use in F# to allow us to keep composing functions even when we can get more than one type of result from another function.

Written by Mark Needham

April 12th, 2010 at 6:21 pm

Posted in F#

Tagged with

F#: Passing an argument to a member constraint

with one comment

I’ve written previously about function overloading in F# and my struggles working out how to do it and last week I came across the concept of inline functions and statically resolved parameters as a potential way to solve that problem.

I came across a problem where I thought I would be able to make use of this while playing around with some code parsing Xml today.

I had a ‘descendants’ function which I wanted to be applicable against ‘XDocument’ and ‘XElement’ so I originally just defined the functions separately forgetting that the compiler wouldn’t allow me to do so as we would have a duplicate definition of the function:

let descendants name (xDocument:XDocument) = xDocument.Descendants name
let descendants name (xElement:XElement) = xElement.Descendants name

I wanted to make use of the inline function to define a function which would allow any type which supported the ‘Descendants’ member:

let inline descendants name (xml:^x) =  
    (^x : (member Descendants : XName -> seq<XElement>) (xml))

I couldn’t work out how I could pass the ‘name’ input parameter to ‘Descendants’ so I was getting the following error:

expected 2 expressions, got 1

I posted the problem to StackOverflow and ‘Brian’ pointed out the syntax that would allow me to do what I wanted:

let inline descendants name (xml:^x) =  
	(^x : (member Descendants : XName -> seq<XElement>) (xml,name))

Tomas Petricek pointed out that in this case we could just write a function which took in ‘XContainer’ since both the other two types derive from that anyway:

let descendants name (xml:XContainer) = xml.Descendants name

In this situation that certainly makes more sense but it’s good to know how to write the version using member constraints for any future problems I come across.

Written by Mark Needham

February 15th, 2010 at 12:05 am

Posted in F#

Tagged with

F#: Unexpected identifier in implementation file

without comments

I’ve been playing around with some F# code this evening and one of the bits of code needs to make a HTTP call and return the result.

I wrote this code and then tried to make use of the ‘Async.RunSynchronously’ function to execute the call.

The code I had looked roughly like this:

namespace Twitter
module RetrieveLinks
    open System.Net
    open System.IO
    open System.Web
    open Microsoft.FSharp.Control
    let AsyncHttp (url:string) = async {
        let request =  HttpWebRequest.Create(url)
        let! response = request.AsyncGetResponse()
        let stream = response.GetResponseStream()
        use reader = new StreamReader(stream  )
        return! reader.AsyncReadToEnd() }
    let getData =
        let request = "http://some.url"
        AsyncHttp <| request
	Async.RunSynchronously getData

The problem was I was getting the following error on the last line:

Error	3	Unexpected identifier in implementation file

I’ve seen that error before and it often means that you haven’t imported a reference correctly and hence the compiler doesn’t know what you’re trying to refer to.

In this case I was fairly sure all my references were correct and I was still getting the same error when I used the full namespace to ‘Async.RunSynchronously’ which seemed to suggest I’d done something else wrong.

After comparing this file with another one which was quite similar but didn’t throw this error I realised that I’d left of the ‘=’ after the module definition. Putting that in solved the problem.

namespace Twitter
module RetrieveLinks = 
	// and so on

As I understand it if we don’t use the ‘=’ then we’ve created a top level module declaration and if we do use the ‘=’ then we’ve created a local module declaration.

From MSDN:

You do not have to indent declarations in a top-level module. You do have to indent all declarations in local modules. In a local module declaration, only the declarations that are indented under that module declaration are part of the module.

Given this understanding another way to solve my problem would be to remove the indentation of the functions inside the module like so:

module RetrieveLinks
open System.Net
open System.IO
open System.Web
open Microsoft.FSharp.Control
// and so on until...
Async.RunSynchronously getData

That compiles as expected.

From reading the MSDN page it would suggest that in my first example I’d created a top level module declaration but indenting the code inside that module somehow meant that the ‘Async.RunSynchronously’ function wasn’t recognised.

I don’t quite understand why that is so if anyone can enlighten me that would be cool!

Written by Mark Needham

February 14th, 2010 at 1:03 am

Posted in F#

Tagged with

F#: Inline functions and statically resolved type parameters

without comments

One thing which I’ve often wondered when playing around with F# is that when writing the following function the type of the function is inferred to be ‘int -> int -> int’ rather than allowing any values which can be added together:

let add x y = x + y
> val add : int -> int -> int

It turns out if you use the ‘inline’ keyword then the compiler does exactly what we want:

> let inline add x y = x + y
val inline add : 
	^a -> ^b -> ^c
	when ( ^a or  ^b) : (static member ( + ) :  ^a *  ^b ->  ^c)

Without the inline modifier type inference forces the function to take a specific type, in this case int. With it the function has a statically resolved type parameter which means that “the type parameter is replaced with an actual type at compile time rather than run time”.

In this case it’s useful to us because it allows us to implicitly define a member constraint on the two input parameters to ‘add’. From the MSDN page:

Statically resolved type parameters are primarily useful in conjunction with member constraints, which are constraints that allow you to specify that a type argument must have a particular member or members in order to be used. There is no way to create this kind of constraint by using a regular generic type parameter.

The neat thing about the second definition is that we can add values of any types which support the ‘+’ operator:

add "mark" "needham";;
> val it : string = "markneedham"
> add 1.0 2.0;;
val it : float = 3.0

From a quick look at the IL code in Reflector it looks like the ‘add’ function defined here makes use of the ‘AdditionDynamic‘ function internally to allow it to be this flexible.

One thing which I found quite interesting while reading about inline functions is that it sounds like it’s quite similar to duck typing in that we’re saying a function can be passed any value which supports a particular method.

Michael Giagnocavo has a post where he covers the idea of statically type resolved parameters in more detail and describes what he refers to as ‘statically typed duck typing’.

Written by Mark Needham

February 10th, 2010 at 11:06 pm

Posted in F#

Tagged with

F#: function keyword

with one comment

I’ve been browsing through Chris Smith’s Programming F# book and in the chapter on pattern matching he describes the ‘function’ key word which I haven’t used before.

It’s used in pattern matching expressions when we want to match against one of the parameters passed into the function which contains the pattern match.

For example if we have this somewhat contrived example:

let isEven value = match value with 
                    | x when (x % 2) = 0 -> true
                    | _ -> false

That could be rewritten using the function keyword to the following:

let isEven  = function 
               | x when (x % 2) = 0 -> true
               | _ -> false

It’s a relatively straight forward way to simplify code like this although one thing I noticed while looking back through some old code I’ve written is that if we use this syntax then we need to ensure that the parameter we want to pattern match against is passed as the last parameter to a function.

For example this function which is used to parse the arguments passed to a script was originally written like this:

let GetArgs initialArgs  =
    let rec find args matches =
        match args with
        | hd::_ when hd = "--" -> List.to_array (matches)
        | hd::tl -> find tl (hd::matches) 
        | [] -> Array.empty
    find (List.rev (Array.to_list initialArgs) ) []

If we want to use ‘function’ then we’d need to put ‘args’ implicitly as the second argument passed to the recursive ‘find’ function:

let GetArgs initialArgs  =
    let rec find matches =
        | hd::_ when hd = "--" -> List.to_array (matches)
        | hd::tl -> find (hd::matches) tl
        | [] -> Array.empty
    find [] (List.rev (Array.to_list initialArgs) )

I’m not sure that the resulting code is necessarily more intention revealing if the function has more than one argument passed to it. The second version of this function could be very confusing if you didn’t know what the ‘function’ keyword actually did.

Written by Mark Needham

February 7th, 2010 at 2:54 am

Posted in F#

Tagged with

F#: Refactoring to sequence/for expressions

with 6 comments

Since I started playing around with F# one of the things I’ve been trying to do is not use the ‘for’ keyword because I was trying to avoid writing code in an imperative way and for loops are a big part of this for me.

Having read Jon Harrop’s solution to the word count problem where he made use of both sequence and for expressions I thought it’d be intersting to see what some of the code I’ve written would look like using that approach.

An example of a function that I wrote which could be rewritten the other way is the following:

let delimeters (value:string) = Regex.Matches(value, "\[([^]]*)\]") |> Seq.cast |> 
                       (fun (x:Match) -> x.Groups) |>
                       (fun x -> x |> Seq.cast<Group> |> Seq.nth 1) |>
                       (fun x -> x.Value)

This could be written like this if we used a sequence expression instead of chaining map operations:

let delimeters (value:string) = seq { for m in Regex.Matches(value, "\[([^]]*)\]") do yield m.Groups.Item(0).Value }

One interesting thing I found about writing it like this was that I noticed that ‘GroupCollection’ had the ‘Item’ property on it which would let me get the match much more easily.

I completely missed that when I was writing the first solution so I’m not sure if that was just due to my lack of knowledge of that part of the API or whether the second approach actually encouraged me to explore more and therefore end up with a simpler solution.

Another example I found was this expression for getting the matches for a regular expression:

let regex pattern input = Regex.Matches(input, pattern) |> Seq.cast |> (fun (x:Match) -> x.Value)

That can be simplified to the following with a sequence expression:

let regex pattern input = seq { for m in Regex.Matches(input, pattern) do yield m.Value }

One neat thing about using sequence expressions is that we don’t need to make use of ‘Seq.cast’ to convert a value to a typed sequence – we can just use it as it is.

The following function can be rewritten to just use a for expression:

let writeTo (path:string) (values:seq<string * int>) = 
    use writer = new StreamWriter(path)
    values |> (fun (value, count) -> value + " " + count.ToString()) |> Seq.iter (fun x -> writer.WriteLine(x))

Like so:

let writeTo (path:string) (values:seq<string * int>) = 
    use writer = new StreamWriter(path)
    for (value,count) in values do writer.WriteLine(value + " " + count.ToString())

We eventually iterate through the sequence anyway so I think it’s more intention revealing to just do the iteration and mapping in one step.

This is a function from when I was writing the little Feedburner application:

let calculateWeeklyAverages =
    Seq.reverseSequence >>
    Seq.windowed days >> (fun (entries:array<Entry>) -> 
                (entries.[0]).Date , entries |> (fun e -> e.Circulation |> toDecimal) |> Array.average ) >>

If we use a sequence expression it’d look like this:

let calculateWeeklyAverages entries =
    seq { for (e:array<Entry>) in (entries |> Seq.reverseSequence |> Seq.windowed days) do 
              yield ((e.[0]).Date, entries |> (fun e -> e.Circulation |> toDecimal) |> Array.average) } 
    |> Seq.reverseSequence

The resulting code is shorter but it seems to me like the focus when you read the code has moved to the line which yields the tuple whereas in the first version I find that I read the function as a whole.

I’ve not really used sequence expressions that much so it’s been interesting going through the code and seeing where they might be useful.

I found several places where I’d used lists because I find those easier to pattern match against but I wonder whether it would make sense to use sequences there as well.

Written by Mark Needham

January 14th, 2010 at 8:01 am

Posted in F#

Tagged with