[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 procedures functions ourselves.
[2] The value of a set! expression is implementation-dependent. Set! should be used only for its effect, not for its value. The name set! reflects a naming convention used in Scheme: Operations that change the values of variables (or that change data structures, as we will see in section 3.3) are given names that end with an exclamation point. This is similar to the convention of designating predicates by names that end with a question mark. The value of an assignment is the value being assigned to the name. Assignment expression statements look similar to and should not be confused with constant and variable declarations of the form const $name$ = $value$; and let $name$ = $value$; in which a newly declared $name$ is associated with a $value$. Assignment expressions look similar to and should not be confused with expressions of the form $expression_1$ === $expression_2$ which evaluate to true if $expression$$_1 evaluates to the same value as expression$$_2$ and to false otherwise.
[3] We have already used cond and in begin implicitly in our programs, because in Scheme the body of a procedure can be a sequence of expressions. Also, the consequent part of each clause in a cond expression can be a sequence of expressions rather than a single expression.
[4] We have already used sequences implicitly in our programs, because in JavaScript the body block of a function can contain a sequence of function declarations followed by a return statement, not just a single return statement, as discussed in section 1.1.8.
[5] In programming-language jargon, the variable balance is said to be encapsulated within the new-withdraw procedure. 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] Blocks as bodies of lambda expressions were introduced in section 2.2.4.
[7] 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.
[8] In contrast with new-withdraw make_withdraw_balance_100 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