Cornelis H. A. Koster

Visibility and types

In this paper it is argued that there is a strong connection between the issue of abstract types and the more general issue of information hiding in large program systems, since abstraction has to be enforced by the careful and controlled hiding of details. In the first part of the paper, the notions of visibility and interface are discussed. In the second part, it is shown how, by careful control of visibility through interfaces, data abstraction can be achieved. Finally a comparison is made between this approach and the class approach.

Using the CDL Compiler-Compiler

In this sequence of lectures one compiler compiler is going to be highlighted by means of somewhat larger examples, preceded by a discussion of ideas underlying it.

Two-Level Grammars

In the definition of ALGOL 60, a clear distinction was maintained between the syntax and the semantics of the language defined: syntax is concerned with the form of things, semantics with their meaning.

CDL-A compiler implementation language

The Compiler Description Language CDL has evolved from a more or less classical compiler compiler system to an implementation language, which is well suited for the design and realization of compilers. In this paper it is discussed how those properties that make the language oriented towards compiler writing, have been enhanced in the revised version of CDL, and the advantages to be gained from such specialization.

A Technique for Parsing Ambiguous Languages

From a given context free grammar, it is possible in a variety of ways to generate automatically a program that acts as a recogniser for the language of that grammar. Under a number of conditions, depending on the particular technique used, this program is an “exact recogniser” of that language, accepting only sentences of the language and rejecting all other strings of symbols.

Language and Metalanguage

a) ALGOL 68 is a language in which algorithms may be formulated for computers, i.e., for automata or for human beings. It is defined by this Report in four stages, the “syntax” {b}, the “semantics” {c}, the “representations” {d} and the “standard environment” {e). b) The syntax is a mechanism whereby all the constructs of the language may be produced. This mechanism proceeds as follows: (i) A set of “hyper-rules” and a set of “metaproduction rules” are given {1.1.3.4, 1.1.3.3}, from which “production rules” may be derived: (ii) A “construct in the strict language” is a “production tree” {1.1.3.2.f} which may be produced by the application of a subset of those production rules; this production tree contains static information {i.e., information known at “compile time”} concerning that construct: it is composed of a hierarchy of descendent production trees, terminating at the lowest level in the “symbols”; with each production tree is associated a “nest” of properties, declared in the levels above, which is passed on to the nests of its descendents; (iii) A “program in the strict language” is a production tree for the notion ‘program’ {2.2.1.a}. It must also satisfy the “environment condition” {10.1.2}. c) The semantics ascribes a “meaning” {2.1.4.1.a} to each construct {i.e., to each production tree} by defining the effect (which may, however, be “undefined”) of its “elaboration” {2.1.4.1}. This proceeds as follows: (i) A dynamic {i.e., run-time} tree of active “actions” is set up {2.1.4}; typically, an action is the elaboration of some production tree T in an “environ” consistent with the nest of T, and it may bring about the elaboration of descendents of T in suitable newly created descendent environs; (ii) The meaning of a program in the strict language is the effect of its elaboration in the empty “primal environ”. d) A program in the strict language must be represented in some “representation language” {9.3.a} chosen by the implementer. In most cases this will be the official “reference language”. (i) A program in a representation language is obtained by replacing the symbols of a program in the strict language by certain typographical marks {9.3}. (ii) Even the reference language allows considerable discretion to the implementer {9.4.a, b, c}. A restricted form of the reference language in which such freedom has not been exercised may be termed the “canonical form” of the language, and it is expected that this form will be used in algorithms intended for publication. (iii) The meaning of a program in a representation language is the same as that of the program {in the strict language} from which it was obtained. e) An algorithm is expressed by means of a particular-program, which is considered to be embedded, together with the standard environment, in a program-text {10.1.1.a}. The meaning of a particular-program {in the strict or a representation language} is the meaning of the program “akin” to that program-text {10.1.2.a}.

Tokens and symbols

{Tokens (9.1.1.f) are symbols (9.1.1.h) possibly preceded by pragments (9.2.1.a). Therefore, pragments may appear between symbols wherever the syntax produces a succession of tokens. However, in a few places, the syntax specifically produces symbols rather than tokens, notably within denotations (8), format-texts (10.3.4.1.1.a) and, of course, within pragments. Therefore, pragments may not occur in these places.}

Modes and nests

{The identification of a property in a nest is the static counterpart of the dynamic determination (4.8.2.b) of a value in an environ: the search is conducted from the newest (youngest) level towards the previous (older) ones.

The computer and the program

The meaning of a program in the strict language is explained in terms of a hypothetical computer which performs the set of actions {2.1.4} which constitute the elaboration {2.1.4.1} of that program. The computer deals with a set of “objects” {2.1.1}.

Declarations, declarers and indicators

{Declarations serve to announce new indicators, e.g., identifiers, to define their modes or priorities, and to ascribe values to those indicators and to initialize variables.}