Cours Modula-3 the powerful and safe language, tutoriel & guide de travaux pratiques en pdf.

Goals and Features

The motto of the Modula-3 committee when it was formed was to select simple, safe and proven features to include in Modula-3. Ultimately, Modula-3 has ended up with a mixture of features selected from other languages and a few features of its own. The features selected by the committee were geared towards the following goals, as outlined in :
1. support for structuring of large programs
2. maximizing safety and robustness of programs
3. support for machine-level programming when required
4. simplicity
The above goals were geared towards a compromise between BCPL-like languages and lisp-like lan-guages. One provided the e ciency and exibility and the other provides a beautiful programming model while compromising on e ciency. Modula-3 attempts to eliminate the dangers of BCPL-like languages using a strong type system, while e ciency can be achieved when required by writing unsafe code which may be machine-dependent.
We will now outline the features of Modula-3. Modula-3 assimilated the following features from other languages simplifying them to a large extent.
In addition, Modula-3 possesses a few novel features which are unique to itself:
isolation of safe and unsafe code, powerful and clean type system, layered abstractions.
Overall, objects, interfaces and modules, threads and generics are those which contribute to the goal of structuring large programs and the rest of the features are useful for safety and robustness and for system-level programming. The goal of simplicity is followed in the inclusion of all of these features. In the following subsections we focus on those features which we think are either unique to Modula-3 or are more important in contributing towards its goals.

Modules and interfaces

Modules are main building blocks of Modula-3 programs. They provide the outermost scope: in addition to variables declared within a module, only names in imported interfaces are visible.
Modules are interrelated through interfaces. An interface de nes parts of a module that are publicly visible. An interface contains declarations only, implementation is always within the module that exports it.
The le structure of a program is parallel to its module/interface structure: each module is located in a .m3 le by the same name, and each interface in a .i3 le by the same name as the interface.
A typical module looks like the following:
MODULE m EXPORTS i1 ;
IMPORT i2 ;
PR OC ED UR E f ();
VAR x ;
BEGIN
(* module body *)
END m .
Here, i1 is an interface implemented in the module m, while i2 is an interface implemented else-where.
By convention, the main program is in a module named Main. Alternatively, any name can be used for the main module as long as it exports the Main interface.
A module can export one or more interfaces. If no interface is explicitly exported by the module, the module implicitly exports the interface by the same name as the module. However, the interface must always be explicitly de ned in an .i3 le. The explicit de nition of interfaces between modules is Modula-3’s feature that is geared towards large programs: it helps avoid namespace cluttering.
Unless the name n from interface i is made visible directly via FROM i IMPORT n, names from imported interfaces are pre xed by the interface name: i.n.
A module may or may not have a body (startup code within the BEGIN/END block). Typically, the focus of the main module would be on the body, while that of a library module would be on the type and procedure de nitions before the BEGIN keyword.
Modules are at the same time the smallest units that can be made generic or unsafe, and the largest units available in Modula-3: there is no larger concept such as a package.

Type system

As speci ed by Laverman in Chapter 3 of [5], types serve three major purposes: structuring data, speci cation tool and consistency checking. We will deal with each of these three with respect to Modula-3.
With regard to structuring of data, Modula-3 provides array and record types, object types and packed types. Record types are provided for structuring of di erent kinds of data into a single entity. Object types are provided in order to implement Object-Oriented concepts where a set of operations are de ned to be performed on a set of data. This simplistic de nition is expanded upon in Section 3.4. Packed types in Modula-3 allow for the speci cation of the number of bits used for each member of the type. These contribute to a predictable mapping onto the hardware.
With regard to the type system as a speci cation tool, Modula-3 provides a concept called opaque types which can both be used as a speci cation tool and for information hiding. These two uses are closely tied. Record and Object types specify a set of elds for a particular type.
These elds constitute what the type signi es and what can be performed with the type. For a single type, depending on an implementation which uses it, di erent speci cations can be provided. These di erent speci cations of a single type are implemented using opaque types in Modula-3. A programmer could specify di erent speci cations of the same type in di erent interfaces which are used by di erent implementations. A consequence of using such a system is that parts of a speci cation of a type are hidden to the implementer of another speci cation of the same type. This constitutes the information hiding mechanism of Modula-3. We devote Section 3.3 to this topic.
With regard to the use of types for consistency checking, Modula-3 supports features such as Structural Equivalence and Strong Typing as well as keeping the type system simple and uniform. These concepts are discussed below. However, we will see that Structural Equivalence has its own share of problems and in order to resolve these, Modula-3 supports a form of name equivalence when needed.
We now discuss the features of Modula-3 which deal with consistency checking.

Assignability and Compatibility

Modula-3 is strongly typed. In the context of Modula-3, strong typing implies that (1) There are no ambiguous types or target typing (2) No Auto-Conversions (3) Well-de ned rules for type compatibility. These are accomplished through Static Type-Checking.