There are potentially three different types of libraries of modules available to a programmer from which to import entities at any given time. These are:
This is the collection of modules provided to the programmer as a part of the language package as it comes from the vendor. They include:
1. The Standard Library Modules:
These are the library modules defined by the International Organization for Standards (ISO). Some might include variations on the library modules that Wirth suggested be part of the operating environment in this package. This material includes:
a. system modules to interface between Modula-2 and certain low level facilities that must exist on any computer
b. separate modules which include (among others) those for
(i) input and output
(ii) text/numeric conversion
(iii) mathematical functions
The ISO standard also distinguishes between library modules that are optional and those that are required for certified compliance with the standard.
2. Nonstandard Utility Modules
These may include modules to provide communications capabilities, or certain useful data types or operations that programmers commonly use, but may not wish to write for themselves.
3. System Specific Modules
These support specialized facilities available only on a particular type or brand of
a. computer (VAX, Apple, IBM PC, Sun, or a mainframe.)
b. operating system (UNIX, the UCSD P-system, VMS, MS-DOS, Macintosh or other graphics user interface, etc.)
In some implementations, all three groups might be collected together formally into a single library file and in others they may be present as separate but previously compiled files. This text has already made use of several of these library modules, and shall have more to say about others in later chapters.
This is the set of library modules that the programmers working on the system have devised for themselves. As indicated already in this chapter, these are compiled and their entities used in exactly the same way as those in the supplied library.
Each module has a definition part and a (probably) separate symbol file created by the compiler and for its later use when compiling client programs to determine if the correct syntax has been used. It also has an implementation part that is keyed to the corresponding definition part and contains the actual run-time code for the linker to use in generating the executable version of a program module.
When the implementation part has been compiled in the presence of the previously compiled definition part, the defined entities are available for import in exactly the same way as the supplied ones.
NOTE: If the supplied library is a single file, instead of a scattering of files, there will probably be a supplied utility called a library manager that will allow the code of the user library collection also to be bound into a single file, or perhaps even added to the system library. If the latter is done, there will be a slight increase in linking speed, as the module loader will search in the supplied library before going through the other disk files for the desired name.
This is the set of modules that are part of a program file itself, for a module can contain another module. This idea will not be pursued here, as this is a more advanced technique (see chapter eleven). However, note the following definitions:
A module that can be independently compiled, such as a program module, is called a global module. It may also be termed a compilation unit. One that is contained inside some other module, and is therefore not itself a compilation unit, is called a local module.