Back in Chapter 2, the following definition was provided:
A module is a container to hold the items and information that constitute all or part of an executable program.
At the time, the concept was left deliberately vague. Thus far, this text has employed program modules and has pointed out that various imports were also derived from modules. As the definition implies, a module is simply a box, the function of which is to enclose the various entities that are defined or used therein. As ought to be evident already, the entities contained in a module may be variables, constants, types and procedures. Each of these may be defined inside the module in question or may be imported from some other module. One module can even contain another module in this way; and this nesting can go on for as many levels as the programmer desires, or the system permits.
The closest analogue among the other things seen thus far may be the procedure. An entity such as a variable is either visible and useful in a procedure or it is not. Likewise, an entity (via its identifier) is either visible and usable within the confines of a module or it is not. If it is not, any attempt to employ it in that module will result in an "Undeclared Identifier Error."
None of this is entirely new, for much of it has been stated or hinted at already--but it does allow some refinement of the definition into a more useful form.
A module is an enclosing device or container to delimit the visibility and use of entities, whether these be internally defined or imported.
This version of the definition implies that the entities in question may constitute all or part of a program. If the module encloses types, constants, and procedures only (as does a library module) then these entities are not part of an actual program until they are imported and used by one. Until that time, they are only abstractly (or more correctly, potentially) portions of programs.
As remarked both here and in section 4.2, a module defines a scope of visibility, much as does a procedure. Indeed, that is all it does. One might be tempted to extend the analogy between these procedures and modules, but such an attempt quickly fails, for modules are not themselves subprograms; they are only enclosures into which programs, subprograms, and other entities can be placed. They are either used within their own enclosure (as with a program module) or they are extracted from there for use inside another one.
Like procedures, modules are themselves entities, so they are named. This name must appear both in the declaration and with the end of the module as in all program modules thus far in the text. Unlike procedures, modules in the base ISO standard language have no parameter lists and are not generally subprograms themselves, so it is safest to regard a module as a set of walls and nothing more.
These concepts will be discussed in more detail in chapter eleven in the sections on scope and visibility rules for local modules. For now, more practical matters demand some attention.