The simplest composite type to understand is the option type, which is effectively an either/or type similar in some ways to the Boolean data type, but with an entirely different purpose and use.

Options are similar to Booleans in that there are only two acceptable values for a given option, None, indicating an absence of value, and Some, which indicates a value. As can be easily inferred from the description here, options are used as a replacement for the null-checking that object-oriented languages traditionally use to determine the difference between "nothing" and "something":

let nothing : string option = None
let something : string option = Some("Ted Neward")
System.Console.WriteLine("nothing = {0}", nothing)
System.Console.WriteLine("something = {0}", something.Value)

As is demonstrated here, options are tied to another type, the actual type "carried" as part of the Some value, which in this case, is a string. (The Option type is a generic type, which should be familiar to .NET developers; generics in F# are discussed in Chapter 10). F# allows us two different ways to specify an option type, one using the T option syntax (as shown here), or to use a more .NET/BCL-like syntax, which may seem more comfortable to the C# crowd:

let nothing : Option<string> = None
let something : Option<string> = Some("Ted Neward")
System.Console.WriteLine("nothing = {0}", nothing)
System.Console.WriteLine("something = {0}", something.Value)

It's important to note that the two syntaxes are entirely equivalent and produce exactly the same IL; the former is preferred among functional-language programmers, but the latter may be more comfortable for object-oriented developers until the functional style becomes more intuitive. (We'll see similar kinds of syntax when looking at list declarations later in this chapter.)

The option type serves as a simple type designed to differentiate between (as its name implies) "some" data and "no" data. Pragmatically, Option acts as a measure to avoid developers having to worry about null-object values and the inevitable NullReferenceException that gets thrown when forgetting to test for null before dereferencing the possibly-null value. Because None is an object instance just as any other object is,^[5] None is perfectly acceptable as a target for comparisons and method calls:

let possibleValue =
    if (System.DateTime.Now.Millisecond % 2) = 0 then
        None
    else
        Some("Have a happy day!")
if possibleValue.IsSome then
    System.Console.WriteLine("Ah, we got a good value. Good!")
    System.Console.WriteLine(possibleValue.Value)

This makes the use of Option vastly superior to the use of null and goes a long way toward removing a significant source of exceptions thrown at runtime. (Consider this a prescriptive piece of advice: Prefer Option to null as a return type indicating a lack of data or response.)

As is shown in the preceding code, testing an option value for Some-ness can be done several different ways. The Option type has several properties defined on it directly, such as the IsSome property already shown, which returns true if the underlying Option is a Some of some value, just as IsNone returns true if the underlying Option instance is set to None. Accessing the value of a Some is done through the Value property, but it is important to note that for None, Value will return null, so only access it when IsSome is true.

Any of the following code, when invoked, will throw an exception, so careless use of None can still create NullReferenceExceptions:

let nothing : string option = None
if nothing.Equals(None) then
    System.Console.WriteLine("None.Equals(None)")
System.Console.WriteLine(nothing.GetHashCode())
System.Console.WriteLine(nothing.ToString())

F# does this for efficiency and performance reasons, so although the compiler does attempt to make None appear as if it is a legitimate value, be careful when trying to peek too far under the hood. More often than not, using IsSome (or relying on the functions described below) is the preferred approach to test for Some-ness or None-ness.

let possibleValue =
    if (System.DateTime.Now.Millisecond % 2) = 0 then
        None
    else
        Some("Have a happy day!")
Option.iter (fun o -> System.Console.WriteLine(o.ToString()))
            possibleValue

Tuples group two or more unnamed values into an ordered collection of values described as a single value:

let myName = ("Ted", "Neward")
let myDescription = ("Ted", "Neward", 38, 98053)

Tuples are described by comma-separated values in between parentheses, so in the preceding snippet, the two tuples listed are of string and string type, and of string and string and int and int or more accurately, (string * string) and (string * string * int * int) in the F# syntax. These are two separate and unique types, even if they have no formal name assigned to them so that any attempt to use a (string * string) where a (string * string * int * int) is expected will fail.

Any tuple whose list of types — in both number and order — is equivalent to another is thus considered to be of the same type. Thus, in the following:

let myName = ("Ted", "Neward")
let herName = ("Sarah", "Michelle", "Gellar")

the two values, myName and herName, are of entirely separate types and therefore incompatible, whereas in:

let myName = ("Ted", "Neward")
let cityState = ("Phoenix", "AZ")

the values myName and cityState, despite representing obviously different intended values, are both (string * string), and therefore are type-equivalent. Formally, this kind of equivalence is known as structural equivalence, meaning that the two values are equal in terms of their contents, even if they may or may not be of the same type.^[6] Thus, when the following is run:

System.Console.WriteLine("myName = herName? {0}",
    myName.GetType().Equals(herName.GetType()))
System.Console.WriteLine("myName = cityState? {0}",
    myName.GetType().Equals(cityState.GetType()))

the resulting printed values will be False and True.

Accessing the individual values inside the tuple is typically done through one of three methods. First, the F# library provides functions (fst and snd) that return individual elements from inside the tuple. Second, pattern-matching can be used to extract elements from within the tuple (and is described in Chapter 6), or third, a new set of individual values can be bound based on values from inside the tuple.

The first approach uses F# library functions fst and snd ("first" and "second") to extract either the first or second element from inside the tuple value:

let me = ("Ted", "Neward")
let firstName = fst me
let lastName = snd me
System.Console.WriteLine("Hello, {0} {1}", firstName, lastName)

Each returns only that particular element, and restrictions on the fst and snd functions require that the tuple be a pair (2-element tuple). For this reason, any triple (3-element tuple) or tuple with elements beyond that will not be accessible via this approach.

The third approach uses new values to pull elements out of the tuple, as in the following:

let me = ("Ted", "Neward", 38, "Redmond", "WA")
let (firstName, lastName, age, city, state) = me
System.Console.WriteLine("Hello, {0} {1}", firstName, lastName)

This is actually a short form of pattern-matching (discussed in Chapter 6) so the use of the wildcard (_) to ignore certain elements of the tuple also works:

let me = ("Ted", "Neward", 38, "Redmond", "WA")
let (firstName, _, _, city, _) = me
System.Console.WriteLine("Hello, {0}, how's {1}",
    firstName, city)

Note that any sort of name-binding can be used, so if we have an array (see the next section for more on arrays) of tuples that we need to extract values from individually, we can do so using for again:

let people = [|
    ("Ted", "Neward", 38, "Redmond", "WA")
    ("Katie", "Ellison", 30, "Seattle", "WA")
    ("Mark", "Richards", 45, "Boston", "MA")
    ("Rachel", "Reese", 27, "Phoenix", "AZ")
    ("Ken", "Sipe", 43, "St Louis", "MO")
    ("Naomi", "Wilson", 35, "Seattle", "WA")
|]
for (firstName, lastName, _, _, _) in people do
    System.Console.WriteLine("{0} {1}", firstName, lastName)

Where other .NET languages tend to use custom value types (those types that inherit from System.ValueType, also known as structs in C# or as Structures in Visual Basic), F# encourages the use of tuples instead. Note that it is still possible to create value types in F# (see Chapter 7 for details), but that should be reserved for the specific case where a new kind of "primitive type" needs to be created, rather than simply creating a "bundle of values," which is the province of the tuple type.

Arrays, as most .NET developers know, are homogenous collections that are laid out sequentially in memory, providing fast random-access capabilities. Because arrays of objects are just arrays of mutable references to objects, however, arrays are discouraged as constructs for use in functional programming. As a fully vested member of the CLR platform, the F# language provides a complete set of functionality to arrays that is similar to that for lists and other collection types, but aside from interoperability with the underlying CLR platform and assemblies written in other languages, F# code "in the wild" rarely uses it. For new F# programmers, the general recommendation is to reach for a list (seen next) rather than an array.

let emptyArray = [| |]

let arrayOfIntegers = [| 1; 2; 3; 4; |]

let arrayOfStrings = [|
    "Fred"
    "Wilma"
    "Barney"
    "Betty"
|]

let arrayOfZeroes = Array.create 10 0
let arrayOfTeds = Array.create 10 "Ted"

let arrayOfIntegers = [| 1 .. 10 |] // [ 1; 2; 3; ... 10; ]

let arrayOfEvenIntegers = [| 0 .. 2 .. 10 |]
    // [ 0; 2; 4; ... 10; ]

let arrayOfFloatsToTen = [ 0.0 .. 0.5 .. 10.0 ]

let mutableArray = Array.create 10 0
for i = 0 to 9 do
    mutableArray.[i] <- i*i

let arrayBuiltList = [ for i in 1 .. 10 -> i * i ]

let (arrayOfObjects : obj array) = [|
    (1 :> obj)
    ("two" :> obj)
    (3.0 :> obj)
|]

let people = [|
    ("Ted", "Neward", 38, "Redmond", "WA")
    ("Mark", "Richards", 45, "Boston", "MA")
    ("Rachel", "Appel", 27, "Pittsburgh", "PA")
    ("Neal", "Ford", 43, "Atlanta", "GA")
    ("Naomi", "Wilson", 35, "Seattle", "WA")
|]
let thirdPerson = people.[2]

// Happy Birthday, Mark!
people.[2] <- ("Mark", "Richards", 46, "Boston", "MA")

let array = Array.create 10 0
for i = 0 to array.Length - 1 do
    System.Console.WriteLine(array.[i])

for p in array do
   System.Console.WriteLine(p)

Array.iter (fun it -> System.Console.WriteLine(it.ToString()))
           array

ParallelArray.iter
    (fun it -> System.Console.WriteLine(it.ToString()))
    array

Lists are an ordered collection of a single type and, like tuples, form a major backbone of functional programming. Internally, lists are singly linked lists, meaning that list construction and extraction is extremely fast and space-efficient. However, random access to elements in the list will be far slower than arrays; fortunately, most functional programming prefers recursion over iteration, and recursion works well to extract elements one at a time out of the list for processing.

let emptyList = []

let listOfIntegers = [ 1; 2; 3; 4; ]
let listOfStrings = [
    "Fred"
    "Wilma"
    "Barney"
    "Betty"
    ]

let listOfStrings = [
    "Fred"      // Flintstone
    "Wilma"     // Flintstone
    "Barney"    // Rubble
    "Betty"     // Rubble
    ]
let listOfPeopleTuples = [
    ("Ted", "Neward", 38, "Redmond", "WA")
    ("Katie", "Ellison", 30, "Seattle", "WA")
    ("Mark", "Richards", 45, "Boston", "MA")
    ("Rachel", "Reese", 27, "Phoenix", "AZ")
    ("Ken", "Sipe", 43, "St Louis", "MO")
    ("Naomi", "Wilson", 35, "Seattle", "WA")
    ]

let listOfIntegersToTen = [ 1 .. 10 ]  // [ 1; 2; 3; ... 10; ]
let listOfEvenIntsToTen = [ 0 .. 2 .. 10 ]
    // [ 0; 2; 4; ... 10; ]
let listOfFloatsToTen = [ 0.0 .. 0.5 .. 10.0 ]

let consedList = 1 :: 2 :: 3 :: 4 :: []

let consedList = 1 :: (2 :: (3 :: (4 :: [])))

let mutable forBuiltList = []
for i = 1 to 10 do
    forBuiltList <- (i * i) :: forBuiltList

let forBuiltList = [ for i in 1 .. 10 -> i * i ]

let concattedList = listOfIntegers @ consedList
    // [ 1; 2; 3; 4; 1; 2; 3; 4; ]

listOfIntegers : int list
listOfStrings : string list
listOfPeopleTuples : (string*string*int*string*string) list
listOfFloatsToTen : float list
consedList : int list
forBuiltList : int list
concattedList : int list

let notWorkingList = [ 1; "2"; 3.0; ]

let (objectList : obj list) = [
    (1 :> obj)
    ("2" :> obj)
    (3.0 :> obj)
]

let people = [
    ("Ted", "Neward", 38)
    ("Mark", "Richards", 45)

("Naomi", "Wilson", 38)
    ("Ken", "Sipe", 43)
]
let peopleHead = people.Head
System.Console.WriteLine(peopleHead)

let people = [
    ("Ted", "Neward", 38)
    ("Mark", "Richards", 45)
    ("Naomi", "Wilson", 38)
    ("Ken", "Sipe", 43)
]
let firstPerson = List.head people
System.Console.WriteLine(firstPerson)

let people = [
    ("Ted", "Neward", 38)
    ("Mark", "Richards", 45)
    ("Naomi", "Wilson", 38)
    ("Ken", "Sipe", 43)
]
let (personOne :: rest) = people
System.Console.WriteLine(personOne)

Because using the functions described in the List and Array modules can be confusing at first to the traditional object-oriented programmer, a few examples may help clear up their use.

In C# and Visual Basic, when looking through an array (or list) of Person objects for a Person whose last name is "Neward", most programmers write a for-each loop, looking through at the LastName property of the Person object to see if it matches the criteria in question. To do this in F#, assuming the existence of a class type called Person was already defined, you would write instead:

let people = [|
    new Person("Ted", "Neward", 38)
    new Person("Mark", "Richards", 45)
    new Person("Ken", "Sipe", 43)
    new Person("Naomi", "Wilson", 38)
    new Person("Michael", "Neward", 16)
    new Person("Matthew", "Neward", 9)
|]
let newardsFound =
    Array.find (fun (it : Person) -> it.LastName = "Neward")
               people
System.Console.WriteLine(newardsFound)

If, instead, the goal was to know all the people who were of drinking age, however, the find operation would want all the Persons whose age was greater or equal than 21. Because this could be any number of Persons, and all of them need to be returned, this is better returned as another array:

let drinkers =
    Array.filter (fun (it : Person) -> it.Age > 21) people

Of course, everybody who's over 21 deserves a beer, and that's something that needs to be applied to each element in the array:

Array.iter (fun (it : Person) ->
    System.Console.WriteLine("Have a beer {0}!", it.FirstName))
    drinkers

The real power of this functional style becomes apparent when used with the pipeline operator (discussed in Chapter 13) to string each of these operations together:

people
    |< Array.filter (fun (it : Person) -> it.Age > 21)
    |< Array.iter (fun (it : Person) ->
        System.Console.WriteLine("Have a beer, {0}!",
            it.FirstName))

When the filtered and iterated functions are named, the code becomes almost a natural language:

people |> Array.filter isADrinker |> Array.iter haveABeer

Or the functions involved in the filter and iter operations can be named to make it look even more readable:

let isADrinker (ar : Person array) =
    Array.filter (fun (p : Person) -> p.Age > 21) ar
let haveABeer (ar : Person array) =
    Array.iter (fun (p : Person) ->
        System.Console.WriteLine("Have a beer, {0}!",
            p.FirstName) )
        ar
people |> isADrinker |> haveABeer

Of course, all these operations are equally applicable to either arrays or lists, simply by either converting the type descriptors to use Person list instead of Person array, or in some cases by omitting the type descriptor entirely and allowing F# to infer the types.

F#, like most functional languages, is without peer when working with collections this way. Most C# and VB developers, after having used LINQ for a while, discover that many of the exact same concepts built into LINQ are here in F# (and other functional languages). Even more deeply, if the budding F# programmer wants to spend a few mind-blowing moments, they should go back to their old SQL code, replace the columns with tuples and the tables with lists of tuples, and see how quickly list access and manipulation in F# using functions feels almost identical to the canonical SQL operations (SELECT, INSERT, UPDATE, DELETE).

More on using F# against a relational database is given in Chapter 19.

A sequence, according to the formal definition of the F# language, is simply a synonym for the IEnumerable type defined in the .NET platform. As such, anytime an F# function produces an iterator across a collection, it is typically a sequence type. However, because functional languages have a rich history of using generators (functions that produce values, including functions that appear to be infinitely large or lazily computed) as the source of values to other functions, F# has a much wider suite of functions for sequence types (seq) than the .NET developer might expect.

By default, the sequence type is just a producer of values; in other words, when a sequence is obtained, the sequence itself has no sense of what values it holds and will hand back — instead, it has code internally that knows how to produce the next-expected value. For this reason, sequences are frequently thought of as lazy, meaning they do not initialize to contain all the values they will eventually produce.^[8]

By far, the easiest way to obtain a sequence is to create one, using the seq keyword and a block of code that yields a result each time the sequence is asked to produce one, as in:

let x = seq { for i = 1 to 10 do yield i }

It's important to note that the sequence will not have yet produced any values — x is simply a generator of values, and each time it is asked to generate the value, it will execute the next branch of the for construct. This means that the loop inside of the sequence isn't really a loop at all, but a sequence of executable statements — contrary to what might seem obvious, there isn't a collection of 10 integers waiting to be handed back.

This becomes more obvious when we put some obvious side effect into the sequence loop, such as:

let y = seq { for i = 1 to 10 do
                System.Console.WriteLine("Generating {0}", i)
                yield i }

When run, no such "Generating" lines appear on the screen, because as of this point, the sequence has only been created, not asked to produce a value. The Console.WriteLine action won't take place until the sequence is asked to produce a value, such as when we convert the sequence into an IEnumerable and ask it for its current value:

let y = seq { for i = 1 to 10 do
                System.Console.WriteLine("Generating {0}", i)
                yield i }
let yEnum = y.GetEnumerator()
if yEnum.MoveNext() then
    System.Console.WriteLine(yEnum.Current)

This will produce "Generating 1" to the screen as soon as MoveNext() is called, because it is at that point that the sequence is asked to produce its first value. No other value is generated, because only that particular value is needed — any future values will be waiting to be generated on demand.

Note that sequences can be "reset" at any time by obtaining a new IEnumerator from the GetEnumerator() method on the sequence, or by simply using the sequence in a different Seq module call. It is important to realize, however, that it is the IEnumerator that holds the "current state" of the sequence and not the sequence itself.

This means that F# can permit what other languages would consider to be "impossible" sequences, such as a sequence that never terminates. Imagine for a moment that we have a program that needs to simulate rolling three six-sided dice several times.^[9] This can be approximated by an infinite sequence generating random numbers between 3 and 18, inclusive. We can generalize the function that creates it to generate random numbers between any minimum and maximum values:

let randomNumberGenerator minVal maxVal =
    let randomer =
        new System.Random()
    seq {
        while (true) do
             yield (randomer.Next(maxVal - minVal) + minVal)
    }
let diceRolls = (randomNumberGenerator 3 18) |> Seq.take 6
Seq.iter
    (fun (roll : int) ->
        System.Console.WriteLine("You rolled a " +
            roll.ToString()))
    diceRolls

(See Chapter 13 for details on writing functions.) This code uses the Seq.take function to obtain the first six values from the sequence, which should range between the values 3 and 18 and then takes that resulting sequence of six "die rolls" and hands that into the Seq.iter function for printing each roll to the console.

In Chapter 4, we saw that for loops could be initialized with range expressions that made it fairly easy to iterate through a collection of numbers in a sequential stepped format. It turns out that the range expression is a kind of sequence expression so that the expression seq {0 .. 2}; produces a sequence consisting of the values 0, 1, and 2. However — the difference between this expression and the list or array examples we saw earlier is that, as discussed already, the sequence has not yet produced those values but will do so on demand.

Combining sequences with a "for comprehension" is a trivial and natural thing to do, as in:

let squares = seq { for i in 0 .. 10 -> (i, i*i) }

This produces a sequence of int * int tuples consisting of the numbers 0 through 10 and their squares; but again, the lazy nature of the sequence means that the body of the for loop has not yet been fired but is waiting to be asked for the first value.

Sequences have broad application beyond just the computation of numbers, particularly anywhere a stream of data instances from outside the program itself is the principal data item. For example, developers frequently iterate through a directory or series of directories looking for files of a particular type for processing. If we consider the file itself to be the data item in question, then the directory or set of directories becomes the scaffolding for the sequence:

let dir d =
    let di = new System.IO.DirectoryInfo(d)
    seq { for fi in di.GetFileSystemInfos() -> fi }

This makes it easy to get all the files in the root directory on the system:

let rootFiles = dir "C:\"

Now, of course, given the sequence, it becomes trivial to walk through those files and display their names:

let printFileInfo (fi : System.IO.FileSystemInfo) =
    System.Console.WriteLine("{0}", fi.FullName)
for fi in rootFiles do printFileInfo fi

But the real power of the sequence again comes in its laziness; normally, trying to build a list of all the files on the system requires the program to do a harsh bit of I/O gathering up all the data required, but if a sequence is generated instead of an ordinary list, no disk I/O is performed until the developer starts to look through the sequence:

let rec recursiveDir d =
    let di = new System.IO.DirectoryInfo(d)
    seq {
        for f in di.GetFiles() do yield f
        for sd in di.GetDirectories() do
            yield! recursiveDir sd.FullName }
let allFiles = recursiveDir @"C:"
for fi in allFiles do printFileInfo fi

A couple things are happening here simultaneously: One, the sequence is being built from two sources, rather than the single source expression that's been demonstrated so far, and two, rather than using the yield keyword to return a single instance back to the sequence, we use the yield! keyword to yield back a sequence into the sequence, essentially appending the results of that (recursively obtained) sequence to the one being generated. This second sequence, the one generating an additional sequence, must be the last expression in the sequence block. Any number of item-generating expressions can be used prior to that, however.

Like the array and list types, the sequence has a large number of functions defined in the Seq module and can be thought of in a few loosely grouped categories which are described next.

Maps, or dictionaries as the .NET FCL tends to call them, are collections of object-to-object pairings, most often used as name-value or key-value pairs, where the key is typically a string and the value is any particular type. Although not officially supported as an F# language construct, maps are commonly enough used that we can think of them as such, and have a number of interesting library supporting functions that make them almost trivial to use.

let nicknames = Map.ofList [
                    "Ted",new Person("Ted", "Neward", 38);
                    "Katie",new Person("Katie", "Ellison", 30);
                    "Mike",new Person("Michael", "Neward", 16)
                ]

let moreNicknames =
    nicknames.Add("Mark", new Person("William","Richards",45))

let numberMappings = dict [
                         (1, "One"); (2, "Two"); (3, "Three")
                     ]

let ted = nicknames.["Ted"]
System.Console.WriteLine(ted)

let ted = Map.find "Ted" nicknames
System.Console.WriteLine(ted)

try
    let noone = nicknames.["Katie"]
    System.Console.WriteLine(noone)
with
| ex -> System.Console.WriteLine("Katie not found")

try
    let noone = Map.find "Katie" nicknames
    System.Console.WriteLine(noone)
with
| ex -> System.Console.WriteLine("Katie not found")

let notfound = nicknames.TryFind("Katie")
System.Console.WriteLine(
    if notfound = None then "Not found"
    else notfound.Value.ToString()

)
    let notfound = Map.tryFind "Katie" nicknames
    System.Console.WriteLine(
        if notfound = None then "Not found"
        else notfound.Value.ToString()
    )

Sets are another example of a type in F# that isn't implemented as a built-in type, yet has syntactic support enough to make it "feel" as it if were built-in, like maps. Fundamentally, a set is a strongly typed collection of objects that enforces a "no duplicates" principle:

let setOfPeople = Set.ofList [ new Person("Ted", "Neward", 38);
                               new Person("Ted", "Neward", 38);
                               new Person("Ted", "Neward", 38); ]
for p in setOfPeople do
    System.Console.WriteLine(p)

When run, only one object will display, the other two having been determined to be duplicates and therefore discarded.

The object that is returned is a Set<>, in this particular case, a Set<Person>, and like the preceding map, implements many of the .NET FCL types that .NET developers would expect for a collection type: IComparable, ICollection, and IEnumerable to be precise. (See Chapter 9 for details on interface inheritance in F#.) It also implements the interface corresponding to sequences, so any place a sequence is expected, a correspondingly strongly typed set can be passed in its place.

Like the map, sets can also be constructed using the set function that takes a list and converts it to a set:

let setOfNicknames = set [ "Ted"; "Theo"; "Tio";
                           "Ted"; "Ted"; "Teddy" ]
for p in setOfNicknames do
    System.Console.WriteLine(p)

In the case of set, however, the returned object is the exact same type as that returned from Set.ofList (or Set.ofArray or Set.ofSeq, used to construct sets from arrays or sequences, respectively), so there is no practical difference between the two.

One thing that differentiates sets from other collections is that types that are placed into a set must be comparable somehow so that the set can determine if the object instance is already present inside the set. In F#, this means the type in question must implement the IComparable interface (as described in Chapter 9), and as a result any type which doesn't support IComparable, such as the base type System.Object, won't go into a set; attempts to do so will generate an error, either at compile-time or at runtime.

Given that objects in a set are comparable, however, the set can provide some interesting additional functionality, such as finding the maximum and minimum value of all the items inside the set. These are available either as instance methods on the Set<> object, or as library methods from the Set module.

Again like its cousin the map, the set is an immutable collection, meaning that any attempt to modify the set will result in a new set being created and returned. More interestingly, however, beyond the simple add and remove from the set, the set also supports various "set theory" operations, such as intersection, union, difference, and testing for superset and subset comparison operations, all of which are possible because of the "comparison requirement" that sets impose on their contents.

In general, sets are good for domain objects, because domain objects frequently want or need to be unique within the domain, and the set operations can reduce the code developers need write.

F# provides a number of powerful composite types for the F# programmer, above and beyond those provided by the underlying .NET BCL. Lists are first-class citizens and the preferred way to collect a homogenous group of values together, but arrays are fully supported as well. Option types provide a safer means of dealing with the "no value" possibility, and tuple types provide a stronger method of working with a tightly grouped set of values without going to the trouble of creating a named, distinct type. Sequences are generic streams of objects and can either be a concrete finite set of data or lazily generated values produced on demand. Maps and sets are collection types that have some useful library support that allow them to look like language-supported built-in types and stand as an example of what additional functionality can be layered into F# without having to change the language itself, in addition to being useful entities in their own right.