F# for Fun and Profit

In programming language terminology, an “expression” is a combination of values and functions that are combined and interpreted by the compiler to create a new value, as opposed to a “statement” which is just a standalone unit of execution and doesn’t ret…

NOTE: Before reading this series, I suggest that you read the “thinking functionally” series as a prerequisite.

Although we have focused on the pure functional style so far, sometimes it is convenient to switch to an object oriented style.

Now that you know how to define functions, how can you organize them?

It may not be obvious, but F# actually has two syntaxes - one for normal (value) expressions, and one for type definitions.

We have seen how to create typical functions using the “let” syntax, below: let add x y = x + y In this section, we’ll look at some other ways of creating functions, and tips for defining functions.

Function associativity If we have a chain of functions in a row, how are they combined?

In the previous post on currying, we looked at breaking multiple parameter functions into smaller one parameter functions.

After that little digression on basic types, we can turn back to functions again, and in particular the puzzle we mentioned earlier: if a mathematical function can only have one parameter, then how is it possible that an F# function can have more than one?

Now that we have some understanding of functions, we’ll look at how types work with functions, both as domains and ranges.

Let’s look at the simple function again let add1 x = x + 1 What does the “x” mean here?

The impetus behind functional programming comes from mathematics.

Now that you have seen some of the power of F# in the “why use F#" series, we’re going to step back and look at the fundamentals of functional programming – what does it really mean to “program functionally”, and how this approach is different from object…

This completes the tour of F# features.

As should be apparent, you should generally try to prefer functional-style code over object-oriented code in F#, but in some situations, you may need all the features of a fully fledged OO language – classes, inheritance, virtual methods, etc.

We have already seen many examples of F#’s use with the .NET libraries, such as using System.Net.WebRequest and System.Text.RegularExpressions.

In this final set of posts, we will look at some other aspects of F# under the theme of “completeness”.

Events are everywhere.

In this post, we’ll look at the message-based (or actor-based) approach to concurrency.

In this post we’ll have a look at a few ways to write asynchronous code in F#, and a very brief example of parallelism as well.

We hear a lot about concurrency nowadays, how important it is, and how it is “the next major revolution in how we write software”.

In this post, we’ll see how you can design for correctness (or at least, for the requirements as you currently understand them), by which I mean that a client of a well designed model will not be able to put the system into an illegal state – a state that…

You are familiar with static type checking through languages such as C# and Java.

We briefly noted earlier that when pattern matching there is a requirement to match all possible cases.

To see why immutability is important, let’s start with a small example.

As a programmer, you are constantly judging the code that you and others write.

F# has a special type of pattern matching called “active patterns” where the pattern can be parsed or detected dynamically.

A particularly convenient feature of F# is that complicated functions with many parameters can have some of the parameters fixed or “baked in” and yet leave other parameters open.

An important aspect of functional programming is that, in a sense, all functions are “interfaces”, meaning that many of the roles that interfaces play in object-oriented design are implicit in the way that functions work.

One nice thing about F# is that most types immediately have some useful “out-of-the-box” behavior such as immutability and built-in equality, functionality that often has to be explicitly coded for in C#.

In the next set of posts, we will explore a few more features of F# that I have grouped under the theme of “convenience”.

So far we have seen the pattern matching logic in the match..with expression, where it seems to be just a switch/case statement.

A well-known principle of good design is to create a set of basic operations and then combine these building blocks in various ways to build up more complex behaviors.

In the very first example in this series, we saw a simple function that calculated the sum of squares, implemented in both F# and C#.

In C#, there is a disincentive for creating new types – the lack of type inference means you need to explicitly specify types in most places, resulting in brittleness and more visual clutter.

As you have already seen, F# uses a technique called “type inference” to greatly reduce the number of type annotations that need to be explicitly specified in normal code.

After having seen some simple code, we will now move on to demonstrating the major themes (conciseness, convenience, correctness, concurrency and completeness), filtered through the concepts of types, functions and pattern matching.

In the next few posts we’ll move on to demonstrating the themes of this series: conciseness, convenience, correctness, concurrency and completeness.

In this example, we will compare the F# and C# code for downloading a web page, with a callback to process the text stream.

In this next example, we will implement a quicksort-like algorithm for sorting lists and compare an F# implementation to a C# implementation.

To see what some real F# code looks like, let’s start with a simple problem: “sum the squares from 1 to N”.

Here is a very quick overview on how to read F# code for newcomers unfamiliar with the syntax.

This series of posts will give you a guided tour through the main features of F# and then show you ways that F# can help you in your day-to-day development.