Protection in programming languages
Communications of the ACM
GEDANKEN—a simple typeless language based on the principle of completeness and the reference concept
Communications of the ACM
SIMULA 67 common base language, (Norwegian Computing Center. Publication)
SIMULA 67 common base language, (Norwegian Computing Center. Publication)
Some ideas on data types in high-level languages
Communications of the ACM
| Hi-index | 0.02 |
High level programming languages tend to free a programmer from concern about the underlying machine structure and permit him to talk about his problem domain in more direct terms. Thus, he may imagine that objects such as real numbers, character strings, and linear arrays really exist in the machine as atomic entities and he need not understand the details of how they are actually represented in the machine. Of course what distinguishes various kinds of objects are the operations that may be performed on them, so when talking about the domain of real numbers, we should include the basic arithmetic operations and constants, and for strings, operations such as length, concatenation and indexing.Unfortunately, existing languages do not permit a programmer to ignore completely questions of representation, for if his problem domain does not happen to be included already in the repertoire of domains supported by the language, the programmer must figure out a representation himself and remember it throughout his programming effort. For example, a FORTRAN programmer may know that it is not meaningful to multiply two integers that happen to represent insurance policy numbers, but he has no way of informing the compiler of this fact.Many extensible languages do provide a wide range of data types including structured types, enabling a programmer to choose a more natural representation of his external objects, but the structured data types reflect only the structure of the data, not its meaning. They still provide only one natural representation for both integers and dates, mass and speed, or planar vectors in cartesian or polar coordinates.Many domains that arise in practice have a great deal of similarity between them which one must employ in his programs. For example, the domain of length 3 vectors and the domain of length 4 vectors have the "same" rule of addition, that is, add componentwise, and it would be onerous to have to repeat this information for each new length vector. Thus, one needs both the ability to define brand new domains and also a method for expressing relations among them.We present here some mechanisms, collectively called Aleph-1, which allow the expansion of a programming language's repertoire of internal domains. Many of the ideas embodied in Aleph-1 have been described previously in the literature, and we acknowledge their influence on our thinking, in particular the work of Balzer [1] and Reynolds [5] suggesting the utility of separating out the abstract behavior of an object from its representation, the languages Pascal [10] and Simula-67 [3] which associate functions with data types and types with alternate representations, modular generic functions in Basel [2], Standish's wide variety of structured data [6], and the systematic (though not extensible) treatment of coercion in Algol-68 [8]. Our domain mechanisms bear certain strong similarities to those developed by Morris for the purposes of protection [4].