Pascal had become quite popular in the 1970s. This was in part attributed to the fact that it was a somewhat easy language to learn. It was not as fast a language, as say Fortran, but it did incorporate the notion of structured programming, so that by the late 1970s programmers had learnt to code without using the dreaded
goto statement. Wirth realized that Pascal had its shortcomings , and considered Pascal’s I/O to be “inadequate and inflexible“. A new language was to be designed, but instead of being called Pascal-2, it was called Modula-2. To experiment with multiprogramming primitives, Wirth contrived a rudimentary language called Modula . Modula was never intended to be a language like Pascal.
In 1976 Wirth spent a year at the Xerox Palo Alto Research Center (PARC). Here he learned about hardware design, and on returning to Switzerland began work on what was to become Lilith, a personal workstation . Wirth had some fixed constraints on the system: single-user, single processor, and all software written in a single language . As to the language, Pascal was not capable, nor was Modula, at least not by themselves. The solution? Modula-2, a conglomeration of the bloodlines of Pascal, Modula, and Mesa (a language being developed at Xerox PARC). The Lilith was marketed as “The Modula Computer”, and sold for US$22,750.
Modula-2 was based on the concept of a module, which allowed for high level abstraction, and low-level facilities. The language was defined in 1978, and implemented on a PDP-11, with the first Modula-2 compiler was released in 1980. One of the reasons Modula-2 didn’t succeed was the lack of a good free compiler (there is one now, but only for Windows).
Modula-2 was influenced by Pascal, Modula, and Mesa (a Pascal offspring).
Why was it developed?
To alleviate the shortcomings of Pascal, and to design a language more apt for the time. Whereas Pascal was designed more for teaching, Modula-2 was designed as more of a systems-language.
What did it actually do for programming?
Modules. Derived from the notion of abstract data types, and incorporating information hiding, it built on the concepts of Mesa. This allowed things like I/O to be removed from the language proper, and encapsulated in a module forming a “standard library”. The module structure isolates its contents from the surrounding program, and modules can be separated into a definition and an implementation part. All communications to other modules occurs through the imported and exported identifiers. The module can also be regarded as a representation of the concept of an “abstract data type” postulated by Liskov in 1974 .
Language features (Modula) “dumped” from Pascal
- Variant records.
- Built-in I/O – move to libraries.
- No goto statement.
- Packing of data – Pascal allowed data in record and array structures to be packed.
Improvements over Pascal (i.e. what was added/modified)
- Source code is case-sensitive, reserved words are in UPPERCASE.
- Open arrays.
- The PROCEDURE type.
- Flexible declarations: types, variables, and procedures can be mixed together, as
opposed to Pascal’s strict const, type, var, etc.
- CASE has an ELSE for matching unspecified values. Also permits subranges.
- Boolean expressions are evaluated conditionally.
- I/O is relegated to library modules to avoid system dependencies.
- Readability was enhanced through the use of control structure terminators:
REPEAT–UNTIL, IF/WHILE/FOR – END. This eliminates the begin-end block construct.
- The FOR statement is augmented by the clause BY. Pascal’s downto clause is missing.
- The type CARDINAL to allow for unsigned (positive) integers.
- Two standard procedures for incrementing and decrementing: INC and DEC.
- LONG identifiers.
- There are better control transfers. The statements RETURN and EXIT are used to transfer control from procedures and looping structures. HALT is used to terminate a program.
- No goto statement.
- No syntactic ambiguities in decisions, e.g. no dangling ELSE. IF statements always require an END.
- A new looping statement called LOOP, providing an infinite loop.
- Standard I/O functions, dynamic storage allocation, files via library modules.
- No standard procedures for I/O and storage allocation (some found this quite onerous).
For a list of ambiguities and insecurities, the interested reader is referred to , , and .
|1988||Modula-3||Designed by DEC and Olivetti. Not adopted widely in industry.|
- Wirth, N., “The development of procedural programming languages – personal contributions and perspectives”, in Modular Programming Languages, JMLC 2000, LNCS, V.1897 (2000)
- Wirth, N., “History and Goals of Modula-2”, BYTE, pp.145-152 (Aug.1984).
- Ohran, R., “Lilith and Modula-2”, BYTE, pp.181-192 (Aug.1984).
- Paul, R.J., “An Introduction to Modula-2”, BYTE, pp.195-210 (Aug.1984).
- Coar, D., “Pascal, Ada, and Modula-2”, BYTE, pp.215-232 (Aug.1984).
- Gutknecht, J., “Tutorial on Modula-2”, BYTE, pp.157-176 (Aug.1984).
- Wirth, N., “Modula: A language for modular multiprogramming”, Software- Practice and Experience, 7, pp.37-65 (1977)
- Spector, D., “Ambiguities and insecurities in Modula-2”, ACM SIGPLAN Notices, 17(8), pp.43-51 (1982)
- Torbett, M.A, “More ambiguities and insecurities in Modula-2”, ACM SIGPLAN Notices, 22(5), pp.11-17 (1987)
- Liskov, B., Zilles, S., “Programming with abstract data types”, in ACM SIGPLAN Notices, 4, pp.50-59 (1974).
- Collins, S., “Comparing Modula-2 with Pascal and Ada”, Data Processing, 26(10), pp.32-34 (1984)
- Cornelius, B.J., “Problems with the language Modula-2”, Software-Practice and Experience, 18(6), pp.529-543 (1988)