F# and Swift

I’m looking at Apple’s Swift language and it’s interesting to see how similar it is to F# (which itself is similar to Scala and Haskell). I think this is all in reaction to the trouble we’re having in general with pure object-oriented programming and the advantages of a functional (or at least hybrid) approach in the age of distributed systems.

Value declaration

This is some F# for assigning variables:

let someConstant = 10
let mutable someVariable = 1.23
let specifyTypeExplicitly : String = "blah"

and in Swift:

let someConstant = 10 
var someVariable = 1.23
var specifyTypeExplicitly : Double = "blah"

let mutable for var, otherwise the same. Types are generally inferred but can be set explicitly.

Both languages have tuples and dictionaries assigned in basically the same way.

Pattern matching

Instead of F#’s match, Swift puts its matching inside a traditional switch statement.

//let rgba = ( 1.0, 1.0, 1.0, 1.0 ) "white"
//let rgba = ( 0.4, 0.4, 0.4, 1.0 ) "gray"
//let rgba = ( 0.0, 0.6, 0.8, 1.0 ) "blue is 0.8"
let rgba = ( 0.0, 0.6, 0.8, 1.0 )
switch rgba {
case ( 1.0, 1.0, 1.0, 1.0 ):
    print( "white" )
case let ( r, g, b, 1.0) where r==g && g==b:
case (0.0, 0.5...1.0, let b, _):
    print("blue is \(b)")

In F#, this would be something like (this is from memory):

//let rgba = ( 1.0, 1.0, 1.0, 1.0 ) "white"
//let rgba = ( 0.4, 0.4, 0.4, 1.0 ) "gray"
//let rgba = ( 0.0, 0.6, 0.8, 1.0 ) "blue is 0.800000"
let rgba = ( 0.0, 0.6, 0.8, 1.0 )
match rgba with
| ( 1.0, 1.0, 1.0, 1.0 ) ->
    printfn "white"
| ( r, g, b, 1.0 ) when ( r = g ) && ( g = b ) ->
    printfn "gray"
| ( 0.0, g, b, _ ) when ( g >= 0.5 ) && ( g <= 1.0 ) ->
    printfn "blue is %f" b 
| _ -> ()

Some and None

Swift and F# both support the Some and None keywords for optional values. e.g.

var x : Int? = nil
switch x {
case .Some( let value ):
    print("x has a value")
case .None:

In F#:

let x : int option = None
match x with
| Some(value) ->
    printfn "x has a value"
| None ->
    printfn "x is nil"


In my first look at the language, currying doesn’t seem quite as nice.
Here’s some F#:

let add a b = a + b
let add2 = add 2
let result = add2 3 // 5

In Swift (in the tersest way I know how at present) :

let add : (Int,Int) -> Int = { $0 + $1 }
let add2 = { add( 2, $0 ) }
let result = add2( 3 ) // 5

Another way (according to this) is to make the add function return a function like in the example below, but then doing a call to the initial function does not look like a standard function call:

func add (a:Int)(_ b:Int)-> Int {
    return a + b
add(2)(3) // not add(2,3) // 5
let add2 = add(2)
add2(3) // 5


This is a very shallow comparison. I just thought it was interesting.

F#, WPF, and Prism

I recently attempted to use F# to create a WPF project using the Prism MVVM library.  The project, if you want to download it or look at the code, is at https://github.com/mkb137/FSharpAndPrism.

Creating a WPF Application in F#

This isn’t too hard.  There’s no option to create an F# WPF application by default, but if you create an F# Console Application and then, in the project settings, flip it over to “Windows Application” it will run like one.

To get the WPF libraries, you have to add these references:
* PresentationCore
* PresentationFramework
* UIAutomationClient
* UIAutomationTypes
* WindowsBase
* System.Xaml

I used the FsXaml project to create usable F# types from WPF XAML files.
You can add vanilla XAML files, like App.xaml, with no backing class and then convert them to F# types via:

type App = XAML<"App.xaml", true>

Two things to be aware of:
1. All XAML files must be compiled as “Resource” (the default is None)
2. Visual Studio LIES.  As you may know, in F# the order of the files in solutions matter.  In F# projects, Visual Studio gives you “move up” and “move down” functions to put the files in order.  But once you start adding XAML files, all bets are off.  If you find the solution mysteriously failing to find libraries that it should, open your .fsproj file in a text editor and have a look at the included file order.  You may need to order it manually.

Adding Prism

I used the UnityBootstrapper, which in F# looks like this:

type Bootstrapper() =
    inherit UnityBootstrapper()
    override this.CreateShell() = 
        WindowUtils.loadComponent "/FSharpAndPrism;component/Shell.xaml"
    override this.InitializeShell() =
        Application.Current.MainWindow <- ( this.Shell :?> Window )
    override this.ConfigureContainer() =
        this.Container.LoadConfiguration() |> ignore
        this.Container.RegisterInstance( this.Container ) |> ignore
    override this.ConfigureModuleCatalog() =
        let moduleCatalog = this.ModuleCatalog :?> ModuleCatalog
        moduleCatalog.AddModule typedefof<AlphaModule> |> ignore

That WindowUtils.loadComponent is just a utility function to load the XAML resource:

module WindowUtils =
    let loadComponent( path ) =
    let resourceLocator = new Uri( path, UriKind.Relative )
    Application.LoadComponent( resourceLocator ) :?> DependencyObject

So I create a Shell with a MainRegion region…

    Title="F# Prism Demo" Height="150" Width="500"
    <StackPanel Orientation="Vertical">
        <Label Content="View Goes Here:"/>
        <ContentControl prism:RegionManager.RegionName="{x:Static infrastructure:RegionNames.MainRegion}"/>

And I create a view…

    <StackPanel Orientation="Horizontal">
        <Label>This is my view - Data context = </Label>
        <Label Content="{Binding}"/>

Register it as an F# type…

type MyView = XAML<"MyView.xaml",true>

And define a module that registers it with the region:

type AlphaModule( regionManager : IRegionManager, container : IUnityContainer ) =
    interface IModule with
        member this.Initialize() =
            regionManager.RegisterViewWithRegion( RegionNames.MainRegion, typedefof<MyView> ) |> ignore

And the result is… It doesn’t work.  The application runs but my view is not being loaded into the region.  Why?  Actually, with a little digging I find that the view is being loaded, it’s just not rendering.


FsXaml, Prism, and Unity

Problem #1 – Extra Constructor

As it turns out, when FsXaml creates a type derived from UserControl, in addition to UserControl’s void UserControl() constructor, FsXaml is adding a hidden void UserControl(FrameworkElement) constructor.  If the default configuration is not overridden, Unity will use this constructor when resolving the component and the type created with this constructor will not render itself correctly.  A simple but tedious way around this problem is to, for each view, register it with Unity so that the constructor taking no parameters is used.

container.RegisterType<MyView>( new InjectionConstructor() ) |> ignore


Problem #2 – Adding a data context

Prism Views aren’t that useful with out their ViewModel data contexts and those are usually passed in the constructor.  So the first thing we want to do is subclass our the type that FsXaml created and add our own constructor.  This, by the way, solves our Unity problem as well since our subclassed type won’t have the bogus constructor that FsXaml is creating.
Here’s a basic view model type:

type MyViewModel() =
    let mutable name: string = null
    member this.Name
        with public get() = name
        and public set value = name <- value

Here’s our subclassed view (where the original has been renamed with a tick):

type MyView' = XAML<"MyView.xaml",true>

type MyView() =
    inherit MyView'()
    new( viewModel : MyViewModel ) as this =
            this.DataContext <- viewModel

and… we have a problem.  By default, FsXaml derived types are sealed.  There’s no real reason for this other than that FsXaml is using a type provider from the fsprojects/FSharp.TypeProviders.StarterPack and it creates types as sealed for, I suppose, educational purposes.  If the “Sealed” attribute is removed from the created type it works fine.  I submitted a pull request to FsXaml who asked me to submit it upstream to FSharp.TypeProviders.StarterPack.  I submitted it a moment ago and haven’t heard back yet.  Until then, a “fixed” FsXaml implementation is at mkb137/FsXaml

Using the modified FsXaml library, it works and we have our view loaded with its data context:


Final Problem: FSC: error FS2024: Static linking may not use assembly that targets different profile.

A normal WPF project is compiled against the .NET 4.5 profile which is known internally as Profile7 (see a list of PCL profiles here.  If you attempt to directly use any third-party library that is compiled not just for .NET 4.5, but for .NET 4.5 and Windows Phone (e.g. Profile78), you’ll get the error that you would never see in the same C# project:

FSC: error FS2024: Static linking may not use assembly that targets different profile.

And there’s no way around it as far as I know.  The bug has been logged here on F#’s current home on GitHub, and not yet fixed.

Functional programming with F#

In an episode of the .NET Rocks podcast, guest Bryan Hunter describes his experience analyzing a large object-oriented code base. It’s a good listen. The problems with it were the same problems you see with all large O-O code bases, he says. But one module was a complete surprise because…there were no problems. The application had zero downtime in 4 years of operation. The team was even able to do “hot loading” to deploy updates while the application was running. What was the difference? This module was written in Erlang, a functional language.

The life of a software engineer - cartoon
Life of a software engineer. I believe the original source is http://www.bonkersworld.net/building-software/

Whenever you build an enterprise-scale project, you will find yourself using a bare minimum of libraries and patterns such that despite your best intentions – or even because of your best intentions – your solution will be complex and tricky to maintain from moment one. It’s a terrible life we lead where following best practices feels bad and wrong. Functional programming may be the answer.

I’ve begun to learn .NET’s own functional programming language, F#. I wouldn’t call the language mainstream, but it’s not a toy, either. It’s completely compatible with the rest of the .NET class library so one can make WPF or ASP.NET MVC applications with it. I hope that it will one day lead to a more satisfying experience developing enterprise applications.

Some F# learning resources: