Modula-2 (817/mod020) |
 |
Wirth, ETH 1977.
Developed as the system language for the Lilith workstation.
The central concept is the module which may be used to encapsulate a set of related subprograms and data structures, and restrict their visibility from other portions of the program. Each module has a definition part giving the interface, and an implementation part.
The language provides limited single-processor concurrency (monitors, coroutines and explicit transfer of control) and hardware access (absolute addresses and interrupts). Uses name equivalence.
Related languages
| Mesa | => | Modula-2 | Influence | |
| Modula | => | Modula-2 | Evolution of | |
| Pascal | => | Modula-2 | Positive Strong Influence | |
| Modula-2 | => | *MOD | Derivation of | |
| Modula-2 | => | Alma | Subset | |
| Modula-2 | => | Alma | Extension of | |
| Modula-2 | => | HERAKLIT | Based on | |
| Modula-2 | => | House Algol 60 | Influence | |
| Modula-2 | => | LTR | Based on | |
| Modula-2 | => | M2001 | Evolution of | |
| Modula-2 | => | MAS | Extension to | |
| Modula-2 | => | MIKE | Based on | |
| Modula-2 | => | MODSIM | Based on | |
| Modula-2 | => | Modula SC | Extension of | |
| Modula-2 | => | Modula-2* | Extension of | |
| Modula-2 | => | Modula-2+ | Extension of | |
| Modula-2 | => | Modula-3pi | Evolution of | |
| Modula-2 | => | Modula-P | Evolution of | |
| Modula-2 | => | Modula-Prolog | Built on | |
| Modula-2 | => | Modula-R | Augmentation of | |
| Modula-2 | => | Oberon | Subset | |
| Modula-2 | => | Orca | Influence | |
| Modula-2 | => | Parallaxis | Based on | |
| Modula-2 | => | SR | Influence | |
| Modula-2 | => | Zuse | Influence |
References:
in IEEE Comms 1981 view details
This paper briefly reviews the advantages offered by Modula-2 for systems programming and other applications, then presents a critique of the Modula-2 language manual, with the most important issues flagged as such. A number of problem areas have been omitted due to lack of space.
Detailed familiarity with the Modula-2 language is assumed in the critique sections; no tutorial material is included.
DOI Extract: Introduction
Introduction
While it is not yet clear whether Ada, BLISS, Mary/2, Modula-2, Mesa, C, CLU, Edison, Concurrent Euclid, Icon, Newton, PLAIN, PLUS, Praxis, Smalltalk, SQURL, Y, or some other language is "best" for systems programming, each language represents an advance towards the goal of supporting an understandable and efficient organization of the many details and relationships inherent in systems programming.
Unfortunately, no one language has yet achieved the delicate balance between simplicity and power that would distinguish it as ideal, but it appears that Modula-2 comes quite close. Modula-2 represents a step forward in language design, both because it incorporates existing features instead of inventing its own, and because of its evident concern for simplicity.
Modula-2 offers the following valuable language features:
Simplicity.
Few primitive datatypes are defined, few control constructs are supported (there is no "go to"), and input-output operations are not provided as part of the language (they can be provided via extensions written in Modula-2). This simplicity allows for easier standardization and better portability than can be achieved with most other languages.
Modules
A module is a named collection of variables and procedures, similar to an Ada package. It controls the interfacing and encapsulation of the conceptual parts making up large software systems. Modules provide a more flexible solution to the problem of partitioning the name space of a large program than does the more familiar hierarchical nesting of procedures. They are so valuable they are even being force-fitted onto existing languages.
Separate Compilation.
Modules may be compiled separately, providing good management for large programsr and definition modules allow for specifying interfaces without giving implementation details.
Flexible Datatypes.
Strong datatypes are enforced, but this can be relaxed when necessary in systems programming to just declaring a parameter to be a word, an address, or an array of words.
Machine Access.
Access to specific memory addresses and other characteristics of the underlying machine is supported.
Tasking.
Flexible and efficient tasking is provided by coroutine management routines.
in SIGPLAN Notices 17(08) August 1982 view details
in SIGPLAN Notices 17(08) August 1982 view details
Since its syntax was more in line with Modula than Pascal’s the
chosen name was Modula 2.
[...]
The language’s main additions with regard to Pascal are:
1. the module concept, and in particular the facility to split a module into a
definition part and an implementation part.
2. A more systematic syntax which facilitates the learning process. In particu -
lar, every structure starting with a keyword also ends with a keyword, i.e. is
properly bracketed.
3. The concept of process as the key to multi-programming facilities.
4. So called low level facilities which make it possible to breach the rigid type
consistency rules and allow to map data with Modula 2 structure onto a store
without inherent structure.
5. The procedure type which allows procedures to be dynamically assigned to
variables.
in SIGPLAN Notices 17(08) August 1982 view details
in SIGPLAN Notices 20(12) December 1985 view details
As any other language Modula-2 undergoes a constant development. Therefore, the 3rd edition of this book does not only contain formal corrections of the 2nd edition but also modifications of the language Modula-2.
"Programming in Modula-2" by Niklaus Wirth can be considered as the standard reference for Modula-2 programmers.
in SIGPLAN Notices 20(12) December 1985 view details
in SIGPLAN Notices 21(05) May 1986 view details
in SIGPLAN Notices 21(05) May 1986 view details
in [ACM] Proceedings of 17th ACM Annual Computer Science Conference : Computing trends in the 1990's Louisville, Kentucky, United States 1989 view details
Two of the hottest languages these days are Modula-2 and C++. They appeared in the early 1980s, and both are gaining in popularity. Each was designed and written by a single person: Niklaus Wirth created Modula-2, and C++ was developed by Bjarne Stroustrup. An additional similarity is that both languages are extended versions of earlier languages. This article contrasts Modula-2 and C++; it assumes you have a cursory familiarity with both Pascal and C (the root languages of Modula-2 and C++, respectively). Extract: Modula-2 Background
Modula-2 Background
Pascal was designed as a teaching language, to show students how to structure programs properly. It lacks intrinsic support for character strings, file I/O, and separately compiled modules. Pascal has many features that are useful in software development, and the language gradually gained popularity outside the academic community. Unfortunately, the vendors that implemented Pascal did not develop a standard for extending the language to cover its weak points. Thus, every Pascal compiler is unique, and porting programs between implementations is difficult.
Wirth intended Modula-2 to be the successor to Pascal. Modula-2's name implies one of its basic concepts: modular program design. Through the use of modular facilities, Modula-2 supports data abstraction and encapsulation. All I/O is done through procedures in modules as an aid to portability. As long as the interface to the I/O procedures does not change, the implementation of those procedures can be modified for different environments without having to make alterations in the programs using them.
Among high-level languages, only Modula-2 and Ada support multiprocessing. In addition, Modula-2 supports bit manipulation, generic types, and system-level access. Modula-2 (unlike Pascal) is well suited to the writing of system software such as operating systems and device drivers.
Extract: C++ Background
C++ Background
C is a powerful system-level language; in its original definition, however, it lacked many features necessary for large, complex projects. Stroustrup designed C++ to amend problems with the C language, in much the same way as Wirth designed Modula-2 to correct the deficiencies of Pascal. C++ provides capabilities for strong type checking, modular programming, and data abstraction while maintaining full compatibility with existing C programs.
Stroustrup borrowed the object-oriented paradigm from Smalltalk; classes and methods are the most significant additions he added to C in creating C++. In an object-oriented language, objects (data items) belong to classes (types), which have associated methods (functions). "Messages" are sent to objects via their class methods; the messages tell the objects how to act. For example, an object of class int would be given the message "add 1" by the ++ (increment) method. Although this concept can take some getting used to, it can be more appropriate than traditional program design methods.
C++ is often implemented as a translator. The C++ translator works much like the standard C preprocessor, converting C++ programs into C programs. A C compiler is then run on the output of the translator, producing executable code. By its nature, this process is cumbersome and slow. Recently, manufacturers have released true C++ compilers.
In addition to adding object-oriented capabilities to C, C++ offers other enhancements, including in-line functions, function prototyping (since added to the ANSI standard), and overloading. Because it retains all C's low-level facilities, C++ can be used for a wide variety of applications. Extract: General Language Features
General Language Features
Modula-2 and C++ have the following general features:
* Source code format -- Source code is case sensitive in C++ and Modula-2. All C++'s keywords must be in lowercase; Modula-2 requires uppercase.
* Data types -- Both languages are rich in data types and allow the creation of new types. They offer long and short, signed and unsigned, integers and reals. Strings in both languages are handled as arrays of characters terminated by a zero (NUL) byte. Both languages have pointer types. C++ provides the capability to smoothly integrate new types through its class structure, while Modula-2 provides generic types and better control over data item visibility. Modula-2 provides SET types (including BITSET, which allows access to the individual bits of an item), whereas C++ has C's bit structures.
* Functions and procedures -- Modula-2 has procedures, whereas C++ has functions. The purpose is the same in both languages: to provide callable routines with parameters and local variables. Modula-2 allows the nesting of procedures within procedures, using the same scoping rules as it does for variables. Modula-2 and C++ parameters can be passed either by reference or by value.
* Control structures -- Here, too, there are no important differences. Although the syntax may vary, the capability is the same. Both languages have loops with tests at both the top and the bottom of the loop. The for, which iterates through a succession of values, is available in both languages. There is (of course) the ubiquitous if ..else ..endif conditional construct. Useful multiple-condition branches (switch in C++ and CASE in Modula-2) are available.
* Library routines -- C++ uses the standard C library, which is extensive and robust. Wirth defined several standard modules in his definition of Modula-2, but these provided only minimal capabilities. Most Modula-2 vendors have created expanded libraries for their implementations.
Extract: Unique Features of Modula-2
Unique Features of Modula-2
Modula-2 is not a superset of Pascal; rather, it is an evolution of the earlier language. For example, one of Modula-2's most welcome enhancements over Pascal is its simplified block structure. A Modula-2 program is not filled with BEGIN...END pairs; each control structure has an implicit block terminated by an END statement. Where Pascal has functions and procedures (the former returns a value whereas the later does not), Modula-2 simply has procedures. A Modula-2 procedure returns a value if it is specified as doing so.
One fascinating feature of Modula-2 is its support for coroutines, which are individual processes within a program that run concurrently. This allows multiple tasks (within a program) to be performed simultaneously. A word processor, for example, could use coroutines to allow a document to be printed while another is being edited.
The strong type checking in Pascal prevents spurious errors but also causes difficulties. For instance, it is impossible to create a general function in standard Pascal that can accept arrays (such as character strings) of different sizes. Modula-2 introduces the concept of the open array parameter -- for example, a parameter to a procedure can be declared as an array without bounds (array of char). Any length array of the specified type (in this case, a character array) can be passed to that function. The procedure can then find out the actual length of the array with the built-in HIGH procedure.
Modula-2 also provides the generic type. A WORD type is equal in size to the default word size of the hardware it is running on. In the case of MS-DOS, a WORD type is 16 bits long. Any type of the same size (usually the INTEGER and CARDINAL types) is assignment compatible with WORD. An extension of this is that any value can be passed to an open array of type WORD (that is, a procedure parameter of type ARRAY OF WORD). The size of the array is the number of WORD types required to hold the value being passed.
The concept of modules allows Modula-2 programmers to control access to individually compiled portions of a program. The following object-oriented example illustrates how modules can be used.
Extract: Unique Features of C++
Unique Features of C++
C++ refines and expands C while including all C's strengths. Several features of the emerging ANSI C standard are actually borrowed from C++. Examples of this are function prototypes, const, and void. Function prototypes were added so that C++ could do type checking or arguments; under the original K&R C, values of incorrect types could be passed to functions, often causing obscure errors. Const provides named constants. Adding void allowed the creation of generic pointers and made it possible to declare that a function does not return a value.
Overloading functions lets the programmers create several functions with the same name but differentiated by their parameters. Instead of C's current crop of absolute value functions (abs, dabs, fabs, and labs), a C++ implementation could have the following:
overload abs; int abs(int i); long abs(long l); float abs(float f); double abs(double d);
At compile time, the C++ compiler determines which version of abs to use based on the parameters it is being passed. This facility can make programs easier to understand.
It is possible to overload operators in C++. You can, for instance, create a new class that can use the same operators as existing classes. The section on object-oriented programming later in this article contains an example of operator overloading.
The object-oriented features of C++ are prominent. Object-oriented programming requires a change in thinking for many programmers; instead of thinking in terms of the nuts and bolts of programming, programmers are required to visualize a program as a series of processes applied to data items. This may seem to be a subtle distinction, but it must be mastered to truly appreciate and use an object-oriented language. The object-oriented features of C++ are illustrated in the section on the subject in this article.
C++ provides dozens of other extensions to C, including in-line functions, anonymous (unnamed) unions, and default function parameter values. There are dangers to the many features provided by C++. Whereas C has always been famous for providing the rope by which programmers hang their programs, C++ adds the noose. Care must be taken to avoid "going wild," especially with the overload capabilities.
Extract: Conclusion
Conclusion
Modula-2 and C++ are powerful languages; both have bright futures. C++'s classes, methods, and overloading make it a powerful tool, but it has few restraints to keep programmers from being too "creative." Modula-2 is a strongly organized language with restraints to keep programmers within guidelines. It is not as extensible as C++, but it does implement its own unique features, such as SETs, coroutines, and open arrays. Which of these languages is more appropriate for a specific project will depend on the type of application and the experience of the programmers involved. Both languages are powerful and interesting to work with.
in [ACM] Proceedings of 17th ACM Annual Computer Science Conference : Computing trends in the 1990's Louisville, Kentucky, United States 1989 view details
Of course, Pascal and C didn't experience great popularity when they first appeared, either. But 1991 could be the year that Modula-2 breaks into the ranks of major languages. In January, PC Week proclaimed that Modula-2 "is just more than eight years old -- less than half the age of C -- and is ready to enjoy the same surge of interest that C received during its own ninth year, in 1981."
What makes 1991 such an important year? For starters, the international standard is expected to be completed -- although not formally approved -- this year. New versions of the three major DOS compilers are due. In September, the Second International Modula-2 Conference is expected to draw hordes of enthusiasts to England.
1991 also presents serious challenges for Modula-2. In particular, Modula-2 faces stiff competition from languages such as Ada and C++. Modula-2 is even in danger of being upstaged by its own offspring, Oberon and Modula-3.
In this article, I'll assess how Modula-2 is doing, describe the status of Modula-2 standardardization efforts, discuss the latest Modula-2 compilers, and tell you how to find out more about Modula-2, Oberon, and Modula-3.
Extract: Whither Modula-2?
Whither Modula-2?
So how is Modula-2 really faring? Hard data is difficult to obtain, but Rich Gogesch of Stony Brook Software estimates that there are roughly 150,000 Modula-2 users worldwide. That's a respectable number, but nowhere near the number of Pascal or C users. In the U.S., Modula-2 use is reportedly static: Current users are pleased but the language isn't attracting many new converts.
In other countries, the story is different. According to Steve Collins of Real Time Associates, a British Modula-2 vendor, Modula-2 is "beating the pants off" C in the European embedded systems arena. What's more, he notes that almost all U.K. university graduates currently learn Modula-2 as their primary language; the one university that doesn't teach Modula-2 is expected to adopt it this fall. American vendors have noticed the strength of Modula-2 in Europe. Gogesch, for example, estimates that two-thirds of Stony Brook's sales are made there.
Why isn't Modula-2 as popular in the U.S. as it is elsewhere? There was once a lack of high-quality compilers, but today's Modula-2 compilers compete with the best C compilers for compilation speed and code quality. The real reasons are more subtle. First, Modula-2 has failed to distinguish itself from other languages, notably Turbo Pascal. Modula-2 has never achieved "critical mass" in the way C and Pascal have; users complain about the shortage of third-party Modula-2 libraries. The lack of an official standard for the language--and especially the libraries--has not helped. Also, Modula-2 doesn't get the publicity that newer languages do; Gogesch feels that the hoopla surrounding C++ in particular "has hurt Modula-2 quite a bit."
Plenty of programmers agree with Gogesch that, "in terms of large program development, there's nothing as good as Modula-2." In the U.S., Modula-2 is used by a surprising number of companies; however, small users don't get much attention and large firms often shun publicity. A classic example is the defense contractor whose 50 programmers write everything for Modula-2, then use a translator to convert their code to Ada before delivery.
Extract: Standardization
Standardization
An international standard for Modula-2 has been making steady progress since 1987, when working group ISO/IEC JTC1/SC22/WG13 first began to meet. A draft proposed standard was issued in late 1989 and a revision has been in preparation since mid-1990; it is expected to be ready by the time WG13 meets in Germany this summer.
For various reasons, work on the standard has slowed recently. WG13 continues to make major language changes even at this late stage; working out the implications of these changes takes time. The standard will use VDM-SL (the Vienna Development Method Specification Language) to specify the semantics of Modula-2. Using VDM-SL adds rigor to the language definition but increases the amount of time required to draft the standard. And unfortunately, members of WG13 still disagree concerning such basic issues as the philosophy behind the I/O library.
The draft proposed standard makes a number of changes to Modula-2. Because of limited space, I can't describe them all, but I'll try to hit a few of the high points. For more details, order a copy of the draft standard or read my Modula-2 column in back issues of the Journal of Pascal, Ada & Modula-2.
Structured Value Constructors. The draft standard adds "structured value constructors," which construct array and record values from their components in a manner similar to Ada aggregates. For example, if T is an array type (say T = ARRAY [0..3] OF INTEGER), the expression T {1, 2, 3, 4} constructs an array of type T containing 1, 2, 3, and 4, in that order. Records are constructed in the same way.
Complex Numbers. One of the surprises of last year's WG13 meeting was the decision to provide support for complex numbers. The current plan is to add COMPLEX and LONGCOMPLEX types to the language and ComplexMath and LongComplexMath modules to the library.
Strings. Modula-2's string handling deficiencies are well known. At one point, WG13 considered putting an "honest" string type in the language--a type whose representation would be hidden from the programmer. The working group acknowledged the value of such a type, but felt it to be too great a language change. Instead, WG13 added both a standard function named LENGTH that computes the length of a string and concatenation symbol for string literals and constants. The group is also attempting to define a standard Strings library module.
Input/Output. Improving the I/O library has been a top priority of WG13 from the beginning. Unfortunately, the members don't always agree on how the library should be improved. Some favor an industrial-strength library; others prefer a simple, streamlined library suitable for writing example programs and textbooks. The library in the first draft proposed standard leans in the former direction; it contains a hefty 23 modules and 201 procedures. After much discussion at last year's meeting, WG13 agreed to simplify the library.
The SYSTEM Module. The SYSTEM module, Modula-2's source of machine-dependent features, has undergone a great deal of change. To give just one example, the type LOC has been added in an attempt to make porting programs between byte-addressable and word-addressable machines easier. LOC represents the smallest addressable unit of memory; on some machines, a LOC value will be a byte; on others, a word.
Exception Handling. WG13 has long favored adding exception handling to Modula-2, but members disagreed over which exception-handling model to use. In fact, when the first draft standard was issued, they were still considering two different proposals; both are described in an appendix. At last year's meeting, WG13 agreed to adopt a mechanism somewhat similar to C's setjmp/longjmp. The latest proposal, which adds an EXCEPTIONS module to the library, actually provides a more powerful mechanism than setjmp/longjmp. In particular, the RETRY procedure allows a program to redo an operation that failed because an exception was raised.
Copies of the first draft proposed standard are available from the IEEE Computer Society (see "Modula-2 Resouce Guide") for $35; ask for "ISO/JTC1/SC22/WG13 draft of DP10154 - P1151 Modula-2." (Members of MODUS, the Modula-2 User's Assocation, can obtain the draft at a reduced rate.) The next draft should be available later this year.
Extract: Compilers
Compilers
One sign of Modula-2's maturity is the number of high-quality implementations available. This is especially true in the DOS world, where TopSpeed Modula-2, Stony Brook Modula-2, and Logitech Modula-2 lead the market. According to a recent review in PC Week, "these three products rival offerings for better-known languages such as C and Pascal, from better-known vendors such as Borland and Microsoft.
Jensen & Partners international recently released Version 3.0 of TopSpeed Modula-2. Version 2.0 was the first to include support for object-oriented programming; Version 3.0 adds multiple inheritance and support for data hiding. Another feature of Version 3.0 is an automatic overlay system for both code and data, making it possible to write DOS programs as large as 16 Mbytes.
JPI now sells compilers, for C, C++, and Pascal as well. All TopSpeed compilers plug into a common environment and share a common code generator, making multilanguage programming easy. Because of the environment's language independence, it is now sold separately from the Modula-2 compiler. The VID debugger is included with the environment.
TopSpeed Modula-2 is available in both DOS and OS/2 versions. The optional Professional Techkit supports Windows 3.0 development.
Version 2.2 of Stony Brook's Professional Modula-2 compiler came out last October; it features full support for Windows 3.0 and OS/2 1.2. Version 3.0 should appear late this year or early next year. Current plans call for 3.0 to support object-oriented extensions compatible with those found in Turbo Pascal. Version 3.0 promises additional optimizations as well.
Logitech Modula-2 has been taken over by MultiScope Inc., a Logitech-owned enterprise best known for its debugger. Version 4.0 of Logitech/MultiScope Modula-2, which should be out by the time you read this, is actually the Stony Brook system, modified to retain compatibility with Logitech Modula-2 3.0. MultiScope is already at work on Version 5.0 of the compiler, which is being developed in-house.
In the Macintosh arena, the leading compiler is Metrowerks Modula-2, which comes in two versions: the Professional Standalone Edition and the MPW version. A student package, the StartPak, sells in college bookstores for $39.
Modula-2 compilers are also available for a huge number of other platforms. The best source for compilers (and Modula-2 books as well) is the catalog published by Real Time Associates. The catalog is accompanied by a newsletter containing the latest Modula-2 news, gossip, and more; the current issue even includes a Modula-2 crossword puzzle!
Extract: Conferences
Conferences
The First International Modula-2 Conference was held in 1989 at Bled, Yugoslavia. The conference drew 120 participants from 14 countries. Niklaus Wirth not only gave a keynote speech but also attended most sessions and participated vigorously in discussions.
The Second International Conference, to be held September 11-13, 1991 at the Loughborough University of Technology in England, should draw an even larger crowd. The conference will be preceded by a one-day workshop that gives an overview of Modula-2 and describes its advantages over older languages. Wirth is again expected to attend.
Extract: User Groups and Publications
User Groups and Publications
The primary Modula-2 user group is MODUS (the Modula-2 User's Association), which publishes the MODUS Quarterly. Another way to meet Modula-2 users is to join USUS, the UCSD Pascal System User's Society, which has expanded to serve "the Pascal, Modula-2, and portable programming community."
With Modula-2's popularity in Britain, it's no surprise that the British Computer Society has its own Modula-2 Specialist Group, which is open to all interested parties. Because the ISO standard is being drafted in England, joining this group is a good way to keep track of the standardization effort. A membership application form is included with the Real Time Associates catalog.
Several online services and networks feature coverage of Modula-2. BIX (the Byte Information Exchange) is an excellent place to meet other Modula-2 fans in the modula.2 conference. Many Modula-2 compiler vendors have conferences on BIX. On CompuServe, check out the CodePort (formerly MUSUS) forum operated by USUS. Although CodePort is nominally devoted to portable programming languages in general, discussions of Modula-2 often dominate. On Usenet, Modula-2 is discussed in the comp.lang.modula2 newsgroup. Incidentally, comp.lang.modula2 can be reached from BIX and FidoNet.
With the demise of the Journal of Pascal, Ada & Modula-2 last year, there are no major magazines focused on Modula-2. However, a relatively new publication named Modules & Definitions is devoted exclusively to Modula-2. It is a shareware magazine that can be downloaded from CompuServe and BIX. Readers are expected to pay $9.95 annually; a paper subscription is available for $19.95.
Extract: Oberon
Oberon
Any report on the status of Modula-2 would be incomplete without a discussion of Oberon and Modula-3, which have lately begun to receive as much attention as Modula-2 itself. (In fact, the theme of the Second international Modula-2 Conference is "Modula-2 and Beyond," with an emphasis on Oberon and Modula-3.)
Oberon, another Wirth-designed language, simultaneously simplifies Modula-2 (by dropping variant records, opaque types, enumeration types, subrange types, and the FOR statement, among other features) and adds extensions for object-oriented programming. In typical Wirth fashion, the added features (principally "type extension") are simpler than the OOP extensions of Turbo Pascal and similar languages.
Incidentally, the name "Oberon" refers not only to the language, but also to the operating system developed for Wirth's own Ceres workstations. The Oberon operating system, like the Oberon language, is designed to offer state-of-the art functionality without complexity.
Getting information on Oberon used to require a trip to the local college library to obtain journal articles. The first book on Oberon recently appeared, however. The Oberon System: User Guide and Programmer's Manual was written by Martin Reiser, who worked with Wirth on the Oberon system. Raiser's book clears up at least one mystery surrounding Oberon -- the origin of the language's name. According to Reiser, "the project was whimsically christened Oberon by Wirth who was fascinated by the accuracy and reliability of the space probe Voyager which passed the moon Oberon of planet Uranus at the time of conception of the new project."
Reiser's book describes the Oberon system -- user interface, editor, compiler, file system, and so forth -- from both the user's and the application programmer's viewpoints. Reiser doesn't cover the Oberon language, however. That task is left to a forthcoming book (coauthored by Wirth) titled Programming in Oberon: Steps beyond Pascal and Modula. Unfortunately, this book won't be available until mid-1992. For a discussion of design issues faced by the Oberon team, we'll have to wait for The Oberon Project, a 1993 book by Wirth and Jurg Gutknecht, his collaborator on the Oberon project. Both books will be published by Addison-Wesley in conjunction with the ACM Press.
Public-domain versions of the Oberon system are available for the Macintosh and for Sun Sparcstations via anonymous FTP from neptune.ethz.ch (129.132.101.33). For more information about Oberon, see "Oberon" by Dick Pountain in Byte, March 1991.
Incidentally, Wirth isn't resting on his laurels; rumor has it that he's already at work on Oberon- 2
Extract: Modula-3
Modula-3
Modula-3 was designed jointly by groups at DEC's Systems Research Center and the (now defunct) Olivetti Research Center in an attempt to create a language safer, yet more powerful than Modula-2. Modula-3 has a different type system than Modula-2 and provides improved safety from runtime errors. It also adds several new features, including garbage collection, exception handling, threads (lightweight processes), and support for object-oriented programming.
The design of Modula-3 began in 1986; the first description of the language was published in 1988. Since then, the language has continued to evolve. After one final set of changes last winter (during which a generic facility was added), the language was finalized.
The first book on Modula-3 is Systems Programming in Modula-3, a collection of papers -- including the official language report -- written by the people who designed and implemented the language. A second book, Programming in Modula-3, is due out later this year. The author is Sam Harbison, who wrote about Modula-3 in the November 1990 issue of Byte (and who, oddly enough, is coauthor of the best-selling C: A Reference Manual). Programming in Modula-3 will be the first complete tutorial and reference for the language. Both books are published by Prentice-Hall.
If you're interested in Modula-3, write to DEC's Systems Research Center and ask for Research Reports 52 and 53. Contact Harbison's company, Pine Creek Software, to receive a free Modula-3 newsletter. If you have access to Usenet, check out the comp.lang.modula3 newsgroup.
A Modula-3 compiler for Unix is available by anonymous FTP from gatekeeper.dec.com (16.1.0.2); the directory is /pub/DEC/Modula-3.
in [ACM] Proceedings of 17th ACM Annual Computer Science Conference : Computing trends in the 1990's Louisville, Kentucky, United States 1989 view details
Pascal, 1968-1972
Freed from the constraining influence of a working group's consensus, Wirth developped the language Pascal in Zurich. The basis was Algol-W and the desire to have a language that would satisfy the requirements of system design (compilers, operating systems, etc.). Also, there was to be a basis of clear concepts and structures, definable axiomatically and independently of any particular computer, as the language was to be suitable also for teaching in an academic environment. Pascal has satisfied these requirements; it is today one of the most widely used languages in computer science education. The first Pascal compiler was designed in Zurich for the CDC 6000 computer family, and it became operational in 1970. Already in 1972 Pascal was used in introductory programming courses. Extract: 0. Introduction
0. Introduction
Many times I have been asked how one "invents" a programming language. One cannot really tell, but it certainly is a matter of experience with the subject of programming, and of careful deliberation. Sometimes I answered: "Like one designs an airplane. One must identify a number of necessary building blocks and materials, and then assemble and combine them properly to a functioning whole". This answer may not be entirely satisfactory, but at least in both cases the result either flies or crashes.
Programming languages were one of the first topics that established computing science as a discipline with its own identity. The topic belonged neither to mathematics nor to electrical engineering. It was Algol 60 that introduced rigor and precision to the subject through its formal definition of syntax. A flurry of activities began in academia to investigate language properties, to find faults and inconsistencies, to devise powerful algorithms of syntax analysis, and to cope with the challenges of compilers. Soon the range of application of Algol was felt to be too narrow. A new, better language was required, perhaps a successor to Algol. Committees were established and hot controversies raged, some protagonists dreaming of grandiose formal systems, some thinking more modestly of a practical improvement. It was this environment that bred Pascal.
Extract: 1. Structured Programming and Pascal
1. Structured Programming and Pascal
Pascal was born in 1969 out of an act of liberation [0]. In more than one sense. Confronted with the duty to teach programming, I had been faced with the dire options of Fortran and Algol. The former did not appeal to my taste as a scientist, the latter not to those of the practical engineer. I liberated myself from this jail by designing Pascal, convinced that an elegant style and an effective implementation were not mutually exclusive. I felt strongly -- and still do -- that a language used in teaching must display some style, elegance, consistency, while at the same time also reflecting the needs (but not necessarily bad habits) of practice. I wanted to design a language for both my classroom and my "software factory".
The second alluded liberation was from the design constraint imposed by committee work. In 1966, Algol W [1] had been a compromise bowing to many divergent opinions and requests from both an Algol committee and an Algol community. Surely, many of them were inspiring and beneficial, but others were incompatible and hindering. Some members had high ambitions of creating a language with novel features whose consequences were to be the subject of further research, whereas I had been brought up as an engineer feeling uneasy with proposals whose realization was still the subject of speculation. I wanted to have at least a concrete idea of how a construct was to be represented on available computers, and these, let me add, were rather ill-suited for any feature not already present in Fortran.
The general idea dominating the design of Pascal was to provide a language appealing to systematic thinking, mirroring conventional mathematical notation, satisfying the needs of practical programming, and encouraging a structured approach. The rules governing the language should be intuitive and simple, and freely combinable. For example, if x+y stands for an expression, x+y should be usable as a sub expression, in assignments, as procedure parameter, or as index. For example, if a widely established convention interprets x-y-z to mean (x-y)-z, we should not redefine this to denote x-(y-z). Or if x=y is used for centuries to denote equality of x and y, we should refrain from the arrogance of replacing it by x==y. Clearly, Pascal was to build up on the notational grounds established by mathematics and Algol. Pascal and its successors were therefore called Algol-like.
Today, it is hard to imagine the circumstances prevailing in the 1960s. We must recall that the computing community was strictly split into two professional camps. The scientists and engineers used Fortran for their programming large-scale, word-oriented, binary computers, wheres the business community used Cobol for their smaller, character-oriented, decimal machines. System programmers were labouring within computer companies using proprietary machine-code assemblers. There were attempts to unite the two worlds, such as the highly innovative Burroughs B-5000 computer, or IBM's programming language PL/I. Both were ill-fated and devoured considerable budgets. Pascal was another such attempt, although less ambitious and without budget or industrial support. It applied the idea of recursively defined structures not only to executable statements, but also to data types. As elements, it adopted arrays (vectors, matrices) from Fortran and Algol, as well as records and files from Cobol. It allowed them to be freely combined and nested.
The other fact about the 1960s that is difficult to imagine today is the scarcity of computing resources. Computers with more than 8K of memory words and less than 10us for the execution of an instruction were called super-computers. No wonder it was mandatory for the compiler of a new language to generate at least equally dense and efficient code as its Fortran competitor. Every instruction counted, and, for example, generating sophisticated subroutine calls catering to hardly ever used recursion was considered an academic pastime. Index checking at run-time was judged to be a superfluous luxury. In this context, it was hard if not hopeless to compete against highly optimized Fortran compilers.
Yet, computing power grew with each year, and with it the demands on software and on programmers. Repeated failures and blunders of industrial products revealed the inherent difficulties of intellectually mastering the ever increasing complexity of the new artefacts. The only solution lay in structuring programs, to let the programmer ignore the internal details of the pieces when assembling them into a larger whole. This school of thought was called Structured Programming [2], and Pascal was designed explicitly to support this discipline. Its foundations reached far deeper than simply "programming without go to statements" as some people believed. It is more closely related to the top-down approach to problem solving.
Besides structured statements, the concept of data types characterized Pascal profoundly. It implies that every object, be it a constant, a variable, a function, or a parameter has a type. Data typing introduces redundancy, and this redundancy can be used to detect inconsistencies, that is, errors. If the type of all objects can be determined by merely reading the program text, that is, without executing the program, then the type is called static, and checking can be performed by the compiler. Surely errors detected by the compiler are harmless and cheap compared to those detected during program execution in the field, by the customer. Thus static typing became an important concept in software engineering, the discipline emerging in the 1970s coping with the construction of large software complexes.
A particularly successful concept was the integration of pointers into static typing as suggested by Hoare [3] and adopted in Pascal. The simple idea is to attribute a fixed type not only with every data object, but also with every pointer, such that a pointer variable can at any time only refer to an object of the type to which it is bound (or to none at all). Programming with pointers, then called list processing, notoriously fraught with pitfalls, now became as safe as programming without pointers.
Yet, Pascal also suffered from certain deficiencies, more or less significant depending on personal perception and application. One of them had its origin in a too dogmatic interpretation of static typing, requiring that the type of every procedure parameter be known at compile-time. Since this included index bounds in the case of array types, the frequently convenient dynamic arrays were excluded. In hindsight, this rigidity was silly and kept many Algolites from adopting Pascal. Arrays are typically passed by a reference, and for dynamic arrays only the array bounds must be added to this information. The limited additional complexity of the compiler would certainly have been outweighed by the gained language flexibility.
Extract: 2. Modular Programming and Modula-2
2. Modular Programming and Modula-2
With various defects clearly identified and new challenges in programming emerging, time seemed ripe for a fresh start, for a successor language. The two foremost novel challenges were multiprogramming and information hiding. For me personally, a third, quite practical challenge became an ambition: To create a language adequate for describing entire systems, from storage allocator to document editor, from process manager to compiler, and from display driver to graphics editor. I perceived that many problems in software development stemmed from the mixing of parts written in different languages. The challenge became real within our project to design and build the workstation Lilith in 1978 [6]. Its precursor was Xerox PARC's pioneering workstation Alto [5]. The Alto's software was mostly written in Mesa; Lilith's software entirely in Modula-2. It would have been prohibitive to implement more than one language. Evidently, Modula was born out of an act of necessity [7].
The cornerstone of Modula-2 was the module construct. Whereas Pascal had served to build monolithic programs, Modula-2 was suitable for systems consisting of a hierarchy of units with properly defined interfaces. Such a unit was called module, and later package in Ada. In short, a module is like a Pascal program with the addition of an explicit interface specification to other modules. This is obtained as follows: Modules are described by two, distinct texts, a definition part and an implementation part. In the former all objects are defined which are visible by other modules, typically types and procedure signatures. They are said to be exported. The latter part contains all local, hidden objects, and the bodies of procedures, i.e. their implementations. Hence the term information hiding. The heading contains lists of identifiers to be imported from other modules.
[...]
This key feature catered for the urgent demands for programming in teams. Now it became possible to determine jointly a modular decomposition of the task and to agree on the interfaces of the planned system. Thereafter, the team members could proceed independently in implementing the parts assigned to them. This style is called modular programming. The concept of module arose earlier in work by Parnas and, in conjunction with multi-programming by Hoare and Brinch Hansen, where the module construct was called a monitor [8, 9]. The module was also present in a concrete form in Mesa, which in Modula was simplified and generalized.
The module construct would, however, have remained of mostly academic interest only, were it not for the technique of separate compilation, which was from its inception combined with the module. By separate compilation we understand that (1) full type checking is performed by the compiler not only within a module, but also across module interfaces, and (2) that compatibility (or version) checking between modules to be joined is achieved by a simple key comparison when the modules are linked and loaded. We refrain from expounding technical details, but emphasize that this is a crucial requirement for the design of complex systems, yet still poorly handled by most systems of commercial provenience.
Besides the successful feature of the module with separate compilation, the language also had some drawbacks. Surely, the evident deficiencies of Pascal had been mended. The syntax was now unambiguous, type specifications complete, and the set of basic data types adequately comprehensive. But as a result, the language, and with it the compiler, had become relatively large and bulky, although still orders of magnitude less so than comparable commercial ventures. The goal of making the language powerful enough to describe entire systems was achieved by introducing certain low-level features, mostly for accessing particular machine resources (such as I/O device registers) and for breaching, overriding the rigid type system. Such facilities, like e.g. type casting, are inherently contrary to the notion of abstraction by high-level language, and should be avoided. They were called loopholes, because they allow to break the rules imposed by the abstraction. But sometimes these rules appear as too rigid, and use of a loophole becomes unavoidable. The dilemma was resolved through the module facility which would allow to confine the use of such "naughty" tricks to specific, low-level server modules. It turned out that this was a naive view of the nature of programmers. The lesson: If you introduce a feature that can be abused, then it will be abused, and frequently so! Extract: 3 Object-oriented Programming and Oberon
3 Object-oriented Programming and Oberon
The advent of the personal computer around 1980 changed the way in which computers were used dramatically. Direct, immediate interaction replaced remote access and batch processing. User interfaces became an important issue. They were shaped by the novel mouse and the high-resolution display, replacing the 24 lines by 80 character screens. They established the paradigm of windows and multi-tasking. It had been pioneered by the Xerox Alto workstation, and in particular the Smalltalk project [10]. Along with it came the object-oriented style of programming. Object-oriented design emerged from the specialized subject of discrete event simulation and its language Simula [11], whose authors Dahl and Nygaard had realised that its concepts had a scope far beyond simulation. Some of the proponents of object-oriented programming even suggested that all of programming should be converted to the new view of the world.
We felt that a revolution was undesirable to cure the lamented ills of the software profession, and we considered evolution as the wiser approach. Tempted to design a version of Modula stripped down to essentials, we also wanted to identify those features that were indispensable to encompass object-orientation. Our findings were revealing: A single feature would suffice, all other ingredients were already present in Modula. The one feature to be added had to allow the construction of data type hierarchies, called sub-classing in Smalltalk. Our own term was type extension: The new type adds attributes to those of the old type. Type extension had the welcome side effect of practically eliminating all needs for loopholes.
The absence of loopholes is the acid test for the quality of a language. After all, a language constitues an abstraction, a formal system, determined by a set of consistent rules and axioms. Loopholes serve to break these rules and can be understood only in terms of another, underlying system, an implementation. The principal purpose of a language, however, is to shield the programmer from implementation details, and to let him think exclusively in terms of the higher-level abstraction. Hence, a language should be fully defined without reference to any implementation or computer.
The language Oberon was born out of the ambition to simplify language to the essentials. The result turned out to be a considerably more powerful and more elegant language than its predecessors The defining report of Pascal required 30 pages, that of Modula grew to 45 pages, Oberon's could do with 16 [12]. Not surprisingly, implementations profited substantially from this achievement after 25 years of experience in language design, from a continuous evolution.
One of the simplifications was the reunification of the definition and implementation parts of modules. An Oberon module is again defined by a single text. Its heading contains a single list of server modules (rather than of individual, imported objects). Declarations of objects that are to be accessible in client modules are specially marked. Unmarked, local objects remain hidden. From a didactic point of view this reunification may be regretted, because ideally definition parts are designed among team members and form contracts between them, whereas implementation parts can thereafter be designed by individual members without regard for the others, as long as the definition part remains untouched. However, the proliferation of files and the burden to keep corresponding parts consistent was considered a drawback. Moreover, reunification eliminated the compiler's duty to check for consistency between definition and implementation parts. Also, a definition part can readily be extracted from the module text by a simple tool. Extract: 4 Conclusions and Outlook
4 Conclusions and Outlook
In his article about Oberon, M. Franz wrote in [13]: "The world will remember Niklaus Wirth primarily as 'that language guy' and associate his name with Pascal." His observation is accurate; also the invitation to speak at this Conference hinted that I should concentrate on Pascal. My disobedient digression stems from my conviction that its successors Modula and Oberon are much more mature and refined designs than Pascal. They form a family, and each descendant profited from experiences with its ancestors. At the end, the time span was 25 years.
Why, then, did Pascal capture all the attention, and Modula and Oberon got so little? Again I quote Franz: "This was, of course, partially of Wirth's own making". He continues: "He refrained from ... names such as Pascal-2, Pascal+, Pascal 2000, but instead opted for Modula and Oberon". Again Franz is right. To my defense I can plead that Pascal-2 and Pascal+ had already been taken by others for their own extensions of Pascal, and that I felt that these names would have been misleading for languages that were, although similar, syntactically distinct from Pascal. I emphasized progress rather than continuity, evidently a poor marketing strategy.
But of course the naming is by far not the whole story. For one thing, we were not sufficiently active -- today we would say aggressive -- in making our developments widely known. Instead of asking what went wrong with Modula and Oberon, however, let us rather ask what went right with Pascal. In my own perception, the following factors were decisive:
1. Pascal, incorporating the concepts of structured programming, was sufficiently different and progressive from Fortran to make a switch worth while. Particularly so in America, where Algol had remained virtually unknown.
2. In the early 1970s, an organization of users (Pascal User Group PUG) was formed and helped to make Pascal widely known and available. It also published a Newsletter.
3. Pascal was ported just in time for the first micro computers (UCSD) [14], and thereby reached a large population of newcomers unconstrained by engrained habits and legacy code.
4. Pascal was picked up by start-up companies. Borland's Pascal implementation was the first compiler to be available for less than $50, turning it into a household article.
5. UCSD as well as Borland properly integrated the compiler into a complete development tool, including a program editor, a file system, and a debugging aid. This made Pascal highly attractive to schools and to beginners. It changed the manner in which programs were "written". A fast write-compile-test-correct cycle and interactivity were the new attractions.
6. Shortly after the initial spread, an ever growing number of text books on programming in Pascal appeared. They were as important as the compiler for Pascal's popularity in schools and universities. Text books and software entered a symbiotic partnership.
Perhaps it is worth observing that this chain reaction started around 1977, fully seven years after Pascal had been published and implemented on a CDC mainframe computer. Meanwhile, Pascal had been ported to numerous other large computers, but remained largely within universities. This porting effort was significantly facilitated by our project resulting in the Pascal P-compiler generating P-code, the predecessor of the later M-code (for Modula) and Java byte-code.
In contrast to Pascal, Modula and Oberon did not appear at a time when computing reached new segments of the population. The module concept was not perceived in teaching as sufficiently significant to warrant a change to a new, albeit similar language. Text books had been selected, investments in learning had been made, time was not ripe for a change. Industry did not exactly embrace Modula either, with a few exceptions, mainly in Britain. A more palatable solution was to extend Pascal, retaining upward compatibility and old shortcomings. And there appeared competition in the form of C++ and Ada with powerful industrial backing.
Oberon fared even worse. It was virtually ignored by industry. This is astounding, as not only the elegant and powerful language was presented in 1988, but also a compact and fast compiler in 1990, along with a modern, flexible development environment for workstations, complete with window system, network, document and graphics editor, neatly fitting into about 200 Kbytes of memory, the compiler alone taking less than 50 Kbytes. The entire system was fully described in a single, comprehensive book, including its source code [15]. It carried the proof that such a system could be built using only a small fraction of manpower typically allotted to such endeavors, if proper methods and tools were employed.
One is tempted to rationalize this history with recent, deep changes in the computing field. Computing resources are no longer at a premium, memory is counted in megabytes rather than kilobytes as 15 years ago, instruction cycles in nanoseconds instead of microseconds, and clock frequencies in gigahertz instead of megahertz. The incentive to economize has dwindled alarmingly. The only scarce resource is manpower, competent manpower. Industry has difficulties even in finding good C-programmers, those of finding Oberon programmers are insurmountable. So how could one reasonably expect companies to adopt Oberon?
We recognize a deadlock: The adoption of new tools and methods is impracticable, yet the retention of the old ones implies stagnation. Are we therefore condemned to eternally produce an ever growing mountain of software of ever growing complexity, software that nobody fully understands, although everybody is well aware of its defects and deficiencies? In order to avert this highly unpleasant vision of the future, some fresh starts will have to undertaken now and then. They require the courage to discard and abandon, to select simplicity and transparency as design goals rather than complexity and obscure sophistication.
In the field of programming languages two fresh starts have been attempted recently. I refer to Java and C#. Both tend to restrict rather than augment the number of features, trying to suggest a certain programming discipline. Hence they move in the right direction. This is encouraging. But there remains still a long way to reach Pascal, and longer even to Oberon.
in Software Pioneers: Contributions to Software Engineering, Bonn, 28-29. 6. 2001 eds Broy, Manfred and Denert, Ernst Springer 2002 view details
in Software Pioneers: Contributions to Software Engineering, Bonn, 28-29. 6. 2001 eds Broy, Manfred and Denert, Ernst Springer 2002 view details
Resources
Modula 2 for DECs
"- Homepage at Newcastle
external link - book