Amiga ISO Collection/AmigaUtilCD2.iso/Programming/Misc/OB3.2D1.DMS/in.adf/ModulaToOberon/__headers__.txt

Text File | 1992-10-15 | 3.8 KB | 71 lines

N. Wirth

Abstract

The programming language Oberon is the result of a concentrated effort to
increase the power of Modula-2 and simultaneously to reduce its complexity.
Several features were eliminated, and a few were added in order to increase
the expressive power and flexibility of the language. This paper describes
and motivates the changes. The language is defined in a concise report.

Introduction

The programming language Oberon evolved from a project whose goal was the
design of a modern, flexible, and efficient operating system for a
single-user workstation. A principal guideline was to concentrate on
properties that are genuinely essential and - as a consequence - to omit
ephemeral issues. It is the best way to keep a system in hand, to make it
understandable, explicable, reliable, and efficiently implementable.

Initially, it was planned to express the system in Modula-2 [1]
(subsequently called Modula), as that language supports the notion of
modular design quite effectively, and because an operating system has to be
designed in terms of separately compilable parts with conscientiously
chosen interfaces. In fact, an operating system should be no more than a
set of basic modules, and the design of an application must be considered
as a goal-oriented extension of that basic set: Programming is always
extending a given system.

Whereas modern languages, such as Modula, support the notion of
extensibility in the procedural realm, the notion is less well established
in the domain of data types. In particular, Modula does not allow the
definition of new data types as extensions of other, programmer-defined
types in an adequate manner. An additional feature was called for, thereby
giving rise to an extension of Modula.

The concept of the planned operating system also called for a highly
dynamic, centralized storage management relying on the technique of garbage
collection. Although Modula does not prevent the incorporation of a garbage
collector in principle, its variant record feature constitutes a genuine
obstacle. As the new facility for extending types would make the variant
record feature superfluous, the removal of this stumbling block was a
logical decision. This step, however, gave rise to a restriction (subset)
of Modula.

It soon became clear that the rule to concentrate on the essential and to
eliminate the inessential should not only be applied to the design of the
new system, but equally stringently to the language in which the system is
formulated. The application of the principle thus led from Modula to a new
language. However, the adjective "new" has to be understood in proper
context: Oberon evolved from Modula by very few additions and several
subtractions. In relying on evolution rather than revolution we remain in
the tradition of a long development that led from Algol to Pascal, then to
Modula-2, and eventually to Oberon. The common traits of these languages
are their procedural rather than functional model and the strict typing of
data. Even more fundamental, perhaps, is the idea of abstraction: the
language must be defined in terms of mathematical, abstract concepts
without reference to any computing mechanism. Only if a language satisfies
this criterion, can it be called "higher-level". No syntactic coating
whatsoever can earn a language this attribute alone.

The definition of a language must be coherent and concise. This can only be
achieved by a careful choice of the underlying abstractions and an
appropriate structure combining them. The language manual must be
reasonably short, avoiding the explanation of individual cases derivable
from the general rules. The power of a formalism must not be measured by
the length of its description. To the contrary, an overly lengthy
definition is a sure symptom of inadequacy. In this respect, not complexity
but simplicity must be the goal.