The Language Modula (Cours informatique), tutoriel & guide de travaux pratiques en pdf.

The Language Modula-2

The defining report of Modula-2 appeared in 1979, and a textbook on it in 1982. A tutorial was published, following the growing popularity of the language [17, 18]. In planning Modula-2, I saw it as a new version of Pascal updated to the requirements of the time, and I seized the opportunity to correct various mistakes in Pascal’s design, such as, for example, the syntactic anomaly of the dangling « else », the incomplete specification of procedure parameters, and others. Apart from relatively minor corrections and additions, the primary innovation was that of modules.

Modules

ALGOL had introduced the important notions of limited scopes of identifiers and of the temporary existence of objects. The limited visibility of an identifier and the limited lifetime of an object (variable, procedure), however, were tightly coupled: All existing objects were visible, and the ones that were not visible did not exist (were not allocated). This tight coupling was an obstacle in some situations. We refer to the well-known function to generate the next pseudo-random number, where the last one must be stored to compute the next, while remaining invisible. ALGOL’s designers noticed this and quickly remedied the shortcoming by introducing the own property, an unlucky idea. An example is the following procedure for generating pseudo-random numbers (c1, c2, c3 stand for constants):
real procedure random;
begin own real x;
x := (c1*x + c2) mod c3; random := x end
Here x is invisible outside the procedure. However, its computed value is retained and available the next time the procedure is called. Hence x cannot be allocated on a stack like ordinary local variables. The inadequacy of the own concept becomes apparent if one considers how to give an initial value to x.
Modula’s solution was found in a second facility for establishing a scope, the module. In the first facility, the procedure (block in ALGOL), locally declared objects are allocated (on a stack) when control reaches the procedure, and deallocated when the procedure terminates. With the second, the module, no allocation is associated; only visibility is affected. The module merely constitutes a wall around the local objects, through which only those objects are visible that are explicitly specified in an « export » or an « import » list. In other words, the wall makes every identifier declared within a module invisible outside, unless it occurs in the export list, and it makes every identifier declared in a surrounding module – possibly the universe – invisible inside, unless it occurs in the module’s import list. This definition makes sense if modules are considered as nestable, and it represents the concept of information hiding as first postulated by Parnas in 1972.
The notation for a module was chosen identical to that of a monitor proposed by Hoare in 1974 [6], but lacks connotation of mutual exclusion of concurrent processes (as it was in Modula-1 [7]).
Modula-2’s module can also be regarded as a representation of the concept of abstract data type postulated by Liskov in 1974 [5]. A module representing an abstract type exports the type, typically a record structured type, and the set of procedures and functions applicable to it. The type’s structure remains invisible and inaccessible from the outside of the module. Such a type is called opaque. This makes it possible to postulate module invariants. Probably the most popular example is the stack. (For simplicity, we refrain from providing the guards s.n < N for push and s.n > 0 for pop).