6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 10.3.17 In essence, the opaque name and the infrastructure hidden behind Information hiding in types: opaque names it, guarantee clean performance for this particular data type. As a onsequence, we can change that infrastructure, without affecting Given functions ml and m2 and unspecified type My Type anything on the other side of that opaque name ,): number→ My Type (define (m2 myt)...) MyType ->undef .Which of the following is OK? Which is (m2 (ml 10)) retum type of ml mat ches i argument type of m2 (car (m1 10)) retum type of ml fails to match argument type of car car; paisa.B>→A Effect of an opaque name functions will match except the functions of the ADt 17a Slide 10.3.18 Types for table1 So, for tables here is everything that a user needs to know Here is everything the rest of the program knows First is the opaque type name, a thing called Tablel that has inside of it two arguments of types k and v Or said another way, opaque type make-table1 oid->Table 1<anytype, anytype> this type is created out of pairings of k's and v's, but we havent tablel-put! Table 1<k,v>, k, v> undef said anything about how this is done tablel-get abe1<kv>,k→|nu Our constructor for this type takes no arguments as input, and creates an instance of this type of object. Note that the elements paired within this table can be of any type Our operation for putting things into the table takes a table object, and a k and a v as input. It doesn 't return any value, since its role is to change the bindings within the table object And our accessor takes one of these abstract table objects, and a k and either returns the associated v or the empty list to signal that no binding was found Note again, this is everything that a user of tables needs to know. And nothing is said about a-lists or cons pairs or anything else. This simply defines an interaction between the abstract data type and the elements within it Slide 10.3. 19 Hiding below that abstraction barrier, or if you like behind that Types for table1 opaque name, is the actual implementation. Here we have made a|. Here is everything the rest of the program knows choice. Specifically, we have decided that a table will be a pairingTable1ck,v>opaque type of a symbol (for our tag) and an a-list (for the actual bindings) ake-tablel void->Table 1 <anytype, anytype> Note that we can also provide a formal specification of an a-list ablel-put! Table 1<k, v>, k, v undef a list of elements each of which is a 2 element list, as shown Tabe1skv,k→(|nu here is the hidden part only the implementation knows it Table 1<k, v> symbol x Alist<k, v> 1506.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 10.3.17 In essence, the opaque name and the infrastructure hidden behind it, guarantee clean performance for this particular data type. As a consequence, we can change that infrastructure, without affecting anything on the other side of that opaque name. Slide 10.3.18 So, for tables here is everything that a user needs to know. First is the opaque type name, a thing called Table1 that has inside of it two arguments of types k and v. Or said another way, this type is created out of pairings of k's and v's, but we haven't said anything about how this is done. Our constructor for this type takes no arguments as input, and creates an instance of this type of object. Note that the elements paired within this table can be of any type. Our operation for putting things into the table takes a table object, and a k and a v as input. It doesn't return any value, since its role is to change the bindings within the table object. And our accessor takes one of these abstract table objects, and a k and either returns the associated v or the empty list to signal that no binding was found. Note again, this is everything that a user of tables needs to know. And nothing is said about a-lists or cons pairs or anything else. This simply defines an interaction between the abstract data type and the elements within it. Slide 10.3.19 Hiding below that abstraction barrier, or if you like behind that opaque name, is the actual implementation. Here we have made a choice. Specifically, we have decided that a table will be a pairing of a symbol (for our tag) and an a-list (for the actual bindings). Note that we can alsor provide a formal specification of an a-list as a list of elements each of which is a 2 element list, as shown