Static and dynamic environments

Let's develop a mental model for what happens in a program with types and values. At its core, a program is made up of a series of type and value definitions. For example:

/* src/Ch02/Ch02_Demo.re */
type person = {id: int, name: string};
type company = {id: int, name: string, employees: list(person)};

let bob = {id: 1, name: "Bob"};
let acmeCo = {id: 1, name: "Acme Co.", employees: [bob]};

Here, we're defining person and company types, and then allocating a person (bob) and a company he works for (acmeCo).

Without worrying too much about the syntax (we will introduce this in Chapter 4, Group Values Together in Types), let's think about how the programming environment sees this program.

In a statically typed programming language, the typechecker and runtime environment together make up the static and dynamic environments. These are areas where type definitions are stored while typechecking takes place, and where value definitions are stored during program execution (runtime). We can think of these as two distinct areas that are only relevant during the distinct phases of compilation and runtime. After compilation, all type information is wiped out (type erasure), but during runtime the dynamic environment becomes active in memory (that is, the stack and the heap).

Here is how the static and dynamic environments look for the preceding code:

In each of the static and dynamic environments, each definition is allowed to refer to definitions that came before it. This is a crucial abstraction technique – it's how we build larger programs out of smaller ones at both the type and value levels.

Among other things, this strict separation balances the needs of safety and efficiency. Note that this is in sharp contrast to dynamic typing, where types exist at runtime as well, and must be checked before every operation.