[1] Actually, this is not quite true. One exception was the random-number generator in section 1.2.6. Another exception involved the operation/type tables we introduced in section 2.4.3, where the values of two calls to get with the same arguments depended on intervening calls to put. On the other hand, until we introduce assignment, we have no way to create such functions ourselves.
[2] Note that assignment statements look similar to and should not be confused with constant and variable declarations of the form const $\textit{name}$ = $\textit{value}$; and let $\textit{name}$ = $\textit{value}$; in which a newly declared $\textit{name}$ is associated with a $\textit{value}$. Also similar in looks but not in meaning are expressions of the form $\textit{expression}_1$ === $\textit{expression}_2$ which evaluate to true if $\textit{expression}_1$ evaluates to the same value as $\textit{expression}_2$ and to false, otherwise.
[3] We have already used sequential composition implicitly in our programs, because in JavaScript the body of a function can be a sequence of statements, not just a single return statement, as discussed in section Cound not find label for sec:block-structure.
[4] Blocks as bodies of function definition expressions were introduced in section 2.2.4.
[5] In programming-language jargon, the variable balance is said to be encapsulated within the new_withdraw function. Encapsulation reflects the general system-design principle known as the hiding principle: One can make a system more modular and robust by protecting parts of the system from each other; that is, by providing information access only to those parts of the system that have a need to know.
[6] In contrast with make_withdraw above, we do not have to use let to make balance a local variable, since formal parameters are already local. This will be clearer after the discussion of the environment model of evaluation in section 3.2. (See also exercise 3.10.)
3.1.1 Local State Variables