F# for Fun and Profit

“I think I understand functional programming at the micro level, and I have written toy programs, but how do I actually go about writing a complete application, with real data, real error handling, and so on?"

Are you fed up with all the hype about functional programming?

We’re coming into the home stretch now.

In a previous post, we saw how to avoid unnecessary evaluation of expressions in a workflow until needed.

In this post, we’ll take a detour and look at some tricks you can do with methods in a computation expression builder.

In the last few posts we have covered all the basic methods (Bind, Return, Zero, and Combine) needed to create your own computation expression builder.

In this post we’re going to look at returning multiple values from a computation expression using the Combine method.

Having covered bind and continuations, and the use of wrapper types, we’re finally ready to take on the full set of methods associated with “builder” classes.

In the previous post, we looked at the concept of “wrapper types” and their relation to computation expressions.

In the previous post, we were introduced to the “maybe” workflow, which allowed us to hide the messiness of chaining together option types.

In the last post we talked about how we can think of let as a nice syntax for doing continuations behind scenes.

In the previous post we saw how some complex code could be condensed using computation expressions.

By popular request, it is time to talk about the mysteries of computation expressions, what they are, and how they can be useful in practice (and I will try to avoid using the forbidden m-word).

In this series, we’ve looked at some of the ways we can use types as part of the design process, including: Breaking large structures down into small “atomic” components.

In this series we’ve seen a lot of uses of single case discriminated unions to wrap strings.

In a previous post, I talked about avoiding using plain primitive strings for email addresses, zip codes, states, etc.

In this post we will look at making implicit states explicit by using state machines, and then modelling these state machines with union types.

In the last post, we looked at how we could represent a business rule using types.

In this post, we look at a key benefit of F#, which using the type system to “make illegal states unrepresentable” (a phrase borrowed from Yaron Minsky).

At the end of the previous post, we had values for email addresses, zip codes, etc., defined like this: EmailAddress: string; State: string; Zip: string; These are all defined as simple strings.

In this series, we’ll look at some of the ways we can use types as part of the design process.

Before we get started on the detailed examples, we’ll go back to basics and do some simple porting of trivial examples.

NOTE: Before reading this series, I suggest that you read the following series as a prerequisite: “thinking functionally”, “expressions and syntax”, and “understanding F# types”.

So as we saw in the previous post, implementing interfaces in F# is a bit more awkward than in C#.

Interfaces are available and fully supported in F#, but there are number of important ways in which their usage differs from what you might be used to in C#.

This is a follow-on from the previous post on classes.

This post and the next will cover the basics of creating and using classes and methods in F#.

In this series, we’ll look at how F# supports object-oriented classes and methods.

In this post, we’ll take a small detour and look at how to create formatted text.

As we mentioned earlier in the “why use F#?”

In this post we’ll take a quick look at how F# handles the standard types that are built into .NET.

Before we finish with types, let’s revisit type inference: the magic that allows the F# compiler to deduce what types are used and where.

The enum type in F# is the same as the enum type in C#.

In this post, we’ll implement a simple stack based calculator (also known as “reverse Polish” style).

Last time we looked at parsing a command line.

Now that we’ve seen how the match expression works, let’s look at some examples in practice.

Pattern matching is ubiquitous in F#.

Now let’s look at a particular union type, the Option type.

Tuples and records are examples of creating new types by “multiplying” existing types together.

As we noted in the previous post, plain tuples are useful in many cases.

We’re ready for our first extended type – the tuple.

Let’s start with the simplest type definition, a type abbreviation or alias.

Before we dive into all the specific types, let’s look at the big picture.

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

Just like other .NET languages, F# supports throwing and catching exceptions.

In this post, we’ll look at the control flow expressions, namely: if-then-else for x in collection (which is the same as foreach in C#) for x = start to end while-do These control flow expressions are no doubt very familiar to you.

If you are coming to F# from an imperative language such as C#, then you might find a lot of the names shorter and more cryptic than you are used to.

The syntax for F# is mostly straightforward.

In this post we’ll look at the different kinds of expressions that are available in F# and some general tips for using them.

As we’ve have already seen, there are no “variables” in F#.