File modules

It turns out we've already made some modules! Reason treats the .re source files as modules, so our src/Ch01/Ch01_Demo.re and src/Ch02/Ch02_Demo.re files are automatically available as modules, with the names Ch01_Demo and Ch02_Demo, respectively. In the Reason world, these are called implementation files. We will informally refer to them as file modules.

Let's take advantage of Reason's automatic module resolution, by creating a new (file) module that refers to something in an existing module:

/* src/Ch03/Ch03_Greet.re */
let greet(person: Ch02_Demo.person) = /* (1), (2), (3) */
  "Hello, " ++ /* (4), (5) */
  person.name ++
  " with ID " ++
  string_of_int(person.id) ++ /* (6) */
  "!";

Here we're defining a function that knows how to greet people with a name and an ID. There are a few things happening in this example (marked by the numbered comments):

1. We assign a type to the person function parameter by appending a colon followed by the type. You can read this as "person has type c h 0 2 demo dot person". We can assign types to any function parameters in Reason; they are almost always optional though, because of type inference. In this case, we wanted to be explicit because of a subtle issue: there are actually two different record types (person and company) with the name and id fields in the Ch02_Demo module, and we need to distinguish between them.
2. Function definitions have a body consisting of a single expression; this can also be a compound expression delimited by brackets (we'll see examples later).
3. We can have a person value and a person type–they don't clash because Reason stores them separately, in the static and dynamic environments.
4. Reason is whitespace-insensitive; you can lay out your code any way you want, as long as you separate bindings with a semicolon. For most codebases, you would actually just use the Reason formatter tool, refmt, which would automatically take care of all formatting.
5. The ++ operator in Reason concatenates two strings (and nothing else!) together.
6. person.id is an int, so we can't concatenate it with its surrounding strings–unless we convert it to a string with the built-in string_of_int function. Reason has strict, strong typing, and doesn't implicitly convert between types (not even between int and float variables).

To understand what Reason is doing for us, let's look at the relevant part of the output JavaScript:

// src/Ch03/Ch03_Greet.bs.js
function greet(person) {
  return "Hello, "
    + person[1]
    + " with ID "
    + String(person[0])
    + "!";
}

As usual, we see the types are completely erased, and the output is concerned only with values. Based on the types, though, the Reason compiler knew to access the person's name at array index 1 and ID at index 0. Also, it knows to ensure that person[0] gets converted into a string by using the JavaScript string constructor.

In the JavaScript world, we'd say that such a conversion is unnecessary. But in the statically typed Reason world, the compiler keeps a tally of the types of all values and ensures they interact only according to the rules of their types. Thus we ensure that a number can't accidentally be added to a series of strings.

On a larger scale, notice that the fact that Reason files are modules is not directly visible in the JavaScript output code–except that the Reason files are directly compiled, with a one-to-one relationship, to JavaScript modules.