I finally got it but it took a while. The issue, particularly in F#, is that combinators don’t make all that much sense as a substitute for non-recursive functions. After all, the only way to run the combinator recursively is with a recursive function (as in let rec). A different solution might be to use recursive types, but that’s is pretty pointless. There was a great StackOverflow question about that by the way.

What is a combinator

I am getting ahead of myself though. Combinators are a mathematical concept pioneered by Haskell Curry. The essence of combinators is that they allow sophisticated computation by combining simple functions. Hence the term combinator. Combinators allow a recursive algorithm to be written using a function that does not call itself but instead invokes another function that is passed in as one of the arguments.

One distinct characteristic of a combinator function is that all of its variables are bound. That means that the function only depends on its parameters, not any other data structures or function defined elsewhere. Just about the best description of what is a combinator and what isn’t can be found here

let freevar=3 //a variable

let IAmACombinator x = x*2;; //variable x is bound as a formal parameter
let IAmNotACombinator x = x*y;; x is bound but y is free. This is not a combinator

Example

Lets do some examples. An algorithm that I will implement is the sum of arithmetic progression. It’s an algorithm that can really be solved in O(1) time (by using the formula (m+n)*(m-n+1)/2, but it makes for good tail recursion test (i.e. you can blow the stack quite easily, unlike the factorial, which runs out of the integer range at about 15).

This is the normal recursive arithmetic progression function:

let rec progsum x =  
    if x <= 1 then 1 
    else x+progsum (x-1)

Combinator Version

Thanks to F# type inference, the combinator function is pretty the same for any application and only depends on the number of parameters to the worker function.

This is the combinator version of the above function:

//Normal arithmentic progression sum combinator
let rec comb f = f (fun x -> comb f x)
let progworker f x = 
    if x <= 1 then 1 
    else x+f(x-1)
//Use partial application to wrap up the combinator call    
let progCombinator x = comb progworker x ;;

This might need a bit of explaining. comb is a higher order function that takes another function as a parameter and returns a function taking one argument. This returned function is what we actually want – a function taking one parameter and returning something of the same type as the parameter.

In the above snippet progCombinator is a convenient way to partially apply our combinator to the arithmetic progression worker function. We could have just as easily done for a factorial:

let factworker f x = 
    if x <= 1 then 1
    else f(x-1) * x;;
//Use partial application to wrap up the combinator call    
let factCombinator x = comb factworker x ;;

Tail recursion

Tail Call Optimization is an F# compiler feature (and in some cases JIT Compiler feature) where it will transform a recursive function into a while loop if the recursive call is the last statement in the function. Let’s go back to the original arithmetic progression function and see if that is the case:

let rec progsum x =  
    if x <= 1 then 1 
    else x+progsum(x-1)

And it isn’t. Even though it looks like the function call is the last statement of the function, progsum(x+1) will be evaluated before x+progsum(x+1) can be computed. Let’s rewrite it to take advantage of tail recursion:

let progTR x =  
    let rec inner x sum = 
        if x <= 1 then sum 
        else inner (x-1) (sum + x)
    inner x 1;;

So, what happened here? Well, for once we declared a wrapper function and the worker function inside it. This is not strictly necessary, but allows to hide some of the implementation semantics. So, if we can visualize how the original function worked, this is a crude diagram that shows the execution path for x = 4:

progsum 4
->calls progsum 3
  ->calls progsum 2
    ->calls progsum 1
       ->returns 1
    <-returns (progsum 1) + 2
  <-returns (progsum 2) + 3
<-returns (progsum 3) + 4

As you can see the result is computed "on the way out" - i.e. as the function returns. In the tail recursive version we compute the result "on the way in", which allows the recursive function invocation to be the last statement in the function. Here is the diagram:

inner 4 1
->calls inner 3 (1 + 4)
  ->calls inner 2 (5 + 3)
    ->calls inner 1 (8 + 2)
      -> returns 10
    <-returns 10
  <-returns 10
<-returns 10

An interesting side effect of this tail recursive function is the fact that the order in which sum happens is not quite the same as in the original function.

Original:

4 + (3 + (2 +(1)))

Tail Recursive:

((4 + 1) + 3) + 2

Tail Recursive Combinator

So, now that we've gone over combinator functions and tail recursive functions you may ask: "What about tail recursive combinators? Do those exist?". And the answer would be "Yes, indeed, such beasts do exist". Here is the same algorithm implemented as a tail recursive combinator:

let rec combTR f = f (fun x acc -> combTR f x acc)
let progTR f x acc = 
    match x with
    | 1 -> acc
    | x -> f(x-1) (acc + x);;
    
let progCombTR x = combTR progTR x 1;;

Looking at the code, there is nothing groundbreaking there. Just as we converted the original function into a tail recursive function by adding a second parameter, we did the same for the both the combinator function and the inner function.

For more details on tail recursion and different ways to optimise it have a look here and here.

I would like to start off by comparing programming languages to spoken languages. Most will agree that the comparison is fair. Programming languages bear most hallmarks of real life languages. There is syntax, grammar, dictionary, there are historical reasons for why the language the way it is, etc. Generally speaking one is most fluent in their native tongue and could deal with a couple of others. Similarly in programming you have your native language – C family, VB, Pascal, Ruby, Python, Perl, hieroglyphics(PHP) etc.

My native language is Russian and that’s what I grew up with. From a reasonalby early age I learnt English and was reasonably fluent in it as a second language. I would like to equate this SECOND language to your FIRST programming language. The similarity, for the sake of this post, is that you think in your native language and translate it into code. The process, as those who speak other tongues would know, is similar. You form what you want to say in your head, translate all the words into the other language, rearrange the sentence if the target language requies so and then produce the output.

As with a second spoken language, writing programs eventually becomes second nature. Enter third (spoken) langague, e.g. French, that I learned in school. I found that my brain was stuck in this binary Russian/English mode and I could not add French to the mix, so my French was coming out very English like.

This is the problem I am facing with F#. It is SO compltely different that my C/C++/C#/Whatever-happy brain does not accept it. If comparing to spoken languages, it’s even further away from C than French is from English. It’s more like Japanese, where both the alphabet and the mindset are different.

So, coming back to the point of this dribble. I like words. I like the explicitness of procedural languages. I think it tends to follow how one thinks. if statements, while statements, assignment, parameter passing – they are all very logical.

My biggest hurdle understanding F# is the fact that the same syntax can be used for instantiation and matching. For example defining a function that takes a tuple with two members:

let func (a, b) = printfn "a: %d, b: %d" a b;;

The syntax is the same as when you define a tuple:

let tuple = (4, 5);;

Wheres a, say C++ would do something like this:

Tuple<int, int> = new Tuple<int, int>(4,5);

void func(Tuple<int, int> tuple) {
}

F# seems to just use all these symbol operators for everything and I just can’t let go of my attachment to words. List.Add is logical, [4;5;]@[6;7] is less so, especially considering that the operands cound be either values or lists.

Speaking of words, here is some lingo that you will undoubttedly come across as you learn a functional programming language. The list is not complete and some words are not simple definitions, but quite complex concepts – like combinators – those will make your head hurt extra good :))

• High Order Function – Function that can take functions as parameters and/or return a function
• Curried function – High Order Function that binds one or more of the parameters to a predetermined value and returns a function that takes less parameters.
• Purity – Functions not having side effects – i.e. the function produces an output without chnaging the input or modifying state somewhere else. This normally invoves using immutable data structures and combinators.
• Cons operator (::) – Adding an element to the beginning of the list.
• Strictness – Evaluating parameters to the function before the function is evaluated.
• combinator – High order function that has no free variables. Short version is that this function only operates on its parameters, not any other functions or values defined elsewhere.
• Memoization – Remembering the result of a slow running function for future use (Caching).
• Imperative programming – “normal” programming – i.e. Procedural, Object Orientated, etc.