6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology 6.001 Notes: Section 15.6 Slide 15.6.1 The next stage in the evolution of our evaluator is to pull the 5. Environment as explicit parameter environment out as an explicit parameter. Up until now we could rely on just having a single environment in which to store (eva1'(pus*64)) bindings for variables. It made sense to have a global (eval '(plus* 6 4)environment) environment in which to hold names for procedures and global I .al rocedures that call val have extra argument lookup and define use evironment from argument fact we built a simple version of application but we want to extend that to procedures that need local environments. Thus let's pull out the environment explicitly. So we will have to change our evaluator from simply evaluating expressions to evaluating expressions with respect to some environment What changes to we need? All procedures must now call eval with that extra argument of an environment. Loo kup and define* are going to use that environment argument to specify where to work exphcit paramet Slide 15.6.2 This is actually a really boring change! The functionality of 14 this evaluator is exactly the same as the previous version. All do is extend eval to take an environment as arguments, and then make sure that all the dispatch functions also take environments as arguments. Other a than make those changes, everything else is exactly as before Of course now when we evaluate an expression we have to specify what environment, and we will need an initial or global environment to start with. This will contain bindings for built in procedures Otherwise this is just bookkeeping. It will allow us to extend our evaluator in a more general way Slide 15.6.3 5. Environment as explicit parameter Notice in fact that the only non-trivial case is that dealing with application inside of eval. Remember that this is the dispatch (eva1(p1us*64)) that says that we have to apply the object that represents the (eval ' (plus* 6 4) environment) procedure to its arguments. Notice the change we need. As all procedures that call eval have extra argument before, we will evaluate the first subexpression of the tree lookup and define use environment from argument tructure to get the procedure, now including the environment o other change from evaluator 4 as an argument In order to get the values of the other expressions before we could just map eval down the list of expressions. He Only nontrivial code: case for application? in eval however, we have to evaluate each expression with respect to the environment so we need a lambda here to capture that ..old We will come back to this shortly, but you can see from a Scheme perspective this makes sense. We are mapping a procedure that evaluates each subexpression with respect to the environment passed in. This is the only non-trivial extension in this case6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. 6.001 Notes: Section 15.6 Slide 15.6.1 The next stage in the evolution of our evaluator is to pull the environment out as an explicit parameter. Up until now we could rely on just having a single environment in which to store bindings for variables. It made sense to have a global environment in which to hold names for procedures and global variables. We are about to start moving towards application, in fact we built a simple version of application but we want to extend that to procedures that need local environments. Thus let's pull out the environment explicitly. So we will have to change our evaluator from simply evaluating expressions to evaluating expressions with respect to some environment. What changes to we need? All procedures must now call eval with that extra argument of an environment. Lookup and define* are going to use that environment argument to specify where to work. Slide 15.6.2 This is actually a really boring change! The functionality of this evaluator is exactly the same as the previous version. All we do is extend eval to take an expression and an environment as arguments, and then make sure that all the dispatch functions also take environments as arguments. Other than make those changes, everything else is exactly as before. Of course now when we evaluate an expression we have to specify what environment, and we will need an initial or global environment to start with. This will contain bindings for built in procedures. Otherwise this is just bookkeeping. It will allow us to extend our evaluator in a more general way. Slide 15.6.3 Notice in fact that the only non-trivial case is that dealing with application inside of eval. Remember that this is the dispatch that says that we have to apply the object that represents the procedure to its arguments. Notice the change we need. As before, we will evaluate the first subexpression of the tree structure to get the procedure, now including the environment as an argument. In order to get the values of the other expressions before we could just map eval down the list of expressions. Here, however, we have to evaluate each expression with respect to the environment so we need a lambda here to capture that procedure. We will come back to this shortly, but you can see from a Scheme perspective this makes sense. We are mapping a procedure that evaluates each subexpression with respect to the environment passed in. This is the only non-trivial extension in this case