is a
Computer Programming Language invented by
Niklaus Wirth at
ETH around
1978 , as a successor to
Modula , another language by him. Modula was implemented 1980 in the
Lilith computer, commercialized 1982 by startup company DISER (Data-Image-Sound-Processor-and Emitter-Receiver-System) as MC1 and MC2. DISER sold 120 units worldwide, The Modula-2 language is loosely based upon the
Mesa Programming Language , from Xerox, that Wirth saw during his 1976 sabbatical year at Xerox PARC.
Modula-2 is a general purpose
Procedural Language , sufficiently flexible to do systems programming, but with much broader application. In particular, it was designed to support separate compilation and data abstraction in a straightforward way. Much of the syntax is based on Wirth's earlier and better-known language,
Pascal . Modula-2 was designed to be broadly similar to Pascal, with some elements removed and the important addition of the ''module'' concept, and direct language support for
Multiprogramming .
The Modula-2 ''module'' may be used to encapsulate a set of related subprograms and data structures, and restrict their visibility from other portions of the program. The module design implemented the data abstraction feature of Modula-2 in a very clean way. Modula-2 programs are composed of modules, each of which is made up of two parts: a , the interface portion, which contains only those parts of the subsystem that are ''exported'' (visible to other modules), and an '''implementation module''', which contains the working code that is internal to the module.
The language has strict scope control. In particular the scope of a module can be considered as an inpenetrable wall: Except for standard identifiers no object from the outer world is visible inside a module unless explicitly imported; no internal module object is visible from the outside unless explicitly exported.
Suppose module M1 exports objects a, b, c, and P by enumerating its identifiers in an explicit export list
DEFINITION MODULE M1;
EXPORT QUALIFIED a, b, c, P;
...
Then the objects a,b,c, and P from module M1 become now known outside module M1 as M1.a, M1.b, M1.c, and M1.P. They are exported in a ''qualified'' manner to the universe (assumed module M1 is global). The exporting module's name, i.e. M1, is used as a qualifier followed by the object's name.
Suppose module M2 contains the following IMPORT declaration
MODULE M2;
IMPORT M1;
...
Then this means that the objects exported by module M1 to the universe can now be used inside module M2. They are referenced in a ''qualified'' manner like this: M1.a, M1.b, M1.c, and M1.P. Example:
...
M1.a := 0; M1.c := M1.P(M1.a + M1.b);
...
Qualified export avoids name clashes: For instance, if another module M3 would also export an object called P, then we can still distinguish the two objects, since M1.P differs from M3.P. Thanks to the qualified export it does not matter that both objects are called P inside their exporting modules M1 and M3.
There is an alternative technique available, which is in wide use by Modula-2 programmers. Suppose module M4 is formulated as this
MODULE M4;
FROM M1 IMPORT a, b, c, P;
Then this means that objects exported by module M1 to the universe can again be used inside module M4, but now by mere references to the exported identifiers in an "unqualified" manner like this: a, b, c, and P. Example:
...
a := 0; c := P(a + b);
...
This technique of unqualifying import allows to use objects outside their exporting module in exactly the same simple, i.e. ''unqualified'', manner as inside the exporting module. The walls surrounding all modules have now become irrelevant for all those objects for which this has been explicitly allowed. Of course unqualifying import is only applicable if there are no name clashes.
These export and import rules may seem unnecessarily restrictive and verbose. But they do not only safeguard objects against unwanted access, but also have the pleasant side-effect of providing automatic cross-referencing of the definition of every identifier in a program: if the identifier is qualified by a module name, then the definition comes from that module. Otherwise if it occurs unqualified, simply search backwards, and you will either encounter a declaration of that identifier, or its occurrence in an IMPORT statement which names the module it comes from. This property becomes very useful when trying to understand large programs containing many modules.
The language provides for (limited) single-processor concurrency (
Monitors ,
Coroutine s and explicit transfer of control) and for hardware access (absolute addresses, bit manipulation, and
Interrupt s). It uses
Name Equivalence .
There are two major dialects of Modula-2. The first is named after the book
"Programming in Modula-2" by
Niklaus Wirth . There were three major editions of PIM,
the second, third (corrected), and fourth editions, each describing slight variants of the
language. The second major dialect is from the standardization effort by the
International Organization For Standardization .
-
- --- Required explicit clause in definition modules.
-
- --- Removed the clause from definition modules by the observation that everything within a definition module defines the interface to that module, hence the clause was redundent.
-
- --- The behaviour of the and '''REM''' operators were specified when their operands were negative.
-
- --- ISO Modula-2 resolved most of the ambiguities in PIM Modula-2. It added the data type and '''LONGCOMPLEX''', exceptions, module termination ('''FINALLY''' clause) and a complete standard I/O library. There are numerous minor differences and clarifications.
- (parallel extension), ISO Modula-2's OO and generic extensions, Modula-3 (by DEC and Olivetti; adding garbage collection, objects, and generics), Oberon (another, later, Wirth design), Oberon-2 (Oberon with OO extensions), Objective Modula-2 (a hybrid of Modula-2 and Smalltalk ) and a number of others. These should not be regarded as "better versions" or "replacements" for Modula-2; most are different languages with different purposes, and with strengths and weaknesses of their own.
Along with
C and
Ada , Modula-2 is often regarded as one of the three most significant "modern" programming languages (ie, of the
Structured Programming era). Of the three, Modula-2 is the smallest, easiest to read, easiest to learn, and cleanest designed, both syntactically and conceptually. Modula-2 was developed as the system language for the
Lilith workstation, and formed the basis of the
Oberon project at ETHZ. Most current programming languages have adopted many of the features of Modula-2.
- ACK Modula-2 for Minix 2.0 (freeware)
- Cambridge Modula-2 for various micro-controllers and embedded MINOS operating system (commercial)
- Canterbury Modula-2 generates Java source code
- DEC Modula-2 for BSD and Ultrix, both VAX and MIPS (freeware)
- FST Fitted Software Tools Modula-2 for MS-DOS (freeware)
- Gardens Point Modula-2 for BSD, Linux, OS/2, Solaris and .NET - ISO compliant (freeware)
- GNU Modula-2 compiler for GCC platforms, work in progress but already generates code, PIM compliant (open source, GPLed)
- M2Amiga for Amiga (open source)
- MacMETH by N. Wirth and collaborators from ETH Zurich for Macintosh, but Classic only (freeware)
- Mod51 for the Intel 80x51 micro-controller family (commercial)
- ModulaWare for OpenVMS, both VAX and Alpha, ISO compliant (commercial)
- MTC Modula-2 to C translator, available in Modula-2 and C source (open source)
- p1 Modula-2 for Macintosh, both Classic and MacOS X, ISO compliant (commercial)
- The Karlsruhe Modula-2 Compiler MOCKA for various platforms, PIM compliant (commercial, free Linux/BSD versions)
- TERRA M2VMS for OpenVMS, both VAX and Alpha, PIM compliant (commercial)
- The Ulm Modula-2 System for Solaris, both SPARC and MC68K (open source, GPLed)
- Excelsior Modula-2 (XDS) for Windows, OS/2 and Linux, ISO compliant (freeware)
