This preview shows pages 1–3. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: M UTABLE D ATA 15 GEORGE WANG [email protected] Department of Electrical Engineering and Computer Sciences University of California, Berkeley July 19, 2010 1 Review The readers have asked me to talk about code like this: (if (predicate?) #t #f) What’s wrong with this? 2 Introduction to Mutable Data So last week, we talked about the ability of objects to have local state. Up until now, all our data structures have been functional. In other words, we never changed a data structure, we’ve always made new ones. Another word for this type of data structure is IMMUTABLE. In other words, it’s something that doesn’t change. Today and tomorrow, we’ll analyze mutable data structures, and look at some advantages and disadvantages that things like this can have. 2.1 Building a Pair in OOP So let’s think about a pair, as defined in OOP notation: (define-class (pair car cdr)) Well...that was anticlimactic. This class can do everything we know we can already do with a pair. But let’s try to expand this a bit: (define-class (pair car cdr) (method (set-car! new-car) (set! car new-car)) (method (set-car! new-cdr) (set! cdr new-cdr)) 1 Now we have a pair that can change its values! One thing that I want you guys be very careful about is that note that set-car! and set-cdr! are messages that we send to pairs, not values! In other words, a pair is able to change its own values, but you have to ask a pair to change its own values. 2.2 Regular Scheme Well, we already have talked about the Constructors and Selectors for pairs: (cons a d) (car pair) (cdr pair) So now let’s introduce 2 MUTATORS: (set-car! PAIR NEW-VALUE) (set-cdr! PAIR NEW-VALUE) Note that the first argument to the mutators is not a value, it is a pair! In other words, do not say (set-car!...
View Full Document