6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 10.2.9 first,we have no constructor. We are just building a list using list Alists are not an abstract data type operations or quotes. This may seem like a neat efficient hack, but it has an important impact (define a1 '((x 15)(y 20))) Slide 10.2.10 Alists are not an abstract data type In particular, there is no abstraction barrier. That means there is no Missing a constructor. way of separating out the implementation and manipulating of a- Use quote or list to construct lists from the use of the a-list as a table. In fact a-lists are designed (define al '((x 15)(y 20))) that way and the definition from the scheme manual clearly states There is no abstraction barrier. this. A-lists are intended to just be exposed lists association. the car of an association is called the Slide 10.2.11 As a consequence, the implementation of the table is exposed, Alists are not an abstract data type meaning that the user can operate on the a-list just using list Missing a constructor. operations, rather than being required to use operations designed Use quote or list to construct for tables. The example shown seems very convenient, using filter directly on the list, but this is a dangerous thing to do There is no abstraction barrier. An alist is a list of pairs, each of which is called an ssociation. The car of an association is called the herefore, the implementation is exposed. User may operate (filter oda (a)(< (cadr a) 16))a1)) 【x15)) Slide 10.2.12 Why do we care that Alists are not an ADT? So why should we care that a-lists are not an abstract data type? Modularity is essential for software engineering The primary reason is the loss of modularity. Good software design Build a program by sticking modules together always involves programs that are created from units that are easily Can change one module without affecting the rest glued together, are easily replaced with other small sized units, and can be treated as black box abstractions If done right, we can easily change one module without having to change anything else6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 10.2.9 ...first, we have no constructor. We are just building a list using list operations or quotes. This may seem like a neat efficient hack, but it has an important impact. Slide 10.2.10 In particular, there is no abstraction barrier. That means there is no way of separating out the implementation and manipulating of a￾lists from the use of the a-list as a table. In fact, a-lists are designed that way and the definition from the Scheme manual clearly states this. A-lists are intended to just be exposed lists. Slide 10.2.11 As a consequence, the implementation of the table is exposed, meaning that the user can operate on the a-list just using list operations, rather than being required to use operations designed for tables. The example shown seems very convenient, using filter directly on the list, but this is a dangerous thing to do. Slide 10.2.12 So why should we care that a-lists are not an abstract data type? The primary reason is the loss of modularity. Good software design always involves programs that are created from units that are easily glued together, are easily replaced with other small sized units, and can be treated as black box abstractions. If done right, we can easily change one module without having to change anything else in the system