03-mutation-post

03-mutation-post - Mutation Readings: HtDP, section 39, and...

Info iconThis preview shows pages 1–8. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Mutation Readings: HtDP, section 39, and optionally sections 40, 41, 42. We will use a somewhat different approach to the ideas in these sections, and use some PLT Scheme features not discussed in the textbook. As Yoda might say: Assignment leads to mutation. Mutation leads to pointers. Pointers lead to suffering! (Anton van Straaten, PLT Scheme mailing list, 20011224) CS 136 Fall 2009 03: Mutation 1 Loss of knowledge, again Accumulators allow us to retain knowledge from earlier parts of a recursive computation. But we cant retain knowledge from earlier applications of a function, or from earlier applications of different functions. One place where this might be useful is in extended interaction with a user. Example: an address book keeping names and phone numbers. This sounds like just another application of the table ADT, until we add interaction. CS 136 Fall 2009 03: Mutation 2 Sample behaviour: > ( lookup " Arturo Belano " ) false > ( add-entry " Arturo Belano " 6345789 ) > ( lookup " Arturo Belano " ) 6345789 Here, we want two identical function applications to produce different results, because of an intervening application of a different function. We cant ensure behaviour like this with what we know of Scheme so far. CS 136 Fall 2009 03: Mutation 3 Mutation: the fall from grace The knowledge of prior history is called memory or state . In certain circumstances, we need to maintain state in variables, and change them during a computation. Scheme permits mutation , or rebinding of a name to a different value. If the name x has been bound to some value, and we wish to rebind it to a value v , we can evaluate the expression ( set! x v ) . set! is pronounced set-bang. Many built-in and user-defined functions that involve mutation end with an exclamation mark, just as predicates often end with a question mark. CS 136 Fall 2009 03: Mutation 4 Heres how we can use set! to maintain our address book as an association list. ( define address-book empty ) . . . ( set! address-book ( cons ( " Arturo Belano " 6345789 ) address-book )) The effect of the last expression is to rebind the name address-book to the new value ( cons ( " Arturo Belano " 6345789 ) empty ) . It is as if the define expression had been rewritten. CS 136 Fall 2009 03: Mutation 5 ( define address-book empty ) ( set! address-book ( cons ( " Arturo Belano " 6345789 ) address-book )) ( define address-book ( cons ( " Arturo Belano " 6345789 ) empty )) This idea of rewriting a definition is how we will handle the semantics of set! . CS 136 Fall 2009 03: Mutation 6 Variable variables address-book is a state variable whose value binding changes through mutation....
View Full Document

This note was uploaded on 10/30/2011 for the course CS 136 taught by Professor Becker during the Spring '08 term at Waterloo.

Page1 / 60

03-mutation-post - Mutation Readings: HtDP, section 39, and...

This preview shows document pages 1 - 8. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online