(Harry is @ DevTeach in Vancounver with his family this week. He was hoping to still do Morning Coffee posts, but that’s turned out to be infeasible. So instead, you get a series of pre-written posts about F#.)

Significant Whitespace

If you’re a Python programmer, you already know this one. Instead of delineating code blocks explicit with curly braces or begin/end keywords, F# uses whitespace. Code blocks are indented relative to their parent. This enforces readability standards as well as conciseness. You can see that in the code Additive function above. Technically, this is optional in F# if you specify the #light compiler option, but pretty much all the docs and books assume this by default.

Custom Operators

This is minor, but cool nonetheless. Many languages let you overload existing operators like + and *. However, F# goes a step further and also lets you create custom operators. You just pick a combination of symbols that isn’t already being used and define a function for it. For example, in my parsing code I wanted a simple way to adorn my input parse strings in my tests so that I could later easily change their type if I changed the type of NextChar and CheckForToken as described above. I defined the “double bang” operator !!. Currently, double bang converts a string into a character list, but originally it simply returned the string since I had written my Char and Token classes in terms of string.

(Harry is @ DevTeach in Vancounver with his family this week. He was hoping to still do Morning Coffee posts, but that’s turned out to be infeasible. So instead, you get a series of pre-written posts about F#.)

For you LINQ early adopters, you may think you know everything about type inference, but F#’s uses it much more extensively. In C#3 , you can write “var o = new SomeObject()” and the compiler is smart enough to figure out the variable o is of type SomeObject. Saves some typing, but it’s not exactly brain surgery. F# can not only infer the type of local variables like C#, but it can also infer type of a function’s input parameters and return value based on how those variables are used in the function. For example, in the Additive function, F# can infer that the “input” parameter is a char list because Token takes a generic list and ‘+’ is a char.

F# automatically “generisizes” the functions you write. So if you write a function for traversing a list, by default it will work on a list of any type. You don’t have to explicitly declare the generics, F# automatically makes your code as generic as possible, based on your usage of the variables.

What’s really interesting about this approach is that changes to parameter or return types in a low-level function can have a rippling effect up the stack. In my parsing code, I haven’t settled on the type I’m going to use to represent the string to be parsed. My tests are all short strings, so F#’s intrinsic char list type is fine. However, I don’t know how well that will work for longer strings like a typical input file. F#’s native parsing tools (based on lex & yacc which I dislike) have a special LexBuffer class to represent the parse string. However, I’ve written my code so I can change the type of the lowest-level functions (NextChar and CheckForToken) and not affect the rest of my code. That’s pretty wicked.

Type inference does have a downside. I guess VS has rotted my mind, but I’m hooked on Intellisense. The BCL is too big to remember all the classes and all the method parameters. Intellisense is kinda like Google a web search engine. If you sorta know what you’re looking for, Intellisense helps close the gap to find it. Otherwise, it’s time to break out the docs. However, if you’re inferring type based on usage, Intellisense is out of luck. Honestly, there have been times where I’ve put in an explicit type declaration to get Intellisense to work, written the code, then removed the type declaration.

(Harry is @ DevTeach in Vancounver with his family this week. He was hoping to still do Morning Coffee posts, but that’s turned out to be infeasible. So instead, you get a series of pre-written posts about F#.)

Most FP languages include some type of pattern matching, and F# is no exception. At first blush, pattern matching looks a little like a switch statement, but it’s much more powerful. Where switch statements typically only do simple matches such as “does this variable equal this constant?”. In F#, you can break apart types, use wildcards even pass the potential match data into a custom function to determines if there’s a match. Of course, you can also do your more run-of-the-mill “does value equal constant” comparisons as well.

The problem with most functional language is that while pattern matching is powerful, it’s not particularly extensible. As Don pointed out in a recent paper, this becomes a real problem when trying to integrate FP with OO. OO is designed to hide details behind abstractions. Yet those abstractions can’t be used in pattern matching. Luckily, Don and the F# Guys (sounds like a band) have invented an extensible pattern matching syntax called Active Patterns to deal with this problem. Basically, in more recent versions of F#, you can adorn functions with special syntax so that you can use them in your pattern matching clauses.

This turns out to be wicked cool for writing parsers. I’m building recursive descent parsers, so each grammar production is implemented as a function. Yet, since I’m using the active pattern syntax, I can use them in pattern matching clauses. This allows me to chain together functions in a single match clause rather than having multiple match statements. And it’s very readable. For example, the function to recognize the grammar production Additive  <- Multitive ‘+’ Additive | Multitive is translated into the following F#:

and (|Additive|_|) input =
    match input with
    | Multitive(v1,Token '+' (Additive(v2, input))) -> Some(v1+v2,input)
    | Multitive(v,input) -> Some(v,input)
    | _ -> None

The weird “bananas” around Additive on the first line indicate this is an active pattern. Multitive and Token are also an active patterns. This syntax is a little parens heavy, but otherwise, that translation from grammar to F# is nearly declarative. It almost defeats the need for having a parser generator when building a parser is this straightforward. Almost.

(Harry is @ DevTeach in Vancounver with his family this week. He was hoping to still do Morning Coffee posts, but that’s turned out to be infeasible. So instead, you get a series of pre-written posts about F#.)

If you’re coming from the imperative object-oriented world of C#, Java or VB, functional programming just seems odd at first. But you might as well start getting used to it – functional aspects have been leaking into C# and VB with every version. The way LINQ chains together iterators (Where, Select, Order By, etc) is heavily influenced by FP (aka functional programming).

It takes a while to get the hang of FP, but I’ve found that some problems that are hard to solve in C# are easy in F#. For example, in my parsing code, I have a bunch of boilerplate caching and tracing code that I need to execute in each parsing function. How do I do that in C# without having to cut and paste the boilerplate code over and over again?

In F#, I wrote a function called CacheAndTrace that takes a parsing function as a parameter and returns a new function that adds the caching and tracing code. Since the new function has the same signature as the original parsing function, the caller can’t tell the difference but it saves me having to write the boilerplate code over and over again.

Actually, you can do this type of functional composition with C#. In fact, I first wrote my version of the CacheAndTrace function in C#. But F#’s syntax is much better for functional programming – probably since it was designed for FP, rather than having FP tacked on later.

My father once compared functional programming to Aspect Oriented Programming. AOP is about factoring apart cross cutting concerns, which tends to be hard to do in a straight-up OO language. But in an FP language, AOP-esque separation of concern is fairly straightforward.

F# isn’t a pure functional language – it’s actually a multi-paradigm language, so you can do imperative and OO stuff if you want to. For example, variables are typically immutable in functional programming. So how do you do something like cache the most recent result from a given function – which is what my CacheAndTrace function does? Frankly, I don’t know. But in F#, I can easily mark the cache value as mutable so I can update it on every call. Sort of the best of both worlds, though mixing and matching can get a little tricky.

F#’s OO support is really useful when you interop with other .NET languages, since they’re mostly OO themselves. For example, I’m using NUnit test cases for all my parsing code. My parsing code is F#, so I wanted to write my tests in F# as well. NUnit requires test methods to be grouped into classes known as test fixtures. Frankly, if I were designing a native F# xUnit library, I wouldn’t require all the test methods to be grouped into a class. But it’s easier to just define an test fixture object in F# rather than build my own xUnit Framework for F#

(Harry is @ DevTeach in Vancounver with his family this week. He was hoping to still do Morning Coffee posts, but that’s turned out to be infeasible. So instead, you get a series of pre-written posts about F#.)

I’ve been spending some real quality time with F# of late. I’ve been getting into parsing again, and it turns out that functional pattern matching languages like F# are really good at text processing. After claiming I’d learn F# this year, then abandoning the effort to learn Powershell, I went back to F#. Nothing against PowerShell – I’ve moved over to using it as my primary command line shell and have tricked out my startup script and everything. But I haven’t found much need to code in it lately.

If you’re a .NET ninja guru, you owe it to yourself to take a long look at F#, if for no other reason to expand your mind. It takes a while to get used to. Don Syme (aka father of F#) can attest I’ve been peppering him with questions (Thanks, Don!). I’ve also been writing code in C# and F#, and looking at the result in Reflector so I can understand what’s happening. I certainly am not an F# expert by any stretch, but I do think I’m getting the hang of it.

Since I’ve reached this first plateau of getting it, I thought I’d write out some of the things I like and don’t like about the language. This is by no means an introduction to F#. I’d recommend Robert Pickering’sFoundations of F# book as well as Don’s Expert F# book (when it comes out). You should also be reading Luke Hoban‘s and Jomo Fisher‘s blogs – they both just joined the F# team. C# MVP Tomas Petricek has written several blog posts introducing F#, which he’s brought together in a single post. For an general overview of functional programming (the primary programming paradigm of F#), check out Slava Akhmechet’s Functional Programming For The Rest of Us.

This turned into a fairly long post, so I split it out into a series that I’ll post thru the end of the week.

• Functional Programming
• Pattern Matching
• Type Inference
• Assorted Goodness
• Assorted Not-So-Goodness

Update: added link to Tomas Petricek’s F# Introduction