Abstract Data Type (ADT)

In most of the more modern languages, there are constructs that programmers can use to define types in addition to the standard types (such as Integer). Usually, these constructs require the programmer to represent values of the new type in terms of low-level concepts such as records, arrays and pointers. Since the details of the representation are usually messy, subject to change, and of little interest at the point where the new types are actually used, it is standard practice to suppress them. Such suppression of details amounts to a process of abstraction and hence a programmer defined type is typically referred to as an Abstract Data Type or ADT.

In Slim, the situation is somewhat different: Types are merely sets of values. Values are either standard values, or values that represent models of real world entities. (See Data Modelling.) Since it is neither feasible, nor desirable, for a model to capture every detail of the corresponding real world entity, a model is necessarily the product of a process of abstraction. It thus makes sense to refer to a value that represents a (data) model of a real word entity, as an abstract value. A type which is a set of abstract values is thus naturally referred to as an abstract (data) type.

This does not imply, however, that there is any need or possibility to suppress or hide anything within the program itself. See import and export.

A major point to note about abstract types in Slim, is that they are not constructed by means of type expressions. Instead, abstract values are created as needed (see New) and are added to one or more sets of values assigned to abstract type variables. This means that special rules apply to type checks performed on (ordinary) variables typed with abstract type (variables).

Another way to describe the above is to say that an abstract type is not the set of all possible instantiations of a template, but the set of all actual instantiations. This means that the Slim type model subsumes the database concept of referential integrity constraints.

Herman Venter
This is Slim documentation as snarfed on 27 May 1999 by dB.