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 15.1.1 Why do we need an interpreter? Our goal over the next few lectures is to build an interpreter which in a very basic sense is the ultimate in programming, since doing so will allow us to define our language

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

Slide 14.1.1 Elements of ooP Last time we introduced the idea of object oriented systems Today, we want to build on those basics, looking at how we can expand object-oriented systems to deal with hierarchies of objects, to leverage the commonality of methods between

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

luse this is the central part of the environment model, let's look in very painful detail at an example of an evaluation. In (square 4)I g particular, let's look at the evaluation of (square 4)with x;10 respect to the global environment. Here is the structure we start

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 31.1 Slide 3l.ll Trees, graphs and Search In previous lectures we have seen a number of important themes, which relate to designing code for complex syste

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 10.1 Slide 1o.1.1 Table: a set of bindings Over the past few lectures, we have introduced the concepts of data abstractions, types and aggregate structures. In this lecture