6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 103.10 Table1 example If we get a value out of this table, say the pairing associated with (define ttl (make-tablel)) the key y, then table-get does a very similar thing. It removes (tablel-put! tt1 'y 20) the tag, getting the pointer to the actual a-list(shown in light blue) tablel-put! ttl 'x 15 and then uses find-assoc, the operator associated with the a ttl\ (tablel-g list, to find and return the value associated with this key 旧 Slide 10.3.1 So this gives us a simple implementation of a table. It has a tag at the front to identify it, it has some constructors and selectors to get (define ttl (make-tablel)) at the internal representation of the table, which in this case is an a (tablel-put! tt1 'y 20) ist, pairing up keys and values ( table1-put!tt1·x Slide 10.3.12 How do we know Table1 is an ADT implementation So what is it that makes this an abstract data type? Is it the fact that that it has a tag? While this is careful programming, it does not Because it has a type tag suffice to create an adt Because it has mutators and accessors No Is it the fact that it has a constructor? While having a distinct interface is good programming, this also does not suffice to create ADT Similarly, the fact that it has accessors or selectors, and mutators (the set-cdr!)is useful, but not sufficient to define an ADT. In fact, a-lists also had these properties, but we argued that they were not adt's Slide 10.3.13 In fact, the key issue is the isolation of the abstraction from its How do we know Table1 is an ADT implementation users. We can't use any list processors, like car, cdr, map Potential reason filter directly on the table Because it has Because the rest of the program does not apply any functions to Table 1 objects other than the function For example, no car, cdr, map, filter done to table6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 10.3.10 If we get a value out of this table, say the pairing associated with the key y, then table-get does a very similar thing. It removes the tag, getting the pointer to the actual a-list (shown in light blue), and then uses find-assoc, the operator associated with the a￾list, to find and return the value associated with this key. Slide 10.3.11 So this gives us a simple implementation of a table. It has a tag at the front to identify it, it has some constructors and selectors to get at the internal representation of the table, which in this case is an a￾list, pairing up keys and values. Slide 10.3.12 So what is it that makes this an abstract data type? Is it the fact that that it has a tag? While this is careful programming, it does not suffice to create an ADT. Is it the fact that it has a constructor? While having a distinct interface is good programming, this also does not suffice to create an ADT. Similarly, the fact that it has accessors or selectors, and mutators (the set-cdr!) is useful, but not sufficient to define an ADT. In fact, a-lists also had these properties, but we argued that they were not ADT's. Slide 10.3.13 In fact, the key issue is the isolation of the abstraction from its users. We can't use any list processors, like car, cdr, map or filter directly on the table