Returning Tuples

First, I’ll talk about why you should avoid tuples. If you return a tuple from your function, you will force the user to reference FSharp.Core.dll. Also, the code needed to use the tuple just doesn’t look that great from C#. Consider the following example where you define the function hourAndMinute that returns the hour and minute from a DateTime structure:

module Strangelights.DemoModule
open System

// returns the hour and minute from the given date as a tuple
let hourAndMinute (time: DateTime) = time.Hour, time.Minute

// returns the hour from the given date
let hour (time: DateTime) = time.Hour
// returns the minutes from the given date
let minute (time: DateTime) = time.Minute

To call this from C#, you need to follow the next example. You need to create a C# project alongside your F# solution. To do this, choose File ➤ Add ➤ New Project, and then choose a C# console project.

Next, you need to add a project reference from the C# project to the F# project. Then add the following C# class to the newly created project:

// !!! C# Source !!!
using System;
using Strangelights;
using FSharp.Core;

static class PrintClass {
        internal static void HourMinute() {
                // call the "hourAndMinute" function and collect the
                // tuple that's returned
                Tuple<int, int> t = DemoModule.hourAndMinute(DateTime.Now);
                // print the tuple's contents
                Console.WriteLine("Hour {0} Minute {1}", t.Item1, t.Item2);
        }
}

This example, when executed, returns the following:

Hour 16 Minute 1

Although the C# in this example isn’t too ugly, it would be better if the function had been split in two, one to return the hour and one to return the minute.

Exposing Functions That Take Functions As Parameters

If you want to expose functions that take other functions as parameters, the best way to do this is using delegates. Consider the following example that defines one function that exposes a function, and another that exposes a function as a delegate:

module Strangelights.DemoModule
open System

/// a function that provides filtering
let filterStringList f ra =
    ra |> Seq.filter f

// another function that provides filtering
let filterStringListDelegate (pred: Predicate<string>) ra =
        let f x = pred.Invoke(x)
        new ResizeArray<string>(ra |> Seq.filter f)

Although the filterStringList is considerably shorter than filterStringListDelegate, the users of your library will appreciate the extra effort you’ve put in to expose the function as a delegate. When you look at using the functions from C#, it’s pretty clear why. The following example demonstrates calling filterStringList. To call your function, you need to create a delegate and then use the FuncConvert class to convert it into a FastFunc, which is the type F# uses to represent function values. As well as being pretty annoying for the user of your library, this also requires a dependency on FSharp.Core.dll that the user probably doesn’t want.

// !!! C# Source !!!
using System;
using System.Collections.Generic;
using Strangelights;
using FSharp.Core;

class MapOneClass {
        public static void MapOne() {
                // define a list of names
                List<string> names = new List<string>(
                        new string[] { "Stefany", "Oussama",
        "Sebastien", "Frederik" });

                // define a predicate delegate/function
                Converter<string, bool> pred =
                        delegate(string s) { return s.StartsWith("S"); };

                // convert to a FastFunc
                FastFunc<string, bool> ff =
                        FuncConvert.ToFastFunc<string, bool>(pred);

                // call the F# demo function
                IEnumerable<string> results =
                         DemoModule.filterStringList(ff, names);

                // write the results to the console
                foreach (var name in results) {
                        Console.WriteLine(name);
                }
        }
}

This example, when executed, returns the following:

Stefany
Sebastien

Now, compare and contrast this to calling the filterStringListDelegate function, shown in the following example. Because you used a delegate, you can use the C# anonymous delegate feature and embed the delegate directly into the function call, reducing the amount of work the library user has to do and removing the compile-time dependency on FSharp.Core.dll.

// !!! C# Source !!!
using System;
using System.Collections.Generic;
using Strangelights;

class MapTwoClass {
        public static void MapTwo() {
                // define a list of names
                List<string> names = new List<string>(
                        new string[] { "Aurelie", "Fabrice",
            "Ibrahima", "Lionel" });

                // call the F# demo function passing in an
                // anonymous delegate
                List<string> results =
                        DemoModule.filterStringListDelegate(
                                delegate(string s) { return s.StartsWith("A"); }, names);

                // write the results to the console
                foreach (var s in results) {
                        Console.WriteLine(s);
                }
        }
}

This example, when executed, returns the following:

Aurelie

Using Union Types

You can use union types from C#, but because C# has no real concept of a union type, they do not look very pretty when used in C# code . In this section, you will examine how you can use them in C# and how you as a library designer can decide whether and how your library will expose them. Personally I recommend avoiding exposing them in cross-language scenarios.

For the first example, you define the simple union type Quantity, which consists of two constructors, one containing an integer and the other a floating-point number. You also provide the function getRandomQuantity() to initialize a new instance of Quantity.

module Strangelights.DemoModule
open System

// type that can represent a discrete or continuous quantity
type Quantity =
| Discrete of int
| Continuous of float

// initalize random number generator
let rand = new Random()
// create a random quantity
let getRandomQuantity() =
    match rand.Next(1) with
    | 0 -> Quantity.Discrete (rand.Next())
    | _ ->
        Quantity.Continuous
            (rand.NextDouble() * float (rand.Next()))

Although you provide getRandomQuantity() to create a new version of the Quantity type, the type itself provides static methods for creating new instances of the different constructors that make up the type. These static methods are available on all union types that are exposed by the assembly by default; you do not have to do anything special to get the compiler to create them. They are named after the DU case, prefixed with the word “New.” The following example shows how to use these methods from C#:

using System;
using Strangelights;

static class GetQuantityZeroClass {
        public static void GetQuantityZero() {
                // initialize both a Discrete and Continuous quantity
                DemoModule.Quantity d = DemoModule.Quantity.NewDiscrete(12);
                DemoModule.Quantity c = DemoModule.Quantity.NewContinuous(12.0);
        }
}

Now you know how to create union types from C#, so the next most important task is being able to determine the case to which a particular Quantity value belongs. You can do this in three ways: using the Tag property, using the Is Case methods, or providing explicit functionality within your F# code.

The first option is that you can switch on the value’s Tag property. This property is just an integer, but the compiled version of the union type provides constants, contained in an inner class called Tags, to help you decode the meaning of the integer. If you want to use the Tag property to find out what kind of Quantity you have, you usually write a switch statement, as shown in the following example. Notice also how you have to cast q to the appropriate DU case in order to access its value in the Item property.

// !!! C# Source !!!
using System;
using Strangelights;

static class GetQuantityOneClass
{
    public static void GetQuantityOne()
    {
        // get a random quantity
        DemoModule.Quantity q = DemoModule.getRandomQuantity();

        // use the .Tags property to switch over the quatity
        switch (q.Tag)
        {
            case DemoModule.Quantity.Tags.Discrete:
                Console.WriteLine("Discrete value: {0}", (q as DemoModule.Quantity.Discrete).Item);
                break;
            case DemoModule.Quantity.Tags.Continuous:
                Console.WriteLine("Continuous value: {0}", (q as DemoModule.Quantity.Continuous).Item);
                break;
        }
    }
}

This example, when executed, returns the following:

Discrete value: 65676

If you prefer, the compiled form of the union type also offers a series of properties , all prefixed with Is. This allows you to check whether a value belongs to a particular case within the union type. For example, on the Quantity union type, two properties, IsDiscrete and IsContinuous, allow you to check whether the Quantity is Discrete or Continuous. The following example demonstrates how to use them:

// !!! C# Source !!!
using System;
using Strangelights;

static class GetQuantityTwoClass
{
    public static void GetQuantityTwo()
    {
        // get a random quantity
        DemoModule.Quantity q = DemoModule.getRandomQuantity();
        // use if … else chain to display value
        if (q.IsDiscrete)
        {
            Console.WriteLine("Discrete value: {0}", (q as DemoModule.Quantity.Discrete).Item);
        }
        else if (q.IsContinuous)
        {
            Console.WriteLine("Continuous value: {0}", (q as DemoModule.Quantity.Continuous).Item);
        }
    }
}

This example, when executed, returns the following:

Discrete value: 2058

Neither option is particularly pleasing because the code required to perform the pattern matching is quite bulky. There is also a risk that the user could get it wrong and write something like the following example where they check whether a value is Discrete and then mistakenly cast to the Continuous case. This would lead to an InvalidCastException being thrown.

DemoModule.EasyQuantity q = DemoModule.getRandomQuantity();
if (q.IsDiscrete) {
    Console.WriteLine("Discrete value: {0}", (q as DemoModule.Quantity.Continuous).Item);
}

To provide the users of your libraries some protection against this, it is a good idea where possible to add members to union types that perform the pattern matching for them. The following example revises the Quantity type to produce EasyQuantity, adding two members to transform the type into an integer or a floating-point number:

module Strangelights.ImprovedModule
open System

// type that can represent a discrete or continuous quantity
// with members to improve interoperability
type EasyQuantity =
| Discrete of int
| Continuous of float
    // convert quantity to a float
    member x.ToFloat() =
        match x with
        | Discrete x -> float x
        | Continuous x -> x
    // convert quantity to a integer
    member x.ToInt() =
        match x with
        | Discrete x -> x
        | Continuous x -> int x

// initalize random number generator
let rand = new Random()

// create a random quantity
let getRandomEasyQuantity() =
    match rand.Next(1) with
    | 0 -> EasyQuantity.Discrete (rand.Next())
    | _ ->
        EasyQuantity.Continuous
            (rand.NextDouble() * float (rand.Next()))

This will allow the user of the library to transform the value into either an integer or a floating-point without having to worry about pattern matching , as shown in the following example:

// !!! C# Source !!!
using System;
using Strangelights;

class GetQuantityThreeClass {
        public static void GetQuantityThree() {
                // get a random quantity
                ImprovedModule.EasyQuantity q = ImprovedModule.getRandomEasyQuantity();
                // convert quantity to a float and show it
                Console.WriteLine("Value as a float: {0}", q.ToFloat());
        }
}

Obviously the applicability of this approach varies, but there is often a sensible behavior that you can define for each case of your discriminated union for the benefit of C# callers.

Using F# Lists

It is entirely possible to use F# lists from C#, but I recommend avoiding this since a little work on your part will make things seem more natural for C# programmers. For example, it is simple to convert a list to an array using the List.toArray function; to a System.Collections.Generic.List using the new ResizeArray<_>() constructor; or to a System.Collections.Generic.IEnumerable using the List.toSeq function. These types are generally a bit easier for C# programmers to work with, especially System.Array and System.Collections.Generic.List, because they provide a lot more member methods. You can do the conversion directly before the list is returned to the calling client, making it entirely feasible to use the F# list type inside your F# code. MSDN recommends using the types Collection or ReadOnlyCollection from the System.Collections.ObjectModel namespace to expose collections. Both of these classes have a constructor that accepts an IEnumerable, and so can be constructed from an F# list.

If you need to return an F# list directly, you can do so as follows:

module Strangelights.DemoModule

// gets a preconstructed list
let getList() =
    [1; 2; 3]

To use this list in C#, you typically use a foreach loop:

using System;
using Strangelights;
using FSharp.Core;
using FSharp.Collections;

class Program {
        static void Main(string[] args) {
                // get the list of integers
                List<int> ints = DemoModule.getList();

                // foreach over the list printing it
                foreach (int i in ints) {
                        Console.WriteLine(i);
                }
        }
}

This example, when executed, returns the following:

1
2
3

Defining Types in a Namespace

If you are defining types that will be used from other .NET languages, then you should place them inside a namespace rather than inside a module. This is because modules are compiled into what C# and other .NET languages consider to be a class, and any types defined within the module become inner classes of that type. Although this does not present a huge problem to C# users, the C# client code does look cleaner if a namespace is used rather than a module. This is because in C# you can open namespaces but not modules using the using statement, so if a type is inside a module, it must always be prefixed with the module name when used from C#.

Let’s take a look at an example of doing this. The following example defines TheClass, which is defined inside a namespace. You also want to provide some functions that go with this class. These can’t be placed directly inside a namespace because values cannot be defined inside a namespace. In this case, you define a module with a related name, such as TheModule, to hold the function values.

namespace Strangelights
open System.Collections.Generic

// this is a counter class
type TheClass(i) =
    let mutable theField = i
    member x.TheField
        with get() = theField
    // increments the counter
    member x.Increment() =
        theField <- theField + 1
    // decrements the count
    member x.Decrement() =
        theField <- theField - 1

// this is a module for working with the TheClass
module TheModule = begin
    // increments a list of TheClass
    let incList (theClasses: List<TheClass>) =
        theClasses |> Seq.iter (fun c -> c.Increment())
    // decrements a list of TheClass
    let decList (theClasses: List<TheClass>) =
        theClasses |> Seq.iter (fun c -> c.Decrement())
end

Using the TheClass class in C# is now straightforward because you do not have to provide a prefix , and you can also get access to the related functions in TheModule easily:

// !!! C# Source !!!
using System;
using System.Collections.Generic;
using Strangelights;

class Program {
        static void UseTheClass() {
                // create a list of classes
                List<TheClass> theClasses = new List<TheClass>() {
                        new TheClass(5),
                        new TheClass(6),
                        new TheClass(7)};

                // increment the list
                TheModule.incList(theClasses);

                // write out each value in the list
                foreach (TheClass c in theClasses) {
                        Console.WriteLine(c.TheField);
                }
        }
        static void Main(string[] args) {
                UseTheClass();
        }
}

Defining Classes and Interfaces

In F# there are two ways you can define parameters for functions and members of classes: the “curried” style where members can be partially applied and the “tuple” style where all members must be given at once. Fortunately, from the point of view of C#, both such styles appear as tuple-style calls.

Consider the following example in which you define a class in F#. Here one member has been defined in the curried style, called CurriedStyle, and the other has been defined in the tuple style, called TupleStyle.

namespace Strangelights

type DemoClass(z: int) =
    // method in the curried style
    member this.CurriedStyle x y = x + y + z
    // method in the tuple style
    member this.TupleStyle (x, y) = x + y + z

When viewed from C#, both methods appear in standard C# style (i.e. with the parameters bracketed together):

public int TupleStyle(int x, int y);
public int CurriedStyle(int x, int y);

Specifying abstract members in interfaces and classes is slightly more complicated because you have a few more options. The following example demonstrates this:

namespace Strangelights

type IDemoInterface =
    // method in the curried style
    abstract CurriedStyle: int -> int -> int
    // method in the C# style
    abstract CSharpStyle: int * int -> int
    // method in the C# style with named arguments
    abstract CSharpNamedStyle: x : int * y : int -> int
    // method in the tupled style
    abstract TupleStyle: (int * int) -> int

When you implement these members in C#, the subtle differences between the implementations become apparent:

class CSharpClass : Strangelights.IDemoInterface
{
    public int CurriedStyle(int value1, int value2)
    {
        return value1 + value2;
    }

    public int CSharpStyle(int value1, int value2)
    {
        return value1 + value2;
    }

    public int CSharpNamedStyle(int x, int y)
    {
        return x + y;
    }

    public int TupleStyle(Tuple<int, int> value)
    {
        return value.Item1 + value.Item2;
    }
}

Note that the difference between C# style and curried style is disguised by the F# compiler, so you can call from C# in the same way in these two cases. C# named style is the most caller-friendly because the IDE can know the names of the interface parameters and hence can name the arguments meaningfully when generating code. Tuple style, where you explicitly require that the caller used an F# tuple at the call site, is the least caller-friendly.