Cours From Modula to Oberon (Modules and import/export rules), tutoriel & guide de travaux pratiques en pdf.

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, the general possibility of defining set types based on given element types appeared as redundant. Instead, a single, basic type SET is introduced, whose values are sets of integers from 0 to an implementation-defined maximum.
The basic type CARDINAL had been introduced in Modula in order to allow address arithmetic with values from 0 to 216 on 16-bit computers. With the prevalence of 32-bit addresses in modern processors, the need for unsigned arithmetic has practically vanished, and therefore the type  Pointer types are restricted to be bound to a record type or to an array type.
The notion of a definable index type of arrays has also been abandoned: All indices are by default integers. Furthermore, the lower bound is fixed to 0; array declarations specify a number of elements (length) rather than a pair of bounds. This break with a long standing tradition since Algol 60 clearly demonstrates the principle of eliminating the inessential. The specification of an arbitrary lower bound hardly provides any additional expressive power. It represents a rather limited kind of mapping of indices which introduces a hidden computational effort that is incommensurate with the supposed gain in convenience. This effort is particularly heavy in connection with bound checking and with dynamic arrays.

Modules and import/export rules

Experience with Modula over the last eight years has shown that local modules were rarely used. Considering the additional complexity of the compiler required to handle them, and the additional complications in the visiblity rules of the language definition, the elimination of local modules appears justified.
The qualification of an imported object’s identifier x by the exporting module’s name M, viz. M.x, can be circumvented in Modula by the use of the import clause FROM M IMPORT x. This facility has also been discarded. Experience in programming systems involving many modules has taught that the explicit qualification of each occurrence of x is actually preferable. A simplification of the compiler is a welcome side-effect.
The dual role of the main module in Modula is conceptually confusing. It constitutes a module in the sense of a package of data and procedures enclosed by a scope of visibility, and at the same time it constitutes a single procedure called main program. A module is composed of two textual pieces, called the definition part and the implementation part. The former is missing in the case of a main program module.
By contrast, a module in Oberon is in itself complete and constitutes a unit of compilation. Definition and implementation parts are merged; names to be visible in client modules, i.e. exported identifiers, are marked, and they typically precede the declarations of objects not exported. A compilation generates in general a changed object file and a new symbol file. The latter contains information about exported objects for use in the compilation of client modules. The generation of a new symbol file must, however, be specifically enabled by a compiler option, because it will invalidate previous compilations of clients.
The notion of a main program has been abandoned. Instead, the set of modules linked through imports typically contains (parameterless) procedures. They are to be considered as individually activatable, and they are called commands. Such an activation has the form M.P, where P denotes the command and M the module containing it. The effect of a command is considered – not like that of a main program as accepting input and transforming it to output – as a change of state represented by global data.

Statements

The with statement of Modula has been discarded. Like in the case of imported identifiers, the explicit qualification of field identifiers is to be preferred. Another form of with statement is introduced; it has a different function and is called a regional guard (see below).
The elimination of the for statement constitutes a break with another long standing tradition. The baroque mechanism of Algol 60’s for statement had been trimmed significantly in Pascal (and Modula). Its marginal value in practice has led to its absence from Oberon.

Low-level facilities

Modula makes access to machine-specific facilities possible through low-level constructs, such as the data types ADDRESS and WORD, absolute addressing of variables, and type casting functions. Most of them are packaged in a module called SYSTEM. These features were supposed to be rarely used and easily visible through the presence of the identifier SYSTEM in a module’s import list. Experience has revealed, however, that a significant number of programmers import this module quite indiscriminately. A particularly seductive trap are Modula’s type transfer functions.
It appears preferable to drop the pretense of portability of programs that import a « standard », yet system-specific module. Type transfer functions denoted by type identifiers are therefore eliminated, and the module SYSTEM is restricted to providing a few machine-specific functions that typically are compiled into inline code. The types ADDRESS and WORD are replaced by the type BYTE, for which type compatibility rules are relaxed. Individual implementations are free to provide additional facilities in their module SYSTEM. The use of SYSTEM declares a program to be patently implementation-specific and thereby non-portable.

Concurrency

The system Oberon does not require any language facilities for expressing concurrent processes. The pertinent rudimentary features of Modula, in particular the coroutine, were therefore not retained. This exclusion is merely a reflection of our actual needs within the concrete project, but not on the general relevance of concurrency in programming.

Features introduced in Oberon

In contrast to the number of eliminated features, there are only a few new ones. The important new concepts are type extension and type inclusion. Furthermore, open arrays may have several dimensions (indices), whereas in Modula they were confined to a single dimension.