But in functional language, like F#, it is very natural to design application using recursion, which make the code more concise, succinct and expressive. It tells “What”, instead of “How”.

Let’s take a simple Factorial function as an example to explain how recursion works.

let rec factorial n =
     if n = 0 then 1
     else
        n * factorial (n -1)

The function looks simple, which is exactly the same way as its mathematical expression.

But if we provide a very large number such as 1,000,000, it might raise StackOverFlow exception, because the compiler use stack to store the functions. The stack space is very precious, only 1 M. It sounds like the recursion is not applicable for processing large data. Fortunately, F# compiler can optimize recursion by applying “Tail Recursion”.

“Tail Recursion” is a special recursive function which does not including any other execution after the recursive call, meaning there is no “pending operation”

Obviously, the factorial function above is not “Tail Recursion” because it has to multiply n. How do we solve it? A common approach is to use accumulator pattern. Here is the code:

let rec factorialTR n a =
    if n = 0 then a
    else
       factorialTR (n - 1) (n * a)

The idea is, instead of accumulating the functions in the stack, the code use a “accumulator” type to get the temporal value, which is (n * a) in the function. When it function reaches its base, it only needs to return the “accumulator” value. You see, in this case, compiler does not need to store additional additional functions in the stack any more. Makes sense, right?

Is Factorial function too simple? OK, let’s take some “real world” samples.

1. Sum a List (Just be aware the the list in F# is linked list)

let tempList = [1 .. 1000000]

// Non Tail Recursion Version
let rec sumList lst =
    match lst with
    | [] -> 0
    | hd :: tl -> hd + sumList tl 

sumList tempList

// Tail recursion version
let sumListTR list  =
    let rec innerSum list total =
         match list with
         | [] -> 0 // initial value
         | hd :: tl ->
            let ntotal = hd + total
            innerSum tl ntotal // don't need to store in stack
    innerSum list 0

The first one is not “Tail Recursion” because the recursion function is not the “last” thing, it has to append the value with hd.

The second one is “Tail Recursion” since it calculates the “AsOf” value and the temporal value is one of the parameter passed in the function. There is nothing needed to be stored in the stack.

2. Map function (Note: Map is one of high order functions common in Functional Language)

// Non-Tail Recursive version map  function
let rec map f list =
    match list with
    | [] -> []
    | hd :: tl -> (f hd) :: (map f tl)

// Tail Recursion Version

let mapTR f list =
    let rec loop f list acc =
        match list with
        | [] -> acc
        | hd :: tl -> loop f tl (f hd :: acc) 

     loop f (List.rev list) []

“Tail Recursion” makes it a very useful in our tool box. But it might reach its own limitation that “Tail Recursion” is allow one recursion call in a function. If there have more, we cannot covert it to “Tail Recursion”, so we cannot take the optimization offered by F# compiler.

Take a sample when we process a Tree:

type Tree<'a> =
  | Node of 'a * Tree<'a> * Tree<'a>
  | Leaf of 'a

// Non Trail Recursion version
let rec treeSize = function
  | Leaf _ -> 1
  | Node(_, left, right) -> treeSize  left + treeSize  right

// Trail Recursion version
let  treeSizeTR tree =
  let rec size_acc tree acc =
    match tree with
    | Leaf _ -> 1 + acc
    | Node(_, left, right) ->
        let acc = size_acc left acc // Non Tail Recursion on left
        size_acc right acc          // Tail Recursion on right
  size_acc tree 0

You can see we provide two version of codes to process a tree. The first one is a normal approach by calling two recursive functions. It is interesting to see the second one. As you can see we only have one “Tail Recursion” when processing right side tree. So the whole solution still cannot be optimized by F# compiler.  Now what we should do?

Let’s think about how we apply “accumulator” pattern to solve “Trail Recursion” issue again. We pass a temporal value as an argument to the function. Just be ware, in functional language like F#, function is value too. It can be passed and returned! It is a fundamental in functional programming, but it can help us to solve very tricky issue. OK, let me tell you the answer first, then explain.

The answer is to applying continuous passing style (CPS) by passing another function as the “remaining” of the recursive function call.  So what does it mean? Still confused? Well, actually it is really confusing. It is not very easy to understand when you see it first time. Still, let’s use Fibonacci function we used in the early to illustrate how continuations works.

let  fibonacciCPS n =
  let rec fibonacci_cont a cont =
    if a <= 2 then cont 1
    else
      fibonacci_cont (a - 2) (fun x ->
        fibonacci_cont (a - 1) (fun y ->
          cont(x + y)))

  fibonacci_cont n (fun x -> x)

This implementation takes a inner recursive function by passing the number and a continuation function. Actually the continuation function is a  closure function.

1. when a <=2, it returns by applying the identifier function (fun x –> x)

2. When a > 2, it recursively calls to reach its base case by calling fibonacci_cont (a – 2), and in the same time, it builds up the closure functions. x is the result of fibonacci_cont (a –  2), and y is the result of fibonacci_cont (a –1). The add x and y.

3. Just be aware we use closure here, which use heap, instead of stack.

It really makes the logic inside out. It does not seem a very natural way when we design the code. It made my head hurt when first seeing this code. But later, I think it is very smart to pass closure function like that. It is really the beautiful side of functional programming.

Well, this blog might be too length. I will continue discussing recursive function later. Now let me finish this blog by putting the code to process a tress using continuation at the end.

let  treeSizeCont tree =
  let rec size_acc tree acc cont =
    match tree with
    | Leaf _ -> cont (1 + acc)
    | Node(_, left, right) ->
        size_acc left acc (fun left_size ->
          size_acc right left_size cont)

  size_acc tree 0 (fun x -> x)

Happy programming!

Mouse clicking is sort of distraction from we are doing. Combining with any of the launcher tool, such as Slickrun, you will find you can definitely accomplish your work faster, more effectively and a lot fun!

Don’t try to memorize all of them at once. When you feel you need to use mouse, just do some search to see if any shortcut available. Here is the list I am using a lot as a .NET developer (visual studio and Resharper, of course!)

Here are some of the window-based shortcuts I collected and use very often. Hope it will help.

• Visual Studio shortcut keys
• Resharper shortcut keys (visual studio schema)
• Window common shortcut keys
• Web browser common Shortcut keys
• Firefox shortcut keys
• Microsoft IE shortcut keys
• Microsoft Excel shortcut keys
• Microsoft Word shortcut keys

Visual Studio Shortcut Keys

Basic Windows shortcut keys

Web Browser common shortcut Keys

Mozilla Firefox shortcut Keys

Internet Explorer Shortcut

Microsoft Excel

Microsoft Word

So what is functional programming? Quote from Wikipedia:

"Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast with the imperative programming style that emphasizes changes in state.^[1] "

So what it really tells us? I think the main point is "function is data" which means function can be use to be passed as an parameter or returned argument or modified as any other data in our application. Do we gain benefit for that? Sure, we do.

1. Functional programming can help model data operation. Here is the sample:

1 private static long Watch<T>(Action<T> act, T arg)
2 {
3         Stopwatch watch = new Stopwatch();
4         watch.Start();
5         act(arg);
6         watch.Stop();
7         return watch.ElapsedMilliseconds;
8 }

This Watch function is totally decoupled with the Action, which could be "reading the data from database", or "processing the data from a file". It leads a clean design that Watch function and the Action function can be tested separately.

2. Parallel programming. If you have been worked on Multi-thread programming. You know how hard it is. The limitation of imperative language like C# focuses on the state change. But functional programming is passing function as argument as we mentioned above. The state actually is only closed in the function boundary. So there is no other thread can access that data. Microsoft has released PLINQ, a parallel programming add-on to current .NET framework 3.5. It will be a huge benefit for any .NET who will take advantage of multi-processor computers.

So far, so good, right? from next one, I will illustrate the functional programming features in C# 3.0. Definitely will show more code. Please stay tune.

   1:  IList resultWithAliasedBean = s.CreateCriteria(typeof(Enrolment))

   2:   .CreateAlias("Student", "st")

   3:   .CreateAlias("Course", "co")

   4:   .SetProjection(Projections.ProjectionList()

   5:   .Add(Projections.Property("st.Name"), "studentName")

   6:   .Add(Projections.Property("co.Description"), "courseDescription")

   7:  )

   8:  .AddOrder(Order.Desc("studentName"))

   9:  .SetResultTransformer(NHibernate.Transform.Transformers
  10.  .AliasToBean(typeof(StudentDTO)))

  11:  .List();

The Element and StudentDTO is simple enough.

   1:          [Serializable]

   2:      public class Enrolment

   3:  

   4:          private Student student;

   5:          public virtual Student Student

   6:          {

   7:              get { return student; }

   8:              set { student = value; }

   9:          }

  10:  

  11:          private Course course;

  12:          public virtual Course Course

  13:          {

  14:              get { return course; }

  15:              set { course = value; }

  16:          }

  17:  

  18:          private long studentNumber;

  19:          public virtual long StudentNumber

  20:          {

  21:              get { return studentNumber; }

  22:              set { studentNumber = value; }

  23:          }

  24:  

  25:          private string courseCode = string.Empty;

  26:          public virtual string CourseCode

  27:          {

  28:              get { return courseCode; }

  29:              set { courseCode = value; }

  30:          }

  31:  

  32:          private short year;

  33:          public virtual short Year

  34:          {

  35:              get { return year; }

  36:              set { year = value; }

  37:          }

  38:  

  39:          private short semester;

  40:          public virtual short Semester

  41:          {

  42:              get { return semester; }

  43:              set { semester = value; }

  44:          }

  45:  

  46:          public override bool Equals(object obj)

  47:          {

  48:              Enrolment that = obj as Enrolment;

  49:              if (that == null)

  50:                  return false;

  51:              return studentNumber == that.StudentNumber && courseCode.Equals(that.CourseCode);

  52:          }

  53:  

  54:          public override int GetHashCode()

  55:          {

  56:              return courseCode.GetHashCode();

  57:          }

  58:      }

  59:  public class StudentDTO

  60:      {

  61:          private string studentName;

  62:          private string courseDescription;

  63:  

  64:          public StudentDTO() { }

  65:  

  66:          public string Name

  67:          {

  68:              get { return studentName; }

  69:          }

  70:  

  71:          public string Description

  72:          {

  73:              get { return courseDescription; }

  74:          }

  75:      }

What we can do is to retrieve StudentDTO from Presenter by querying from Repository. Code is elegant and beautiful. How sexy NHibernate is!!

So should we give up DTO totally in our application design? Absolutely not, in the other end, I find DTO still useful especially in UI and UI process layers. For example, we have a complex searching page to find customer by first name, last name, SSN, address, phone, email, and so on. those information may stay in different domain objects. It is also very hard to design a method with a very long list of parameters, not just ugly but also unmaintainable. My approach is to design DTO object pass data between UI and UI process (Presenter or Controller). Then access the service objects, and domain objects from presenter/controller. So I can design domain entity with the interfere from the special requirement of UI. Again it is important to implement MVP pattern to protect the domain object, which is also one of the important principles I heard from DDD: don’t leak business logic out of the domain object layer.