One of our goals in this chapter is to isolate issues about thinking procedurally. As a case in point, let us consider that, in evaluating operator combinations, the interpreter is itself following a procedure. Due to the prominence of the keyword function, we are generally replacing references to "procedure/procedural" with references to "function/functional". The above sentences are an exception; the terms "thinking procedurally" and "procedure" are perhaps still adequate for the JavaScript edition here.

• To evaluate a combination, an operator combination, do the following:
  1. Evaluate the subexpressions operand expressions of the combination.
  2. Apply the procedure that is the value of the leftmost subexpression (the operator) to the arguments that are the values of the other subexpressions (the operands). Apply the function that is denoted by the operator to the arguments that are the values of the operands.

The Scheme version does not distinguish between operator and application combinations. However, due to the infix notation, the JavaScript version needs to describe slightly different rules for those two. This section contains the rule for operator combination, and section 1.1.5 introduces a new rule for function application. Even this simple rule illustrates some important points about processes in general. First, observe that the first step dictates that in order to accomplish the evaluation process for a combination we must first perform the evaluation process on each operand of the combination. Thus, the evaluation rule is recursive in nature; that is, it includes, as one of its steps, the need to invoke the rule itself.[1]

Notice how succinctly the idea of recursion can be used to express what, in the case of a deeply nested combination, would otherwise be viewed as a rather complicated process. For example, evaluating

Original	JavaScript
(* (+ 2 (* 4 6)) (+ 3 5 7))	(2 + 4 * 6) * (3 + 12);

requires that the evaluation rule be applied to four different combinations. We can obtain a picture of this process by representing the combination in the form of a tree, as shown in figure 1.1. figure 1.2. Each combination is represented by a node with branches corresponding to the operator and the operands of the combination stemming from it. The terminal nodes (that is, nodes with no branches stemming from them) represent either operators or numbers. Viewing evaluation in terms of the tree, we can imagine that the values of the operands percolate upward, starting from the terminal nodes and then combining at higher and higher levels. In general, we shall see that recursion is a very powerful technique for dealing with hierarchical, treelike objects. In fact, the percolate values upward form of the evaluation rule is an example of a general kind of process known as tree accumulation.

Original		JavaScript
Figure 1.1 Tree representation, showing the value of each subcombination.		Figure 1.2 Tree representation, showing the value of each subexpression.

Next, observe that the repeated application of the first step brings us to the point where we need to evaluate, not combinations, but primitive expressions such as numerals, built-in operators, or other names. numerals or names. We take care of the primitive cases by stipulating that

• the values of numerals are the numbers that they name, and
• the values of built-in operators are the machine instruction sequences that carry out the corresponding operations, and
Operators are not values in JavaScript, so this item does not apply in the JavaScript version.
• the values of other names are the objects associated with those names in the environment.

We may regard the second rule as a special case of the third one by stipulating that symbols such as + and * are also included in the global environment, and are associated with the sequences of machine instructions that are their values. The key point to notice is the role of the environment in determining the meaning of the symbols names in expressions. In an interactive language such as Lisp, JavaScript, it is meaningless to speak of the value of an expression such as (+ x 1) x + 1 without specifying any information about the environment that would provide a meaning for the symbol x (or even for the symbol +). name x. As we shall see in chapter 3, the general notion of the environment as providing a context in which evaluation takes place will play an important role in our understanding of program execution.

Notice that the evaluation rule given above does not handle definitions. declarations. For instance, evaluating (define x 3) const x = 3; does not apply define an equality operator = to two arguments, one of which is the value of the symbol name x and the other of which is 3, since the purpose of the define declaration is precisely to associate x with a value. (That is, (define x 3) const x = 3; is not a combination.)

Original		JavaScript
Such exceptions to the general evaluation rule are called special forms. Define is the only example of a special form that we have seen so far, but we will meet others shortly. Each special form has its own evaluation rule. The various kinds of expressions (each with its associated evaluation rule) constitute the syntax of the programming language. In comparison with most other programming languages, Lisp has a very simple syntax; that is, the evaluation rule for expressions can be described by a simple general rule together with specialized rules for a small number of special forms.[2]		The word const is a keyword in JavaScript. Keywords carry a particular meaning, and thus cannot be used as names. A keyword or a combination of keywords in a statement instructs the JavaScript interpreter to treat the statement in a special way. Each such syntactic form has its own evaluation rule. The various kinds of statements and expressions (each with its associated evaluation rule) constitute the syntax of the programming language.