To get the most from this chapter, we will set up a comfortable edit-compile workflow. We recommend placing two windows side-by-side in your editor. VSCode supports this functionality with the View | Split Editor command. On one side, load a Reason source file; on the other side, load the JavaScript output file (once it is initially compiled). Then in a terminal, run the following command:

bsb -w

The preceding command starts a build in watch mode, which automatically recompiles any parts of a project that are affected whenever you change any source code. In fact, watch mode is smart enough to also remove an outdated JavaScript output file whenever its corresponding Reason source file is deleted. The editor will also auto-reload the compiled JavaScript file whenever you save a Reason source file.

In VSCode, you can also open a terminal session directly below the files...

Let's set the stage for the rest of the book with a discussion of types and values. At its core, a type is a set of values. Think of the type bool, which is what Reason calls the normal Boolean type. A bool value can be one of two different things: true or false. We say that these values inhabit (live in) the type. Anything else is an error.

This raises an interesting question: what does it mean to say? Anything else is an error' in this context? In fact, why should we care about types at all?

To answer these questions, let's think about what should happen if we try to do the operation "Bob" / 5. What does it mean to divide the string Bob by the number 5?

If you can't think of a good answer, well neither can anyone else. It's kind of a meaningless question. It's like asking, how does the color green taste? (Although this...

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...

We mentioned earlier that the compiler will raise errors if it cannot make sense of a piece of code it comes across. There are a few different kinds of compiler errors, and they are as follows

• Syntax errors
• Type errors
• Name errors
• Stale interface errors (which we'll cover in the next chapter)
• Compiler bugs (these are rare but shouldn't be discounted)

The two most common types of error that we will deal with are syntax errors and type errors. Name errors are fairly simple to avoid: always start type names with a lowercase letter and ensure that the names you refer to in your code were defined before you refer to them. (Reason supports cyclic references but not forward references; we'll cover cyclic references later on.)

In this chapter, we covered a lot of ground, including setting up an editorial workflow, learning about types and values, static and dynamic typing, Reason's separation between compile time and runtime and its type erasure, syntax, and type errors, as well as inference and unification.

In future chapters, we will build on this chapter and introduce many more static typing techniques and the potential type errors that we may see from using them.