Syntactic modules

Let's look at another way of creating modules in Reason: syntactic modules. These are modules that are defined using Reason's module syntax. Here's an example:

/* src/Ch03/Ch03_Domain.re */
module Person = {
  type t = {id: int, name: string};
  let make(id, name) = {id, name};
};

module Company = {
  type t = {id: int, name: string, employees: list(Person.t)};
};

Here we define a Domain file module to contain two nested modules: Person and Company. These nested modules actually contain types similar to the ones we defined in src/Ch02/Ch02_Demo.re, but this time with both types named t.

Syntactic modules have the following form: module Name = {...bindings...}; and all the bindings are then available to outside consumers under the module name, for example, Name.binding1, and so on.

Earlier, we said that modules package types and values together. But in the preceding example, you can see that the Ch03_Domain file module itself contains two modules, Person and Company. I actually oversimplified before. Modules can recursively contain other modules! This is a great code organization and namespacing strategy.

Let's look at the (relevant part of the) JavaScript output to understand what the runtime effect of this domain module is:

// src/Ch03/Ch03_Domain.bs.js
function make(id, name) { return [id, name]; }

var Person = [make];
var Company = [];
exports.Person  = Person;
exports.Company = Company;

The Person and Company modules are represented as JavaScript arrays, and their t types are completely erased, leaving the arrays almost empty. The arrays contain only what file-level module JavaScript output would contain: values. In fact, this is almost exactly how Reason represents modules when compiled to bytecode or native binary form.