No code is required to define a module. If a codefile does not contain a leading namespace or module declaration, F# code will implicitly place the code in a module, where the name of the module is the same as the file name with the first letter capitalized.

To access code in another module, simply use . notation: moduleName.member. Notice that this notation is similar to the syntax used to access static members -- this is not a coincidence. F# modules are compiled as classes which only contain static members, values, and type definitions.

Note: Its possible to nest submodules inside other submodules. However, as a general principle, its best to avoid creating complex module hierarchies. Functional programming libraries tend to be very "flat" with nearly all functionality accessible in the first 2 or 3 levels of a hierarchy. This is in contrast to many other OO languages which encourage programmers to create deeply nested class libraries, where functionality might be buried 8 or 10 levels down the hierarchy.

Seq has a forall member, but does not have a corresponding foralli function, which includes the index of each sequence element. We add this missing method to the module simply by creating another module with the same name. For example, using fsi:

The System.String has many useful methods, but let's say we thought it was missing a few important functions, Reverse and IsPalindrome. Since this class is marked as sealed or NotInheritable, we can't create a derived version of this class. Instead, we create a module with the new methods we want. Here's an example in fsi which demonstrates how to add new static and instance methods to the String class:

By default, all members in a module are accessible from outside the module. However, a module often contain members which should not be accessible outside itself, such as helper functions. One way to expose only a subset of a module's members is by creating a signature file for that module. (Another way is to apply .Net CLR access modifiers of public, internal, or private to individual declarations).

Signature files have the same name as their corresponding module, but end with a ".fsi" extension (f-sharp interface). Signature files always come before their implementation files, which have a corresponding ".fs" extension. For example:

Since Stack.internal_head_tail is not defined in our interface file, the method is marked private and no longer accessible outside of the DataStructures module.

Module signatures are useful to building a code library's skeleton, however they have a few caveats. If you want to expose a class, record, or union in a module through a signature, then the signature file must expose all of the objects members, records fields, and union's cases. Additionally, the signature of the function defined in the module and it's corresponding signature in the signature file must match exactly. Unlike OCaml, F# does not allow a function in a module with the generic type 'a -> 'a -> 'a to be restricted to int -> int -> int in the signature file.

A namespace is a hierarchial catergorization of modules, classes, and other namespaces. For example, the System.Collections namespace groups together all of the collections and data structures in the .NET BCL, whereas the System.Security.Cryptography namespace groups together all classes which provide cryptographic services.

Namespaces are primarily used to avoid name conflicts. For example, let's say we were writing an application incorporated code from several different vendors. If Vendor A and Vendor B both have a class called Collections.Stack, and we wrote the code let s = new Stack(), how would the compiler know whether which stack we intended to create? Namespaces can eliminate this ambiguity by adding one more layer of grouping to our code.

You may have expected the code in Program.fs above to open Princess.Collections.DataStructures rather than Princess.Collections. According to the F# spec, F# treats anonymous implementation files (which are files without a leading module or namespace declaration) by putting all code in an implicit module which matches the code's filename. Since we have a leading namespace declaration, F# does not create the implicit module.

.NET does not permit users to create functions or values outside of classes or modules. As a consequence, we cannot write the following code:

Since we have a leading namespace declaration in both files, F# does not create any implicit modules. The 'a stack, 'a tree, Stack, and Tree types are all accessible through the Princess.Collections namespace: