6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 15.8.2 SuI So it appears that we have worked up to a fairly full-fledged Cycle between eval and apply is the core of the evaluator evaluator. What's is still missing from this interpreter? Only a s apply apply calls eval with expression and environment couple of things right now we can,'t evaluated a sequence of no pending operations on either call expressions. For example the bodies of our procedures expect an iterative algorithm if the expression is iterative only one expression. It would be fairly easy to add such a .What is still missing from scheme*? apability into our system. What else are we missing? We only ility to eval nce of expressions have a couple of data types right now. So for example we might data types other than numbers and booleans add in strings or other data types Slide 15.8.3 This then leads to the major punch line of this lecture Everything in this lecture would still work if we just removed Cycle between eval and apply is the core of the evaluator eval calls apply with operator and argument values the *'s from the names! So what does that mean? It says that apply calls eval with expression and en no pending operations on either call what we have done is describe the process of evaluation and interpretation in Scheme. We have really built a Scheme .What is still missing from scheme*? interpreter. Not as complete as the full-blown one, but the . ability to evaluate a sequence of expressions things missing are pretty minor. Literally everything weve done data types other than numbers and booleans would still work if we removed the x's which says we can build Everything in these lectures would still work if you deleted a Scheme interpreter. We happen to have done it on top of the stars from the names Scheme, but we could have done it on top of a more primitive 4 language, or we could have done it in some other language, and this is the central point. by defining an evaluator or an interpreter we are defining the language. We are specifying what it means to evaluate expressions in this language, what is the legal syntax and the legal semantics, and once we have done that we have created a language that we can then use to solve other problems. This point we will return to. but this is the " take home"message of this lecture6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 15.8.2 So it appears that we have worked up to a fairly full-fledged evaluator. What's is still missing from this interpreter? Only a couple of things: right now we can't evaluated a sequence of expressions. For example the bodies of our procedures expect only one expression. It would be fairly easy to add such a capability into our system. What else are we missing? We only have a couple of data types right now. So for example we might add in strings or other data types. Slide 15.8.3 This then leads to the major punch line of this lecture. Everything in this lecture would still work if we just removed the *'s from the names! So what does that mean? It says that what we have done is describe the process of evaluation and interpretation in Scheme. We have really built a Scheme interpreter. Not as complete as the full-blown one, but the things missing are pretty minor. Literally everything we've done would still work if we removed the *'s which says we can build a Scheme interpreter. We happen to have done it on top of Scheme, but we could have done it on top of a more primitive language, or we could have done it in some other language, and this is the central point. By defining an evaluator or an interpreter we are defining the language. We are specifying what it means to evaluate expressions in this language, what is the legal syntax and the legal semantics, and once we have done that we have created a language that we can then use to solve other problems. This point we will return to, but this is the "take home" message of this lecture