6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 16.1.9 In general, however, we see that our evaluator has exactly the Meal kind of form that we slowly evolved in our previous examples.(define(meal Given an expression and an environment, eval will check the type of the expression, using some abstractions that we will ion? erp) (eval-definition exp en get to, to see if it is a primitive, or if it is a special form, or ultimately if it is an application In each case. eval mmake-procedure -body exp) dispatches that expression to a specific pr ocedure exp) ev) already seen many of these pieces. We know that for variables we should just look up the value of the variable in the telse (error Unknow ion t RVAL environment. We know that for quoted expressions, we should simply grab the expression as tree structure and return it Similarly for the special forms: a definition should create a new binding for a name and a value in the environment; an if should change the order of evaluation of the For an application, we should evaluate the first subexpression( the operator), then evaluate all the other ubexpressions, and apply that operator to that list of values. Notice that I have slightly misled you because we don 't have to assume that the operator is the first subexpression Operator is simply some data abstraction that will get the appropriate subexpression but it could in fact be some piece other than the first or leftmost one Basic Semantics: meval& apply Slide 16.1.10 Here is a quick synopsis of what we see on that evaluator. It self-evaluating, quoted dispatches on type: first for primitives, either self-evaluating vanables and the ey things or things that should not be evaluated; then for ariable definition, lookup and assignment expressions that deal with variables and their manipulation within the environment (creating, looking up, or changing values of variables), then for conditionals, ways of branching depending on the value of an expression; then procedure application sequences 1n Note there are several new forms here that we will have to define: quoted objects, cond, and begin. Let's take a look at some of these Slide 16.1.ll Side comment- procedure body In our evaluators from the previous lectures, when we applied a. The procedure body is a sequence of one or more procedure to a set of arguments, we saw that reduced to simply evaluating the body of the procedure with respect to a new defin environment Evaluation of the body was simply a case of using th⊥nq(+x1)) eval on that expression, and that was because we assumed the body was just a single expression. Before we introduced In m-apply, we eval-sequence the procedure body mutation into our language, this made perfect sense, because the value of the body would be the value of the last expression in it, and it only made sense to have one expression, since any other expressions value in a body would be lost Once we have mutation, however, expressions can do things other than return values they can create side effects. So a generalization for an evaluator is to let the body of a procedure be a sequence of one or more expressions. That is shown here, in which we define foo to be a procedure whose body has two expressions. The first does something, probably a side effect, and the second of6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 16.1.9 In general, however, we see that our evaluator has exactly the kind of form that we slowly evolved in our previous examples. Given an expression and an environment, eval will check the type of the expression, using some abstractions that we will get to, to see if it is a primitive, or if it is a special form, or ultimately if it is an application. In each case, eval dispatches that expression to a specific procedure. We have already seen many of these pieces. We know that for variables, we should just look up the value of the variable in the environment. We know that for quoted expressions, we should simply grab the expression as tree structure and return it. Similarly for the special forms: a definition should create a new binding for a name and a value in the environment; an if should change the order of evaluation of the subexpressions. For an application, we should evaluate the first subexpression (the operator), then evaluate all the other subexpressions, and apply that operator to that list of values. Notice that I have slightly misled you because we don't have to assume that the operator is the first subexpression. Operator is simply some data abstraction that will get the appropriate subexpression but it could in fact be some piece other than the first or leftmost one. Slide 16.1.10 Here is a quick synopsis of what we see on that evaluator. It dispatches on type: first for primitives, either self-evaluating things or things that should not be evaluated; then for expressions that deal with variables and their manipulation within the environment (creating, looking up, or changing values of variables); then for conditionals, ways of branching depending on the value of an expression; then procedure application. Note there are several new forms here that we will have to define: quoted objects, cond, and begin. Let's take a look at some of these. Slide 16.1.11 In our evaluators from the previous lectures, when we applied a procedure to a set of arguments, we saw that reduced to simply evaluating the body of the procedure with respect to a new environment. Evaluation of the body was simply a case of using eval on that expression, and that was because we assumed the body was just a single expression. Before we introduced mutation into our language, this made perfect sense, because the value of the body would be the value of the last expression in it, and it only made sense to have one expression, since any other expression's value in a body would be lost. Once we have mutation, however, expressions can do things other than return values: they can create side effects. So a generalization for an evaluator is to let the body of a procedure be a sequence of one or more expressions. That is shown here, in which we define foo to be a procedure whose body has two expressions. The first does something, probably a side effect, and the second of