The more I study the Dynamic Language Runtime (DLR), the more I am convinced that it deserves to be the centerpiece of Microsoft's .NET 4.0 strategy. I am a statically typed languages guy. Or at least I have been. I love the robustness that the compiler applies to certain preconditions for using objects. Type safety is great but I don't think that statically typed languages go far enough to be honest. I am excited about Spec# because of its supports for invariants, pre and post conditions, static program verification, etc. Will Spec# ever go mainstream? It doesn't appear to have the momentum that F# or IronPython have, to be frank about it. But maybe we'll see some ideas creep into C# from the Spec# research that Microsoft is doing. I have my fingers crossed.

On the other end of the spectrum is IronPython 2.0, Microsoft's first DLR-based implementation of the Python programming language. I just love Python. It's so clean and simple that almost anyone can learn and use it effectively after studying it for an hour or two. If I could send a note to myself in the past to change one thing about my career (besides the winning lottery numbers for the past decade) it would be to encourage my younger self to learn Python back in the mid-1990s. I knew about the language back then but I was a C++ bigot. I wish I had been more open minded. So much of my approach to software development would have been better if I had learned Python back then. I was working in the Intel Architecture Labs and had the perfect opportunity to do so, too. We were helping a very young company named Yahoo.com to evaluate e-mail providers to purchase. We ended up recommending RocketMail technology which was based almost entirely on server-side Python scripting. I had the perfect opportunity to learn Python from real experts right there in front of me and I let it slip right by me.

Well, no sense living in the past, right? I know Python really well now and it has changed the way I think about software development. Learning Python made me fall in love with Ruby and LISP and F#, too. I'm a real polyglot now and being able to understand how these other languages solve problems helps me design better in the language I use every day: C#. By the way, the term polyglot from its Greek roots literally means many tongues. I'm excited about the DLR because it's enabling Python and Ruby on my favorite platform. But the DLR is so much more important than that. It's the Language of Languages. The DLR defines the primitives that must exist on the boundaries of our languages to make them interoperate. In the same way that COM unified the dispatch model in the 1990s through IUnknown and IDispatch, the DLR will define the call semantics and dispatch models for the .NET Framework for the 2010s through IDynamicObject and DynamicMetaObject.

Pretty soon, we'll see a flurry of languages appear on top of the DLR. A bunch of them are already in development. But we'll also see a wave of DLR object binders appear that have no significant language support on the platform, too. The effects will be profound. Imagine a Java RMI bridge written as a DLR object binder. Using the dynamic type in C# 4.0, you could make calls to remote Java objects from .NET as if they were just part of the framework. Or imagine a type binder that exposes RESTful services as a dynamic object model. There's really no end to the possibilities here. The key to all of these scenarios is the enablement of dynamic services and that sounds a lot like what Web 2.0 was supposed to be.

Throughout this series, I will be exploring the F# (pronounced F Sharp) language as a beginner. Perhaps you're just like me in that you've never worked with the F# language before but you are very curious about it. You may not understand the hype you've been hearing about so-called functional languages. But that's OK. If you want to learn along with me, that would be great.

Along the way, I welcome your comments and feedback, both to instruct me and other readers. You can get an overview of the complete series by visiting the series index. Enjoy.

Part 4 - Imperative Features

The F# programming language is not just a functional language. It has features of imperative and object-oriented languages as well. This is, in fact, what makes F# so compelling to work in. By combining the best features of functional, imperative and object-oriented languages, F# has something to offer to just about everyone. Some people say that by trying to be all things to all people, computer programming languages run the risk of becoming diluted. This is certainly one of the arguments we hear about the C# language whevener new features are added to it. And F# is no different except that it's a new programming language. And as a new language, the designers of F# had a great opportunity to get the balance of the features of the language just right. Personally, I think they did a great job.

I think the best way to learn how the imperative language features in F# work is by comparing them to a language you're likely to know already. So, I'll use C# as the teaching tool. If you are a Java developer, don't worry. C# is very close to Java and you should be able to follow along easily. I've attached the source code at the bottom of this post if you want to download it. Building on the example I started last time, let's suppose you want to write a class to handle conversions between Arabic numerals and Roman numerals. If you analyze the way Roman numerals work, you'll see a pattern emerge. I'm only going to handle numbers between and including zero to 3,999 in my class. For that set of Arabic numerals, these are the rules:

• For the Arabic numbers 1000, 900, 500, 400, 100, 90, 50, 40, 10, 9, 5, 4 and 1, there exist discrete Roman numeral sequences that can be evaluated left to right. We'll call these the 13 Arabic divisions.
  
• Only the sequences for the values of 1000, 100, 10 and 1 can be repeated in a Roman number.
• No repeatable Roman numeral can repeat more than three times.
• After encountering the Arabic divisions 900, 400, 90, 40, 9 and 4, no other value in the same order of magnitude (base 10) may be included in the value or the sequence.

Following these simple rules, one can parse an Arabic number by iterating over the 13 divisions, subtracting out the division amounts and accumulating the Roman numeral sequences until the value reaches zero. To parse a Roman number into an integer, you can also iterate through the 13 divisions, accumulating the associated number quantities as you go. As long as the rules are observed, it turns out to be a simple task. I am going to start off by designing a simple interface in C# that allows me to get and set the Arabic integers and Roman numeral strings implementing classes. For the remainder of this post, I am going to implement this interface in a C# based class then again in an F# based class to compare and contrast the two languages.

Now, to begin with implementing the rules shown above, I need some sort of data structure to manage the information about the rules. The three pieces of information I need to collect about each of the 13 Arabic division points are:

• The integer value of the division point.
• The associated Roman number sequence.
• A count of divisions to skip if the current division in selected at least once.

I could create a very specific class to manage this information. Or I could try to implement something a bit more generic. To illustrate one of the important things about F# that you'll need to know later, I'm going to go down the generic path by creating something called a Tuple. In short, a Tuple is a class that will be able to hold a combination of three bits of data. I can refer to those parts as P1, P2 and P3 later. The Tuple class might look like this in C#:

In my C# based class, I am going to create a Tuple<int, string, int> to hold the data for managing my Roman numerals:

Knowning a bit about Roman numerals and the rules I outlined above, you should be able to recognize this data and what I'm going to do with it. To implement the IArabicRomanConverter interface, the ArabicValue implementation in C# is pretty simple. I'll create an integer backing value and a simple property that does a bit of range checking.



The Roman numerals above value 1000 get a bit strange so I am going to leave them out of this example. Considering the rule that no single Roman numeral sequence can be repeated more than three times, my class only handles non-negative integers below 4000. The RomanValue property required to flesh out the IArabicRomanConverter interface is a bit more complicated. I'll show it in two parts. First the getter:



After handling the special case for the number zero, a StringBuilder is used to accumulate the Roman numeral sequences that are collected as each integer value in the array of Tuples is encountered. It's simple to loop through the Tuples, subtracting off the value of each Tuple that's found, going from the largest to the smallest value in the list. The setter for the RomanValue property is a bit more complex because the rules for Roman numeral repetition have to be observed. The setter looks like this in C#:



After the formality of dealing with null, trimming the input string and converting to uppercase, an accumulator is set up to receive the value of the Roman number as it is parsed. String comparisons on the second part of each Tuple are performed in a loop. The rules about allowed repetitions are observed by counting how many times each Tuple sequence is applied. If any Tuple is applied more than three times or if any sequence that is not allowed to repeat appears more than once, an exception is thrown. It turns out that the skip count portion of the tuple (part three) can be used to determine which sequences are allowed to repeat more than once. The cardinal values of 1000, 100, 10 and 1 have skip counts of zero, meaning that when they are used in the parsing operation, the list pointer does not skip over the next item in the list. Those values having zero skip counts are also the ones that can repeat according to the rules. Finally, if any part of the string is left over when the parsing is complete, it's invalid so an exception is thrown.

OK, so the C# class to convert Arabic and Roman numbers is pretty simple. Now, we need to look at what an F# class that does the same thing might look like. Be aware that the code you are about to look at is not ideal. I ported it over to be as close as possible to the C# code so you could start to draw some conclusions in your mind's eye. A more pure F# implementation of this class would look quite different. But for now, the inefficiencies in the F# code you'll see are OK because they are instructive. In a future post, I will show you a near ideal implementation of this class in F#. I'm going to show you the entire F# class below and describe what happening in a list below it. Here's the code:

The type keyword on line 5 is important. It's the equivalent of the class keyword in C#. The next thing I'll point out is the use of the mutable keyword on line 6 in declaring the _arabicValue field. The mutable keyword is at the heart of the imperative language features in C#. If you remember, imperative means "duty to change" in English. So, an imperative language is one that focuses on managing changes in the state of data as the means for tracking calculations. A functional language, on the other hand, treats functions as first-class citizens, using chains of function calls to manage computation. In F#, when you want to be able to change a bit of data, you must mark it as changeable using the mutable keyword (or by another means as we'll see shortly). Also notice that on line 5, I manually declared that the _arabicValue field is of type integer. As you may know, with F#'s incredible type inference system, declaring types is usually not required. F#'s parser goes to extraordinary lengths to figure out what types we're working with by observing how we use them. And it may be that, in this case, F# could figure out that _arabicValue should be an integer. However, it's not always important or prudent to let F# perform type inference. In this case, we know that the _arabicValue will always be an integer so it's OK to say so.

Next, on lines 15 through 20, you can see the _divisions list that in C# consisted of an array of Tuple instances is quite a bit more compact in F#. Lists, Sets and Sequences are first-class citizens in F#, with language constructs to help declaring and manipulating them. Declaring a literal List in F# is done by separating items by semi-colons and using square brackets to bound them. What's happening inside the _divisions List is equally interesting. In C#, I had to write a special class to group my Roman numeral management data into Tuples. But in F#, tuples are also first-class citizens. Separating literals by commas and enclosing them in parentheses creates an F# tuple on the fly as you can see. Collecting tuples into lists is a powerful way to organize strongly-typed data in memory, almost like a database.

Next, you'll notice on line 22 that I am implementing the IArabicRomanConverter interface in this class. This is quite a bit different than the interface implementation models we find in languages like C++, Java and C#. Those languages declare up front what their intentions are. In F#, however, you simply pick the spot where you want to start implementing an interface and have at it. Now, if you scan down the code, pay special attention to lines 23 and 32. These two lines represent the declaration of the two interface properties we need to define. The prefix of "x." on those two declarations is important here and you should try to understand what it means. In C# or Java, you know about the this parameter which is passed invisibly to instance methods and properties of a class. In F#, though, you have to declare the parameter that represents the invoking object yourself. However, rather than passing that parameter on the right side of the declaration, following the name as you might expect, you must do it as shown on lines 23 and 32 instead. The "x." prefix means "within this property, I would like to refer to the invoking object as x." In fact, in the getter for the ArabicValue property on line 24, you can see the "x." designation in use when fetching the class's mutable _arabicValue field using "x._arabicValue". If we had declared the ArabicValue property as "jabberwocky.ArabicValue", we would have fetched the _arabicValue field in the getter as "jabberwocky._arabicValue" instead. Make sure you understand that before proceeding.

The raise statement on line 27 is noteworthy. The raise keyword is equivalent to the throw keyword in C++, Java or C#. The rest of the ArabicValue property implementation is pretty straightforward. However, I want to point out something about line 30 for a moment. There's an operator in use there that you may not understand. When you see the characters "<-" it means assignment. In C#, for example, a single "=" character means assignment whereas a double "==" means equality test. In F#, a single "=" character means equality test whereas "<-" means assignment. I really like that notation. It's like an arrow that says to me, "copy the data in this direction". Of course, it's no surprise that only mutable fields  may be on the left side of the "<-" operator.

Now, let's turn our attention to the RomanValue property implementation in the F# code. Let's focus on the getter first because it's simpler. On line 41, draw your attention to the ref keyword. This keyword is the other way to create mutable data in your F# code. This type of mutable data is called a reference cell. Reference cells are a great way to hide so-called side effects inside of a class boundary. In general, in F#, if you must use mutable data, limiting the scope of the mutation to a specific member or class boundary is a good way to reduce the potential for side-effects that would make the functional programming model less effective. The reference cell called value that's declared on line 41 is limited to the get accessor for the RomanValue property. Actually, if you look at the indentation, which helps define scope in F#, the value reference cell is limited to the block comprising lines 38 through 53 created by the else clause on line 37. So, although the reference cell named value is mutable, it's mutation is limited to a very small scope. This is a good idea, always. Looking at line 51, you'll see an odd syntax that's likely to trip you up. The ":=" operator is used to mutate reference cells, just as the "<-" operator is used to modify class-level mutable fields as discussed earlier. And the "!" operator before the reference cell usage on the right of the ":=" is somewhat like the "*" operator in C Language or the "&" operator in C++. Because the reference cell named value was declared with the ref keyword, it must essentially be "re-referenced" to get to its value.

OK, F# is a functional language so functions are first class citizens. I keep saying that. In lines 47 though 51, you can see the definition of an anonymous function that will be passed to the List.iter function. Passing functions to functions. We're OK with that now, right? I wrote line 46 as I did on purpose to demonstrate a special operator that's unlike anything you've probably encounted before. The forward pipelinging operator "|>" is very important in F# and, like most really important things, it's incredibly simple in defintition yet incredibly difficult to understand without some context. When you see "|>", just imagine that the object or result on the left is being fed into the function on the right. You can chain these forward pipeline operators in interesting ways to give F#'s type inference engine much more power. More on that later. For now, you can see on line 47 that I am iterating over a list using the List.iter function. However, the parameter to List.iter is missing on line 51 (just after the closing parenthetic mark). Where's the parameter coming from. Well, on line 46, the _divisions list is being forward pipelined into List.iter using the "|>" operator. I didn't have to write it this way but I wanted to pick out a simple example that helps you understand how that operator works. In future posts in this series, you'll need to draw on this understanding for much more complex examples.

The last thing I want to point out about the get accessor for the RomanValue property is on line 48. What you see there is called tuple parsing. Tuples are made up of a fixed number of parts of varying types. When you have a tuple in hand, such as the division parameter passed by List.iter as it iterates over the list of tuples in my class, it can be broken up into its constituent parts. In this case, for the getter on RomanValue, I only need parts one and two because the third part contains the skip count. I only need the skip count when parsing Roman number strings into integers. So, the syntax seen on line 48 does what I want. The lone underscore in the third place says "I don't care about this part of the tuple, so toss it". The first two parts go into values named dValue and dSymbol. And you can see that I use those parts in the while loop at the end of the anonymous function being invoked by List.iter.

You're probably expecting me to dive into the set accessor the the RomanValue property now. After all, I said we would start with the get accessor because it was simpler. But that's not really true. The set accessor is only longer. There really aren't any new concepts introduced there. But everything you've learned so far is there. Read through the set accessor source code on lines 55 through 99. If you were paying attention so far, you should be able to understand the code. And that means you're on the way to becoming an F# programmer. In the next post, I'm going to show you how to write this class the right way, the F# way. And that will give us some fresh ideas for how to make our C# better. For me, that's the whole point of learning this new language.

Click here to download the source code for this blog post (20Kb)

That's all for now. Feel free to take a look at the other parts of this series exploring the F# language by visiting the series index.

Throughout this series, I will be exploring the F# (pronounced F Sharp) language as a beginner. Perhaps you're just like me in that you've never worked with the F# language before but you are very curious about it. You may not understand the hype you've been hearing about so-called functional languages. But that's OK. If you want to learn along with me, that would be great.

Along the way, I welcome your comments and feedback, both to instruct me and other readers. You can get an overview of the complete series by visiting the series index. Enjoy.

Part 3 - Functional Programming

An Introduction to Functional Programming with F#

Many years ago, when a new programming language appeared, the few programmers who existed would, on average, spend a few days or a weeks learning the syntax and the concepts of the language. We invested that time because we were looking for ways to fill in the gaps left by our 9-to-5 languages. And there were many gaps to fill. I started out my programming career using C Language and a machine language assembler. We wrote to the metal and achieved truly amazing performance in our applications. But we had to build almost everything from scratch. As a result, we spent way too much time working on the fundamentals and way too little time adding tangible value to the businesses that we served.

But in recent times, languages like C# and Java have become so rich that most developers don't feel a need for spending a lot of their spare time understanding new things that are vastly different from that which they already know. While we may spend time learning new techniques, those new skills are often aimed at increasing the efficiency or reducing the complexity with which we program in our favorite language. Putting some rough numbers in place, I'd say that when I was a C Language developer, my language did 65 percent of what I wanted it to do. C++ gave me about 75 percent satisfaction and Java approached 85 percent. C# is so rich, however, that I believe I'm achieving 95 percent satisfaction in using it. But there are still some things that are hard to do in C#.

Over the past couple of years, I've been using the Python language to help in those cases where C# is just too statically typed. In .NET, I can inject Python code directly into C# using the Dynamic Language Runtime to get an interesting set of capabilities. Mixing Python into C# can give C# a kind of fluidity that cannot be achieved on it's own. But dynamically-typed, duck-typed languages like Python also have their problems. Sometimes they are just too weakly typed to be valuable in a large-scale commercial deployment. For larger applications, I rely on the safety of the static typing that C# provides. In searching for a language that would have the compile-time type safety of C# with the type inference capabilities of Python, I found F#.

My first stumbling block in learning F# was that in looking at the code, I couldn't tell what was going on. That's a huge barrier in learning any new language. Based on the richness of my favorite language as described earlier, if I can't figure out the syntax of a new language within ten minutes, I will probably stop trying at that point because with a little bit more effort, I can probably make C# do what I want. When I look at Visual Basic or Ruby code, I can generally tell what's going on despite the fact that I am not proficient in either of those languages. But F# really threw me for a loop. As I stared at F# code for the first time, I struggled to find some prototype in my brain deposited during my 25 year-long programming career that I could draw upon to make sense of this strange syntax. But I must admit, it just wasn't there. I did not possess the tools to discern the logic buried in the F# code I was looking at.

This was discouraging to me because my friends Amanda Laucher and Matt Podwysocki had told me so many great things about F# and I wanted to share their enthusiasm. But I asked myself, "If F# is that odd, should I step so far out of my comfort zone to learn it?" I almost gave up. Then my friend Justin Etheredge presented a talk on the Functional Programming Features in C# to the Richmond .NET User Group. In that talk, I recognized features that had crept into my favorite language and how they related to the fundamentals of F# which I had read about but didn't yet fully understand. I saw an opportunity to write better C# by learning F#. And that was enough to convince me that I needed to buckle down and learn F# once and for all.

Diving right into the F# syntax, let's take a look at some simple F# code. In this example, I am going to create an array of roman numerals and print them out to the console.

If you have the F# compiler and tools installed, you can simply paste this code into the F# Interactive tool (FSI). Since I am using version 1.9.4.19 of F#, I can change the directory to "C:\Program Files\FSharp-1.9.4.19\bin" in PowerShell or CMD.EXE and execute ".\FSI.exe". If you are using a different version of the F# distribution, your F# tools may be in a different location.

I am now going to walk through this sample step by step, pasting each part of the F# program into the FSI window. In this next graphic, I'll show what happens if you paste the first sample function named romanize into FSI.

Notice that when you paste the romanize function into FSI, it evaluates the code and outputs:

val romanize : int -> string

F# has essentially inferred the type of the parameter n as an integer and the output type of the romanize function as a string. If the F# compiler could talk through it's line of reasoning here, it might say something like, "I see how you are passing the parameter n to the List.nth function as its second parameter. So n must be an integer because that's the type expected by the nth function in the second parameter position. And by selecting the nth string from a list of strings as the last operation, the romanize function must return a string as its result type."

If you haven't already noticed it, the really interesting thing that's happening here is that although we didn't specify parameter type or return type for the romanize function, F# figured it out. And it did so at the time of compilation. So, we can already see that F# has some of the syntactical beauty of Python, Ruby or JavaScript combined with the type safety of C# or Java. Let's paste the next part of the F# program shown above into FSI.

After pasting the showArray function into FSI, we can see F#'s interpretation. However, in this case, we run into a type name that most of us will not recognize: unit. So, this function accepts a string parameter and returns a unit? What's a unit? None of the programming languages I use has a type by that name. And where's the parameter to the function that F# inferred to be a string? It's missing! Well, look at the implementation of the function as I walk you through its declaration step-by-step.

First of all, how did F# figure out that I was going to pass in a string array to the showArray function? Unlike the romanize function shown above, I didn't put the name of a parameter into the declaration of the function. As you may recall, the romanize function used a parameter named n in its declaration. But here, in the showArray function, there's no parameter shown at all. But, somehow F# figured out what was going on. How? Let me show you another way that you could have written the showArray function.

In this case, I've been a bit more explicit. But the output is (almost) the same. So, the original mystery still remains. How did F# figure out that the parameter, implicitly or explicitly defined, should be a string array? Well, as a test, check out this slightly modified method I'll call showArray2. Pay careful attention to the two differences you'll see (not counting the different function name).

Going top to bottom, change one that you should have noticed is that the printfn function is using a different format string of "%d : %d" instead of "%d : %s" as it did in the original showArray function. Change two is that in this case, F# has determined that the input parameter to the function should be of type int array instead of string array. You can see this by the fact that it outputs (int array -> unit) to the console.

So, how did changing the format string for the printing function steer the F# interpreter to this conclusion? C Language programmers may recognize %s to mean string when formatting output and %d to mean integer. And that's what these symbols mean here when used with printfn in F#, too. OK, let's try an experiment. If F# is really parsing the format string to infer the type of the input to this function, let's feed it something invalid and see what happens. In C, C++ or C# which are all strongly-typed languages, an invalid format string wouldn't be caught until runtime. But if our hunch is correct, F# will see the problem much sooner. Let's define a new function called showArray3.

Wow! F# actually does validate the format string and it must also be using the information it finds there to infer the types of other values. It saw the invalid %p format specifier and failed to compile it. That's pretty amazing to me! We've figured out how F# determined that strings would be input, but we still don't know how it knew that an array of strings (not just one string) would be required as a parameter. To understand that, we need to break down the syntax of the showArray function a bit more.

Notice that the function being invoked inside showArray is called Array.iteri. The Array class, which is fully qualified by the name Microsoft.FSharp.Collections.Array, is a helper class that contains interesting functions like the iteri function being invoked here. The iteri function iterates over the elements in an array, executing a function on each one. That function takes two parameters: the zero-based index of the array element and the value of the array element at that index. That function that is invoked for each element has to return nothing. In languages like C++ or C#, we would call a function that returned nothing void. In Visual Basic, you would call it a Subroutined instead of a function. But F# uses the term unit for this concept instead. The unit type is sometimes shown as empty parentheses () in F# interpreter output.I like to think of the F# term unit as meaning the function performs some unit of work that may produce a side effect but has no real return value. If you were to paste a method into FSI matching the functional signature of the Array.iteri function, you would see F#'s interpretation of the method like this:

val iteri: (int -> 'a -> unit) -> 'a array -> unit

The 'a syntax is F#'s way of saying "a generic type". So reading this in English, I might say, "The iteri function takes two parameters. The first parameter is a function. See the parentheses I put around that parameter definition to help you understand that? That function parameter take two parameters of its own. The first is of type int and second is one of whatever generic type the array I'm iterating over contains. That function to be passed as a parameter returns nothing, otherwise called unit. The second parameter to the iteri function is the array itself. And, finally, the iteri function returns nothing."

Now go back and look at the first parameter passed to Array.iteri in the showArray function. It reads:

(fun ndx value -> printfn "%d : %s" ndx value)

This maps to the (int -> 'a -> unit) portion of the Array.iteri signature shown above. The F# keyword fun means this is an inline function. The two parameter are ndx which is an integer and value which is a something, a generic thing held in an element of the array. F# needs to figure out what type that something is. In this case, since we are invoking printfn to print a string to standard output, the only way to determine what type value is, is to look at the format string passed to printfn. Since the value parameter maps to the specifier %s in the format string, the type of value must be a string. And since we are iterating over an array using Array.iter, the entire array must contain strings as a result. This is how F# figured out that the showArray method must accept a string array parameter.

Wow! I don't know about you but that makes my head spin. Forget for a moment that in this language called F#, I can pass functions around as parameters. That's not too big of a stretch if you've used function pointers in C Language or delegates/anonymous methods/lambda expressions in C#. But the depth of probing being done by the F# compiler for type inference is way more than most of us are accustomed to, including me. I like it though. The fact that the compiler is doing that much work for me means that I can write far less code yet have all of the type safety to which I'm accustomed in languages like C#.

Let's take the next step in the program started above by pasting the next line of F# code into FSI.

With this line of F# code, we're using another of the helper functions in the Microsoft.FSharp.Collections.Array class called init. If you could paste the function for init into FSI, it would interpret it like this:

int -> (int -> 'a) -> 'a array

Let's see if we can use the F# skills we've developed so far to read this in English. Array.init must take two parameters: an integer and a function. And it must return an array of some generic, unnamed type. The second parameter, the function one, takes an integer and returns a single instance of the generic type that the array that will be returned contains. So, matching up the call to Array.init in our sample code, the number 5 must be the first integer parameter. That essentially says "Create a one-dimensional array of length 5." And as we saw before in the showArray function, the F# keyword fun is being used here again when invoking Array.init to pass a function as the second parameter to it. This is standard F# faire. Passing functions to other functions is the F# way of doing things.

So, using the signature for Array.iter above, let's analyze what's actually passed as the second function parameter.

(fun value -> romanize value)

If this function must accept an integer, then the value parameter must be an integer. And since it must return a single instance of the type contained in the array, then the call to romanize value must return one of those. Going back to our romanize function definition, we can see that it accepts an integer and returns a string. The value parameter given here is an integer. That matches which is apropos. And the return type of the romanize function is used by Array.init to infer that the array it should create consists entirely of strings. Then the F# interpreter has aptly discerned the type of the value i in our small program as a string array. Lastly, let's execute the showArray function passing the string array i as a parameter.

The showArray method, accepting the value i as an array of strings, iterates over them invoking the printfn function to print the index and the value at that index within the array to the console.

You've learned a lot today, I hope. In the remaining 4 parts in this series, we'll ease deeper into the functional aspects of F# as we examine other language features. That's enough for now though. In closing let me show you how our little program would look if we used the #light;; directive. This directive helps clean up the F# syntax a bit depending on white space indentation to determine functional boundaries. As a part-time Python developer, I just love that feature of F#. White space should be significant, despite what my Ruby-coding friends say. Here's the light version. As an exercise, compare it to the one at the beginning to see what's changed.

That's all for this installment of my F# tutorial. Feel free to take a look at the other parts of this series exploring the F# language by visiting the series index.

[mp3:Why Learning FSharp Is So Difficult.mp3] 

My third installment in the Learning F# Series is coming out in the next day or two. While I was writing it, I had some time to reflect on why learning F# is so hard for an object-oriented programmer like me. So I decided to write some of those thoughts into the third installment. After reading it in context, though, I decided that my observations would be better stated as a separate article, outside of the tutorial altogether. If you are tracking my multi-part F# series, you don't have to read this to stay on track. But if you want to understand why F# and functional programming in general seems so hard to you, you may find this piece interesting.

Gestalt psychologists believe learning new things happens best when you already have a strong basis for the new information. That sounds obvious enough to be silly, doesn't it? Let's break it down a bit, though. The idea is that because most learning involves problem solving and because problem solving requires recognition, all learning must transitively be based first on recognizing the nature of the problems we face. In other words, the prototypes that we've developed throughout our lives become the glasses through which we see the world. More importantly, those prototypes must exist in the right combination and strength relative to the nature of the problems we face to become useful in solving them. When faced with a problem for which we have all the necessary prerequisites, an amazing thing happens which Gestalt psychologists call emergence. The rest of us call this phenomenon the proverbial a-ha moment that we've all experienced in learning new things.

Emergence has a peculiar quality that's worth understanding when you're about to study something new like the F# language. You see, emergence supposes that when the human mind discerns a thing, it happens as a single event in one discrete moment in time. Here's an example that may clarify my point. Suppose that someone handed you a picture of something you should recognize. You would never realize your recognition with this sort of pattern:

"Hmmm, what is this? I see an eye so this must be a living creature of some sort.
There's a long tube descending to the ground from the point between those eyes.
Could that be a snout? It's in the right place to be a nose but its odd looking, for sure.
And those big panels on the sides of what must be the face are absurdly large.
As strange as it may seem, they've got to be the creature's ears.
Those enormous curved white things protruding from the face couldn't be teeth, could they?
Its massive body seems to be supported by four thick pillars that must be the legs.
Oh, I see it now! That's a picture of an elephant!"

Think about it. In your adult life, if you've ever encountered the image of an elephant, you didn't reason through the recognition process in that way. You can't even admit that you followed those steps so quickly that it seemed instantaneous. No, in fact your recognition was instantaneous and no deductive process was required at all. The prototypes from your youth were already properly connected in your mind to help you recognize the image presented to you singularly and instantaneously as an elephant.

The pattern of your recognizing the elephant as a singularity is, in fact, where Gestalt psychology gets its name, by the way. The German word gestalt has the meaning "being more than the sum of a thing's parts." The elephant is certainly made up of parts but in the mind's eye, it's a single entity. In this same way, we go about our lives, instantly and singularly recognizing objects and ideas thousands of times each day. Some are visual, some are aural and some are purely cognitive. These points of recognition happen so often and so naturally in the course of an average day that we don't even realize that we're doing it. That instantaneous recognition process is emergence.

Now think for a moment about how a toddler, who may have no exposure to pachyderms would react to the presentation of a photo of an elephant. The thought pattern in the toddler's mind wouldn't be much different from the line of reasoning outlined above. Try to imagine that you're a child with cognitive prototypes for other mammals like cats, dogs, cows and humans in your mind. But no elephants yet. Now try to imagine your first encounter with an elephant. Go back to the paragraph above where I proposed a line of reasoning for the recognition process. In this case, there is no way for emergence to occur in the toddler's mind because he hasn't the prototypes necessary to finish the work. So he must follow a pattern of discovery that is slower and more deliberate than the emergence experience. And the last step of the discovery process cannot be completed for the child without some assistance.

When an adult (or another educated peer) teaches the child by confirming hints about the trunk and the tusks and the thick legs of the elephant, a new prototype will be created that will become a new singularity in the child's mind, ready for future chances at emergence. For the remainder of that child's life, the gestalt of elephant-ness, i.e. the entire elephant as a singular concept with parts bearing distinct features, will emerge instantaneously every time he encounters a new instance of an elephant.

So, what in the world does Gestalt Psychology and emergence have to do with learning F#? A lot, I think. If you've always used imperative programming languages like C++, Java, Visual Basic and C#, you might find functional programming as strange as our toddler finds his first encounter with an elephant. It may be that you don't have the prototypes necessary to learn F#, in which case, you may find yourself falling back to the discovery model that our toddler used to build his pachydermal prototype. Admittedly, the discovery mode of learning is much more arduous than learning that relies heavily on prototypes. Discovery learning often goes much slower, too.

Looking at F# code for the first time, you'll almost certainly ask, "What in the world is that thing?" And just as the toddler might use an eye in a photograph as a starting point, you may find yourself struggling to find a starting point in F# source code to discern the logic that you've been told flows from it. Finding that eye is possible, though. In the remainder of my Learning F# Series, I'm going to attempt to give you that starting point that will help you identify other parts that eventually will lead you to understanding the body of functional programming. My advice is to stick with it. Get outside of your comfort zone and do some real discovery. You'll be happy you did.

Throughout this series, I will be exploring the F# (pronounced F Sharp) language as a beginner. Perhaps you're just like me in that you've never worked with the F# language before but you are very curious about it. You may not understand the hype you've been hearing about so-called functional languages. But that's OK. If you want to learn along with me, that would be great.

Along the way, I welcome your comments and feedback, both to instruct me and other readers. You can get an overview of the complete series by visiting the series index. Enjoy.

Part 2 - Installation and Configuration

To get started with F#, you need to get the compiler installed. Go to the Microsoft Research F# Downloads Page and download the latest release. If you are using Windows, download the MSI installer. If you're on Windows and want the Visual Studio experience but can't afford those tools, there is another interesting option. You can first install the Visual Studio 2008 Shell which is a free Integrated Development Environment (IDE) that Microsoft made available to help people integrate with specialized tools like F# or IronPython, for example. Whether you are using the full edition of Visual Studio 2003, 2005 or 2008 or the free Visual Studio 2008 Shell, the F# installer will affect all of the necessary changes to make working with F# in the IDE a smooth experience. If you don't have Visual Studio and don't care to use an IDE, you can always run the F# tools from the command line. And if you are using Mono runtime on Linux or Mac OS, download the ZIP file instead and follow the instructions in the README file to complete the installation.

At the time of this writing, I am working with version 1.9.4.19 released on May 1, 2008. Today, the F# installer requires one of Windows 2000, Windows XP, Windows Server 2003 or Vista and the .NET Framework 2.0. I've been running F# on Windows Server 2008 Standard Edition with no problems although Microsoft doesn't officially claim support for that operating system yet. If you are using Linux or Mac OS, you must install the Mono runtime.

If you aren't going to be using F# through the Visual Studio integration, you can skip all the way to the end of this article to the section entitled Using F# Interactive from the Command Line.

Installation on Windows

When you run the MSI installer you downloaded on Windows, you'll see something like this:

The installation usually takes about 5 minutes although your experiences may vary. After you're done with the installer, if you have Visual Studio, start it up. There's an add-in for F# Interactive that's installed but not enabled by default. You may want to turn it on. To do that within Visual Studio, select the Add-in Manager... choice from the Tools menu. You'll see a dialog that looks like this:

Enable the add-in entitled F# Interactive for Visual Studio by checking the box on the left. Press OK to close that dialog and save your changes. You'll see a tool window appear for the F# Interactive that looks like this:

This interactive F# interpreter is very handy. You can type or paste F# code into the interpreter window to try things out. But what's even better is that when you highlight code in the Visual Studio text editor and press the combination Alt+Enter keys, you can send the selected F# source over to the interpreter and run it. That's very handy, indeed.

Changing the Alt+Enter Key Assignment (ReSharper Users Only)

If you are using ReSharper, however, you may run into a problem here. If you are not using ReSharper, you can skip ahead to the next section entitled Using Alt+Enter and Alt+' to Evaluate F# Code in the Interpreter. If you use the standard IdeaJ/ReSharper keyboard settings, the Alt+Enter key combination is set by ReSharper to perform a different function within the scope of the text editor. So, when you press Alt+Enter in the text editor, the associated ReSharper function will run instead. To fix this, let's take a look at the keyboard settings. Here's the Text Editor scope key setting that shows how ReSharper's QuickFix function is assigned to the Alt+Enter key combination. This dialog is shown by clicking the Options... choice on the Tools menu in Visual Studio.

And here's Global scope key setting that shows how F#'s MLSendSelection function is assigned to the Alt+Enter key combination.

The easiest way to fix this clash of key assignments is to change one of them. Since I use Alt+Enter in ReSharper already, I decided to change the F# key mapping instead. I did this my clicking the Remove button in the dialog shown above to disconnect Global Alt+Enter key combination from F#'s MLSendSelection method. Next, I picked a new keystroke that makes sense. For me, Ctrl+Alt+Enter is close to the original and not used by any other add-in. Pressing those keys in combination while the text box under the "Press shortcut keys:" text has the focus makes the description of that keystroke appear in the text box. Next, I changed the scope of the assigned key by selecting "Text Editor" from the dropdown list entitled "Use new shortcut in:" and pressed the Assign button. There's really no sense in having that key assignment be Global in scope because, "What would the MLSendSelection method receive if there's no text editor open?" Does that makes sense? The dialog looked like this when I was done.

Using Alt+Enter and Alt+' to Evaluate Code in F# Interactive

Note: If you changed the key combination for invoking MLSendSelection as described in the previous section, anywhere you see Alt+Enter in the remainder of this tutorial, please substitute your selected keystroke instead.

To try out the F# Interactive tool window, you can type some F# code directly into the window or you can use the Alt+Enter and Alt+' (Alt+Single Quote) key combinations to send F# code from an open text editor. Let's try something simple. Open a new text window in Visual Studio and type a single line containing the following text

   printfn "Hello World.";;

This F# statement will invoke the printfn function for printing text to the console window. The literal text that we're going to print is "Hello World" minus the quotes of course. Lastly, the two semi-colons indicate the end of the "batch" if you will. More on that later. If you were to select all of the text you typed in by highlighting it in the text editor and press the Alt+Enter key combination, you would invoke F#'s MLSendSelection function in the IDE. The selected text would be run as a script and the output would show in the F# Interactive window. Here's what you might see:

Hey, you just wrote and executed the proverbial Hello World program using F#. Notice how the text output to the console that we expected to see shows up there. The Alt+Enter key combination you used is appropriate when you want to select only a portion of one line or multiple lines to send to the F# interpreter.

Another key mapping, Alt+' (Alt+Single Quote), exists after installing F# which is bound to a method called MLSendLine instead of MLSendSelection. As its name may imply, pressing Alt+' will cause the line on which the caret currently rests to be selected in its entirety and sent to the F# interpreter. So, the Alt+' key combination is useful for running one line of F# in the current text editor window at a time without having to select any text first.

Using F# Interactive from the Command Line

You don't have to use the F# Interactive add-in for Visual Studion. And if you're working on Mac OS or Linux using the Mono runtime, you need another option. In this case, the command line version of the F# Interactive tool can be used. On a Windows system, the FSI.EXE program is installed in the following folder:

   C:\Program Files\FSharp-<version>\bin

where <version> is the version number of the F# product you installed. For me, since I am using version 1.9.4.19, my binaries folder is:

   C:\Program Files\FSharp-1.9.4.19\bin

On Windows, you can invoke the help for the FSI.EXE by adding the --help flag to the command line.

Running FSI.EXE allows for interactive interpretation of F# code. After running FSI.EXE, enter the following text:

   printfn "Hello World.";;

and press Enter. You've just written the proverbial Hello World program using F#. Here's what it looks like running F# Interactive in PowerShell: 

When you're ready to quit F# Interactive, type #quit;; and press Enter. 

That's all for now. Feel free to take a look at the other parts of this series exploring the F# language by visiting the series index.

Throughout this series, I will be exploring the F# (pronounced F Sharp) language as a beginner. Perhaps you're just like me in that you've never worked with the F# language before but you are very curious about it. You may not understand the hype you've been hearing about so-called functional languages. But that's OK. If you want to learn along with me, that would be great.

Along the way, I welcome your comments and feedback, both to instruct me and other readers. You can get an overview of the complete series by visiting the series index. Enjoy.

Part 1 - What is F#? 

If you are like me, a software developer with a C++/C# background, you may have heard about the F# language but you haven't had a chance to learn anything about it yet. You may also be a Java developer or a Visual Basic developer who's curious. Don't let the name fool you. You don't have to be a C# developer to love F# once you start learning about it. As we'll see, the F# language doesn't have strong roots or ties to languages like C, C++, Java, C# or Visual Basic. As such, I think it can teach us a lot about alternative ways of thinking.

An FAQ (of Sorts) for Defining the F# Language

Here are some questions I've accumulated about the F# language. My answers below aren't definitive, by any means. But this is what I've learned so far. If you have other questions that you think belong in an entry-level FAQ for the F# language, let me know and I'll add them.

• With a name like that, is F# a derivative of C#?
• What does the F in the F# language's name mean?
• What is a functional programming language?
• What is an imperative programming language?
• Is F# object-oriented?
• Can F# be integrated into Visual Studio?
• Are there command line tools for working with F#?
• Is F# a portable language?
• Does F# require me to deploy a runtime library?
• Is F# a scripting language or a compiled language (or both)?
• How does F# perform in terms of speed as compared to other languages?
• Where can I go to find out more about F#?

With a name like that, is F# a derivative of C#?

Not at all. F# comes from a family of languages that were spawned by a language created in the late 1970s known as ML or MetaLanguage. The ML language has a special type inference algorithm built into it that allows it to infer the types of most expressions automatically. This allows the language to feel dynamically typed like many scripting languages while actually being statically typed. F# behaves this way as well. In F#, you can declare types but you don't often need to do it.

More recently, F# is a derivative of a language known as Objective Caml (or OCaml) which extended Caml (Categorical Abstract Machine Language), an ML derivative, by adding certain object-oriented capabilities to it. F# has a high degree of compatibility with OCaml source code as a result.

What does the F in the F# language's name mean?

I'm sure it's debatable but the F in F# mostly likely stands for the term Functional. It's hard to get an exact answer on this one but one can assume that since F# is often touted as a functional language, that must be the meaning. F# is not just a functional language, however. It's a multi-paradigm language that allows for functional programming as well as imperative programming. So, it's conceivable that the language could have been called I#. But the functional feature of F# sort of steal the show so, the name makes sense.

What is a functional programming language?

Words are designed to conjure up ideas and images. So, what does the word functional mean in the context of a programming language. Merriam-Webster's dictionary defines functional as:

1 a: of, connected with, or being a function b: affecting physiological or psychological functions but not organic structure <functional heart disease>
2: used to contribute to the development or maintenance of a larger whole <functional and practical school courses>; also : designed or developed chiefly from the point of view of use <functional clothing>
3: performing or able to perform a regular function

As an American English speaker, the third definition is the one that I'm likely to think of when I hear the word functional. If something is functional, it's performing as it is supposed to. For other English dialects, the term functional could conjure up other meanings. But when I hear the term functional programming language, I'm likely to think of a programming language that's able to do what it was designed to do.

Of course, that makes no sense at all. If programming languages didn't perform as we expected them to, we wouldn't call them programming languages at all. We would call them probability languages or gee-i-sure-hope-this-thing-does-something-useful-when-i-press-the-button languages. Instead, the term functional in the realm of programming languages relates to the use of functions (or callable mathematical parts) as the basis for computation rather than changes in state and the mutation of data. So functional programming languages emphasize the second of the three definitions given above, i.e. viewing computation as the sum of the parts (functions) that are used to describe a larger solution.

In the 1930s, something called the Lambda Calculus was conceived to explore how functional decomposition of a problem could be used to more naturally describe potential solutions to it. Nowadays, functional programming languages are just implementations of the Lambda Calculus as a specific system with some extra bells and whistles, as they say. As functional programming languages go, however, F# is not a pure because it includes constructs for mutability, i.e. changing the state of objects in certain cases.

What is an imperative programming language?

Just as we did for the term functional above, it's probably worth investigating what the word imperative means at this point. Merriam-Webster defines imperative this way:

1 a: of, relating to, or constituting the grammatical mood that expresses the will to influence the behavior of another b: expressive of a command, entreaty, or exhortation c: having power to restrain, control, and direct
2: not to be avoided or evaded : necessary <an imperative duty>

As an American English speaker, both definitions come to mind. Imperatives are about the will and the duty to change things. The term imperative programming language is understandable in this context because imperative programming is all about state management.

To understand how imperative systems are built, think about the modern computer system. From the hardware up, all computers are somewhat imperative in nature. We store memory as a series of electrical signals and manipulate those signals to change the meaning of the data they represent. Registers on the CPUs change value as programs execute to track things like the position of a stack pointer or the location of the next executable instruction in memory. If you think about it, the entire computer system is nothing more than a very large state machine with a googolplex of possible states.

Imperative systems are, by definition, mutable, meaning that they can mutate or change in some way over time to create state that is representative of the progress of the computation being performed. Imperative programming languages, in particular, usually allow the programmer to define global and/or local state through various memory constructs like variables and classes. Because F# is based on OCaml, it has some object-oriented features that depend on mutable data. As we'll see later, the F# keyword mutable is at the heart of the language's imperative programming model.

Is F# object-oriented?

Yes. F# supports the .NET typing model including:

• Classes
• Inheritence
• Interface implementation
• Polymorphism

All types in F# ultimately derive from the .NET type System.Object so the model is completely unified and compatible with other .NET languages.

Can F# be integrated into Visual Studio?

The installation package for F# includes complete integration with Visual Studio 2003, 2005 and 2008. Included are:

• A new F# project type (with file extension .fsharpp)
• Templates for F# source, scripts and interfaces (including ML-compliant ones)
• Templates for F# Lex and Yacc source
• Integrated debugger support
• A tool window for using the command-line tool called FSI.EXE (F# Interactive) for testing and running F# scripts and code

Are there command line tools for working with F#?

Yes. In fact, many people (like me) prefer working with the F# command line tools most of the time. There are F# command line tools in the installer package for:

• F# compilation (FSC.EXE)
• F# interactive interpreter (FSI.EXE)
• F# Lex compiler (FSLEX.EXE)
• F# Yacc compiler (FSYACC.EXE)
• Resource compiler (RESXC.EXE)

Is F# a portable language?

Using the #light directive, F# can compile or interpret most OCaml code. So if you use that directive, your F# code should port back to OCaml without much effort. However, dependence on .NET types that are not available on other platforms will, of course, make your F# code non-portable (or at least portable with a lot of effort to replace the missing types).

Does F# require me to deploy a runtime library?

Yes. There is an assembly called FSharp.Core.dll which is referenced by your compiled F# code. A command line flag for the FSC.EXE compiler exists called --standalone. If you use this flag, the compiler will statically link the core components in so that you don't have to deploy the core assembly with your compiled F# assemblies. Using the --standalone flag will add between one and two megabytes to your F# assemblies, though.

Is F# a scripting language or a compiled language (or both)?

F# is definitely a compiled language. But it also supports  scripting via FSX files. You can run FSX scripts at the command line using the --exec flag of the F# Interactive (FSI.EXE) tool. This is useful when you want to run some F# code without having to compile it first.

How does F# perform in terms of speed as compared to other languages?

Compiled F# runs about as fast as C# or C++. I don't have personal benchmarks yet but empirically and anecdotally, compiled F# seems to be about as fast as other compiled .NET languages. The F# compiler has a cross-module optimizer that can be enabled using the -O command line flag. This flag is turned off by default. Of course, without hard performance data, my assessment remains quite subjective. We will examine F# performance in detail later on in the series.

Where can I go to find out more about F#?

Here are some links I've found useful:

• Microsoft Research F# Home Page - http://research.microsoft.com/fsharp/fsharp.aspx
• The Blog of Tomáš Petříček, C# MVP - http://tomasp.net/blog/
• The MSDN Blog of Don Syme - http://blogs.msdn.com/dsyme/default.aspx
• The MSDN Blog of Chris Smith - http://blogs.msdn.com/chrsmith/default.aspx
• The Inside F# Blog of Brian L - http://lorgonblog.spaces.live.com/default.aspx
• The Blog of Matt Podwysocki - http://weblogs.asp.net/Podwysocki/

That's all for now. Feel free to take a look at the other parts of this series exploring the F# language by visiting the series index.