Cours the Role of Modules in Modula-2 (Installation), tutoriel & guide de travaux pratiques en pdf.

The Role of Modules in Modula-2

Modules are the most important feature distinguishing Modula-2 from Pascal. Relying heavily upon the concepts of « scope » and « block, » modules address the problem (usually found in large programs) of separating « visibility » from « existence. »
In block-structured languages the range (i.e. program sections) i&which an object (e.g. a variable or procedure) is known is called that object’s scope, and therefore, defines its visibility.
Unfortunately, an object’s visibility also binds its existence — objects created when the block in which they reside is entered are destroyed when the block is exited. It should be possible as-an alternative to declare variables that maintain their values, but are visible only in a few parts of a program. Concurrently, there is also a need for closer control of visibility; a procedure should not be able to access every object declared outside of it when it only needs to access a few of them.
Syntactically, modules closely resemble procedures, but they have different rules about visibility and the existence of their locally declared objects. Consider the declarations in the example given in Figure 2.
The only syntactic differences between the module Mod and a normal Pascal procedure declaration are the reserved word beginning the declaration (MODULE instead of PROCEDURE) and the presence of IMPORT and EXPORT declarations following the module heading.
The semantic differences are more interesting. The objects declared within Mod — a,b,and c — exist at the same time as the variables x, Y, and z, and remain so as long as Outside is active. The objects named in Mod’s IMPORT list are the only externally declared objects visible within Mod — x, but neither y nor z. The objects declared in Mod’s EXPORT list are the only em locally declared objects visible outside Mod. Thus, a and Pl are accessible throughout Outside, but b and c remain hidden inside Mod.
Figuratively speaking, a module can be considered a syntactically opaque wall protecting its enclosed objects, be they variables or procedures. The export list names identifiers defined inside the module that are also to be visible outside. The import list names those identifiers defined outside the module that are visible inside. Generally, the rules for modules are:
1. Locally declared objects exist as long as the enclosing procedure remains activated;
2. Locally declared objects are visible inside the module and, if they appear in the module’s export list, they are also visible outside;
3. Objects declared outside of the module are visible inside only if they appear in the module’s import list; em The example given in Figure 3 demonstrates the essence of modularity.
The random number generator in these examples uses its previous value as a seed variable to generate the next random number.
Thus, that value must be maintained across function calls. The program on the right shows the classical Pascal solution. Notice that Seed’s declaration is at the top of the program, while its
initialization is forced to the bottom. Two obvious disadvan- -a tages arise from the scattering of Seed across the face of the program:
1. Its occurrences become hard to find, especially in a large – « -s%Q program;
2. It becomes accessible to every other procedure in the program, even though it is used only by Random;
The example on the left demonstrates the usefulness of the module structure. The only object visible to the outside world is the procedure Random, while all objects pertaining to the random number generator are contained in one place. Note that the module RandomNumber contains both declarations and a statement part.
Module bodies are the (optional) outermost statement parts of module declarations and serve to initialize a module’s variables.
Although subject to the module’s restrictive visibility rules, module bodies conceptually belong to the enclosing procedure rather than to the modules themselves. Therefore, module bodies are automatically executed when the enclosing procedure is called.

Relaxed Declaration Order

New Pascal users are often frustrated and confused by the enforced declaration and definition block structure required within the program skeleton. Despite the emphasis on modules, blocks still play an important part in Modula-2: implementation modules, program modules, internal modules, and procedures are all declared as blocks. Differences from Pascal include relaxed order of-declarations, termination of all blocks by a procedure or module identifier, and the optional nature of block bodies.
Pascal imposes a strict order on the declaration of objects; within any given block, labels must be declared before constants, constants before types, and so on. Modula-2 eliminates this restriction — declarations can appear in any order. Programs containing a large number of declarations are easier to read and understand when related declarations are grouped together (regardless of their kind).