6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 15.1.13 So here is a summary of that process in words Role of each part of the interpreter break up input string into"words"called tokens Parser also convert self-evaluating tokens to their internal values #f is converted to the internal false value Printe convert value to human-readable output string Goal of this lecture Slide 15.1.14 lement an interpreter for a programming language Our goal is to implement an interpreter. Actually, that's not quite right. Our goal is for you to understand what goes into an Only write evaluator and environment use schemes reader for lexical analysis and parsing interpreter, which we will explore by implementing one. Since use scheme's printer for output the key part of an interpreter, the crucial part, is the evaluator, to do this, our language must look like scheme we are going to concentrate almost exclusively on that. We are going to use Scheme for all the rest of the pieces, that is, we All names end with a star will use Scheme's lexical analyzer and parser, and Scheme's Start with a simple calculator for arithmeti printer, rather than building them from scratch. This means of Progressively add scheme* features course that we will need to create an evaluator for a language that looks a lot like scheme in the sense of having a tree structure as the output of its parser and a set of rules for manipulating that tree structure, as the way of dealing with the actual evaluation. It also says that the syntax of the language we are going to use to demonstrate an interpreter will need to look at lot like Scheme, in terms of things lke using parentheses to delimit expressions and other related issues We say this because we don,'t want you to get confused between what is going in Scheme and the general ideas of building an evaluator and interpreter. Our goal is to build an interpreter, especially the evaluator part, and let you going to build our own simple language and its evaluator For convenience, we are going to call this language are see how that occurs and use that to explore the idea of how these things implement the rules for a language. w Scheme*. It has a lot of the characteristics of Scheme, but we will use the convention that a* will be placed at the end of every expression in our language, to distinguish it from the corresponding Scheme expression We'll start with a simple evaluator and work our way up The first simple evaluator will be one that handles simple arithmetic expressions 6.001 Notes: Section 15.26.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 15.1.13 So here is a summary of that process in words. Slide 15.1.14 Our goal is to implement an interpreter. Actually, that's not quite right. Our goal is for you to understand what goes into an interpreter, which we will explore by implementing one. Since the key part of an interpreter, the crucial part, is the evaluator, we are going to concentrate almost exclusively on that. We are going to use Scheme for all the rest of the pieces, that is, we will use Scheme's lexical analyzer and parser, and Scheme's printer, rather than building them from scratch. This means of course that we will need to create an evaluator for a language that looks a lot like Scheme in the sense of having a tree structure as the output of its parser and a set of rules for manipulating that tree structure, as the way of dealing with the actual evaluation. It also says that the syntax of the language we are going to use to demonstrate an interpreter will need to look at lot like Scheme, in terms of things like using parentheses to delimit expressions and other related issues. We say this because we don't want you to get confused between what is going in Scheme and the general ideas of building an evaluator and interpreter. Our goal is to build an interpreter, especially the evaluator part, and let you see how that occurs and use that to explore the idea of how these things implement the rules for a language. We are going to build our own simple language and its evaluator. For convenience, we are going to call this language, Scheme*. It has a lot of the characteristics of Scheme, but we will use the convention that a * will be placed at the end of every expression in our language, to distinguish it from the corresponding Scheme expression. We'll start with a simple evaluator and work our way up. The first simple evaluator will be one that handles simple arithmetic expressions. 6.001 Notes: Section 15.2