This preview has intentionally blurred sections. Sign up to view the full version.
View Full Document
Unformatted text preview: CS 3110 Lecture 9 Representation and Module Invariants We need to write some comments in module implementations to help code implementers and maintainers to reason about the code within the module. We'd like them to be able to reason about individual functions within the module in a local way, so they can judge whether each function is correctly implemented without thinking about every other function in the module. Last time we saw the abstraction function , which is essential to this process because it explains how information within the module is viewed abstractly by module clients. Commutation diagrams Using the abstraction function, we can now talk about what it means for an implementation of an abstraction to be correct . It is correct exactly when every operation that takes place in the concrete space makes sense when mapped by the abstraction function into the abstract space. This can be visualized as a commutation diagram : A commutation diagram means that if we take the two paths around the diagram, we have to get to the same place. Suppose that we start from a concrete value and apply the actual implementation of some operation to it to obtain a new concrete value or values. When viewed abstractly, a concrete result should be an abstract value that is a possible result of applying the function as described in its specification to the abstract view of the actual inputs. For example, consider the union function from the implementation of sets as lists with repeated elements covered last time. When this function is applied to the concrete pair ([1,3],[2,2]) it corresponds to the lowerleft corner of the diagram. The result of this operation is the list [2,2,1,3], whose corresponding abstract value is the list {1,2,3}. Note that if we apply the abstraction function AF to the lists [1,3] and [2,2], we have the sets {1,3} and {2}. The commutation diagram requires that in this instance the union of {1,3} and {2} is {1,2,3}, which is of course true. Some specifications, as we have seen, are nondeterministic: they do not fully specify the abstract behavior of the functions. For nondeterministic specifications there are several possible arrows leading from the abstract state at the upper left corner of the commutation diagram to other states. The commutation diagram is satisfied as long as the implemented function completes the diagram for any one of those arrows. Some missing information Recall the SET interface from last time: module type SETSIG = sig type 'a set val empty : 'a set val add : 'a > 'a set > 'a set val mem : 'a > 'a set > bool val rem : 'a > 'a set > 'a set val size: 'a set > int val union: 'a set > 'a set > 'a set val inter: 'a set > 'a set > 'a set end Last time we we talked about two implementations: a list of integers with no duplicates and a list of integers possibly with duplicates, each with its own abstraction function....
View
Full Document
 '07
 GIAMBATTISTA,A
 ObjectOriented Programming, Type system, Type theory

Click to edit the document details