An adventure journey of Functional Programming and F# 2.0 in Visual Studio 2010: Part 7 of 17

Hello there!

This blog of F# contains full (long) blog posts of adventure in functional programming and F#. I call it adventure, because I’ll try to make F# as fun to as possible to learn.

NOTE:

This blog is starting to use Visual Studio from Visual Studio 2012 and Visual Studio 2013 (from Release Candidate to RTM), and provide hints of F# 3.0 in Visual Studio 2012.

Now, here are the parts:

1. Part 1: Introduction to Functional Programming
2. Part 2: Functional Programming Concepts
3. Part 3: Introduction to F#
4. Part 4: Functions, Delegates and Computation expressions in F#
5. Part 5: F# standard libraries
6. Part 6: OOP in F#
7. Part 7: Using LINQ in F# (you are here)
8. Part 8: F# Asynchronous workflow
9. Part 9: F# MailboxProcessor
10. Part 10: Units of Measures
11. Part 11: F# Power Pack
12. Part 12: F# for Silverlight 4 (and above)
13. Part 13: A look at F# 3.0 in VS 11 (Visual Studio 2012)
14. Part 14: A look of Functional Programming in VB 10 and C# 4.0 compared to F#
15. Part 15: A look of F# compared to Haskell, Scala and Scheme
16. Part 16: F# future and what features that F# must have
17. Part 17: Retrospective

---

Using LINQ in F# 3.0

Before F# 3.0 in Visual Studio 2012, LINQ was not available in F#. If you use F# Powerpack for F# 2.0, LINQ was implemented as computation expression.

An overview of LINQ

LINQ stands for Language INtegrated Query. LINQ has its first release in C# 3.0 and VB 9.0 in Visual Studio 2008.

Basically, LINQ is a syntactic sugar on top of C# 3.0 and VB 9.0. It is then translated by the compiler into a series of extension method calls to Enumerable (for LINQ to Object) or Queryable (for LINQ to SQL, LINQ to Entity).

Let’s look at LINQ to Object, because this is the basic foundation of all other LINQ to others.

LINQ to Object is the basic foundation because it is available for the basic foundation of all generic or typed collection in .NET: IEnumerable<T>

Why? There are always misconception that LINQ is a mean to connect to database, and the fact is not that! LINQ is a way to query a collection of data. The data can be a single type or can be a collection.

I can also query the running processes on my machine that consumes memory more than 1 MB: (using C#)

In VB, we can also do that:

Now we can prove that LINQ is not used only to query database.

The interesting point of using LINQ is, the from, where, select is used as keywords. The compiler will translate those LINQ keywords into series of Lambda expressions.

In C#, the code will be translated into: (the commented is the original source code)

If you see the source code very well, you’ll also notice that there are type inferences in action! But the type inferences in C# and VB are different with F#.

In C# and VB, type inferences are happened in local scope, and also for method’s parameter but not for the method return type.

F# will deduce an infer the return type of the method gracefully and flows nicely outside the scope of the methods.

F# 3.0 LINQ query expressions

Let’s dive into F# 3.0 LINQ!

LINQ in F# 3.0 was composed using monad builder, by a class names QueryBuilder. The complete fully qualified class name is Microsoft.FSharp.Linq.QueryBuilder. Don’t worry, you don’t have to use it directly because it’s composed for us to be used nicely as composable query.

In F# 3.0 the code will be:

The interesting aspect is the use of Seq.ofArray. Let’s say we’ll delete the use of Seq,ofArray, run the code, and display the result using the F# interactive:

Now with Seq.ofArray added, the result is much simpler and also nicer to observe:

Without Seq.ofArray, the F# interactive will display all of the resulting array of Process.GetProcesses after it display the result of running process. Because the basic behavior of GetProcesses is eager evaluation, not lazy evaluation. Seq.ofArray pipeline will execute it lazily, only evaluate it as needed.

The type inference will infer that array of Process is a derived from IEnumerable<Process>. It is also true in C# and VB.

In the F# code, I also use sortByDescending to sort the result descending, based on the size (using property of WorkingSet64). It is equal to order by in C# and VB with descending option added.

What about the semantic? The semantic is the same, only few clause has different semantic.

This is the table of semantic and syntax differences between C#, VB and F#:

Notes:

All of the aggregates are not available in LINQ of C# and VB in a query comprehension. F# has integrated in the query computation, as with other SQL clauses (FROM, SELECT, WHERE, JOIN, GROUP BY).

Those query operations that has no semantic differences are really having the same calls to the same methods of LINQ to object. Having no semantic differences means that it’s guaranteed for F# to have the same results as in C# and VB.

We have known SELECT, WHERE, and ORDER BY in F# and a hint of “take”. They are very simple to use, and it has the same semantic although the syntax of ORDER BY in F# has different name, using sortBy.

This is F#’s groupBy in action:

(I intentionally group the processes by ProcessName, and then display the number of grouped process)

As usual, svchost has the largest number of instances.

Note:

The groupBy sample has Count(), and this require System.Linq.
Iterating the result of group by requires us to look at the Key collection first, then the grouped data. Why?

Due to the returned result of groupBy is the same as Enumerable.GroupBy, that returns a IDictionary<Key,Value>.

It returns a dictionary because of the nature of group by: the result is grouped by a key, then each key will have values that grouped by the key.

Now, I’m going to display the maximum amount of memory taken by those process.

This is the code using maxBy:

Those equalities of query operators table is not displaying all, actually. But it can be considered the same as the operations in System.Linq.Enumerable extension methods.

---

Further readings

• F# query expression in VS 2012: http://msdn.microsoft.com/en-us/library/hh225374.aspx

An adventure journey of Functional Programming and F# 2.0 in Visual Studio 2010: Part 6 of 17

Hello there!

This blog of F# contains full (long) blog posts of adventure in functional programming and F#. I call it adventure, because I’ll try to make F# as fun to as possible to learn.

NOTE:

This blog is starting to use Visual Studio from Visual Studio 2012 and Visual Studio 2013 (from Release Candidate to RTM), and provide hints of F# 3.0 in Visual Studio 2012.

Now, here are the parts:

1. Part 1: Introduction to Functional Programming
2. Part 2: Functional Programming Concepts
3. Part 3: Introduction to F#
4. Part 4: Functions, Delegates and Computation expressions in F#
5. Part 5: F# standard libraries
6. Part 6: OOP in F# (you are here)
7. Part 7: Using LINQ in F# (and the upcoming F# 3.0)
8. Part 8: F# Asynchronous workflow
9. Part 9: F# MailboxProcessor
10. Part 10: Units of Measure
11. Part 11: F# Power Pack
12. Part 12: F# for Silverlight 4 (and above)
13. Part 13: A look at F# 3.0 in VS 11 (Visual Studio 2012)
14. Part 14: A look of Functional Programming in VB 10 and C# 4.0 compared to F#
15. Part 15: A look of F# compared to Haskell, Scala and Scheme
16. Part 16: F# future and what features that F# must have
17. Part 17: Retrospective

---

OOP in F#

F# is not just a functional programming language, but it is also an object oriented programming language which also an imperative programming language.

The OOP feature of .NET are supported by F#, including interfaces, classes, inheritances, method overrides, overloads.

The classes created in F# can be used in C#, VB and others because it’s generated into the same IL that C#, VB and other have (as long as the IL is standard .NET CLR’s IL).

This OOP feature is where the flexibility of F# has risen above all other functional programming languages that only offers pure functional programming languages. But this flexibility also marks F# as non pure functional programming language.

Why? This is where the critics often attack F#. Before diving deeper into F# OOP, I'm going to introduce a very quick glimpse of OOP.

OOP often described as how you develop software using object as the main attention.

An object in OOP is an object that has attributes and behaviors, just like us humans.

Attributes can be name, address, gender, nationality. Behaviors in OOP are the common capabilities that we have, such as Walk, Run, Eat, Drink.

This is a simple illustration of human as object:

We can often inherit our attributes (but not all) from our parents, and so does our behaviors. This is called inheritance, the most common known concept part of OOP.

 

OOP first stop: Inheritance, Polymorphism, Encapsulation

Inheritance in OOP is really what makes OOP really shines: the ability to inherit an available object with all of the visible allowed attributes and behaviors.

It is called visible allowed attributes, because there are scope modifiers at the attributes that control this visibility.

In F#, these are allowed scope modifiers:

• public
• private
• internal (the scope is only assembly scope)

F# does not allow protected modifier, like those in C# and VB.

But this OOP doesn’t stop just having inheritance.

Generally OOP has these 3 concepts:

• Inheritance
• Polymorphism
• Encapsulation

So, what are Polymorphism and Encapsulations?

Polymorphism is concerning the change of behavior when an object inherits other object, this is why there are method overrides that define behavior overrides.

Encapsulation means an object is known to outside by having definition of attributes (properties in .NET and C#/VB/F#) and behaviors or operations.

In F#, OOP is supported in the form of class and interface.

 

Interface in F#

Interfaces in F# are implemented in two ways:

• Using object expressions
• Using class types

To create interfaces using class types are quite straightforward, the syntax is similar to interface declaration of C# and VB.

This is the syntax using class types:

// Interface declaration:
[ attributes ]
type interface-name =
   [ interface ]
     abstract member1 : [ argument-types1 -> ] return-type1
     abstract member2 : [ argument-types2 -> ] return-type2
     ...
   [ end ]

This is a sample code of creating interfaces using class types (from F# in Visual Studio 2010 Tutorial template):

type IPeekPoke =
    abstract Peek: unit -> int
    abstract Poke: int -> unit

The IPeekPoke will be treated as interface and will have the same signature as declaring interface in C# and VB. By default, the access modifier when not specified is public. This interface can also contain other members not just methods, but it can contain properties:

type IConnectionFactory =
    interface
        abstract ConnectionString : string with get, set
        abstract ConnectionState : int with get
        abstract Open : unit -> unit
        abstract Close : unit -> unit
    end

The interface declaration above can also be written to omit interface keyword that ending with end keyword:

type IConnectionFactory =
    abstract ConnectionString : string with get, set
    abstract ConnectionState : int with get
    abstract Open : unit -> unit
    abstract Close : unit -> unit

The type IConnectionFactory simulates a database connection commonly found in System.Data. It demonstrate an abstract property of ConnectionString with setter (set) and getter (get), ConnectionState that has getter only, and abstract method of Open and Close.

Note that F# clearly defines that each method that has no parameter and returns no parameter has to have signature as unit, returning no parameter as unit.

To create interface using object expressions, the interface are declared within a class. This is the syntax:

// Implementing, by using an object expression:
[ attributes ]
let class-name (argument-list) =
   { new interface-name with
       member self-identifier.member1 argument-list = method-body1
       member self-identifier.member2 argument-list = method-body2
       [ base-interface-definitions ]
   } 

member-listThis is a sample of interface implemented using object expressions:

let makePrintable(x: int, y: float) =
    { new IPrintable with
              member this.Print() = printfn "%d %f" x y }
let x3 = makePrintable(1, 2.0)
x3.Print()

The advantages of using the object expression syntax are subtle: the interface does not have to be named and the scope of the interface is not visible from outside. Concrete implementation has to be implemented directly inside the class. But the disadvantage of using this syntax is quite clear; this syntax has no comparable features in C# and VB.
Create type that implements interfaces
To create types that implements interface, the interface must be declared using class type syntax.

For example, we can create type that implement IPeekPoke interface above:

// Types: classes with interface implementations
// ---------------------------------------------------------------
/// A widget which counts the number of times it is poked
type Widget(initialState:int) =
    /// The internal state of the Widget
    let mutable state = initialState
    // Implement the IPeekPoke interface
    interface IPeekPoke with
        member x.Poke(n) = state <- state + n
        member x.Peek() = state
    /// Has the Widget been poked?
    member x.HasBeenPoked = (state <> 0)

Now, to call the method of the interface, F# requires the call to be explicit to specify the interface, and this is clearly specified in MSDN Library:

"Interface methods can be called only through the interface, not through any object of the type that implements the interface. Thus, you might have to upcast to the interface type by using the :> operator or the upcast operator in order to call these methods."

This is a sample code to call methods of IPeekPoke:

let widget = Widget(12) :> IPeekPoke
widget.Poke(4)
let peekResult = widget.Peek()

There is an alternative syntax to call interface method.

An alternative is to declare a method on the object that upcasts and calls the interface method, as in the following example, with comparison of having an added sample of using upcast of above:

type IPrintable =
   abstract member Print : unit -> unit

type SomeClass1(x: int, y: float) =
   interface IPrintable with
      member this.Print() = printfn "%d %f" x y

type SomeClass2(x: int, y: float) =
   member this.Print() = (this :> IPrintable).Print()
   interface IPrintable with
      member this.Print() = printfn "%d %f" x y

// sample usage
let x2 = new SomeClass2(1, 2.0)
x2.Print()

The code of SomeClass2 declaration define member Print that has upcast to IPrintable.Print and also has concrete implementations of Print method.

 

Class in F#

A class in F# is the same class in C# and VB. A class can have properties and methods, with fields as well.

Class in F# is quite straightforward. You can create class with no constructor or with default constructor with parameters.

Declaring a class with no constructor will imply that the class will have default constructor that has no parameter.

This is the base syntax:

In the preceding syntax, the type-name is any valid identifier. The type-params describes optional generic type parameters. It consists of type parameter names and constraints enclosed in angle brackets (< and >). The parameter-list describes constructor parameters. The first access modifier pertains to the type; the second pertains to the primary constructor. In both cases, the default is public.

A class that inherits from specific type is defined using inherit keyword. If there’s no inherit, then the class is automatically or implied to be derived from System.Object, just like every classes in .NET.

This is a very simple but good sample from Tutorial.fsx from F# template:

When you define types that reference each other in a circular way, you string together the type definitions by using the and keyword. The and keyword replaces the type keyword on all except the first definition, as follows.

This is why in MSDN called as "Mutually Recursive Types".

A sample of mutual recursive type:

You can also add generic type parameter for the type.

Generic in F# is declared in “<generictype>” syntax, like “<’T>” with single quote added to differentiate a concrete type or truly generic type.

This is a sample of generic in class declaration:

 

Defining abstract classes

F# also supports abstract class. An abstract class in F# is the same abstract class in C# and VB, and it’s also semantically the same.

An abstract class in OOP is simply a class that has abstract method or properties with no implementation body but abstract class can also have concrete method.

In F#, abstract class must have AbstractClass attribute. The abstract method and properties must have abstract keyword as identifier.

Sample abstract class:

The class that derives from an abstract class MUST implement all of the abstract members.

Sample derived class from Shape2D class:

 

Declaring properties in F#

Property in F# is the same as property in C# and VB, and they are also semantically the same. This is also one advantage of F# of seamlessly interop with C# and VB to have OOP support, not just interface and classes supports.

Declaring properties is simple, using member keyword with the desired set and get.

NOTE: when defining properties, all property value  is mutable by default because of the nature of getter and setter in OOP.

Syntax:

Declaring the property starts with member keyword, with the combined get and set accessors.

If the get and set are combined, with keyword must be used.

Sample:

Or we can use separate set and get, like this sample:

member this.MyReadWriteProperty with get () = myInternalValue
member this.MyReadWriteProperty with set (value) = myInternalValue <- value

Begins with F# 3.0 in Visual Studio 2012, F# can use auto properties just like auto properties in C# and VB.

Sample of auto properties:

 

---

Further reading

1. Tutorial of OOP in Java (but it can be applied in .NET): http://docs.oracle.com/javase/tutorial/java/concepts/
2. Interface in F#: http://msdn.microsoft.com/en-us/library/dd233207.aspx
3. Classes in F#: http://msdn.microsoft.com/en-us/library/dd233205.aspx