Types issue in F#

Question

In my ongoing adventure deep diving into f# I am understanding a lot of this powerful language but there are things that I still do not understand so clearly. One of the most important issues I need to master is types.

Well the book I am reading is very straight forward and introduces entities and main functionalities with a direct approach. The first thing I could get start with is types. It introduces the main types as list, option, tuples, and so on... It is clearly underlined that all these types are IMMUTABLE for many reasons regarding functional programming and data consistance in functional programing. Well, no problems until now...

But now I am getting started with Concrete Types...

Well... I have problems in managing with types like list, option, tuples, types created through new operator and concrete types created using type keyword (for abbreviations, concrete types...).

So my question is: how can I efficently catalogue/distinguish all types of data in f#????

I can create a perfect separation among types in C#, VB.NET... FOr example in VB.NET there are value and reference types while in C# there are only references and also int, double are treated as objects (they are objects while in VB.NET a value type is not a object and there is a split in types for this reason). Well in F# I cannot create such differences among types in the language. Can you help me? I hope I was clear.

Answer 1

It's possible that you've misunderstood types in C# and VB.NET. Types work almost the same across all .NET languages; for instance, both VB.NET and C# have value types and reference types.

Any type can be immutable if there's no way to change it from outside. For instance, these two pieces of code are equivalent:

// an immutable reference type in F#
type Person =
    {
        FirstName : string
        LastName : string
    }

// an immutable reference type in C#
public class Person
{
    public Person(string firstName, string lastName)
    {
        FirstName = firstName;
        LastName = lastName;
    }

    public string FirstName { get; private set; }
    public string LastName { get; private set; }
}

Edit: There's nothing really special about the built-in types in F#, except for some special syntax in the compiler. You can make your own - here are examples of list and option :

type List<'a> = Empty
              | Item of 'a * List<'a>

type Option<'a> = None
                | Some of 'a

It helps to take an F# assembly and load it into Reflector, alongside assemblies from C# and VB.NET; you can see that the compiler produces standard .NET types from your F# type declarations.

Answer 2

Update

For a good reference of the different types in F#, scroll down to F# Types on the MSDN article . I've found that the MSDN site really does have some of the best information about F# out there. To summarize, you've got F#'s own flavor of collections (ie Map , Seq , etc), tuples (which are just a like cross product of several types), discriminated unions, and more.

F# uses type inference , so you do not need to explicitly specify the type your member variables in a type/class. This means, that in most scenarios you do not need to specify that variable is an int , double , or any reference type like you would in C#. The distinction between reference types and value types is hidden from you basically.

Also, when you say:

VB.NET there are value and reference types while in C# there are only references

This isn't exactly accurate, it's actually the same in VB.NET/C#, see Jon Skeet's article about reference vs. value types for a really clear explanation.

Answer 3

The challenge of hybrid functional/object-oriented languages like F# is that they must span both functional and object-oriented concepts. Although this makes such languages very powerful, it also makes them large; larger than strictly functional languages or strictly OO languages. One place that is most evident is the type catalog.

The official documention for F# types is here . As you can see, there are no less than 17 different types of...types.

One thing to keep in mind, though, is that any type that can be defined or used in F# must be representable as a .NET type (which implies that it can also be used by other .NET languages). An interesting example of that is Discriminated Union types (discriminated union types are similar to enumerations, except that each alternate value can have other values associated to it). Other .NET languages do not have discriminated union types, so the F# compiler translates such types to object hierarchies. Something gets lost in the translation, though: F# 'knows' all possible cases of the type at compile time, but C# and VB.NET must assume that the number of cases is open-ended.