6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology what value to return We call this style of programming, message passing, because the procedure accepts a message as input, and then does something based on the value of that Slide 13. 2.3 Example: Pair as a Procedure with State This looks a bit weird! Our constructor for gluing things together gives us a procedure as the actual object. Should we (lambda (cond ((eq? msg CAR) x) Of course we know that we shouldn't care. To complete the ((eq? msg 'PAIR2) #t abstraction for a pair, we simply need to create car and cdr t”m8))))) to fulfill the contract of the abstraction of a pair (odr p) (p CDR)) Each of those is itself a procedure that takes as input a pair, to a single argument, which in this case is just a symbole qure which we know is a procedure, and then applies that procedi message. Ideally, that message should get back for us the value we need to satisfy the contract. If we look at this definition for car, we see it takes as input one of these new pairs, and then applies that pair(a procedure) to the symbol carr which in principle should return for us the value we used when we created the pair Note the other procedure we built here. Our predicate for testing whether something is a pair now relies on the identifying itself. This is the version of our tag. Before we attached a tag as a symbol on a data structure. Here tags are part of the procedure Example: What is our"pair"object? Slide 13.2.4 To check it out, let,'s take this strange implementation of pairs and verify that this implementation satisfies the contract for a Slide 13. 2.5 Example: What is our"pair object? To test this, lets cons together the numbers l and 2, and give the resulting pair the name foo (det ine too (cons 1 2)) 600SC6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. what value to return. We call this style of programming, message passing, because the procedure accepts a message as input, and then does something based on the value of that message. Slide 13.2.3 This looks a bit weird! Our constructor for gluing things together gives us a procedure as the actual object. Should we care? Of course we know that we shouldn't care. To complete the abstraction for a pair, we simply need to create car and cdr to fulfill the contract of the abstraction of a pair. Each of those is itself a procedure that takes as input a pair, which we know is a procedure, and then applies that procedure to a single argument, which in this case is just a symbolic message. Ideally, that message should get back for us the value we need to satisfy the contract. If we look at this definition for car, we see it takes as input one of these new pairs, and then applies that pair (a procedure) to the symbol car, which in principle should return for us the value we used when we created the pair. Note the other procedure we built here. Our predicate for testing whether something is a pair now relies on the pair identifying itself. This is the version of our tag. Before we attached a tag as a symbol on a data structure. Here, our tags are part of the procedure. Slide 13.2.4 To check it out, let's take this strange implementation of pairs and verify that this implementation satisfies the contract for a pair. Slide 13.2.5 To test this, lets cons together the numbers 1 and 2, and give the resulting pair the name foo