26 August 2012

FsCheck 0.8.3 and FsCheck.Xunit 0.3

I’ve just uploaded new NuGet packages for FsCheck and FsCheck.Xunit.

The changes are minor:

  • FsCheck.Xunit now works with instance methods. NCrunch, for example, reportedly only works with instance methods, so this means you can now use NCrunch for running FsCheck properties.
  • Both NuGet packages now call Add-BindingRedirect on install. This will generate an app.config file in your test project if necessary, to spell out to the .NET loader that tests compiled with F#3.0 and so in all likelihood using FSharp.Core 4.3 should indeed use 4.3 instead of the older 4.0, which FsCheck is compiled with.
  • Added symbols on symbolsource.org.

Note that running “Add-BindingRedirect <project name>” in the NuGet package manager console should resolve any problems you may have running FsCheck in VS2012. Also, since xunit is strongly signed, there are similar problems with FsCheck.Xunit – Add-BindingRedirect solves that one too.

If you’re not into NuGet, add the following lines to your app.config file:

<?xml version="1.0" encoding="utf-8"?>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="" newVersion="" />
Technorati Tags: ,,
Share this post : MSDN! Technet! Del.icio.us! Digg! Dotnetkicks! Reddit! Technorati!

26 June 2012

FsCheck 0.8.1: The ecosystem release

Yesterday I’ve released a new version of FsCheck. There are some minor changes, additions and bug fixes to FsCheck itself. The most important part of this release is that FsCheck is now integrated with Xunit through the new FsCheck.Xunit assembly.

For the impatient: NuGet packages for FsCheck and FsCheck.Xunit

Here goes a more detailed overview.

Generators are now applicative. Or, without the general abstract nonsense: say you’ve got three generators

let ga,gb,gc :Gen<_> * Gen<_> * Gen<_>

And you have a function of three arguments that you’d like to map over those.

let f = fun a b c ->

No problem, you can use Gen.map3 – right? But how many instances of map do you need? FsCheck currently defines 6. But now that Gen is applicative, we can write:

let result = f <!> ga <*> gb <*> gc

Hey, doesn’t that almost read like function application? That’s the idea. The weird operators in between just make sure everything is applied properly. Besides being a bit nicer to use sometimes, you can also keep chaining this indefinitely, up to any arity.

And hey, if you still prefer map, FsCheck still has those.

New generators. Mauricio Scheffer contributed int64 and TimeSpan generators. I’ve also added an int16 generator, and DontSize wrappers for all of those – the default generators for int16, 32 and 64 will generate integers smaller than the test size, which is increased by FsCheck as the test progresses. The DontSize variants ignore the size and always pick from the whole range for the type.

Xunit integration. Xunit is a very nice framework – very simple to use and extend. FsCheck integrates with Xunit by adding a PropertyAtttribute. To use it, just use Property instead of Fact, and you can now give your test arguments. These are randomly generated by FsCheck. You can also use all of the normal property combinators in the Prop namespace. A couple of examples:

let ``abs(v) % k equals abs(v % k)`` v (NonZeroInt k) = 
    (abs v) % k = abs(v % k)
let ``divMod should satisfy definition`` (x:int) (y:int) = 
    y <> 0 ==> lazy (let (d,m) = divMod x y in d*y + m = x)

Note that Property test methods, as opposed to Fact, don’t need to return unit – they can return anything that’s testable with FsCheck, including bool. But since a test fails in FsCheck when it throws an exception, you can still use the Assert class if you like. You can also use FsUnit or Unquote or whatever to write your assertions. FsCheck does not care – it does the hard work of generating random values and shrinking them if the test fails and generally tries to get out of your way for the rest.

You can also set various configuration parameters using the Property attribute, which then apply to that method only. Most of these are trivial (e.g. the number of tests), but an interesting one is that you can override the random generation for certain types on one test method only:

type TestArbitrary1 =
    static member PositiveDouble() =
        |> Arb.mapFilter abs (fun t -> t >= 0.0)

[<Property( Arbitrary=[| typeof<TestArbitrary1> |] )>]
let ``should register Arbitrary instances from Config in last to first order``(underTest:float) =
    underTest >= 0.0

Here the generator for float is overridden to generate only positive floats.

Finally, a special thanks to @mausch for contributing, integrating FsCheck with Fuchu, and giving me a gentle nudge to get this release out the door at last!

Technorati Tags: ,,
Share this post : MSDN! Technet! Del.icio.us! Digg! Dotnetkicks! Reddit! Technorati!

26 May 2012

Accessibility modifiers on F# record types

In the note to self category.

type internal Internal = { Si : string }

means that the class Internal will be internal. The constructor and properties are technically public, but that is meaningless since the enclosing class is internal. However, if the Internal type implements public interfaces, then the public methods it implements are visible and usable by clients outside the assembly (provided they get hold of an instance, of course – they can’t construct one since they can’t see the name of the class).

type IGet = abstract Get : string

type internal Internal = 
    { Si : string }
    interface IGet with
        member x.Get = x.Si

If an instance gets out as an obj, clients can still call HashCode and Equals because those are exposed as public overrides from obj or as public interfaces, e.g. IComparable.

type Internal = internal { Si : string }

means that the class Internal is public, but the constructor and properties are internal.

Both can be combined, and private of course works too. Similar accessibility modifiers can be given to discriminated unions – it is not possible to give a different accessibility to individual union cases, just like it isn’t possible to give different modifiers to different fields of a record.

Share this post :

07 May 2012

Making F# reflection faster

I don’t really believe I’m the first one to do this, but I couldn’t find anything that’s publically available. If you know about a mature implementation, please leave a comment!

I put up some code on https://bitbucket.org/kurt/fsreflect/wiki/Home that has a small API, mirroring FSharpValue’s PreComputeXXX reflective construction and deconstruction methods for unions and records. It does the exact same thing as the original methods, only faster.

As explained on the project page, the code uses two techniques. The first is on-the-fly IL code generation using DynamicMethod. This is used for the fast record and union construction code. The second is using delegates instead of MethodInfo.Invoke for the record and union readers, using a great trick introduced by Jon Skeet. The former is explained in a lot of places – the latter is explained perfectly by Mr Skeet already.

Anyway the code is pretty short and sweet, so if you’re interested please do have a browse.

Here are some gratuitous micro-benchmarks.

> repeat (fun i -> fastRecordCtor [| "2"; i; 3. |] :?> MyRecord)
Real: 00:00:00.198, CPU: 00:00:00.202, GC gen0: 73, gen1: 2, gen2: 1
val it : unit = ()
> repeat (fun i -> standardRecordCtor [| "2"; i; 3. |] :?> MyRecord) 
Real: 00:00:02.811, CPU: 00:00:02.808, GC gen0: 115, gen1: 0, gen2: 0
val it : unit = ()
> repeat (fun i -> fastUnionCtor [| "3"; i |] :?> MyUnion) 
Real: 00:00:00.150, CPU: 00:00:00.156, GC gen0: 50, gen1: 0, gen2: 0
val it : unit = ()
> repeat (fun i -> standardUnionCtor [| "3"; i |] :?> MyUnion) 
Real: 00:00:02.551, CPU: 00:00:02.542, GC gen0: 72, gen1: 0, gen2: 0
val it : unit = ()
> repeat (fun i -> fastRecordReader { S = "2"; i = i; f = 3.0 }) 
Real: 00:00:00.209, CPU: 00:00:00.218, GC gen0: 76, gen1: 0, gen2: 0
val it : unit = ()
> repeat (fun i -> standardRecordReader { S = "2"; i = i; f = 3.0 }) 
Real: 00:00:05.390, CPU: 00:00:05.397, GC gen0: 77, gen1: 1, gen2: 0
val it : unit = ()
> repeat (fun i -> fastUnionReader (Two ("s",i))) 
Real: 00:00:00.160, CPU: 00:00:00.171, GC gen0: 50, gen1: 0, gen2: 0
val it : unit = ()
> repeat (fun i -> standardUnionReader (Two ("s",i))) 
Real: 00:00:03.477, CPU: 00:00:03.478, GC gen0: 49, gen1: 0, gen2: 0
val it : unit = ()
Technorati Tags: ,,
Share this post : MSDN! Technet! Del.icio.us! Digg! Dotnetkicks! Reddit! Technorati!

04 January 2012

API design: Record types and backwards compatibility

If you’re designing an API in F#, be very careful when exposing any of the public types as record types. Record types, as they stand in F# 2.0, by default are impossible to change while keeping backwards binary compatibility.

Let’s look at a couple of changes that you might want to make to a record type:

  • Adding a new field.
  • Changing the type of a field.
  • Changing the order of the fields.

None of these changes are backwards compatible. A record type is compiled by F# to a normal .NET class, with a constructor that takes the fields as arguments. This means order of the fields matters, and also the number and types of fields of course. Accessing the record fields is accomplished through a getter for each of the fields. So if your clients are using a very limited usage pattern – basically only accessing an existing record type using a getter – you may be alright with 1 and 3, and even 2 if they don’t happen to access the particular field whose type you’re changing. Anything else, including with syntax, is a no-no.

To make this abundantly clear – a record type definition and usage:

type MyRecord =
    { Field : int
      SecondField : string }

let instance = { Field = 3; SecondField = "3" }

Is translated by the F# compiler to:

type MyRecordTranslated(field:int,secondfield:string) =
    member this.Field = field
    member this.SecondField = secondfield

let instanceTranslated = new MyRecordTranslated(3,"3")

Now in the translated case, it’s intuitively clear that changing the order of the arguments in the constructor is not backwards compatible. With the record syntax however, the F# syntax makes the record type look like a bag of fields. However, the compiler looks up the one and only constructor for the type, and explicitly calls that. So, if you change the constructor in any way, clients are going to fail at runtime if they are not recompiled first.

Two solutions (sort of)

The first solution is not to use record types as part of a public API that needs to be backwards compatible – use class types instead.

If record types are still handy, say because they have automatic value-based comparison and equality, then with some planning you can still use them – but to your clients they won’t look much like record types anymore, because we’re going to prevent clients from accessing the constructor and getters (unfortunately there’s no way to set accessibility on those two separately). And there is a lot of tedious code involved. Here’s an example – here’s the first version of a “record type” that can be kept backwards compatible:

module A_v0 =
    type MyRecord =
        internal { _Field : int } with
        static member Create(field:int) = { _Field = field }
        member this.Field = this._Field
        member this.With(?Field:int) = { this with _Field = defaultArg Field this.Field }  

Note that the most important change is that we made the constructor internal (private does not make much sense, as everything in the assembly of the record type itself should be trivial to update in concert with any change to the record type). To create the record type from outside of the assembly there is the factory method ‘Create’. Note that using F# method call syntax, we can still make this look much like a record type: ‘MyRecord.Create(field=3)’ for example.

Then we need to provide a getter for each field ourselves (because we’ve made them internal...). I’ve chosen to start the actual field names with an underscore above, just to allow the explicit getters.

Finally, using optional fields, we can regain some sort of with syntax. Here’s an example of usage:

let a = A_v0.MyRecord.Create(2).With(Field = 3).Field

Now, suppose we want to add a new field. We can do that as follows, without breaking any clients:

module A_v1 =
    type MyRecord =
        internal { _Field : int 
                   _Foo   : string } with
        static member Create(field:int) = { _Field = field; _Foo = "default" }
        static member Create(field:int,foo:string) = { _Field = field; _Foo = foo }
        member this.Field = this._Field
        member this.Foo = this._Foo
        member this.With(?Field:int) = { this with _Field = defaultArg Field this.Field }                                   
        member this.With(?Field:int,?Foo:string) = { this with _Field = defaultArg Field this.Field
                                                               _Foo = defaultArg Foo this.Foo }

Note how we can now use overloading of both Create and With to our advantage.

In this way, we prevent clients from using the record constructor directly, but pay the cost of re-implementing most of the useful functionality for record types ourselves. It’s not much less work than basically doing the same with a class type.

Can F# v_next solve this?

The  problem is that the syntax is deceiving: it looks like the order of arguments does not matter – both in the definition syntax, and in construction syntax. Also, if you use ‘with’ it looks like the call is resilient to adding a new field. And in fact, it is as long as you recompile – which makes the problem worse in some sense as a programmer will see her intuitions confirmed with every compilation.

Given that the syntax is pretty much set in stone at this point, I don’t see a good way around it. If you want to keep the illusion of order-independence of the fields, one thing to do is make the compiler generate some kind of discovery phase at runtime, which would incur an unreasonable performance cost. Another approach would be to have Set method per field that returns a new record instance, and make the constructor private – but then setting many fields would involve as many object creations – again unreasonable for performance reasons.

In fact, I don’t think this is such a big problem at all, as 95% of users will probably not encounter it, and for them the abstraction is valid. What v next could address though, is a way for the other 5% to control backwards compatibility of record types better.

A first idea would be to allow the declaration of “optional fields”, and compile those as overloaded constructors – say you could write:

type MyRecord =
    { Field : int
      SecondField : string
      ?OptionalField = 5 }

which would be compiled to:

type MyRecordTranslated(field:int,secondfield:string, optionalField:int) =
        new(field:int,secondfield:string) = MyRecordTranslated(field,secondfield, 5)
        member this.Field = field
        member this.SecondField = secondfield
        member this.OptionalField = optionalField

I.e. make an overloaded constructor per optional field, and the F# compiler can enforce that optional fields should always be last in the definition. This shouldn’t be too much of a surprise, as the same restriction holds for optional arguments, and also helps somewhat to counter the wrong intuition that order of record fields does not matter. This would at least allow people to add new optional fields without breaking backwards compatibility.

Another option is to explicitly allow overloaded constructors – similar to the implicit class definition syntax, it could be enforced that all the overloads call into the same constructor. Syntax may be a bit of a pain, but I’m sure something can be worked out.

Finally, it would be good to be able to control the visibility of the constructor and the getters separately. In fact it would be nice for other reasons too to control accessibility of the getter for each field separately anyway. internal/private could be allowed in front of the field definitions to control visibility of the getter, while the visibility in front of the curly brace, as now, would only influence visibility of the constructor.

In retrospect, I think there’s something to be said for having the compiler emit a warning or even error when constructing a record type with the fields in a different order from the record type definition, if only to counter the wrong intuition.

I believe the best option here is the second one, allowing overloaded constructors. 3 and 4 are not backwards compatible as far as the F# compiler is concerned, and although the optional fields are nice, this is probably best left as some syntactic sugar over real overloaded constructors as the latter are more flexible.


Binary compatibility may not be a big issue for you. It’s certainly not an issue if you don’t expose any programmatic API as part of your F# projects. In that case, live happily ever after.

On the other hand, you may want to think about giving yourself some flexibility in keeping your API backwards compatible. In that case, hopefully this post has given you some tools to come up with an appropriate strategy. Note that if you can reasonably expect that your clients will recompile whenever you release a new version, the whole problem is moot too.

Overall many F# programmers don’t need to consider this at all. However it deserves a bit more attention than it’s getting, and might catch some people unaware (it certainly caught me out at some point...).

Share this post : MSDN! Technet! Del.icio.us! Digg! Dotnetkicks! Reddit! Technorati!