jaredpar's WebLog : F#

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.

Vim Emulator Editor Extension Released

Jared Parsons — Wed, 09 Sep 2009 05:09:00 GMT

I just released version 0.5.0 of VsVim: a vim emulation editor extension for Visual Studio 2010 Beta1 written in F#. This is a hobby project I’ve been working on for awhile now. I expect to continue updating this release as time goes on as I use it on a daily basis and I’m interested in getting back feedback from users on it.

Link: http://visualstudiogallery.msdn.microsoft.com/en-us/59ca71b3-a4a3-46ca-8fe1-0e90e3f79329

Here’s a quick break down on the state of this project

Caveats and Expectations

This extension is being released by me, not by Microsoft. As such the support level for this extension is equivalent to the amount of free time I have to put into it.

Quality Level

I would classify this as a Beta style release. I use this extension every day and I have a very large test bed to verify functionality. There are still several known bugs (detailed below) and little quirks I’m working on. But they are mostly minor issues

What’s Implemented

At this point the engine has an Insert, Normal and Command mode.

Insert Mode
- Basic insertion layer which allows for typing. No special insert mode commands are implemented
Normal Mode.
- Movement Commands: h,j,k,l,w,b,$,^,n,*,#
- Edit Commands: x,X,d,p,P,A,u,<,>,o
- Incremental Search
Command Mode
- :e
- Jump to line
- Beginning / end of line

Deviations

The biggest deviation I made from a traditional VIM engine is that I am using .Net regular expressions instead of VIM style regular expressions. This allowed me to focus on getting a lot of features written vs. spending time building a regular expression engine. Getting this working will be a focus of a later release.

Another issue is the cursor. As flexible as the new editor is, one part that is very tricky is changing the appearance of the cursor. So making a block style cursor for normal mode was not done for this release. Instead I simply color the cursor red for normal mode and black for insert mode. This will be fixed in a later release.

Bugs

Below is the list of known issues for the extension. I’ve noted all bugs for which I cannot get a steady repro. If you can find one I would appreciate you emailing the steps to me.

Cursor appearance in normal mode is not a block cursor but instead a red cursor
Need Repro: Using ‘o’ in normal mode can cause the line ending to switch from \r\n to \r or \n.
Both ‘#’ and ‘*’ match partial words instead of full words
Register list is limited to standard a-z alphabet

What’s next?

Thus far I’ve been working on features which don’t conflict with existing Visual Studio key bindings. The next big release will be focusing on the infrastructure needed to integrate these commands smoothly into the core Vim engine and Visual Studio itself. This will allow me to expand the number of implemented features a great deal.

Where’s the source?

Should be released soon. Right now I’m working out where I should host this project long term. Preferably a place where users can file bugs and leave feedback.

Mapping LINQ to F#

Jared Parsons — Tue, 02 Dec 2008 16:00:00 GMT

In my projects with F#, I often find that I know exactly what type of sequence transformation I want to run, yet I spend all of my time trying to find it!!! The problem is I’m used to query comprehensions in LINQ terminology. Select, Where and SelectMany are so ingrained into my programming they are practically done through muscle memory.

Unfortunately there is a disconnect between the naming convention used in LINQ and the ones used in F#. Some of the names are more intuitive than others. I’ve now spent enough time digging through Seq.fs that it’s time to draw up a table that maps various LINQ functions to their equivalent method in F#.

If nothing else, it will be a good table for me to come back to. Below is a list of many methods in Enumerable, mapped to the equivalent function in F#’s seq

Aggregate –> fold
All –> for_all
Any –> exists
Average –> average
Cast –> cast
Count –> length
Distinct –> distinct
ElementAt –> nth
Empty –> empty
First –> hd
GroupBy –> group_by
Max –> max
Min –> min
OrderBy –> sort_by
Select –> map, mapi
SelectMany –> concat, map_concat
SequenceEqual –> compare
Skip –> skip
SkipWhile –> skip_while
Sum –> sum
Where –> filter

Below are the functions for which an equivalent was not found (or was quite simply overlooked). Most of these can be added with a combination of other simple transformations.

DefaultIfEmpty
Except
FirstOrDefault
GroupJoin
Intersect
Join
Last
LastOrDefault
LongCount
OfType
Reverse
Single
SingleOrDefault
Union

Comparing Continuations in C# and F# Part 3: Double wrong

Jared Parsons — Thu, 13 Nov 2008 16:00:00 GMT

Is it better to be wrong once or to be right then think you’re wrong but find out you were right but wrong about being wrong? Besides the obvious be right the first time, it’s certainly an educational experience.

Here’s the original sample:

let FoldRight combine (sequence:seq<'a>) acc = 
    use e = sequence.GetEnumerator()
    let rec inner cont = 
        match e.MoveNext() with
            | true -> 
                let cur = e.Current
                inner (fun racc -> cont (combine cur racc))
            | false -> cont acc
    inner (fun x -> x )

Brian McNamara pointed out I wasn’t considering all of the call sites for this sample. In addition to the recursive call to “inner” and the initial inner call, there is the actual recursive invocation of the of the continuations. Effectively the “inner” function is building up a list of list of lambdas which call the combine function. The output of the combine function is simply passed into the next lambda in the list. The last lambda in the list is the identity lambda and returns the final call to combine. This value is the actual value returned from the initial invocation “cont acc”. Lambdas are methods under the hood. Without a tail instruction, this chain of lambda calls will just as easily overflow the stack.

Digging deeper into the compiled F# code we can view this call and indeed it is done with tail recursion.

 
.method public virtual instance !V Invoke(!U racc) cil managed
{
    .maxstack 8
    L_0000: nop 
    L_0001: ldarg.0 
    L_0002: ldfld class [FSharp.Core]Microsoft.FSharp.Core.FastFunc`2 Program/clo@9::cont
    L_0007: ldarg.0 
    L_0008: ldfld class [FSharp.Core]Microsoft.FSharp.Core.FastFunc`2> Program/clo@9::combine
    L_000d: ldarg.0 
    L_000e: ldfld !2 Program/clo@9::cur
    L_0013: ldarg.1 
    L_0014: call !!0 [FSharp.Core]Microsoft.FSharp.Core.FastFunc`2::InvokeFast2(class [FSharp.Core]Microsoft.FSharp.Core.FastFunc`2>, !0, !1)
    L_0019: tail 
    L_001b: callvirt instance !1 [FSharp.Core]Microsoft.FSharp.Core.FastFunc`2::Invoke(!0)
    L_0020: ret 
}

The below code more accurately resembles the equivalent C# code that is generated for the above F# sample (thanks Brian!).

public static TAcc Inner<TSource, TAcc>(
    this IEnumerator<TSource> e,
    Func<TAcc, TSource, TAcc> combine,
    TAcc start,
    Func<TAcc, TAcc> cont)
{
    while (e.MoveNext())
    {
        var cur = e.Current;
        Func<TAcc, TAcc> innerCont = cont;
        cont = (x) => /*need .tail here */innerCont(combine(x, cur));
    }
    return cont(start);
}

public static TAcc FoldRight<TSource, TAcc>(
    this IEnumerable<TSource> enumerable,
    Func<TAcc, TSource, TAcc> combine,
    TAcc start)
{
    using (var e = enumerable.GetEnumerator())
    {
        return Inner(e, combine, start, (x) => x);
    }
}

Previous Entries

Comparing Continuations in C# and F# Part 2

Jared Parsons — Tue, 11 Nov 2008 19:38:00 GMT

In my last post I went over the differences between using a continuation in F# and C#. As it turns out I was right about the limits and symptoms but wrong about the reason.

The F# code does indeed generate tail calls for part of the continuation. However this is only a very small portion of the actual code and is in fact only generated for the call in the empty case. I misread this function to be the call for the overall continuation. Instead it is the function for the entire “inner” lambda.

So why does F# perform differently than C# in this scenario?

Andrew Kennedy pointed out that F# will actually transform the “inner” function into a loop. In affect the code generated looks like the following.

    TypeFunc func = this._self3;
    while (true)
    {
        if (!this.e.MoveNext())
        {
            break;
        }
        A cur = this.e.Current;
        cont = new Program.clo@9<U V, A ,>(this.combine, cont, cur);
    }
    return cont.Invoke(this.acc);

The actual transformation into a loop is what is preventing F# from overflowing the stack here. Iteration incurs no stack overhead in this case.

Even more interesting is that the tail opcode is quite simply ignored when dealing with un-trusted code. It therefore cannot be relied on to generate performant code in all scenarios.

Comparing Continuations in F# and C#

Jared Parsons — Mon, 10 Nov 2008 16:00:00 GMT

Lately I’ve been playing quite a bit with F#. I have several hobby projects I’m working on that take up a bit of my time. But when I’m not playing around with F# I’m exploring ways to apply certain functional patterns to actual coding on the job and/or porting to my functional library: RantPack.

Recently I’ve been playing around with continuations in F#. I thought this was a great topic to do a F# comparison with other languages. In this case C#.

Let’s examine a classic use of continuations: a right fold on a list. For a detailed explanation of fold right and the use of a continuation I suggest taking a look at Brian's discussion. If you’re unfamiliar with continuations I highly suggest that you take a look at this post as Brian gives a great breakdown of continuations and their uses.

Here's a quick refresher on continuations by example. Fold right is an operation which reduces a sequence of elements into a single element by processing the list from right to left. It’s similar to the LINQ Aggregate method except Aggregate operations left to right.

For this post we’ll be writing FoldRight against a sequence. I chose sequence vs. the traditional list because it’s present in both languages (F# = seq<’a>, C# = IEnumerable<T>). It is possible to other F# data structures in C# but the comparison is cleaner when using a type that is native to both languages.

Sequences are a left to right data structure so processing it right to left is not natural. After all, with a sequence all the developer has is current and whether or not there is a next element. Processing the list in a right to left fashion can be done by such acts as reversing the list, or doing a head recursive call. Both have their detractors.

Continuations are a different way to process the list. Instead of processing the list directly we process the list a single element at a time building up a continuation along the way. For each element a lambda expression is generated representing the work needed to be done for that element. The value calculated within the lambda will then be passed to the lambda calculated for the previous element. Once we hit the end of the list, we essentially have a chain of lambda expressions which process each element in the list in reverse order. All that is needed is to call the final lambda with the starting value and we will effectively process the list in reverse order.

Simple enough? Lets take a look at the code.

F# Code

let FoldRight combine (sequence:seq<'a>) acc = 
    use e = sequence.GetEnumerator()
    let rec inner cont = 
        match e.MoveNext() with
            | true -> 
                let cur = e.Current
                inner (fun racc -> cont (combine cur racc))
            | false -> cont acc
    inner (fun x -> x )

C# Code

public static TAcc FoldRight<TSource, TAcc>(
    this IEnumerable<TSource> enumerable, 
    Func<TAcc, TSource, TAcc> combine, 
    TAcc start) {

    using (var e = enumerable.GetEnumerator()) {
        Func<Func<TAcc, TAcc>, TAcc> inner = null;
        inner = (cont) => {
              if (e.MoveNext()) {
                  var cur = e.Current;
                  Func<TAcc, TAcc> innerCont = (x) => cont(combine(x, cur));
                  return inner(innerCont);
              } else {
                  return cont(start);
              }
          };
        return inner(x => x);
    }
}

My immediate reaction to the two samples is the conciseness of the F# code. This is a not a criticism of C# though. F# is designed to be a concise language and it’s delivery on that goal is evident in this sample.

What makes the big difference here is the type inference power of F#. In the C# sample there are 6 explicit types listed in the code sample. The F# sample only has a single type listed. The compiler is able to infer and/or generate the rest of the signatures. F# also requires less explicit generic parameters 1 vs. 2 in C#.

The next big difference I see is the awkward way in which the inner lambda expression must be declared in C#. The lambda expression is called recursively in order to setup the continuation. In order to do that in C# the lambda must be declared and defined in separate expressions. Otherwise, a self reference of “inner” inside the body of “inner” will generate a used before defined warning from the compiler.

The IL

Examining the full IL of both functions would take several blog posts. Not to mention that trying to read disassembled F# much less IL, is like trying to read disassembled C++. An interesting exercise but a bit time consuming.

I did want to focus a bit on one portion of the generated IL. There is a very significant difference in the way the recursive call to the “inner” lambda is made.

    L_0032: ldarg.1 
    L_0033: ldarg.0 
    L_0034: ldfld !0 Test/clo@6T::acc
    L_0039: tail 
    L_003b: callvirt instance !1 [FSharp.Core]Microsoft.FSharp.Core.FastFunc`2::Invoke(!0)

    
    L_0077: ldarg.0 
    L_0078: ldfld class [System.Core]System.Func`2, !1> ConsoleApplication1.Extensions/<>c__DisplayClass8::inner
    L_007d: ldloc.0 
    L_007e: callvirt instance !1 [System.Core]System.Func`2, !TAcc>::Invoke(!0)
    L_0083: stloc.3

In both cases the first 3 lines are building up the 2 parameters necessary for the recursive lambda call. The closures are structured somewhat differently but the same basic operation is being done.

The key difference between the languages is F#’s use of the tail opcode. This opcode tells the CLR the to call the next method in a tail recursive fashion. This causes the CLR to remove the current method frame from the stack before the next method is called. Because the method is removed from the stack, the recursive call takes up no additional stack space. This is true no matter how many times the function is called.

The C# IL does not have this opcode. So the recursive call will happen with the current method on the frame. With a big enough sequence this will cause the process to run out of stack space and generate a StackOverflowException. This creates a limitation on the number of elements the C# sample can process.

Limits

I explored the limits of both samples on my home laptop. I generated a simple example to sum the sequence with the fold right. Note: For a sum of ints, a fold left is just as good, but it serves fine for this sample.

let sum = FoldRight (fun x y -> x + y) [1..1000000] 0
printfn "%d" sum

var source = Enumerable.Range(1, 9397);
var result = source.FoldRight((x, y) => x + y, 0);
Console.WriteLine("{0}", result);

The C# sample can process a maximum size of 9397 elements. After that I encounter a stackoverflow exception. The F# sample however can easily process 1,000,000 elements.

Closing note. This not meant to be a post criticizing C#. It’s meant to be a general comparison of the same technique in two managed languages. This is a scenario that is far less likely to occur in a C# program. In an F# program it’s quite simply an expectation and hence the F# compiler is optimized for this scenario.

Functional C#: Providing an Option Part 2

Jared Parsons — Wed, 08 Oct 2008 15:00:00 GMT

In my previous post I discussed creating an Option style construct for C#/.Net. This post is a followup with the complete code snippet. It’s been updated in response to several bits of feedback I received. Namely

Option is now a struct vs. class
Added equality metrics
Allowing implicit conversion T –> Option<T>

As usual, this is available in the latest version of RantPack: http://code.msdn.microsoft.com/RantPack

[Immutable]
[Serializable]
[SuppressMessage("Microsoft.Naming", "CA1716")]
public struct Option<T> : IEquatable<Option<T>>
{
    private readonly T m_value;
    private readonly bool m_hasValue;

    public static Option<T> Empty
    {
        get { return new Option<T>(); }
    }

    public bool HasValue
    {
        get { return m_hasValue; }
    }

    [DebuggerDisplay("m_value")]
    public T Value
    {
        get
        {
            if (!HasValue)
            {
                throw new InvalidOperationException("Option does not have a value");
            }

            return m_value;
        }
    }

    public T ValueOrDefault
    {
        get { return m_hasValue ? m_value : default(T); }
    }

    public Option(T value)
    {
        m_hasValue = true;
        m_value = value;
    }

    #region Operators

    [SuppressMessage("Microsoft.Usage", "CA1801")]
    [SuppressMessage("Microsoft.Usage", "CA2225")]
    public static implicit operator Option<T>(Option option)
    {
        return Option<T>.Empty;
    }

    [SuppressMessage("Microsoft.Usage", "CA1801")]
    public static implicit operator Option<T>(T value)
    {
        return new Option<T>(value);
    }

    public static bool operator ==(Option<T> left, Option<T> right)
    {
        return left.Equals(right);
    }
    public static bool operator !=(Option<T> left, Option<T> right)
    {
        return !left.Equals(right);
    }

    #endregion

    #region IEquatable<T> Members

    public bool Equals(Option<T> other)
    {
        if (other.HasValue != this.HasValue)
        {
            return false;
        }

        // Both don't have a value
        if (!other.HasValue)
        {
            return true;
        }

        return EqualityComparer<T>.Default.Equals(m_value, other.Value);
    }

    #endregion

    #region Overrides

    public override bool Equals(object obj)
    {
        if (obj is Option<T>)
        {
            return Equals((Option<T>)obj);
        }

        return false;
    }

    public override int GetHashCode()
    {
        if (!HasValue)
        {
            return 0;
        }

        return EqualityComparer<T>.Default.GetHashCode(m_value);
    }

    #endregion
}

[Immutable]
[Serializable]
[SuppressMessage("Microsoft.Naming", "CA1716")]
public sealed class Option
{
    private static Option s_empty = new Option();

    private Option()
    {
    }

    public static Option<T> Create<T>(T value)
    {
        return new Option<T>(value);
    }

    public static Option Empty
    {
        get { return s_empty; }
    }
}

Unfold

Jared Parsons — Tue, 07 Oct 2008 15:00:34 GMT

F# has a handy method called Unfold. Think of it as the logical opposite of an Aggregate function. Aggregates take a sequence of elements and convert them to a single element. An unfold method will take a single element and turn it into a (potentially infinite) sequence of elements.

The API is straight forward. It takes two parameters

A seed/start value
A function which takes in a seed value and returns either an Empty option to indicate the end of a sequence or a value of Type tuple with two arguments. The first is the next element in the sequence and the second is the next seed value passed into the function.

This is a very powerful function which allows you to quickly build all sorts of interesting functions. Lets look at a potential implementation of Enumerable.Range as an unfold expression.

public static IEnumerable<int> Range(int start, int count)
{
    return Enumerable.Unfold(
        start,
        x => x - start < count
            ? Option.Create(Tuple.Create(x, x + 1))
            : Option.Empty);
}

Not as efficient as the framework version of Range but a good mental exercise to get your head around using Unfold. Implementing this method in C# is fairly straight forward.

public static IEnumerable<TResult> Unfold<TSource, TResult>(
    TSource state, 
    Func<TSource, Option<Tuple<TResult, TSource>>> func)
{
    if (func == null)
    {
        throw new ArgumentNullException("func");
    }

    return UnfoldHelper(state, func);
}

private static IEnumerable<TResult> UnfoldHelper<TSource, TResult>(
    TSource state, 
    Func<TSource, Option<Tuple<TResult, TSource>>> func)
{
    do
    {
        var result = func(state);
        if (!result.HasValue)
        {
            break;
        }

        yield return result.Value.First;
        state = result.Value.Second;
    } while (true);
}

Functional C#: Providing an Option

Jared Parsons — Mon, 06 Oct 2008 15:00:16 GMT

Sorry for the terrible pun in the title. I wanted to blog about developing an F# style Option class for C# and I couldn't resist.

The basics of an Option class are very straight forward. It's a class that either has a value or doesn't. It's almost like nullable but for every type and allows for nulls to be a valid value. Here's a straight forward Option class I coded up.

public sealed class Option<T> {
    private readonly T m_value;
    private readonly bool m_hasValue;
    public static Option<T> Empty {
        get { return new Option<T>(); }
    }
    public bool HasValue {
        get { return m_hasValue; }
    }
    public T Value {
        get {
            if (!HasValue) {
                throw new InvalidOperationException("Option does not have a value");
            }
            return m_value;
        }
    }
    public Option(T value) {
        m_hasValue = true;
        m_value = value;
    }
    private Option() {
        m_hasValue = false;
        m_value = default(T);
    }
}

public sealed class Option {
    public static Option<T> Create<T>(T value) {
        return new Option<T>(value);
    }
}

I modified a bit of terminology to be more consistent with other frameworks I use (Some/None -> Value,HasValue). It's succinct, generic and has type inference friendly create functions. Or does it?

Lets consider a function which has a return type of Option<int>. Case 1 is Option with a value. There is a type inference friendly Option.Create method which makes for a simple return expression. No types needed.

Option<int> SomeMethod() {
    return Option.Create(42);
}

Now lets consider Case #2, None. Here there is no handy inference method because what would we use for inference. There is no variable with a Type to use so we are forced to be explicit about the type.

Option<int> SomeMethod2() {
    return Option<int>.Empty;
}

In this case we're not so bad off because we're dealing with a simple type. But what about more complex types? Consider for example a hypothetical Unfold method. The termination expression would be Option<Tuple<int,string>>.Empty. Anonymous types are even worse since they are unnamable and can not ever be the source of an option with this design. This really pales in the usage category when compared with F#.

Lets see if we can do better.

First we could consider a design where we have a static creation method Empty which takes variables that aren't ever used. This will give us the benefit of type inference but at the expense of an API which is faulty to the core. It forces the user to create parameters that aren't ever used. Definitely not a good design.

This leaves us with using a solution that doesn't involve variables of the necessary type. This essentially forces us into a non-generic solution since we need variables for type inference. This non-generic Option won't be compatible with our generic return type. But wait, what will the compiler do if two expressions have conflicting types? Eventually it will attempt to perform a conversion. So if we make our non-generic empty Option convertible to any generic empty Option we can use the compilers type safety to our advantage.

Definition a non-generic empty Option is straight forward.

public sealed class Option {
    private static Option s_empty = new Option();
    private Option() {
    }
    public static Option Empty {
        get { return s_empty; }
    }
    public static Option<T> Create<T>(T value) {
        return new Option<T>(value);
    }
}

Using a private constructor allows us a high degree of confidence that any Option instance hanging around came from our Empty property and hence represents an empty option. Now all we need to do is define a conversion on Option<T>. Essentially we want to say that any non-generic Option is convertible to this instance. Add the following to Option<T>

public static implicit operator Option<T>(Option option) {
    return Option<T>.Empty;
}

Now, we can use an empty option in any generic scenario without having to specify ugly type parameters.

Option<int> SomeMethod3() {
    return Option.Empty;
}

Euler #2

Jared Parsons — Thu, 11 Sep 2008 15:01:26 GMT

Problem #2 came quite a bit faster. The yield syntax in F# is very similar to the C# iterator syntax and made translating this sample a breeze.

As a commenter posted, in problem #1, I would've been better served to use Seq.filter as opposed to Seq.choose for the purpose of filtering list. I've applied that here. One downfall of learning a new language is finding the right API. I spent a bit of time reading through the Seq documentation looking for the equivalent of the Where extension method and could only find chose. Lesson learned

// Find the sum of all the even-valued terms in the sequence which do not exceed four million.
let problem2() =
    let rec fib prev cur = seq {
            yield prev
            if cur < 4000000 then
                yield! fib cur (prev+cur)
        }
    fib 1 2
        |> Seq.filter (fun x -> 0 = x % 2)
        |> Seq.sum

Debugging F# list's

Jared Parsons — Wed, 10 Sep 2008 15:00:52 GMT

One of the lacking's of the latest F# CTP is debugger visualization support for the built-in list types. Viewing a list in the debugger is decidedly tedious compared to the mscorlib collection classes. Take the following quick code sample

module Main =
    do
        let l1 = [0..4]
        let l2 = List.map (fun a -> a.ToString()) l1
        let l3 = new System.Collections.Generic.List<int>()
        List.iter (fun i -> l3.Add(i)) l1
        MainModuleTemp.Main()   // Breakpoint here

Hit F5 in a F# console application and you'll get the following display.

Notice how the elements of the mscorlib List<> are immediately visible. Getting to the data in a F# list is possible but it takes a lot more clicks than the mscorlib version. This doesn't appear to be an oversight on the F# team either. The expansion of mscorlib List<T> is controlled by the DebuggerTypeProxy attribute on the class definition. If you fire up Reflector and dig into Fsharp.Core.dll and navigate to List<T> you'll notice it indeed has a DebuggerTypeProxy entry which is well formed and points to ListDebugView<T>.

ListDebugView<T> is essentially identical to the one for mscorlib List<T>. So what gives? The bug appears to be in the accessibility of the constructor. Even though it's not explicit in the documentation of DebuggerTypeProxy, it appears that the target type must have a single argument constructor which is public. The one for ListDebugView<T> is internal.

Normally this would be an easy enough problem to work around. Add an assembly level attribute of type DebuggerTypeProxy pointing to List<T> and a modified version of ListDebugView. Unfortunately that will not work in this case. The debugger will prefer DebuggerTypeProxy instances added directly to a type over ones defined at an assembly level.

That is, except for two cases. The debugger will give precedence to assembly level attributes which are defined in an assembly named autoexp.dll and placed in one of the following two locations

Visualizers folder for the current user. One my machine it is C:\Users\jaredp\Documents\Visual Studio 2008\Visualizers
Devenv global visualizer folder. C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\Visualizers\Original

If you navigate to either of these directories you will find both the default autoexp.dll and the source code used to compile it. It's got quite a few entries you may want to add in a modified version. Adding a new ListDebugView<T> here is possible but lets do it in F# instead.

Since autoexp.dll has predecence all we need to do is build a new version which has the appropriate debugger attributes for the F# collections. Fire up a new class library project named autoexp and have it output to either of the directories listed above. Below is a sample definition to get you started.

#light
open System.Diagnostics

module Main =
    type ListProxy<'a>(l:List<'a>) =
        [<DebuggerBrowsableAttribute(DebuggerBrowsableState.RootHidden)>]
        member this.Items = 
            Array.of_list l
            
    [<assembly: DebuggerDisplayAttribute("{Length}", Target=typeof<List<int>>)>]
    [<assembly: DebuggerTypeProxyAttribute(typeof<ListProxy<int>>, Target=typeof<List<int>>)>]
    do 
        ()

Don't be alarmed at the typeof<List<int>>. The visualizer will work for any generic binding of List<T>. In fact, reflector confirms that this attribute will be emitted with the type pointing at the unbound List<T> instead of List<int>. My lack of F# skills is failing me as to why. I'd love to cry bug but I've found crying bug at a compiler is usually ... wrong.

In either case, once you build this and place in the appropriate folder, you should find the visualizations for List<> much more accessible.

Euler and F#

Jared Parsons — Mon, 08 Sep 2008 15:00:44 GMT

I've been looking for some new problems to work on in F# to get more comfortable with the language. I've been rather slack of late because of other projects but I had a little bit of time this week. I decided it would be fun to join the crowd and play away at the problems on the project euler site. That being said, answer #1.

module Euler =
    let problem1() =
        let test i = 
            match (0 = i % 3) || (0 = i % 5) with
                | true -> Some i
                | false -> None
        let targetSeq = Seq.choose test [0..999]
        Seq.sum targetSeq

F# CTP First Impressions

Jared Parsons — Wed, 03 Sep 2008 15:00:27 GMT

I had a little bit of time this weekend to download the F# CTP. The IDE portion of the CTP is a huge improvement over the previous CTP. In particular the intellisense engine feels much more smooth, is available in new places and has much better results. Project engine also has better integration. Debugging support is much better.

Overall the IDE now really feels like a ... well IDE. I felt like the previous CTP was forced into Visual Studio and had much more in common with the old C++ IDE than VB and C#. This time around the IDE is just more smooth and more closely resembles other managed integrations. Definately worth the upgrade.

F# CTP Released

Jared Parsons — Fri, 29 Aug 2008 22:30:07 GMT

A new version of the F# CTP was released today. There are a lot of new improvements to the language and project system. Check it out here