liveBook · Manning

Module

As explained in F# in Action: A Revised Edition of Get Programming with F#

A module is a language construct that groups related declarations such as data types, values, and functions under a named scope.

A module groups related types and values under a name. In F#, it is a practical home for the functions that operate on a domain model: keep a Basket record as data, for example, and place AddItem, Clear, and Checkout-style functions in a module. Each function can return an updated basket rather than modifying hidden object state. This separates data from behavior and keeps functions easier to create, test, replace, and understand. section 2.1.3 section 10.1.2

Modules and namespaces both organize code, but modules can contain values as well as types. A symbol inside a module is accessed through its qualified name, such as Module.Symbol, or made convenient with open. Modules can also contain indented submodules; a nested module can use members of its parent without opening it. section 6.2 section 6.2.2 section 6.4

A small utility module

Declare a module, then place related functions beneath it. A nested module can refine the grouping when a simple utility grows. module FsInAction.MyMaths let add x y = x + y let subtract x y = x - y module Complicated = let ten = 10 let addTogetherThenSubtractTen x y = add x y |> subtract ten The functions are available as MyMaths.add and MyMaths.subtract; Complicated is a child module. section 6.2.2

Listing 6.8 Working with modules in F#
module FsInAction.MyMaths                                          #1
 
let add x y = x + y                                                #2
let subtract x y = x - y                                           #2
 
module Complicated =                                               #3
    open System
    let ten = 10                                                   #4
    let addTogetherThenSubtractTen x y = add x y |> subtract ten   #5

Inspect the listing to see a top-level module, module-qualified naming, and an indented child module working together. section 6.2.2

Use modules as an application grows:

  • Start simply: a few modules in a few files can be enough. Group multiple related types in one file rather than enforcing one type per file. section 6.2.5
  • Separate Domain types, Logic functions, and Program orchestration initially; later regroup around areas such as order management, customer management, or billing when that better fits the application. section 6.2.5
  • Use namespaces when separate files need modules beneath the same parent namespace. A fully qualified module cannot be declared across multiple files. section 6.2.2 section 6.2.5
  • Expect an F# module to appear as a static class to C# callers, with its functions and types exposed as members. section 11.2.1

How F# in Action: A Revised Edition of Get Programming with F# covers it

How deep it goes
Defines module members, qualification, nesting, file constraints, and namespace trade-offs without detailing compiled implementation beyond static-class mapping.
Examples
Uses a retail Basket, a MyMaths utility with a Complicated submodule, and Domain, Logic, and Program application groups.
What it assumes
Introduces modules without assuming F# or .NET knowledge, while contrasting them with familiar object-oriented classes and namespaces.
What you can do after
Apply it via F# modules to group types and functions, nest related functionality, and choose namespaces when multi-file hierarchies require them.
How it connects
Connects modules with namespaces, records, tuples, discriminated unions, immutability, functions, pipelines, and C# interop.

Also explained in

Compare how 35 books explain module →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of F# in Action: A Revised Edition of Get Programming with F#. The section links point to the parts of the book it draws on.