Fresh Fish 6/FreshFish_September1994.bin/new/dev/obero/oberon-a/texts/modulatooberon.text

Text File | 1993-08-23 | 30KB | 594 lines

From Modula to Oberon

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.

In spite of its brevity, a description must be complete. Completeness is to
be achieved within the framework of the chosen abstractions. Limitations
imposed by particular implementations do not belong to a language
definition proper. Examples of such restrictions are the maximum values of
numbers, rounding and truncation errors in arithmetic, and actions taken
when a program violates the stated rules. It should not be necessary to
supplement a language definition with a voluminous standards document to
cover "unforeseen" cases.

But neither should a programming language be a mathematical theory only. It
must be a practical tool. This imposes certain limits on the terseness of
the formalism. Several features of Oberon are superfluous from a purely
theoretical point of view. They are nevertheless retained for practical
reasons, either for programmers' convenience or to allow for efficient code
generation without the necessity of complex, "optimizing" pattern matching
algorithms in compilers. Examples of such features are the presence of
several forms of repetitive statements, and of standard procedures such as
INC, DEC, and ODD. They complicate neither the language conceptually nor
the compiler to any significant degree.

These underlying premises must be kept in mind when comparing Oberon with
other languages. Neither the language nor its defining document reach the
ideal; but Oberon approximates these goals much better than its
predecessors.

A compiler for Oberon has been implemented for the NS32000 processor family
and is embedded in the Oberon operating environment [8]. The compiler
requires less than 50 KByte of memory, consists of 6 modules with a total
of about 4000 lines of source code, and compiles itself in about 15 seconds
on a workstation with a 25MHz NS32532 processor.

After extensive experience in programming with Oberon, a revision was
defined and implemented. The differences between the two versions are
summarised towards the end of the paper. Subsequently, we present a brief
introduction to (revised) Oberon assuming familiarity with Modula (or
Pascal), concentrating on the added features and listing the eliminated
ones. In order to be able to start with a clean slate, the latter are taken
first.

Features omitted from Modula

Data types

Variant records are eliminated, because they constitute a genuine
difficulty for the implementation of a reliable storage management system
based on automatic garbage collection. The functionality of variant records
is preserved by the introduction of extensible data types.

Opaque types cater for the concept of abstract data type and information
hiding. They are eliminated as such, because again the concept is covered
by the new facility of extended record types.

Enumeration types appear to be a simple enough feature to be
uncontroversial. However, they defy extensibility over module boundaries.
Either a facility to extend given enumeration types has to be introduced,
or they have to be dropped. A reason in favour of the latter, radical
solution was the observation that in a growing number of programs the
indiscriminate use of enumerations (and subranges) had led to a type
explosion that contributed not to program clarity but rather to verbosity.
In connection with import and export, enumerations give rise to the
exceptional rule that the import of a type identifier also causes the
(automatic) import of all associated constant identifiers. This exceptional
rule defies conceptual simplicity and causes unpleasant problems for the
implementor.

Subrange types were introduced in Pascal (and adopted in Modula) for two
reasons: (1) to indicate that a variable accepts a limited range of values
of the base type and to allow a compiler to generate appropriate guards for
assignments, and (2) to allow a compiler to allocate the minimal storage
space needed to store values of the indicated subrange. This appeared
desirable in connection with packed records. Very few implementations have
taken advantage of this space saving facility, because the additional
compiler complexity is very considerable. Reason 1 alone, however, did not
appear to provide sufficient justification to retain the subrange facility
in Oberon.

With the absence of enumeration and subrange types, th