Now that we have seen all the elements of the compiler, let us examine an example of compiled code to see how things fit together. We will compile the declaration of a recursive factorial function by passing as first argument to compile the result of applying parse to a string representation of the program (here using back quotes `$\ldots$`, which work like single and double quotation marks but allow the string to span multiple lines):

compile(parse(`
function factorial(n) {
    return n === 1
           ? 1
           : factorial(n - 1) * n;
}
              `),
        "val",
        "next");

The function compile determines that it was given a function declaration, so it transforms it to a constant declaration and then calls compile_declaration. This compiles code to compute the value to be assigned (targeted to val), followed by code to install the declaration, followed by code to put the value of the declaration (which is the value undefined) into the target register, followed finally by the linkage code. The env register is preserved around the computation of the value, because it is needed in order to install the declaration. Because the linkage is "next", there is no linkage code in this case. The skeleton of the compiled code is thus $\langle{}$save env if modified by code to compute value$\rangle$ $\langle{}$compilation of declaration value, target val, linkage "next"$\rangle$ $\langle{}$restore env if saved above$\rangle$ perform(list(op("assign_symbol_value"), constant("factorial"), reg("val"), reg("env"))), assign("val", constant(undefined))

The expression that is compiled to produce the value for the name factorial is a lambda expression whose value is the function that computes factorials. The function compile handles this by calling compile_lambda_expression, which compiles the function body, labels it as a new entry point, and generates the instruction that will combine the function body at the new entry point with the runtime environment and assign the result to val. The sequence then skips around the compiled function code, which is inserted at this point. The function code itself begins by extending the function's declaration environment by a frame that binds the parameter n to the function argument. Then comes the actual function body. Since this code for the value of the name doesn't modify the env register, the optional save and restore shown above aren't generated. (The function code at entry1 isn't executed at this point, so its use of env is irrelevant.) Therefore, the skeleton for the compiled code becomes $\texttt{ }\texttt{ }$assign("val", list(op("make_compiled_function"), label("entry1"), reg("env"))), go_to(label("after_lambda2")), "entry1", assign("env", list(op("compiled_function_env"), reg("fun"))), assign("env", list(op("extend_environment"), constant(list("n")), reg("argl"), reg("env"))), $\langle{}$compilation of function body$\rangle$ "after_lambda2", perform(list(op("assign_symbol_value"), constant("factorial"), reg("val"), reg("env"))), assign("val", constant(undefined))

A function body is always compiled (by compile_lambda_body) with target val and linkage "next". The body in this case consists of a single return statement:[1]

return n === 1
       ? 1
       : factorial(n - 1) * n;

The predicate n === 1 is a function application (after transformation of the operator combination). This looks up the function expression (the symbol "===") and places this value in fun. It then assembles the arguments 1 and the value of n into argl. Then it tests whether fun contains a primitive or a compound function, and dispatches to a primitive branch or a compound branch accordingly. Both branches resume at the after_call label. The compound branch must set up continue to jump past the primitive branch and push a marker to the stack to match the revert operation in the compiled return statement of the function. The requirements to preserve registers around the evaluation of the function and argument expressions don't result in any saving of registers, because in this case those evaluations don't modify the registers in question. $\texttt{ }\texttt{ }$assign("fun", list(op("lookup_symbol_value"), constant("==="), reg("env"))), assign("val", constant(1)), assign("argl", list(op("list"), reg("val"))), assign("val", list(op("lookup_symbol_value"), constant("n"), reg("env"))), assign("argl", list(op("pair"), reg("val"), reg("argl"))), test(list(op("is_primitive_function"), reg("fun"))), branch(label("primitive_branch6")), "compiled_branch7", assign("continue", label("after_call8")), save("continue"), push_marker_to_stack(), assign("val", list(op("compiled_function_entry"), reg("fun"))), go_to(reg("val")), "primitive_branch6", assign("val", list(op("apply_primitive_function"), reg("fun"), reg("argl"))), "after_call8",

The true branch, which is the constant 1, compiles (with target val and linkage "return") to $\texttt{ }\texttt{ }$assign("val", constant(1)), go_to(reg("continue")), The code for the false branch is another function call, where the function is the value of the symbol "*", and the arguments are n and the result of another function call (a call to factorial). Each of these calls sets up fun and argl and its own primitive and compound branches. Figure 5.22 shows the complete compilation of the declaration of the factorial function. Notice that the possible save and restore of continue and env around the predicate, shown above, are in fact generated, because these registers are modified by the function call in the predicate and needed for the function call and the "return" linkage in the branches.