6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 12.1.6 What the EM is: There are two main reasons for doing this. The first is simply to A precise, completely mechanical des understand the effect of our design choices in creating name-rule looking up the of ava procedures, for example how mutation will affect behavior setl-rule changing the value of a variable Ultimately, however, we are going to see that this environment ting a procedure lying a procedure model serves as a blueprint for building an actual interpreter for Scheme, that is, the actual mechanism for evaluating Scheme .Enables analyzing arbitrary scheme code expressions inside a machine As a consequence, for now we will use abstract representations for now draw EM stat oxes and pointers for our environment model, but we will eventually see how this later on: implement wit leads to a very mechanical method that can be implemented to I actually build a Scheme system Slide 12.1.7 A shift in v As we build up the pieces of our environment model, a key As we introduce the environment model, we are going to hing to keep in mind is that we are about to shift our viewpoint hift our viewpoint on computation on what constitutes the basic units of computation Variable. Until we introduced mutation, we could think of a variable as OLD-name for value NEW- place into which one can store things just being a name for a value. That was exactly how it behaved in the functional viewpoint of computation. Now we are going OLD-functional description to change that viewpoint. We are going to think of a variable as, ErpreEw-object with inherited context a place into which one can store things, a name for a cubicle Now only have meaning with respect to an emvironment into which things can be placed The second change we are going to make deals with 600SC procedures. Up until now, we could really think of a procedure as a functional description of some computation We stressed this idea that evaluating the same expression gave rise to the same value, it behaved as a mapping from input values to output values, like any ordinary function would. Now, we are going to change that viewpoint. We will instead think of a procedure as an object, with an inherited context. That context tells us how to interpret symbols in that computation, which will change our overall view of computation And finally, we are going to change the way we think about expressions. We now will say that an expression only has meaning with respect to a structure called an environment, something that we are about to define. This means that an expression now inherits its value, by inheriting information about what was occurring when they were created So we ask that you keep these ideas in mind as we build our new model of computation. Variables are now places into which one can store things, procedures are now objects with an inherited context, and expressions have meaning only with respect to an environment6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 12.1.6 There are two main reasons for doing this. The first is simply to understand the effect of our design choices in creating procedures, for example how mutation will affect behavior. Ultimately, however, we are going to see that this environment model serves as a blueprint for building an actual interpreter for Scheme, that is, the actual mechanism for evaluating Scheme expressions inside a machine. As a consequence, for now we will use abstract representations for our environment model, but we will eventually see how this leads to a very mechanical method that can be implemented to actually build a Scheme system. Slide 12.1.7 As we build up the pieces of our environment model, a key thing to keep in mind is that we are about to shift our viewpoint on what constitutes the basic units of computation. Until we introduced mutation, we could think of a variable as just being a name for a value. That was exactly how it behaved, in the functional viewpoint of computation. Now we are going to change that viewpoint. We are going to think of a variable as a place into which one can store things, a name for a cubicle into which things can be placed. The second change we are going to make deals with procedures. Up until now, we could really think of a procedure as a functional description of some computation. We stressed this idea that evaluating the same expression gave rise to the same value, it behaved as a mapping from input values to output values, like any ordinary function would. Now, we are going to change that viewpoint. We will instead think of a procedure as an object, with an inherited context. That context tells us how to interpret symbols in that computation, which will change our overall view of computation. And finally, we are going to change the way we think about expressions. We now will say that an expression only has meaning with respect to a structure called an environment, something that we are about to define. This means that an expression now inherits its value, by inheriting information about what was occurring when they were created. So we ask that you keep these ideas in mind as we build our new model of computation. Variables are now places into which one can store things, procedures are now objects with an inherited context, and expressions have meaning only with respect to an environment