6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 15.7.39 What else do we still need? Lookup needs to be a bit more explicit. To look up a value in an environment, we start by asking if the environment is empty. If it is, we have a problem 也nhnn时西m七 and we complain that there cannot be a binding for this variable. Otherwise we do what we did before, the only the first frame of the sequence. If there is no binding there, we E d r difference is that we do the lookup with a table-get in recursively move on to doing the lookup in the remainder of the environment. Thus we are just walking down the list of frames looking in each one for a binding of the variable Environment model c● de(part°rea6 Slide 15.7.40 d to make is to de fine * w know this should change the first frame of the environment chain. Thus we should do a table-put! into the first ame in this sequence. Note that this is just list manipulation to "” create a proper sequence of frames constituting an environment 6.001 Notes: Section 15.8 Slide 15.8 Thus, we have implemented our interpreter Cycle between eval and apply is the core of the evaluator The key thing to note is the cycle that occurs with application of eval calls apply with operator and argument values a procedure Eval and apply form the core of the apply calls eval with expression and environment evaluator Eval takes an expression and an environment and no pending operations on either call an iterative algorithm if the expression is iterative educes this to app l ying an operator to a set of values. which in turn reduces to evaluating a new expression with respect to a new environment. They continue this cycle unwinding the abstractions of the procedures, until it reduces the expression to primitive components In particular, notice that there are no pending operations on either call. Eval does not have any pending operations, and is inherently iterative. Apply similarly has no pending operations. Thus, if we are evaluating an iterative procedure, we will get an iterative behavior6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 15.7.39 What else do we still need? Lookup needs to be a bit more explicit. To look up a value in an environment, we start by asking if the environment is empty. If it is, we have a problem, and we complaing that there cannot be a binding for this variable. Otherwise we do what we did before, the only difference is that we do the lookup with a table-get in the first frame of the sequence. If there is no binding there, we recursively move on to doing the lookup in the remainder of the environment. Thus we are just walking down the list of frames, looking in each one for a binding of the variable. Slide 15.7.40 The only other change we need to make is to define*. We know this should change the first frame of the environment chain. Thus we should do a table-put! into the first frame in this sequence. Note that this is just list manipulation to create a proper sequence of frames constituting an environment. 6.001 Notes: Section 15.8 Slide 15.8.1 Thus, we have implemented our interpreter. The key thing to note is the cycle that occurs with application of a procedure. Eval and apply form the core of the evaluator. Eval takes an expression and an environment and reduces this to applying an operator to a set of values, which in turn reduces to evaluating a new expression with respect to a new environment. They continue this cycle, unwinding the abstractions of the procedures, until it reduces the expression to primitive components. In particular, notice that there are no pending operations on either call. Eval does not have any pending operations, and is inherently iterative. Apply similarly has no pending operations. Thus, if we are evaluating an iterative procedure, we will get an iterative behavior