jaredpar's WebLog : Type Inference

Making F# type inference friendly for C#

Jared Parsons — Tue, 15 Dec 2009 19:53:08 GMT

One of my current hobby projects, VsVim, requires me to make a lot of calls between F# and C# projects. The core Vim engine is a pure F# solution based on Visual Studio’s new editor. It additionally has a small hosting layer and a large test bed both written in C#.

When working with the exposed core Vim engine API, I’ve found a number of generated F# constructs which are not easily accessible from C#. The problem stems from the manner in which native F# types are exposed. Many of them are generic and lack type inference friendly helper methods that force awkward usage patterns in C#. Most painful is the FSharpOption<T> type because it’s a type I frequently expose in APIs.

FSharpOption<T> is the exposed type for the native F# option construct representing a value which may or may not be present. It’s similar to C#’s nullable type except that it applies to all types of values. The primary operations you want to do with an FSharpOption<T> are

Create an option with a value
Create an option without a value
Determine if it has a value
Determine if it does not have a value
Access the value

In F# using an option is an inherent part of the language and the hence the resulting code is very elegant.

let OptionExample = 
    let optionWithValue = Some(42)
    let optionWithoutValue = None
    let isSome = Option.isSome optionWithValue
    let isNone = Option.isNone optionWithoutValue
    Option.get optionWithValue

Unfortunately the equivalent C# code is not nearly so nice.

static int OptionExample() {
    var optionWithValue = new FSharpOption<int>(42);
    var optionWithoutValue = FSharpOption<int>.None;
    var isSome = FSharpOption<int>.get_IsSome(optionWithValue);
    var isNone = FSharpOption<int>.get_IsNone(optionWithValue);
    return optionWithValue.Value;
}

Too many explicit types!!! Using any explicit type with F# related code just feels wrong.

In C#, and most other .Net languages, 4 out of the 5 operations you want to do on FSharpOption require an explicit type parameter. This resulting code is a bit tedious with a simple type like int but once you get to more complex generics it can get extremely verbose. In the case of anonymous types, it’s simply not possible to use the FSharpOption<T> without a few wrappers.

Luckily most of these can be solved by using the familiar pattern of using a non-generic class with static generic methods. These allow C# users to take advantage of the languages type inference capabilities to reduce the verbosity of the code.

public static class FSharpOption {
    public static FSharpOption<T> Create<T>(T value) {
        return new FSharpOption<T>(value);
    }
    public static bool IsSome<T>(this FSharpOption<T> opt) {
        return FSharpOption<T>.get_IsSome(opt);
    }
    public static bool IsNone<T>(this FSharpOption<T> opt) {
        return FSharpOption<T>.get_IsNone(opt);
    }
}

Now we can rewrite the original sample a bit cleaner

static int OptionExample() {
    var optionWithValue = FSharpOption.Create(42);
    var optionWithoutValue = FSharpOption<int>.None;
    var isSome = optionWithValue.IsSome();
    var isNone = optionWithoutValue.IsNone();
    return optionWithValue.Value;
}

Notice we still haven’t fixed the None case. Fixing this is a beyond the scope of what I want to write here but it is possible in certain scenarios. You can take a look at how in one of my previous blog articles: Function C# Providing an Option.

This pattern is not just limited to the FSharpOption class but can be applied to many of the generic constructs F# exports to wrap their native types. In particular FSharpFunc<T,Result> and the various FSharpChoice<> types can be made a bit friendlier with a few wrappers.

Using F# Discriminated Unions in C# (Beta2)

Jared Parsons — Tue, 27 Oct 2009 12:00:00 GMT

While updating my VsVim editor extensions for Beta2 [1] I got hit by a change in the way F# exposed discriminated unions in metadata. My extension consists of a core F# component with a corresponding set of unit tests written in C#. It’s mostly API level testing and as such I use a lot of F# generated types in my C# test assembly.

In Beta1 all information which could be extracted from a discriminated type union was immediately available on the value. The underlying type presentation was less than desirable but these details were hidden by type inference and the very accessible API. The type wasn’t perfect because given a particular instance only the subset of the properties relevant to the union value type were valid. All others threw exceptions. But the code use of these methods and properties flowed very well.

For instance take the following F# definition

type ActionKind =
    | Mouse = 1
    | Keyboard = 2

type ActionResult =
    | Complete of (ActionKind * int)
    | Error of string
    | NeedMore of (char -> ActionResult)

The use case in C# was quite simple

[TestMethod]
public void TestActionBeta1(){
    var res = GetResult();
    Assert.IsTrue(res.IsComplete());
    Assert.AreEqual(ActionKind.Mouse, res.Complete1.Item1);
    Assert.AreEqual(42, res.Complete1.Item2);
}

Notice how no type information is necessary and the code flows quite naturally. C# type inference works great here and allows me to do what I need to do without fussing around with little stuff. The type in this case is a detail I don’t need to know about. It simply adds no value.

Discriminated Unions in Beta2 changed substantially in this area. Instead of generating the set of all values on the exposed type, there is now an inner type generated for every discriminated union value and the properties relevant to that union value are stored on the inner type. The outer type now contains only properties to determine which type of value it is (certainly an upgrade from methods!) [2]

For instance in the case of ActionResult there are 3 generated inner classes: Complete, Error and NeedMore. Each one contains a single property Item which contains the associated value(s). This means to get to the value portion a cast to the inner type must be inserted!

Lets take a a look at how the above test code has to change to deal with the Beta2 generation of ActionResult.

[TestMethod]
public void TestActionBeta2() {
    var res = GetResult();
    Assert.IsTrue(res.IsComplete);
    Assert.AreEqual(ActionKind.Mouse, ((ActionResult.Complete)res).Item.Item1);
    Assert.AreEqual(42, ((ActionResult.Complete)res).Item.Item2);
}

Notice the explicit casts which must be added to access the values. This makes it impossible to rely soley on C# type inference. I must now understand the underlying type structure of discriminated unions in order to use them. This extra cast adds no real value to my code.

My C# test assembly has literally hundreds of test cases which use this pattern on F# types. I didn’t know the return type of every method and found myself hitting “Goto Def” on a lot of “var” instances to discover the static type, going back to the original file and inserting the cast. It was a tedious and slow process.

Eventually I settled on a different solution. For every type I exposed in F# I added a set of extension methods in the form of AsXXX where XXX represented the name of the generated inner types. For example

public static ActionResult.Complete AsComplete(this ActionResult res) {
    return (ActionResult.Complete)res;
}

The advantage of this approach is 2 fold

Removes the need to explicitly name types in code and hence gets back the advantages of type inference
I can now use . on any of the values and let Intellisense help me find the appropriate method to use

This extension method allows me to get closer to the Beta1 style code

[TestMethod]
public void TestActionBeta2() {
    var res = GetResult();
    Assert.IsTrue(res.IsComplete);
    Assert.AreEqual(ActionKind.Mouse, res.AsComplete().Item.Item1);
    Assert.AreEqual(42, res.AsComplete().Item.Item2);
}

With these methods and a quick series of Find / Replace calls, I was back in business.

[1] It’s coming I promise!

[2] It also contains a handy set of factory methods for generating values but it’s not relevant to this discussion.

When to use Type Inference

Jared Parsons — Tue, 09 Sep 2008 15:00:10 GMT

Occasionally the debate will come as to when it's OK to use type inference in order to declare a variable. There appear to be three groups in this debate.

Whenever it's possible
Only when it's absolutely clear what the type is
Never, type inference is evil

I fall into camp #1 and here are my reasons

It does not reduce type safety. This doesn't allow for any late binding, type unsafe functions or the like. It simply lets the compiler chose the type for you.
It will actually increase type safety in your code. The best example of this is the foreach statement on non-generic IEnumerable instances. These foreach statements are all technically unsafe because the compiler must do a cast of the Current member under the hood. This declaration looks no different than the type safe generic version of IEnumerable. Using var will force you to write an explicit cast.

foreach (SomeType cur in col)

foreach ( var cur in col.Cast<SomeType>())

Maintains the principles of DRY. This is mostly true for cases where you have an explicit constructor on the RHS.
For some types, this is a requirement in order to use the type (anonymous types for instance). I'm a big fan of consistency and since I must have some instances use type inference, I'd like to use them everywhere.
Makes refactoring easier. I re-factor, a lot. I constantly split up or rename types. Often in such a way that refactoring tools don't fixup all of the problems. With var declarations I don't have to worry because they just properly infer their new type and happily chug along. For explicit type cases I have to manually update all of the type names.
Less typing with no loss of functionality.

The best argument I've heard against type inference is that it reduces readability since you can't look at a variable and know it's type. True, but just hover over the declaration and the IDE will display the type. Yes this is not possible with a non-IDE editor but how often do you use one?

Switching on Types

Jared Parsons — Fri, 16 May 2008 15:00:00 GMT

One action I find frustrating in C# is where a particular action needs to be taken based off of the type of a particular object. Ideally I would like to solve this with a switch statement but switch statements only support constant expressions in C# so no luck there. Previously I've had to resort to ugly looking code like the following.

Type t = sender.GetType();
if (t == typeof(Button)) {
    var realObj = (Button)sender;
    // Do Something
}
else if (t == typeof(CheckBox)) {
    var realObj = (CheckBox)sender;
    // Do something else
}
else {
    // Default action
}

Yes I realize this isn't the ugliest code but it seems less elegant to me over a standard switch statement and I find the casting tedious. Especially since it requires you to write every type twice.

What I want to say is "Given this type, execute this block of code." So I decided to run with that this afternoon. Lambdas will serve nicely for the block of code and using type inference will allow us to avoid writing every type out twice. What I ended up with was a class called TypeSwitch with 3 main methods (see bottom of post for full code).

Do - Entry point where switching begins
Case - Several overloads which take a generic type argument and an Action<T> to run for the object
Default - Optional default action.

I wrote a quick winforms app to test out the solution. I dropped some random controls on a from and bound the MouseHover event for all of them to a single method. I can now use the following code to print out different messages based on the type.

TypeSwitch.Do(
    sender,
    TypeSwitch.Case<Button>(() => textBox1.Text = "Hit a Button"),
    TypeSwitch.Case<CheckBox>(x => textBox1.Text = "Checkbox is " + x.Checked),
    TypeSwitch.Default(() => textBox1.Text = "Not sure what is hovered over"));

Notice that for check box I was able to access CheckBox properties in a strongly typed fashion. The underlying case code will optionally pass the first argument to the lambda expression strongly typed to the value specified as the generic argument.

There are a couple of faults with this approach including Default being anywhere in the list but it was a fun experiment and works well.

TypeSwitch code.

static class TypeSwitch {
    public class CaseInfo {
        public bool IsDefault { get; set; }
        public Type Target { get; set; }
        public Action<object> Action { get; set; }
    }

    public static void Do(object source, params CaseInfo[] cases) {
        var type = source.GetType();
        foreach (var entry in cases) {
            if (entry.IsDefault || type == entry.Target) {
                entry.Action(source);
                break;
            }
        }
    }

    public static CaseInfo Case<T>(Action action) {
        return new CaseInfo() {
            Action = x => action(),
            Target = typeof(T)
        };
    }

    public static CaseInfo Case<T>(Action<T> action) {
        return new CaseInfo() {
            Action = (x) => action((T)x),
            Target = typeof(T)
        };
    }

    public static CaseInfo Default(Action action) {
        return new CaseInfo() {
            Action = x => action(),
            IsDefault = true
        };
    }
}

Design Guidelines: Provide type inference friendly Create function for generic objects

Jared Parsons — Fri, 11 Apr 2008 15:24:50 GMT

Really this guideline is a bit longer but putting it all in a blog title seemed a bit too much. The full guideline should read: "If a generic class constructor arguments contain types of all generic parameters, provide a static method named Create on a static class of the same class name as the generic class which takes the same arguments and calls the constructor." Quite a mouth full.

Lets look at a specific example with Tuples. Tuples are generic with respect to the values they are representing. Without any type inference help we would have to write the following code to create a simple tuple.

            var tuple = new Tuple<int, string>(5, "astring");

Not too bad because we are using simple types. But what happens when we are using really long type names?

            var tuple2 = new Tuple<string,Dictionary<string, List<int>>>(val1, val2);

As we can see, the code is getting quite a bit uglier. This pattern is in fact not maintainable once we start using un-namable types such as anonymous types or generics of anonymous types.

The problem here is we are not leveraging the compilers type inference capabilities. The compiler can easily infer the types of a tuple argument and hence create a tuple. We just need to provide a mechanism to do so. The best way is to define a static method on a static class with the same name as the generic. Lets call this method Create.

    public static class Tuple {
        public static Tuple<TA, TB> Create<TA, TB>(TA valueA, TB valueB) { 
            return new Tuple<TA, TB>(valueA, valueB); 
        }
    }

The method Tuple.Create still has two generic parameters. However since we are providing a set of values which contain types for every generic parameter, the compiler can infer the generic arguments. Now we can create a Tuple without specifying any generic arguments. Because no types are specified this will work with any value in the code including un-namable types.

            var tuple = Tuple.Create(6, "astring");
            var tuple2 = Tuple.Create(6, new { name = "aname", value = 42 });

Tuples Part 3: Type Inference Friendly Constructor

Jared Parsons — Mon, 07 Jan 2008 19:38:11 GMT

Last time we were left with a constructor that required us to explicitly specify generic parameters. This is not always easy or possible. We'll now alter the script to generate a constructor which utilizes type inference to create a Tuple. In addition, all tuples will use the same overloaded method making the creation uniform.

The best way to use type inference to create a generic argument is through static methods. In C# and VB it's legal to define a non-generic class with the same name as a generic class. I tend to create a non-generic class with a static Create method that takes advantage of type inference. For tuples the method will look like the following.

public partial class Tuple
{
    public static Tuple<TA> Create<TA>(TA a)
    { 
        return new Tuple<TA>(a); 
    }
}

This allows us to write the following code.

            var tuple = Tuple.Create("foo");

Partial classes are used because we will be generating one per Tuple class that we create. It's just easier to script it this way.

The method is very straight forward. We need one new additional string for the arguments to the constructor. It's created along the same line as the previous strings.

function script:Gen-InferenceConstructor
{
    param ( [int] $count = $(throw "Need a count") )
    $OFS = ','
    $gen = "<" + [string](0..($count-1) | %{ "T"+$upperList[$_] }) + ">"
    $list = [string](0..$($count-1) | %{ "T{0} {1}" -f $upperList[$_],$lowerList[$_] })
    $argList = [string](0..$($count-1) | %{ $lowerList[$_] })
    "public partial class Tuple {"
    "public static Tuple$gen Create$gen($list) { return new Tuple$gen($argList); } "
    "}"
}

Now just add a call to this function in Get-Tuple and the code is now inference friendly.

Next up is defining an interface for tuples that will allow us to treat a Tuple<2> as a Tuple<1>. Both have an "A" property and should be able to be used in a generic way.

C# Lambda Type Inference

Jared Parsons — Fri, 14 Dec 2007 20:41:47 GMT

One of the limitations of C# type inference is that you cannot use it to infer the type of a lambda expression. For example, the following code will not compile

            var f = () => 4;

Normally this is not too much of an issue because you can just explicitly declare the type of the lambda expression.

            Func<int> f = () => 4;

However, this can be annoying at times. Once you start defining complex lambda expressions the Func/Action declaration can be quite convoluted. Even worse, if your lambda returns an anonymous type, there is no way to declare a Func<> with the anonymous type parameter because you cannot describe it's shape.

            Func<???> f = () => new { Name = "foo" };

This is fixable though by using type inference. The method is very similar to other anonymous type type tricks. While lambda type inference is not supported for variable declaration it is supported for parameters. C# supports return type inference so that can be used to type the variable.

        static Func<T> Lambda<T>(Func<T> del)
        {
            return del;
        }

        static void Main(string[] args)
        {
            var f = Lambda(() => new { Name = "foo" });
        }

Type Inference and IEnumerable

Jared Parsons — Tue, 27 Nov 2007 01:32:10 GMT

This is somewhat of a follow up on a previous post I did on the difference between IEnumerable(Of T) and the IEnumerable interfaces.

I've seen several people type in the following code and wonder if there was a fundamental bug in the type inference code.

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        For Each cur In Controls
            cur.Text = "A Value"
        Next
    End Sub

This code will produce an error stating that "Text" is not a member of object. Users expected type inference to type the variable "cur" as Control. Unfortunately this is "By Design".

Much of the original .Net Framework was written before the CLR implemented support for generics. As a result all of the collection classes were loosely typed to Object by implementing IEnumerable. So in this case type inference will correctly type this as Object.

There are 2 ways to fix this problem.

Explicitly type the For Each variable to be the actual type of objects in the collection
Use a Shim to change the type of the collection. (see http://blogs.msdn.com/jaredpar/archive/2007/10/04/ienumerable-and-ienumerable-of-t.aspx)