Declaring class constructors in F# 2.0, also considering singletons

by Marc Sigrist 19. October 2010 23:53

In F#, class constructors can be declared in several different ways. To declare a non-static class, one usually defines a primary constructor, plus zero or more additional constructors. To declare a static class, one usually defines a module.

Using a Primary Constructor

In F#, it is possible to create a thread-safe singleton with just three lines of code:

/// A public thread-safe singleton class in F#,
/// using a private primary constructor.
type Singleton private() =
    static let instance = Singleton()
    static member Instance = instance
// This would be the equivalent code in C#:
public class Singleton{ 
    static readonly Singleton instance = new Singleton(); 
    Singleton() {} 
    public static Singleton Instance {get { return instance;}} 

In the above F# example, private() defines an empty primary constructor. Using a primary constructor is the recommended practice for non-static classes in F#. According to the F# 2.0 Language Specification, section 8.6.4., any additional constructors must call the primary constructor (either directly or indirectly), as in the following example:

Using a Primary Constructor and an Additional Constructor

/// A public Person class in F#,
/// using a public primary constructor
/// and an additional public constructor.
type Person(name: string, guid) =
    new(name, guid) = Person(name, Guid.Parse(guid))
    member x.Guid = guid
    member x.Name = name
// This would be the equivalent code in C#:
public class Person{
     readonly string name;
     readonly Guid guid;
     public Person(string name, Guid guid){
 = name;
          this.guid = guid;
     public Person(string name, string guid):
          this(name, Guid.Parse(guid)){
     public Guid Guid {get {return guid;}}
     public string Name {get {return name;}}

Using Only "Additional" Constructors

It is also possible to define classes in F# with only "additional" constructors, but no primary constructor. However, the available syntax for the rest of the class is quite restricted. Primary constructors should only be avoided when there is a very compelling reason to do so, e.g., to simplify automatic code generation. The following, modified Singleton example shows some of the difficulties you may face when avoiding a primary constructor:

/// This type is intended for private use within Singleton2 only.
type private SyncRoot = private new() = {}
/// A singleton with no primary constructor.
type Singleton2 =
     // As we cannot use implicit ("let"-bound) fields, we have to
     // use explicit ("val"-bound) fields. However, explicit fields
     // who are static must also be default-initialized, mutable, and private.
     static val mutable private instance: Singleton2
     private new() = {}
     // As we cannot rely on the inherent thread safety of non-mutable
     // let-bound fields, we have to apply a lock.
static member Instance = lock typeof<SyncRoot> (fun() -> if Singleton2.instance Unchecked.defaultof<Singleton2> = 0
then Singleton2.instance <- Singleton2()) Singleton2.instance

Using no Constructor at all

What happens if you define a class in F# without using any constructors at all? As opposed to C#, F# will not generate a default public parameterless instance constructor for you in the background. Your F# class simply cannot be instantiated. Oddly enough, while the compiler forbids the declaration of static fields via let bindings in this scenario (whose usage would seem to make sense), it does not complain if you define instance properties/methods/val bindings (who are useless, because they can never be accessed). This leaves you with only static properties/methods/val fields, which is quite restrictive. Furthermore, even if you decide to define such a "type with only static accessibility", it will not appear as a "static class" to its users. For these reasons, it is best to never define classes without constructors in F#. If you need what in C# we call a static class, you better define a module in F#:

Declaring a Static Class

/// A module (static class) defined in F#. Type-level let bindings are public by default,
/// but can also be internal or private. This is opposed to type (non-static class)
/// definitions, where type-level let bindings are always inherently private.
module PersonFactory =
     let CreatePerson(name, guid: Guid) = new (name, guid)
// This would be the equivalent code in C#:
public static class PersonFactory{
     public static Person CreatePerson(string name, Guid guid){
         return new Person(name, guid);

However, using modules in F# 2.0 has a certain disadvantage: Method overloading is not possible. If you need method overloading in a static class, there is no other way than declaring a non-static type with just a private parameterless constructor, or no constructor at all:

/// A class with overloaded members in F#.
type PersonFactory2 =
     static member CreatePerson(name, guid: Guid) = Person(name, guid)
     static member CreatePerson(name, guid: string) = Person(name, guid)
// This would be the equivalent code in C#:
public class PersonFactory2{
     public static Person CreatePerson(string name, Guid guid){
          return new Person(name, guid);
     public static Person CreatePerson(string name, string guid){
          return new Person(name, guid);

No Static Constructor Method in F#

There is no separate static constructor method in F#. In order to run "static constructor code" in F#, you first need to declare a primary constructor. A primary constructor is actually an instance constructor (it can have a non-public access modifier and can take arguments). However, if and only if a primary constructor exists, any type-level static let and do-bound code implicitly becomes "static constructor code".

/// Running "static constructor code" in F#.
type SomeType() =
     static let instanceCount = ref 0
     static do printfn "Type created at %A" DateTime.Now
     do printfn "Instance created at %A" DateTime.Now
     do incr instanceCount
     static member InstanceCount = !instanceCount
// This would be comparable code in C#:
public class SomeType{
     static SomeType(){
              string.Format("Type created at {0:G}", DateTime.Now));
     public SomeType(){
              string.Format("Instance created at {0:G}", DateTime.Now));
     public static int InstanceCount {get; private set;}

In this blog post, I have covered the basics of declaring F# constructor code for class types and modules. Much more could be said with regards to type construction in F#. For instance, I did not cover structures, records, object expressions, calling base class constructors, and the details of read-only fields versus mutable fields versus reference value fields. Further information can be found in the F# specification, F# Language Reference, F# documentation, or in one of the few outstanding books available, such as Programming F#.

Tags: , ,


Book review: Programming F#

by Marc Sigrist 12. April 2010 00:33
Programming F# Title: Programming F#
Subtitle: A comprehensive guide for writing simple code to solve complex problems
Publisher: O'Reilly®
Author: Chris Smith
Date of appearance: October, 2009 (416 Pages)

The new version of Visual Studio is officially released today, April 12, 2010. It contains a new language called „F#“, designed by Don Syme of Microsoft Research Cambridge, UK. F# is a programming language that has capacities comparable to C#, but also offers the possibilities of a functional language. It is therefore a multiparadigm language; instead of “F#”, I think it could also have been called "M#".

Before discussing the book, let me mention how I came from C# to F#. I seriously started investigating F# after having written, maybe for the the 10,000th time or so, something like:

/// ...
/// <exception cref=“ArgumentNullException“>
/// <paramref name=“bar“> is <see langword=“null“>.
/// </exception>

void Foo(Bar bar) {if (bar == null) throw new ArgumentNullException("bar");}

Even if one uses helper methods, code snippets, or (in .NET 4.0) a preconditional code contract, writing the non-null enforcement logic still remains an annoyingly repetitive task. One day, I read in a blog comment: "If you want a language with reference types that cannot be null, take a look at F#". This sounded like Christmas to me. After some further research, I decided to take the time to learn this new language.

The book appeared only recently and is up-to-date with the current F# 2.0 release. It was written by Chris Smith, Software Design Engineer in Test at the F# team. It contains a densely written overview of the complete F# language. The writing follows a systematic path from the simple to the advanced. There is always a short introduction of a feature, followed by an extensive example, followed by further comments.

In the introductory chapter, we learn that white space matters: In order to create hierarchies of scope in code, one simply uses new lines and indentations, not curly braces and semicolons. Functions can easily be nested in other functions, which can be nested again in still other functions ad infinitum. Each subordinated function has its own narrow scope, which eliminates an important source of bad programming design. Oftentimes, parameter types do not have to be declared, because the compiler can infer them automatically. If so, one can also avoid writing parentheses () for the parameters. Taken together, these features make the F# language nicely self-documentary. Even without looking at the details, from the tense, clear-cut, indented shape of the code alone, one can quickly get a sense of the logical structure.

Conceptually, you could do the same already in C# 2.0 by nesting anonymous methods within each other. However, even in C# 3.0/4.0, nesting lambdas, the code soon becomes convoluted. As a consequence, in C#, one tends to implement functions without applying the appropriate level of local nesting, or even to declare private methods where anonymous methods would be more logical, thereby violating scope. Declaring private types nested in other private types is not really an alternative, because the declaration has to be outside the method, and it all takes so many lines of code that the whole construct will finally diffuse its own purpose to the reader. The way I see it, by offering the feature of function nesting, functional languages promote the object-oriented principle of encapsulation in a more sophisticated and fine-grained way than object-oriented languages themselves.

As one continues reading the first three chapters, the thinking adapts more and more to the fact that functions are just like other values. F# allows you (through partial function application) to transform functions into other functions with less parameters, and (through "currying" with pipes) to build chains of functions in a natural, intuitive way. Discriminated unions are another productivity-enhancing feature: Imagine enums in C#, but with nearly unlimited freedom in defining (and nesting, and sub nesting...) each enum member. Discriminated union members can be matched to other values via typed pattern matching, another fascinating feature, something like C# switch statements on steroids. Together, discriminated unions and pattern matching save many lines of code and of potential errors. They also make the code spontaneously conceivable-at-a-glance, without having to go back and forth through page after page in the code editor to understand the mapping logic.

Another interesting aspect of F# is the built-in special support of collection-like types. F# tuples internally rely on the .NET 4.0 Tuple type (an ordered collection of differently typed, nameless values). F# records are like C# 3.0 anonymous types, without the anonymity (a collection of differently typed, named values). F# lists are read-only singly linked lists of equal types. Of course, F# also has built-in support for arrays and sequences. The language contains specific operators and other constructs to make the declaration, initialization, and general handling of collection-like types as intuitive and natural as possible, allowing you to "write the code the way you think" and let the compiler do the work of implementing your expressed intentions. It is also possible to use the generic collections from the .NET Framework.

Chapter 4 deals with imperative programming in F#, i.e., programming that alters data that is already in memory. This subject is presented in its own separate chapter, because, by default, F# values can never be null and can never be mutated, even if they are of reference types. The chapter explains how you can digress from the default behavior, including how to deal with .NET Framework members that request or may return null.

Chapter 5 explains object-oriented programming in F#. The author starts with a brief explanation of what object orientation is and why it is useful. These remarks are probably directed at proponents of so-called "pure" functional languages (such as Haskell), who might be skeptical about, or not accustomed to, object orientation. However, the author also mentions some shortcomings of pure object orientation. Among other things, it forces the developer to formally implement certain design patterns, which, in functional languages, are implicitly there without needing special consideration.

Chapter 6 shows how to do classical .NET programming with F#, with some exciting extensions. For example, in F#, using object expressions, it is possible to create an "inline instance" of an interface type, without declaring a named, implementing type first. The chapter also explains how to declare and use standard .NET enumerations (instead of F# discriminated unions) and compares F# value types with F# records.

Chapter 7 deals with applied functional programming. It introduces units of measure and explains the usage of active patterns. Active patterns allow using functions inside the pattern matching. The author points out the three kinds of active patterns: Single-case, partial-case, and multi-case, and how they can be nested. The chapter also shows how to use F# lists in recursions. I was amazed by the fact that the F# compiler automatically generates code that avoids a stack overflow when the recursion is implemented in the “tail-recursive” style. A variation of this is the “continuation passing style”, which prevents stack overflows even when two interdependent recursive functions are involved. The chapter goes on with examples with function currying and the forward pipe operator (for a list of F# operators, see here), followed by closures, memoizing, and lazy evaluation, which should be familiar to C# programmers.

Chapter 8 is about applied object-oriented programming in F#. Any arbitrary symbol may be defined as an operator. One can declare indexers, and also “slices”, which return a sub range of a collection via slice notation. In addition to the generic type constraints known from C#, F# offers type constraints for delegate, enumeration, comparison, and equality conditions. As far as events are concerned, using the F# Observable module, one can define, compose, transform, merge, and map events in various ways. Chapter 9 demonstrates how to use F# as a scripting language. Even in scripted usage, F# is always compiled first, and therefore is faster than regular scripting languages. The chapter also contains a few pages about Microsoft Office automation with F#.

Chapters 10 to 13 contain more advanced F# concepts, which, coming from a C# background, were something like a revelation to me. Using computation expression builders, one can redefine the behavior of keywords such as while, return, yield, try/finally, etc., to create custom background processing for asynchronous workflows. F# allows you to call asynchronous operations almost like synchronous ones. You do not need to apply the traditional Asynchronous Programming Model (APM) of the .NET Framework, which is not type safe, and depends on separate callback methods spread in the class. Fortunately, version 4.0 of the .NET Framework contains Parallel Extensions for .NET (PFX) and thread-safe concurrent collections, with some further optimizations, ready to be used by any .NET language. Chapter 12 deals with reflection and declarative programming in F#. Using F# code quotations, one can access not only the static type information (as in classical reflection), but also the compiler’s internally used abstract syntax tree (AST). This is conceptually similar to, but much more elaborate than, expression trees known from lambdas in C# 3.0.

I would like to recommend this book to experienced developers seriously interested in F#. Readers without a functional background had better not expect to understand everything immediately upon a superficial first reading. The content is quite condensed, and many concepts are new to object-oriented developers. However, once you open yourself up to new ways of thinking about code, chances are you will become truly enthusiastic about the power and intuitiveness of this elegant new language. 

Prerequisits for implementing a keep-alive mechanism in WCF 3.0

by Marc Sigrist 7. March 2010 00:59

There seems to be a common misconception that, in order to find out whether a WCF session is still alive, one has to implement some kind of custom ping or heartbeat operation on the service, which is to be regularly called by the client application. However, the WCF framework, when configured correctly, already does this for you in the background.

The key to this feature is the ReliableSession class. When ReliableSession.Enabled is true, WCF will continuously generate internal infrastructure messages to check whether the service is still ready. After the service has been dead for some specified time, the proxy's ClientBase<TChannel>.State is automatically set to CommunicationState.Faulted, and the ICommunicationObject.Faulted event is raised, giving the client application a chance to react. The delay between the service breakdown and the Faulted event can be specified through the ReliableSession.InactivityTimeout. If, for instance, the InactivityTimeout is set to four minutes, WCF will generate several infrastructure messages during every four minutes. Therefore, if you shut down the service, the Faulted event will be raised on the client after four to six minutes. If you set the InactivityTimeout to 20 seconds, it will be raised after 20 to 30 seconds. The exact duration depends on WCF-internal implementation details.

In order for this to work, you also have to set the Binding.ReceiveTimeout to at least the duration of the InactivityTimeout. The ReceiveTimeout specifies how long the service will stay alive without any service operations being called from the client application. If, for instance, you expect your client application to call service operations at least twice an hour, you may set the ReceiveTimeout to 30 minutes, but still let the InactivityTimeout be 4 minutes or so, in order that the client application can take measures in the background when the service is temporarily interrupted.

The following example shows how to define both timeouts on the client and server sides, either configuratively (in the App.config file) or imperatively (in code). The example presupposes that you are using a reliable session-capable binding (such as WSHttpBinding or NetTcpBinding), and that you have applied the ServiceContractAttribute.SessionMode, ServiceBehaviorAttribute.InstanceContextMode, OperationContractAttribute.IsInitiating, and OperationContractAttribute.IsTerminating properties in meaningful ways. If you are not sure about that, you may want to read the respective MSDN documentation entries first. A comparison table of the system-provided bindings can be found here. Furthermore, if you do not like hand-coding configuration files, you can use the WCF service Configuration Editor Tool, which is installed with the Microsoft Windows SDK.

Defining the Timeouts Configuratively


In the App.config files of the service host and client apps: -->
binding name="myNetTcpBinding" receiveTimeout="00:30:00">
reliableSession enabled="true" inactivityTimeout="00:04:00"/>

In the App.Config file of the service host app: -->
service name="MyTest.MyService">

In the App.Config file of the client app: -->


Defining the Timeouts Imperatively

// using System;
// using System.ServiceModel;

// In the service host and client apps:

myNetTcpBinding = new NetTcpBinding();
myNetTcpBinding.ReceiveTimeout = new TimeSpan(0, 30, 0);
myNetTcpBinding.ReliableSession.Enabled = true;
myNetTcpBinding.ReliableSession.InactivityTimeout = new TimeSpan(0, 4, 0);

// In the service host app:
host = new ServiceHost(typeof(MyService));
host.AddServiceEndpoint(typeof(IMyService), myNetTcpBinding, "net.tcp://localhost/MyService");

// In the client app:
factory = new ChannelFactory<IMyService>(myNetTcpBinding, "net.tcp://localhost/MyService");
channel = factory.CreateChannel();

Book review: Pro WPF in C# 2008

by Marc Sigrist 27. February 2010 17:55
Book image Title: Pro WPF in C# 2008
Subtitle: Windows Presentation Foundation with .NET 3.5, Second Edition
Publisher: Apress® Books for Professionals by Professionals™
Series: The Expert's Voice in .NET
Author: Matthew MacDonald
Date of appearance: February, 2008 (1040 Pages)

This book is a thorough examination of the WPF 3.5 technology – its architecture, what you can do with it, and how to do it. It is directed at professional C# developers.

The book is written in a systematic, comprehensible way. A chapter starts with a basic introduction and includes graphics of the respective WPF sub-class hierarchy. The chapter's subject is then steadily explored in more and more detail. For instance, at the beginning, there are five pages just on resolution independence. XAML is explained in-depth, starting with the four ways of loading and compiling: Code-only, code and uncompiled XAML, code and compiled XAML, and XAML only; this is followed by the specifics of the XAML grammar (markup extensions, attached properties, etc.). There are seven pages on non-rectangular windows and sixteen pages on playing sound on different OS versions. As the book goes on, the author really shines in describing complex subjects, such as 3-D drawing, in a logically understandable way. Towards the end, there is a tabular overview of features missing in WPF compared to Windows Forms, with recommendations on when to choose one over the other, or both of them together, and how to mix them best.

The volume also contains lots of small, but precious pieces of surplus information, such as: Properties of WPF controls can be set in any order, without causing any change in behavior; or: By using an overloaded version of DependencyObject.SetValue in code, you can attach a value for any dependency property, even if it is not defined as an attached property (which is not possible in XAML). In addition, the author mentions various quirks of WPF, and how to get around them, if possible. Example: When you restart an animation that is almost complete, and the animation had the current position as the starting point, the animation will appear to slow down. Another example: Windows Vista always requires permission elevation for a setup, even though, in the case of Click Once, this makes no sense. As a consequence, a Click Once WPF application, on Vista, cannot be installed under a regular user account; the user is forced to install it under an admin account - which defeats the purpose of using Click Once in the first place...

Developers are all-too-familiar with the Pareto principle: 80% of the tasks of a project can be solved „easily“ in 20% of the time, but solving the other 20% takes at least 80% of the time. If you want to use WPF in a productive way, I strongly recommend taking the time to study this book. Admittedly, at 1040 pages, this is quite some endeavor. However, you will be rewarded many times over, as you will be saved a lot of frustration and unexpected delays, when you already know from the beginning how to solve much of the other 20%.

Yet another comment on the C# cast ( ) and „as“ operators…

by Marc Sigrist 21. February 2010 19:39

Time and again, the question comes up whether to prefer the cast ( ) or the „as“ operator in C# to perform conversions to reference types. According to the C# 3.0 language specification, the two operators behave differently in several respects:

C# Conversion Operator( )as
Name Cast operator as operator
C# 3.0 Specification section 7.6.6 7.9.11
Can convert to ValueType Yes No
Executes user-defined explicit conversions Yes No
Compile-time errors CS0030: Cannot convert type 'X' to 'Y'. CS0030: Cannot convert type 'X' to 'Y'.
CS0077: The as operator must be used with a reference type or nullable type ('Y' is a non-nullable value type).
Runtime behavior if not convertible Throws InvalidCastException: "Unable to cast object of type 'X' to type 'Y'." Returns null

Given the above comparison table, it follows that you must use the cast operator ( ) in the following cases:

  • to convert to a ValueType:
    object o = 137; var i = (int)o;
  • to convert via a user-defined explicit operator overload defined in the source type. Note that the overload may return anything whatsoever: The same instance, a new instance of the same type, a new instance of a completely non-related type, null, a value type or reference type...
    // Declared inside a class called Source:
    static explicit operator Target(Source s) {return new Target();}

By contrast, you must use the "as" operator in the following cases:

  • to be 100% sure that that the result points to the same instance, or null, but never anything else:
    var bar = foo as Bar;
  • to return null if a runtime conversion to the desired reference type is not possible, as in this construct:
    var bar = foo as Bar ?? new Bar();

Furthermore, the "as" operator is a bit more tolerant with generics at compile time than the cast operator. That’s because the as operator casts „directly“ to a type of the same inheritance line:

TDerived GetDerived<TBase, TDerived>(TBase b) where TDerived: class {
    // Produces compiler error CS0030: Cannot convert
    // type 'TBase' to 'TDerived'.

    // return (TDerived)b;

    // This compiles...
b as TDerived;

In all other cases, from a technical point of view, you may freely choose between the cast and the "as" operator. Therefore, the „right“ decision depends on what you want to express most in the source code. If you use the "as" operator, you thereby clearly document that you are interested in a reference target type that points to the same instance, and nothing else whatsoever – i.e., you do not want some crazy custom explicit operator to produce any side effects! Moreover, as a matter of taste, the "as" operator makes your code less cryptic, because it uses no parentheses, whereas the cast ( ) operator looks like old-fashioned C code.

For these reasons, personally, I prefer the "as" operator over the cast ( ) operator. However, I have met other developers who almost religiously defend usage of the cast ( ) operator as a best practice, „because it immediately throws an InvalidCastException“ at runtime if necessary, while the "as" operator might only later produce a NullReferenceException. Yet, against this, it could be argued that the "as" operator is even more secure, because it does not allow you to compile if it’s a value type, and it will never produce side effects...

Some tools, such as JetBrains‘ ReSharper, warn you if you apply the "as" operator without checking for null with a null comparison within the same procedure, even if null is logically impossible; e.g., when you have defined a null-checking procedure in a separate external helper method. You can turn this off, but only on a per-user basis. Others who look at your code may still see the warning. You may also disable the warning by surrounding the „critical“ section with a specific ReSharper comment, but it’s annoying to have your code cluttered like this. Therefore, if your company uses ReSharper, this might be a pragmatic reason to prefer the cast ( ) operator over the "as" operator.

In my opinion, it would be better if the C# "as" operator did not return null, but throw an InvalidCastException if the direct cast is not possible. Nothing of importance would be lost by this – you can always check for null with the "is" operator - but a lot of misunderstandings and disagreements would be prevented. Interestingly, the VB.NET language has the DirectCast operator, which does exactly this. A similar behavior could be implemented in C# like this:

public static T As<T>(this object o) where T: class{
(o == null) throw new NullReferenceException();
(!(o is T)) throw new InvalidCastException();
o as T;

Simulating multiple inheritance in C#

by Marc Sigrist 18. February 2010 23:15

It is possible to simulate multiple inheritance in C#, in a limited way, by applying extension methods to interfaces. An example is shown below. Note that this works only for method implementation inheritance, but not for properties or any other kinds of base members.

The C# team originally considered including extension properties in C# 4.0, but then dropped the feature. The reason apparently was that including extension properties would logically imply including indexed extension properties as well, which C#, by design, does not support. However, accessing (but not defining) indexed properties will be introduced in C# 4.0, in order to make it easier to work with COM interop. Another reason might be that extension properties in C# 4.0 would cause conceptual confusion with the already-existing feature of attached properties in WPF. Interestingly, F# does offer extension properties, but it cannot be used (yet?) as code-behind language for WPF XAML files.

You probably will not use this approach in order to „simulate multiple inheritance“ very often. However, the capacity to add extension methods to interfaces, as such, is a powerful feature. It allows to cleanly separate categories of standard behaviors from their owners.

 using System;

// This test shows how to simulate multiple inheritance in C#.

// Requires .Net Framework 3.5 as target framework.

namespace Test {

    interface IBase1 { }


    static class Base1Implementation {

        internal static void Base1Method(this IBase1 base1) {

            Console.WriteLine("Base1Method called.");




    interface IBase2 { }


    static class Base2Implementation {

        internal static void Base2Method(this IBase2 base2) {

            Console.WriteLine("Base2Method called.");




    class Derived: IBase1, IBase2 { }


    static class Program {

        static void Main() {

            var derived = new Derived();

            derived.Base1Method(); // Writes "Base1Method called."

            derived.Base2Method(); // Writes "Base2Method called."