The Least a C# Programmer Needs to Know about F# Part I--Implicit Types

Jomo Fisher--A few weeks ago, a fellow C# programmer asked me what the biggest differences between programming in C# and programming in F# are. Since then, I've been building a list of differences. My plan was to write a single article that discussed everything. This morning the list got too long to reasonably put in a single article. Also, I'm not sure when I'll be done discovering the differences. So here's my first in a series of articles. (This is based on the 3.0 version of the C# language. If you want to see what's new in C#, it might be helpful to start here .)

You rarely mention types in F# code

In version 3.0, C# added the var keyword. This keyword allows you to not specify a type and instead rely on the compiler to figure out the type.  This works for locals only so most types are still explicitly specified in the code. In F#, this balance is reversed. You can explicitly specify types but you're rarely required to. F# has a powerful system for deducing the types. Consider this F# function:

let Add a b = a + b

This defines a function which adds two of something to each other. So what are the types of the variables a and b? The F# compiler has chosen int because of the addition that's happening in the function. A second function:

let AddPlusOne a b = a + b + 1.1

looks similar, but now the a, b and the return of the function are types as float. In this case, the compiler decides float is the right type because we're adding constant float value.

Most of the time in F# you don't specify types. I find myself relying heavily on the tooltips in Visual Studio for type information:

I think its legitimate to be uncomfortable with this level of implicitness. Especially coming from the C++ diaspora there is a tradition of being explicit when possible. Indeed, in F# you are free to explicitly specify types everywhere if you choose.

That said, I really like C#'s type inference and have used it in production code (LINQ to SQL). It tends to make the code more readable because you spend more time looking at the algorithm and less time looking at concrete type names.  I haven't shipped or maintained F# code yet, but my feeling is that more type inference is better.

This posting is provided "AS IS" with no warranties, and confers no rights.

Comments

• Anonymous
  October 18, 2007
  PingBack from http://www.artofbam.com/wordpress/?p=10276

• Anonymous
  October 18, 2007
  The comment has been removed

• Anonymous
  October 22, 2007
  Here's to hoping that F#/FP will influence C# even more :).

• Anonymous
  October 23, 2007
  Peter, I find that perfectly normal, what if index was uint.MaxValue and value was -1. The only type that could store the result is a long.

• Anonymous
  October 31, 2007
  Expert F# is about practical programming in a beautiful language that puts the power and elegance of

• Anonymous
  October 31, 2007
  Expert F# is about practical programming in a beautiful language that puts the power and elegance of