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:

#light
module Strangelights.DemoModule
open System

// returns the hour and minute from the give 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 will need to follow the next example. If you are a Visual Studio user you'll need to create a C# project alongside your F# solution. To do this choose File

Figure 14.1. How to create a new C# project file

Next, you'll 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 Microsoft.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);
        }
}

The results of this example, when compiled and executed, are as follows:

Hour 16 Minute 1

Although the C# in the previous 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.

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 one that exposes this 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 didn't want.

// !!! C# Source !!!
using System;
using System.Collections.Generic;
using Strangelights;
using Microsoft.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);
                }
        }
}

The results of this example, when compiled and executed, are as follows:

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);
                }
        }
}

The results of this example, when compiled and executed, are as follows:

Aurelie

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 your library will expose them (though personally I recommend avoiding exposing them in cross-language scenarios).

For the first example, you will 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. 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.Discrete(12);
                DemoModule.Quantity c = DemoModule.Quantity.Continuous(12.0);
        }
}

Now you know how to create union types from C#, so the next most important task is being able to determine the constructor to which a particular Quantity value belongs. You can do this in three ways. I cover the first two in the next two code examples, and I cover the third at the end of this section.

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, always prefixed with tag_, 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 would usually write a switch statement, as shown in the following example:

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

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

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

The results of this example, when compiled and executed, are as follows:

Discrete value: 65676

If you prefer, the compiled form of the union type also offers a series of methods, all prefixed with Is. This allows you to check whether a value belongs to a particular constructor within the union type. For example, on the Quantity union type, two methods, 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.Discrete1);
                }
                else if (q.IsContinuous()) {
                        Console.WriteLine("Continuous value: {0}", q.Continuous1);
                }
        }
}

The results of this example, when compiled and executed, are as follows:

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 use the Continuous1 property. This would lead to a NullReferenceException being thrown.

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

To give your libraries' users some protection against this, it is a good idea 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.get
RandomEasyQuantity();
                // convert quantity to a float and show it
                Console.WriteLine("Value as a float: {0}", q.ToFloat());
        }
}

It is entirely possibly 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 these 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 yet 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 shown in the following example:

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 Microsoft.FSharp.Core;
using Microsoft.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);
                }
        }
}

The results of this example, when compiled and executed, are as follows:

1
2
3

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 only 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();
        }
}

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. When defining classes, your C# clients will find it easier to use your classes if you use the tuple style.

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#, the member CurriedStyle has the following signature:

public FastFunc<int, int> CurriedStyle(int x)

whereas the TupleStyle will have the following signature:

public int TupleStyle(int x, int y);

If you want to use both methods from C#, you would end up with code that looks like the following:

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

class Program {
        static void UseDemoClass() {
                DemoClass c = new DemoClass(3);
                FastFunc<int, int> ff = c.CurriedStyle(4);
                int result = ff.Invoke(5);
                Console.WriteLine("Curried Style Result {0}", result);
                result = c.TupleStyle(4, 5);
                Console.WriteLine("Tuple Style Result {0}", result);
        }
        static void Main(string[] args) {
                UseDemoClass();
        }
}

It is clear from this sample that users of your library will be much happier if you use the tuple style for the public members of your classes.

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 tupled style
    abstract TupleStyle: (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

Note that the only difference between OneArgStyle and MultiArgStyle is that the latter is not surrounded by parentheses. This small difference in the F# definition has a big effect on the signature as seen from C#. With the former, you see the following signature:

int OneArgStyle(Tuple<int, int>);

whereas the latter is seen as the following signature:

int MultiArgStyle(int, int);

The latter is a good bit friendlier for the C# user. However, you can take it a bit further and add names to each of your parameters. This won't change the signature the C# user will use when implementing the method, but it will change the names they see when using Visual Studio tools to implement the interface. Furthermore, some other .NET languages treat argument names as significant. This may sound like a small difference, but it will make implementing your interface a lot easier, because the implementer will have a much better idea of what the parameters of the method actually mean.

The following example shows the C# for implementing the interface IDemoInterface defined in the previous example. It makes it clear that C# users will be happier with interfaces containing methods specified using either MultiArgStyle or NamedArgStyle.

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

// shows how to implement an interface
// that has been created in F#
class DemoImplementation : IDemoInterface {

// curried style implementation
        public FastFunc<int, int> CurriedStyle(int x) {
                // create a delegate to return
                Converter<int, int> d =
                        delegate(int y) { return x + y; };
                // convert delegate to a FastFunc
                return FuncConvert.ToFastFunc(d);
        }

        // tuple style implementation
        public int TupleStyle(Tuple<int, int> t) {
                return t.Item1 + t.Item2;
        }

        // C# style implementation
        public int CSharpStyle(int x, int y) {
                return x + y;
        }

        // C# style implementation, named arguments
        // make no difference here
        public int CSharpNamedStyle(int x, int y) {
                return x + y;
        }
}