In chapter one, it was pointed out that there are a variety of levels of abstraction associated with the details of a task. (Cutting down trees can be viewed as a single task by an experienced logger, or as a series of subtasks in varying detail, depending on the need to elaborate). This is also true of programs--they can be thought of as single entities solving a single task (once they are written), but during their construction attention to the individual details is necessary.
Similar remarks may be made about data. Up to this point, the only data types employed by this text have been those built into Modula-2. It has not been necessary for the programmer to be concerned about specifying in the program any of:
a) how the data is represented in the computer,
b) what the possible values for the type were to be, or,
c) what operations will work with the data type in question.
These characteristics have, in every case seen thus far, been prearranged and the details of the data type's specification hidden from the program. In using an entity of type REAL or CARDINAL, for example, one need not ordinarily be concerned with the way in which the numbers are stored in the computer. Each such entity is considered and used as an organic and indivisible whole. Likewise, while one understands that not everything that can be a real number in mathematics can be one in a program (because infinite precision is not available), the values available for assignment to the type REAL are simply taken for granted. The operations indicated by +, -, *, and / operators are also built-in for all the numeric data types provided in most computing notations.
A data type whose representation (and operational) details are hidden from the user of entities of that type is said to be an abstract data type. This is sometimes abbreviated as ADT.
NOTES:
1. The programmer may know, or be able to discover the representation details. The type is still abstract if that knowledge is not used in a program, that is, if it is not depended on in any way.
2. Sometimes it is suitable to say more about such representation details. For instance, one could think of a REAL as consisting of two cardinals--one to specify the significant figures of the real, and the other to signify the exponent. On the other hand, the REAL could be thought of as the string of characters that would have to be printed on an output device for a user to view it. Thinking about it in either way would not say anything about how the data is actually stored in the computer, though both views might assist in working with the type REAL.
Of more importance to this discussion is the fact that a computing notation usually allows the user to create new data types, and to specify certain details about such types in the program. As indicated above, three aspects of data types may be of interest. This chapter will be concerned only with making a transparent list of potential values for a new data type. In later chapters, the issue of specifying the structure or representation of the data (at some level of abstraction), and that of specifying operations on items of the type will be considered.
A data type whose representation details are visible to the user of entities of that type is said to be transparent.