6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 10.3.1. How do we know Table1 is an ADT implementation This is because the representation for table is not an exposed a-list We have hidden the internal representation for the table from the Because it has a type tag users or consumers of tables. As a consequence, this abstraction Because it has mutators and accessors No barrier would allow us to freely change our internal representation of a table, without requiring a user to make any changes to their code that uses tables. This is the key point. We have hidden away ause the rest of the program does not apply any objects other than the functions the a-list from the user. If we change our choice of representation, led in the Table ADT cdr, map, filter done to table nothing will have to change on the outside of the program, so it can be changed easily Slide 10.3. 15 Because this is a key point, we want to generalize it. By creating iNformation hiding in types:opaque names distinct data structure type for tables, we have in essence hidden Opaque: type name that is defined but unspecific information behind a name. We have made that name opaque to the user Slide 10.3.16 Information hiding in types: opaque names What does this mean? Well, it says that by creating a new type in Opaque: type name that is defined but unspecified this way, its name hides the details. For example, suppose I give Given functions ml and m2 and unspecified type My Type you a new data type, and simply tell you that it exists, but not (define (m1 number ); umber→ My Typ nything about its details. For example, lets call it MyType My Type→unde Further, lets suppose we have two procedures with the indicated . Which of the following is OK? Which is a type mismatch (ml 10)) retum type of ml matches type contracts. M1 maps a number to one of these objects of type argument type of m2 MyType, and m2 takes one of these types of objects as input, and tear (ml 101): retum type of ml fails to match does something to it. Given just that information, we can ask the argument type of car 4 following questions Which of the two indicated expressions is acceptable? Clearly the first expression is fine. The type of object returned by ml is exactly what is expected by m2. Even though we know nothing about the type, the contract (or the opaqueness of the name)allows us to remove those details from consideration, and just consider the overall behavior of the procedure. On the other hand, the second expression should"bomb", because here the type of object returned by ml is not appropriate for a procedure like car. we have no way of knowing if the returned value is a pair or not6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 10.3.14 This is because the representation for table is not an exposed a-list. We have hidden the internal representation for the table from the users or consumers of tables. As a consequence, this abstraction barrier would allow us to freely change our internal representation of a table, without requiring a user to make any changes to their code that uses tables. This is the key point. We have hidden away the a-list from the user. If we change our choice of representation, nothing will have to change on the outside. Slide 10.3.15 Because this is a key point, we want to generalize it. By creating a distinct data structure type for tables, we have in essence hidden information behind a name. We have made that name opaque to the user. Slide 10.3.16 What does this mean? Well, it says that by creating a new type in this way, its name hides the details. For example, suppose I give you a new data type, and simply tell you that it exists, but not anything about its details. For example, lets call it MyType. Further, lets suppose we have two procedures with the indicated type contracts. M1 maps a number to one of these objects of type MyType, and m2 takes one of these types of objects as input, and does something to it. Given just that information, we can ask the following questions. Which of the two indicated expressions is acceptable? Clearly the first expression is fine. The type of object returned by m1 is exactly what is expected by m2. Even though we know nothing about the type, the contract (or the opaqueness of the name) allows us to remove those details from consideration, and just consider the overall behavior of the procedure. On the other hand, the second expression should "bomb", because here the type of object returned by m1 is not appropriate for a procedure like car. We have no way of knowing if the returned value is a pair or not