What does this C# code look like in F#? (part one: expressions and statements)

If you have C# code and just try to transliterate it directly to F#, the F# code you wind up with is unlikely to be idiomatic or "good".  Nevertheless, when you are new to a language (F#), it is sometimes useful to know how to transliterate from a well-known language (C#) for those cases where you just don’t know the idioms yet, but don’t want that to prevent you from making progress.  So today’s blog entry takes the general form of "here’s some C# code, how do I write the same thing in F#".  It is intended to be used as a reference or as casual reading to discover some little-used or lesser-known F# syntax/operators/functions.  Don’t use this blog post as a way to learn the language, instead use the many useful F# tutorials and samples on the web (start here), and just use this blog post to "fill in the gaps" if needed.

Today’s blog entry covers only code that goes inside a method body, so you won’t find anything about declaring classes or using namespaces here.  Instead I will be covering the following bits of C#:

• casts
• operators
• expressions
• statements

and show a way to transliterate those C# forms into the corresponding F#.  Along the way I will inject some editorial comments about what is good, bad, idiomatic, etc, but I will not go into much detail.  If I leave anything common out, or something is very unclear, feel free to post a question as a comment on this blog entry.

Without further ado!

Casts

The cast "operator" in C# (saying "(Typename)expr") can mean all kinds of different things in C#, depending on the source type and destination type.  I will just call out the four most common conversions done via casts:

    // C#
    char c = ‘a’;
    int x = (int)c;         // numerical conversion
    object o = (object)c;   // boxing conversion
    Dog d = new Dog();
    Animal a = (Animal)d;   // upcast
    d = (Dog)a;             // downcast (may fail at runtime)

Here is the corresponding F# code, followed by some commentary.

    // F#
    let c = ‘a’
    let x = int c        // numerical conversion
    let o = box c        // boxing conversion
    let d = new Dog()
    let a = d :> Animal  // upcast
    let d2 = a :?> Dog   // downcast (may fail at runtime)

Numerical conversions in F# are done via library functions.  For example, the function "int" converts a char (or a float or a uint or a whatever) into an int.  There are similar functions for each destination type, so for example the function "char" converts it argument to a char.  You can read a little more about these functions in the library reference.  Note that the "enum" function converts to an enumerated type; the specific enumeration type will be inferred, which sometimes requires a type annotation, as in

    let y : MyEnumType = enum 0 // F#: y is 0-value of MyEnumType

A boxing conversion turns a primitive value into an object.  The F# function "box" does this.  In fact, "box" will upcast anything to the object type System.Object (which in F# goes by the shorthand name "obj").

Upcast: If you want to make a conversion that goes up a class/interface hierarchy, use the F# syntax "expr :> type".  If this compiles, then this conversion will always succeed at runtime.  (Note: in F# 1.9.6.2, this expression form has somewhat weird precedence, and so you may sometimes need to surround it with parens, e.g. "(expr :> type)" to make the code parse.)  You rarely need to use this operator.

Downcast: If you want to make a conversion that goes down a class/interface hierarchy, use the F# syntax "expr :?> type".  The question mark inside this operator is meant to suggest that the operation may fail; just as in C#, you may get an InvalidCastException.  You should rarely use this operator; in C# you typically prefer "is" and "as", see those expressions below for the corresponding idiomatic F#.

Operators

Many arithmetic (e.g. +, *) and conditional (e.g. &&, ||) operators are the same in F# as in C#.  The most common places to get tripped up are (1) with logical negation: in C# it is spelled "!", whereas in F# it is spelled "not"; (2) with equality testing, in C# it is "==" whereas in F# it is just "="; and (3) with inequality, where C# has "!=" whereas F# has "<>".  (As for logical negation, note that "!" already has a meaning in F# associated with the "ref" type, which is inherited from OCaml, oh well.)  The other somewhat common place to get tripped up is that in C# the bitwise-logic operators are one character (e.g. "|" and "&"), whereas the F# operators are three characters ("|||" and "&&&"); you’ll need these operators when using e.g. "Flags" enums.

Most F# operators are overloaded, don’t be fooled by the type inference tooltips when hovering over code like this in Visual Studio:

let f x y = x + y  // hover mouse over f, says int -> int -> int

This does not mean that "+" only works on ints; you can use "+" to add two floats, or two chars, or even two strings.  (The mechanism by which this overloading works involves esoteric black magic involving "inline" and "^a" types.  You’ll be happier if you stay ignorant of those details; the language/tooltips pick "int" as a default when things are otherwise unconstrained in order to hide the underlying complexity.  (A much better "solution" to "how to overload common operators like ‘+’" is to use type classes, but neither the CLR nor even F# have sufficiently expressive type systems to handle type classes, oh well.))

In C#, the same operator (‘=’) is used for both initialization and destructive assignment:

    int i = 3;    // initialization
    i = 4;        // destructive assignment

In F#, these are separate operators (‘=’ and ‘<-’), and only mutable variables admit assignment:

    let i = 3    // initialization
    i <- 4       // does not compile, i is immutable
    let mutable j = 3
    j <- 4       // destructive assignment

 

Expressions

Most expressions involving constructing objects, methods, and properties look the same in C# and F#:

    new Dog()  // constructor
    s.StartsWith("h", StringComparison.Ordinal)  // method call
    s.Length   // property

One notable difference is the syntax for indexing of arrays or other types.  Whereas in C# you say:

    var dict = new Dictionary<string, int>();
    dict["foo"] = 42;
    Console.WriteLine(dict["foo"]);

in F# you need a dot (‘.’) before the square brackets:

    let dict = new Dictionary<string,int>()
    dict.["foo"] <- 42
    printfn "%d" dict.["foo"]

There are tons of variations of syntax for doing lambdas/delegates in C#, I’ll show only one:

    Func<int, int, int> f = (x, y) => x + y;  // C# lambda

and the roughly corresponding F#:

    let f = (fun x y -> x + y)  // F# lambda

There are lots of interesting differences between the language when it comes to representing lambdas/functions/delegates, and I will not go into any detail about these differences in today’s blog entry.

Both C# and F# have "typeof" that returns a System.Type, but C# uses round brackets whereas F# uses angle brackets:

    typeof(int)  // C# typeof

    typeof<int>  // F# typeof

Another distinction involves generic types; C# allows you to omit types to get the generic definition:

    Console.WriteLine(typeof(List<int>).IsGenericTypeDefinition); // false
    Console.WriteLine(typeof(List<>).IsGenericTypeDefinition);    // true

whereas F# has a separate operator called "typedefof" for getting uninstantiated generic types:

    printfn "%A" (typeof<List<int>>.IsGenericTypeDefinition)  // false
    printfn "%A" (typedefof<List<_>>.IsGenericTypeDefinition) // true

C# has "is" and "as" operators for type tests.  F# uses a particular pattern in a match for this.  So this C# code:

    if (animal is Dog)
    {
        Dog dog = animal as Dog;
        // …
    }
    else if (animal is Cat)
    {
        Cat cat = animal as Cat;
        // …
    }

becomes this F# code:

    match animal with
    | :? Dog as dog -> // …
    | :? Cat as cat -> // …

where ":? type" is a type test, and "as ident" names the resulting value of that type if the type test succeeds.  (One other aside: in F# "else if" can be abbreviated as "elif".)

C# has the ternary operator "?:" for conditional expressions:

    condition ? trueVal : falseVal

F# has the same operator, but its name is if-then-else:

    if condition then trueVal else falseVal

(Note that "if" is used much less frequently in F# than in C#; in F#, many conditional expressions are done via pattern-matching rather than if-then-else.)

C# has an operator called "default" that returns the zero-initialization value of a given type:

    default(int)

It has limited utility; most commonly you may use default(T) in a generic.  F# has a similar construct as a library function:

    Unchecked.defaultof<int>

These respective constructs are rarely used in C# and F#.

Statements

This section describes how to transliterate C# statements into F#.  F# doesn’t have "statements", per se; everything is just an expression, and evaluating a a method body just means evaluating its expressions.  The expressions that are most statement-like in F# just return "()", the sole value of the "unit" type, which is akin to "void" in C#.

C# has three looping constructs:

    // C# loops
    while (condition)
    {
        SomeCode();
    }
    foreach (var e in someEnumerable)
    {
        SomeCode();
    }
    for (int i = 0; i < 10; ++i)
    {
        SomeCode();
    }

F# has just "while" and a "foreach" (spelled "for" in F#); a C# "for" loop can usually be emulated with a "range":

    // F# loops
    while condition do
        SomeCode()
    for e in someEnumerable do  // foreach
        SomeCode()
    for i in 0..9 do  // compiles like a C# for loop
        SomeCode()

F# lacks anything like "break" or "continue"; you must use control flow and/or boolean flag variables to emulate these constructs.  "While" loops in F# are rare, since they imply mutable variables in the condition, and F# often eschews mutables, preferring recursion for simple loops.  For(each) loops are also somewhat rarer in F#, since sometimes the form

    someEnumerable |> Seq.iter (fun e -> SomeCode())

is preferred (especially when the argument to Seq.iter is short). 

C# has a switch statement.  It looks something like this:

    switch (x)
    {
        case 1:
            SomeCode();
            break;
        default:
            SomeCode();
            break;
    }

In F#, this is just one of many things that pattern matching expresses more succinctly:

    match x with
    | 1 -> SomeCode()
    | _ -> SomeCode()  // _ is a ‘catch all’ default

C# has a "return" keyword that exits the current function.  There is no comparable construct in F#.  Note that the "return" keyword in F# is part of computation expression syntax (a.k.a. "workflows", a.k.a. "monads") and has nothing to do with C#’s "return".  As with C#’s "break", in F# you will need to use control-flow constructs to simulate "return" for an early exit.  (Though I do occasionally wish for "break" in F#, I have never wished for "return" – I don’t recall ever needing/wanting it.)

In C#, you raise an exception with the "throw" keyword.  In F#, you use the function "raise". 

    throw new Exception("boom");    // C#

    raise <| new Exception("boom")  // F#

This is one of the few places in F# where I think it is very idiomatic to use the backward-pipeline operator "<|".  Without it, the precedence rules of F# force you to parenthesize the expression:

    raise( new Exception("boom") )  // F#

which I think most people feel looks awkward.

C# has a try-catch-finally construct for exception handling.  As a result you can write code like this:

    try
    {
        SomeCode();
    }
    catch (NullReferenceException nre)
    {
        // swallow it
    }
    catch (Exception e)
    {
        throw;
    }
    finally
    {
        SomeOtherCode();
    }

The equivalent F# code would be:

    try
        try
            SomeCode()
        with 
            | :? NullReferenceException as nre -> () // swallow it
            | e -> rethrow()
    finally
        SomeOtherCode()

There are a few things to point out here.  First, in F#, try-with and try-finally are separate constructs – there is no try-with-finally.  In practice, you usually only do one or the other (and you should probably be using try-finally about ten times as often as try-catch, in either language – catching exceptions is rarely the right thing to do).  F# "catch" blocks just use pattern matching type tests on the exception, much like we saw earlier with the transliteration of C# "is"/"as".  In F#, to re-throw the exception, use "rethrow()". 

C# has a "checked" statement for checking for arithmetic overflow; F# has checked operators in the library, so just open this module and use the operators there if you need overflow checking.

C# has a "lock" statement for locking an object for a critical section:

    lock (o)             // C# lock
    {
        SomeCode();
    }

In F#, "lock" is a function that takes the lock object and a lambda of the critical section:

    lock o (fun () ->    // F# lock
        SomeCode()
    )

C# has "using" for IDisposables:

    using (var disp = someDisposable)
    {
        SomeCode();
    }

F#’s corresponding syntax:

    use disp = someDisposable 
    SomeCode()

F#’s "use" is like "let", it is scoped to the end of the surrounding block.

Inside a C# method that returns an IEnumerable, the following "yield" statement forms are allowed:

    yield return 42;  // C# yield a value
    yield break;      // C# end the enumeration

In F#, you don’t have to declare a method-returning-IEnumerable to use "yield", instead you can make a sequence expression anywhere using "seq{…}":

    let myIntSeq : IEnumerable<int> = seq { yield 42; }

I added a type annotation just to remind you that "seq" in F# just means "IEnumerable".  So the sequence expression on the right-hand-side of the line of code above evaluates to an IEnumerable<int> that yields a single value (42).  As with a C# iterator block, you can put arbitrary code using yields in an F# sequence expression.  Just as with loops and C# "break", there is no "yield break" in F#.

The end

I think that just about covers all the interesting C# expressions and statements, showing the corresponding F# counterparts.  I hope this is a useful reference for filling in gaps in your F# knowledge while learning F#.

On lambdas, capture, and mutability

This blog entry is a little more esoteric than I would like, so the author apologizes up front.  :)

A C# brain teaser

Last time I posed a teaser question: what does this C# code print?

    List<Func<int>> actions = new List<Func<int>>();  
    for (int i = 0; i < 5; ++i) 
    {  
        actions.Add( () => i * 2 );  
    }  
    foreach (var act in actions)  
    {  
        Console.WriteLine( act() );  
    }

At a glance it looks like it may print 0, 2, 4, 6, 8.  But in fact it prints 10, 10, 10, 10, 10.

The reason is that all five instances of the Func objects created by the lambda are capturing a reference to the same mutable variable instance "i".  By the end of the "for" loop, the value of "i" is 5, so invoking the Func objects returns "i*2", which is 10.

If you want to write code like that that prints 0, 2, 4, 6, 8, you can do it by changing the "for" loop to this:

    for (int i = 0; i < 5; ++i)
    {
        int copy = i;
        actions.Add( () => copy * 2 ); 
    }

There is a different instance of "copy" for each iteration of the loop.  As a result, each lambda captures a different "int" object.

If you feel that this is rather subtle, you’re not alone.  This example is based off a question on StackOverflow.  But nearly everyone trips over this at some point.  (The astute reader will note that I’ve even run into it myself on this blog – see the C# code at the end of this blog entry.)  For other examples, see this question or this one.  And this isn’t just limited to C#.  People run afoul of this in Python as well, as seen here and here.  (I expect there are more such questions; those are just the ones I found when glancing quickly.  EDIT: There are dozens more instances of this question on StackOverflow; it’s one of the most common questions.  See also Eric’s blog for a nice description.)

In general, with every language that has both mutable variables and closures (lambdas that can capture their environment), you run into this issue.  The lambda captures the mutable variable now, but gets evaluated later, after further mutations may have occurred.  This is an instance of the more general notion of how "lazy evaluation" and "side effects" don’t always mix nicely.  (You can read lots more on the topic by doing a web search for e.g. "closure capture value reference".)

Ok, fine, so this is a gotcha in most languages with mutables and closures.  So, you will ask, how does F# deal with this?  I’m so glad you asked!

Capture in F#

Let’s try transliterating that first C# example into F#.  I write

let FirstAttempt() =
    let actions = new List<unit->int>()
    let mutable i = 0
    while i < 5 do
        actions.Add( fun () -> i * 2 )
        i <- i + 1
    for act in actions do
        printf "%d " (act())    
    printfn ""

What do you think it will print?  The answer: it doesn’t compile!  The compiler points inside the lambda ("fun") and tells me

The mutable variable ‘i’ is used in an invalid way. Mutable variables may not be captured by closures. Consider eliminating this use of mutation or using a heap-allocated mutable reference cell via ‘ref’ and ‘!’.

One interpretation of this error message is "you are about to fall headlong into this messy gotcha of mutables+closures, so I (the compiler) am going to stop you before you have an accident".  Ok, great, so the compiler stopped me before I incautiously drove off a cliff.  How do I do what I want?

Well, that depends on what I want.  The compiler has stopped me from perhaps accidentally capturing mutable state, and now I have to choose.  Do I intend to capture mutable state or not?  That is, do I want to print "0 2 4 6 8" or "10 10 10 10 10"?  If the former, then I need to ensure that the identifier captured by the lambda is not a mutable, which leads naturally to the analogue of the revised C# example:

let Option1() =
    // prints "0 2 4 6 8"
    let actions = new List<unit->int>()
    let mutable i = 0
    while i < 5 do
        let copy = i
        actions.Add( fun () -> copy * 2 )
        i <- i + 1
    for act in actions do
        printf "%d " (act())    
    printfn ""

The new identifier "copy" is not declared mutable, so now the lambda can capture it.  In each iteration of the loop, "copy" is bound to a different value, so each lambda captures a different value.

On the other hand, if I did intend to capture mutable state, then I can use "ref".  As suggested by the compiler diagnostic (and discussed in the previous blog entry), one can use ref cells to hold mutable state that can be captured by closures.  So to write code like the original C# example I could say

let Option2() =
    // prints "10 10 10 10 10"
    let actions = new List<unit->int>()
    let i = ref 0
    while !i < 5 do
        actions.Add( fun () -> !i * 2 )
        i := !i + 1
    for act in actions do
        printf "%d " (act())    
    printfn ""

Now "i" has type Ref<int> – an object with a single integer field.  "i" itself is immutable (it’s a reference to that object in memory; "i" never changes to point to some other object), but the int stored inside the object is mutable.  The lambda captures "i", an immutable reference to the mutable object, and so when it finally executes "!i" it will read the current value of the int field in that object.  (There’s nothing magic about "ref" here, any heap-allocated object would do.  The point is I needed to add a layer of indirection so as to get ‘reference semantics’ rather than ‘value semantics’.)

Language design commentary

Any time a language designer adds closures to a language, he has to decide the semantics for the symbols being closed over.  Ought closures capture by value or by reference?  If you’re in a totally pure (side-effect-free) language, then it doesn’t matter – both "by value" and "by reference" yield the same results.  But one you introduce effects, the distinction matters.  That’s the reason that the programming "teaser" that started this blog entry is, in fact, a brain-teaser; the human reader can easily imagine the program being executed as though the lambdas capture by-value, though in fact C# captures by reference.

F# takes an interesting tack here.  Rather than choose to capture "by value" or "by reference", the F# compiler notices if these two different capture modes would yield distinctive behavior(*) (simply by noting if any of the captured symbols are declared as local mutables), and if they would, then the program doesn’t compile.  The advantage of this strategy is that it makes you far less likely to write brain-teaser code (code that you cannot easily predict the behavior of just by reading it).  The disadvantage is that when you do really want to capture mutable state, you may have to rewrite a bit of "let mutable" code to use "ref"s instead.  Scenarios for capturing mutable state like this are relatively uncommon, so the F# approach seems like a good trade-off.

(*) This is not entirely true, as F# lambdas can capture "let mutable" symbols bound at module-scope or class-scope, but not those bound at expression-scope.  Why this distinction?  Modules and classes are OO software engineering structures designed to encapsulate members in a way that makes it easy to reason about their lifetime, concurrent access & mutability, etc.  As a result, capturing these entities is allowed.  Expression bindings, on the other hand, are less appropriate software-engineering site for such purposes, and thus the ad-hoc capture of let-bound mutable variables from expression bindings is not part of the F# design.

There are a variety of choices available to language designers and compiler implementers… As Jared pointed out in a comment on my prior blog entry, another option is for compilers to emit a warning diagnostic when closing over mutables; apparently this is what VB does (I haven’t tried it myself).

A final note

Of course, we could have avoided all of these issues by eschewing mutation from the start.  When everything is immutable, the code in F# is both shorter to write and harder to misinterpret:

let CompletelyImmutableOption() =
    // prints "0 2 4 6 8"
    let actions = List.init 5 (fun i -> fun() -> i*2)
    for act in actions do
        printf "%d " (act())    
    printfn ""

When nothing is mutable, you don’t have to reason about whether the lambda will be called "now" or "later" – the value will always be the same.  This is the principle motivation for reducing the number of side-effects in your code; "pure" code without side-effects is immune to changes elsewhere in the program, and thus is easier to reason about (since many considerations, such as ‘timing’, can be ignored in effect-free code).

The F# “ref” type

I haven’t written much about the F# "ref" type, as it’s not used all that often.  But I have an interesting blog entry coming up that needs "ref", so I thought I should write a short blog entry on the topic to get the basics out of the way.

Values and Variables; "let" and "let mutable"

In F#, immutability is the default; when I write

    let x = 1

the symbol ‘x’ is permanently bound to the value 1 for the whole scope of ‘x’.

F# introduces the more verbose "let mutable" syntax for creating mutable variables, as in

    let mutable x = 1
    printfn "%d" x  // 1
    x <- x + 1
    printfn "%d" x  // 2

The value of a mutable variable can be accessed just by referring to the variable name (e.g. "x"), and an assignment operator "<-" mutates the variable’s value.

That information is likely "old hat" to you.  But did you know there is another way to do mutability in F#?

The "ref" type

F# has another construct for mutable state that it inherits from OCaml: refs.  A "ref" is a mutable heap-allocated cell that holds one piece of data.  Here’s a short example:

    let y = ref 1
    printfn "%d" !y  // 1
    y := !y + 1
    printfn "%d" !y  // 2

In that snippet, "y" has type "int ref" (a.k.a. "Ref<int>").  There are three notable entities here:

• The function "ref", which allocates a new ref cell given an initial value,
• The prefix operator ‘!’, which dereferences a ref cell (returns the value stored inside it), and
• The ref assignment operator ":=", which updates the value stored in the ref cell.

The syntax is a little ugly in my opinion (especially when so many of us are now accustomed to ‘!’ meaning "not"), but it’s easy and straightforward to use.  For those who like to see a more operational definition of the construct, here is a possible implementation of a type that’s very similar to the one built-in to the F# library:

    type MyRef<’a>(x:‘a) = 
        let mutable contents = x
        member this.Contents with get() = contents
                             and set(x) = contents <- x
    let ref x = 
        new MyRef<_>(x)
    let (:=) (x:MyRef<_>) y = 
        x.Contents <- y
    let (!) (x:MyRef<_>) = 
        x.Contents

(In fact, both in F# and OCaml, the built-in ref type uses a "record" as an implementation, but I have said very little about records on this blog, and didn’t want to explain one unfamiliar construct via another unfamiliar one, so here I chose to write "MyRef" as a class, instead.)  Straightforward, yes?

So of course this begs the question: if F# has "let mutable", when would I ever use "ref" (other than to author OCaml-compatible code)?  It turns out that in some situations you must use "ref" instead of "let mutable", and I’ll describe those situations… in the next blog entry.

Next time

Here is a teaser for next time, though.  What does the following C# code print?  Is it 0, 2, 4, 6, 8?  Perhaps you should run it and find out.

    List<Func<int>> actions = new List<Func<int>>(); 
    for (int i = 0; i < 5; ++i)
    { 
        actions.Add( () => i * 2 ); 
    } 
    foreach (var act in actions) 
    { 
        Console.WriteLine( act() ); 
    }

We’ll see how this C# code snippet relates to F# "ref" next time, too!