Scoping and shadowing

Whenever we define values, they exist (in the dynamic environment) in a scope, in which all previously defined names are available but only until the end of the scope. Scopes are nested inside each other, starting with the top level scope (the definitions at the file level), and nested scopes inside braces ({...}). For example:

/* src/Ch02/Ch02_Scope.re */
let x = 1;

let y = x + 1;

let z = {
  let result = 0;
  result + x + y
};

Here, x and y are in the top level scope, where y can access x by name because x is defined before y; z can access both for the same reason. However, note the definition of result in the nested scope introduced by the braces. The name result is only available from the point it is defined up until the closing brace; outside of that scope, referring to result will result in a compile error (specifically, a name error, which we will talk about later in the chapter).

Because Reason puts all definitions in certain scopes, we can define the same name more than once in the same scope or in a nested scope. This is called shadowing because the new definition hides the old one until the new one goes out of scope. Of course, if the old and new names go out of scope together (that is, they're in the same scope), the old name is effectively hidden forever. The following codeblock is an example of this:

/* src/Ch02/Ch02_Shadowing.re */
let name = "Bob";
let age = "33";

let greeting = {
  let age = "34";
  "Hello, " ++ name ++ " aged " ++ age;
};

let name = "Jim";
let greeting2 = "Hello, " ++ name ++ " aged " ++ age;

Let's now take a look at the output JavaScript as follows:

// src/Ch02/Ch02_Shadowing.bs.js
var age = "33";
var greeting = "Hello, Bob aged 34";
var name = "Jim";
var greeting2 = "Hello, Jim aged 33";

Notice how Bob's age is 34 in his greeting – the age in the greeting scope shadows age in the top level scope. However, as soon as that scope ends (with the closing brace), the original age becomes visible again and is used in Jim's greeting2.

However, the second name binding ("Jim") permanently shadows the first one because they are both in the top level scope. In fact, since the first name and the inner age will never be visible again, the BuckleScript compiler doesn't even bother to output them, instead directly inlining their values.