6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology 6.001 Notes: Section 16.1 Slide 16.1.1 Building up a language Last time, we completed building our evaluator. And as you saw, we slightly misled you. We started off saying we were going to user Scheme's lexical analyzer and parser, but then build our own evaluator, which we did initially for arithmetic expressions, then for defines, then for applications, and eventually we ended up with something that basically looked ke scheme's evaluator written in Scheme Today, we are going to build on that idea, by examining the actual Scheme evaluator. We will run through a quick, but grand tour of the full evaluator, looking at several key ideas First,remember that we are basically describing the process of /4 evaluation, which in our case means making the environment model a concrete set of procedures. Second, the essential message is that by defining the process of evaluation, we are also defining our language. This means that the evaluator design then provides the basis on which we can create abstractions, especially procedural abstractions, as it provides the mechanism for unwinding the abstraction back down to primitive pieces when we want to get an actual value. And finally, given that designing an evaluator is essentially equivalent to defining a language, we are going to look at how variations in a Scheme evaluator can lead to very different language behavior Building up a language Slide 16.1.2 o do this, we are going to have to look at several different rts of the lar guage design. we eval and apply, then look at how we support the syntax of the language, how we create and manipulate the environments that let us look up values that are associated with that syntax, and then how primitives are installed into the initial primitives and initial env or global environment. Finally, we will put together the overal infrastructure for letting a user interact with the evaluator, and d-eval we will see all of these pieces as we quickly walk through our As with previous lectures, there is a code handout that goes with this lecture, and we suggest you print out a copy and have it available as we walk through our discussion6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. 6.001 Notes: Section 16.1 Slide 16.1.1 Last time, we completed building our evaluator. And as you saw, we slightly misled you. We started off saying we were going to user Scheme's lexical analyzer and parser, but then build our own evaluator, which we did initially for arithmetic expressions, then for defines, then for applications, and eventually we ended up with something that basically looked like Scheme's evaluator, written in Scheme! Today, we are going to build on that idea, by examining the actual Scheme evaluator. We will run through a quick, but grand tour of the full evaluator, looking at several key ideas. First, remember that we are basically describing the process of evaluation, which in our case means making the environment model a concrete set of procedures. Second, the essential message is that by defining the process of evaluation, we are also defining our language. This means that the evaluator design then provides the basis on which we can create abstractions, especially procedural abstractions, as it provides the mechanism for unwinding the abstraction back down to primitive pieces when we want to get an actual value. And finally, given that designing an evaluator is essentially equivalent to defining a language, we are going to look at how variations in a Scheme evaluator can lead to very different language behavior. Slide 16.1.2 To do this, we are going to have to look at several different parts of the language design. We will start with the core of eval and apply, then look at how we support the syntax of the language, how we create and manipulate the environments that let us look up values that are associated with that syntax, and then how primitives are installed into the initial or global environment. Finally, we will put together the overall infrastructure for letting a user interact with the evaluator, and we will see all of these pieces as we quickly walk through our full evaluator. As with previous lectures, there is a code handout that goes with this lecture, and we suggest you print out a copy and have it available as we walk through our discussion