The 6.001 Lazy Meta-Circular Evaluator The Core Evaluator (define (l-eval exp env) (cond ((self-evaluating? exp) exp) ((variable? exp)(lookup-variable-value exp env)) ((quoted? exp)(text-of-quotation exp)) ((assignment? exp)(eval-assignment exp env)) ((definition? exp)(eval-definition exp env)) ((if? exp)(eval-if exp env))

Slide 17.1.1 Normal Order(Lazy) Evaluation Over the past few lectures, we have been looking at evaluation especially how to implement eval and apply in a anguage such as Scheme, in order to define a language. What we have seen is that by creating, or specifying, eval and its associated procedures, we actually define the semantics of the

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

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

Slide 14.4.1 Cleaning up some details of our implementation So we have seen a first pass at building an object-oriented tem, using Scheme as the base. There are a few details that The need for self-reference

The role of abstractions In this lecture, we are going to look at a very different style of creating large systems, a style called object oriented programming. This style focuses on breaking systems up in a different manner than those we have seen before To set the stage for this, we are first going to return to the notion of

Slide 12.1.1 In the last lecture, we introduced mutation as a component of 6001s|cP our data structures We saw for example that set was a Environment mode way of changing the value associated with a variable in our system, and we saw that set-car! and set-cdr! were ways of changing the values of parts of list structure Now, several important things happened when we introduced

6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology 6.001 Notes: Section 11.1 Slide ll1.1 Elements of a Data Abstraction For the past few lectures, we have been exploring the topic of data abstractions, and their role in modularizing complex

6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology 6.001 Notes: Section 9.1 Slide 9.1.1 Manipulating complex numbers In the last lecture, we introduced symbols into our language

6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology 6.001 Notes: Section 30.1 Slide 30l1 In this lecture, we are going to go back to several themes that 6.001: Structure and Interpretation of we have been exploring over the past few weeks, and stitch