6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 13.2.12 Example: What is our"pair"object? So what does all this say? Aside from showing that our contract is fulfilled, that what we glue together using this version of cons we can get back apart using car or cdr, we have also seen this common pattern that we can create a data object represented as a procedure. The procedure has some local state captured in a frame that is accessible only by that procedure and it has the ability to accept messages and based on those messages return information from the local state So let's see how to build on that idea q60s7 Slide 13.2.13 Pair Mutation as Change in State n the case we just considered, our procedures for data (define structures could return values as a function of input messages If we are going to use this idea of message-passing procedures to represent information, we also need to have ways of ((eq? nsg 'pAIR?) it) ((eq? nsg SET-CARI) changing the value of the state captured by those procedures. In lambda (new-car)(set! x new-car))) our pair example, here is how we would do this (⊥ ambda w-cctr)(set I y nesw-cdr))) Pair Mutation as change in State Slide 13.2.14 (det ine (cons x y) Let's add two more messages, or two more ways of dealing with messages, to our constructor, cons: one for dealing with cond ((eq? nsg CAR) x) mutating the car and one for dealing with mutating the cdr mbda (newcar) (setI x new-car))) Notice that in this case we need something different If the ((eq? nsgSET-CDRI (I ambda (new-cdr) (setI y new-cdr))) cons pair (i.e. one of these procedures)gets the message talso( oror" pair cannot”重sg))) set-car! we are going to return a procedure that will take a new value for the car and change the old value to this 6 001 SICP I This is a different behavior from before. Now a message gets us back a procedure rather than a number6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 13.2.12 So what does all this say? Aside from showing that our contract is fulfilled, that what we glue together using this version of cons we can get back apart using car or cdr, we have also seen this common pattern that we can create a data object represented as a procedure. The procedure has some local state captured in a frame that is accessible only by that procedure and it has the ability to accept messages and based on those messages return information from the local state. So let's see how to build on that idea. Slide 13.2.13 In the case we just considered, our procedures for data structures could return values as a function of input messages. If we are going to use this idea of message-passing procedures to represent information, we also need to have ways of changing the value of the state captured by those procedures. In our pair example, here is how we would do this. Slide 13.2.14 Let's add two more messages, or two more ways of dealing with messages, to our constructor, cons: one for dealing with mutating the car and one for dealing with mutating the cdr. Notice that in this case we need something different. If the cons pair (i.e. one of these procedures) gets the message set-car! we are going to return a procedure that will take a new value for the car and change the old value to this new value. This is a different behavior from before. Now a message gets us back a procedure rather than a number