Programmers who prefer strongly typed, structured programming are frustrated by languages that are either too simplistic, such as Pascal, or too costly and complex, like Ada. They are looking for a language that is "just right," to quote Goldilocks--a language that supports long-term reliability and maintainability, but also has enough modern, practical features to handle large problems efficiently. A language, in fact, like Modula-3.

Modula-3 was developed by resear-chers at DEC's Systems Research Center (SRC) and the Olivetti Research Center in 1989. It borrows from two evolutionary lines of programming languages: an academic line, represented by Niklaus Wirth's Pascal, Modula-2, and Oberon languages; and an industrial research line, represented by the Mesa, Cedar, and Euclid languages from the Xerox PARC (Palo Alto Research Center). Its immediate parent is Modula-2+, an extension of Modula-2 developed at SRC in the early 1980s and used in its research systems. In 1986, Maurice Wilkes, who had developed the first practical electronic stored-program computer at Cambridge 37 years earlier, sparked an effort to "clean up" Modula-2+. With Niklaus Wirth's blessing, this became a design for a new language, Modula-3. The original language report was issued in 1988, with minor revisions in 1989 and 1990.

Modula-3 emphasizes safety and maintainability and is gaining important converts outside DEC. The computer-science laboratory at Xerox PARC has adopted the language for its research software, and the University of Cambridge in England is now teaching Modula-3 to its computer-science students.

The designers had several goals:

• To provide the abstractions necessary to structure large systems programs: modules, objects, threads, and generics.
• To provide the mechanisms for making programs safe and robust: strong type checking, exceptions, isolation of unsafe code, and automatic garbage collection.
• To keep the language simple. Features were chosen that had been proven in other languages, but compatibility with older languages wasn't important.

Before discussing language features, I should note that DEC provides free-of-charge a high-quality Modula-3 compiler, called SRC Modula-3, which is available in source form on the Inter-net (gatekeeper.dec.com in directory /pub/DEC/Modula-3). SRC Modula-3 runs on most UNIX workstations and is in use at many universities, companies, and research laboratories. SRC Modula-3 also includes a rich run-time library, including UNIX and X Window interfaces, and an object-oriented X Window programming system called "Trestle."

In the rest of this article I'll illustrate the features of Modula-3 by looking at a realistic example--an input line parser modeled on the input facilities of the Awk language. In most programming languages, dealing with free-form numeric and text input is a hassle. Even C, which has a pretty good I/O library, forces you to descend into the mysteries of scanf to read numbers. In Awk, input is effortless: Input lines are automatically broken into whitespace-delimited fields that are referred to by number and can be used as text or in numeric expressions. The goal is to write a module to provide Awk-like input for Modula-3.

Modula-3 supports both object-oriented and traditional programming models. In this case, our input-parser interface uses an object model in which a client creates an object called a "field list" and then uses it to read fields from input lines. The steps to follow are:

1. Create a field-list object, fl.
2. Read a line into fl by calling fl.getLine().
3. Get the value of the nth field as a string with fl.text(n). Get the value of the nth field as a number with fl.number(n).
4. When finished with the current line, go back to step 2.

Error handling in Modula-3 programs is accomplished with exceptions. By using exceptions, you don't have to check return values on every procedure call--something so tedious that most C programmers don't bother. The FieldList interface exports the exception Error, which is raised by certain methods in response to an error. A typical client error would be trying to read the 12th field in a line with only 11 fields.

When an exception is raised, it propagates out of the current procedure into the caller. If it is not handled there, it continues to propagate outward until a handler is found. If no procedure handles the exception, the Modula-3 runtime system terminates the program with a suitable message. Exceptions are part of the specification of procedures in Modula-3; every procedure or method that can raise an exception must list that exception in a RAISES clause. Note the RAISES {Error} clauses in the method declarations in FieldList.

The Sum program deals with exceptions in two ways: by handling some exceptions and ignoring others. The outer loop in the main program is surrounded by a TRY..EXCEPT..END block, which handles any exceptions raised by procedures inside the loop. This particular exception handler simply prints a message and allows the program to finish normally. One message is provided for the end-of-file exception, and another message for all other exceptions.

An alternative to providing an exception handler can be seen in the Put procedure, which includes the pragma <*FATAL Wr.Failure, Thread.Alerted*>. Because there is no exception handler or RAISES clause in the Put procedure, it is a checked run-time error to raise any exception within that procedure. But the compiler knows from the Wr interface that Wr.PutText can raise the Wr.Failure and Thread.Alerted exceptions, so it will warn the programmer of the potential run-time error. The FATAL pragma says, in effect, that it's OK to halt the program if these exceptions are raised within Put, and so the warning message should be suppressed.

You'll notice that the FieldList interface uses the built-in string type TEXT, but the module also uses arrays of characters. Strings (type TEXT) are extremely convenient in Modula-3. They are dynamically allocated and can be of any length. Once created, a TEXT value cannot be changed, so strings have value semantics--no one can change the value of a string you are holding. The built-in interface Text provides basic construction and testing operations on strings, but no searching functions.

For intense character manipulation, you can also convert a TEXT value to an array of characters, as in the getLine procedure. In most languages, arrays of characters are difficult to deal with because they must have a fixed compile-time size. Modula-3 provides a compromise: Although stack-based arrays must have a fixed size, dynamic arrays can be allocated with a run-time size. For example, the FieldList.T object contains a field declared as chars: REF ARRAY OF CHAR. This is a reference (pointer) to an open (unbounded) array of characters. In getLine, the self.chars and Text.SetChars statements store in self.chars a reference to an array of Linelength characters and then fill that array with the characters from string text. Unlike C and C++, dynamic arrays in Modula-3 have subscript bounds checking built in. The AddDescriptor procedure is a good example of how to use dynamic arrays, including how to grow them when necessary. All open arrays are 0 based, and the function NUMBER(a) can be used to determine the number of elements in any array a. SUBARRAY can be used to designate a contiguous set of elements in an array.

Multitasking with threads is a useful structuring tool in many applications. Threads are independent control points, or miniprocesses, that execute within your program's address space. Each thread has its own stack but shares access to global variables and the heap. It is not unreasonable for a large program to have dozens of threads performing various activities. Most new operating systems, including Windows NT, OS/2, and Mach (OSF/1) provide built-in support for preemptive multitasking with threads. So does Modula-3, even on operating systems that don't provide thread support directly.

Coupled with the benefits of threads is the danger of race conditions, which occurs when two threads attempt to modify a shared data structure at the same time. One thread may be suspended after partially modifying the data structure, leaving the data structure in an inconsistent state. A second thread might then trip over the inconsistency. The solution is to synchronize access by "locking" the data structure while it is being used, using a mutual-exclusion semaphore ("mutex" for short). Each thread locks the mutex while using the data structure; if a thread already has the mutex locked, the second thread will be forced to wait.

The implementation of FieldList does not use threads, but it is "thread friendly." That means FieldList provides the necessary synchronization so that clients can be multithreaded without worrying about race conditions. In Modula-3, mutexes are provided by the built-in object type MUTEX. You can store MUTEX objects in your data structures or, as in FieldList, you can simply make your object type a descendant of MUTEX, effectively turning your object into a mutex itself. In using mutexes, there is a special block statement, LOCK mu DO..END, so that you can't forget to unlock a locked mutex. The LOCK statement locks the mutex mu while the enclosed statements are executed, and ensures that the mutex is properly unlocked when the statements terminate, even if they are terminated by an exception or RETURN within the LOCK statement. Throughout the FieldList module, you will see LOCK statements surrounding access to field lists.

What is Modula-3's most important advantage? Without a doubt, it is safety. While the exception mechanism encourages the creation of robust programs, the Modula-3 language is inherently safe and does not require special attention by the programmer.

Some of the hardest bugs to find are those that cause a valid source-code state-ment to execute incorrectly at run time. For example, the C statement s->a[i]=v could fail for many reasons: The pointer s might be null or might point to unallocated storage; the value of i might be too large to use as an index into the array; or v might contain an out-of-bounds value because it was never initialized. ANSI C lists 97 ways in which a C program's behavior might be unpredictable at compile time or run time. Even Ada, usually considered a "safe" language, does not protect you against dangling pointers or uninitialized variables.

Modula-3 guarantees that all run-time assumptions remain valid. It will initialize your variables (if you don't) to ensure that they always contain values of their declared types. It checks pointer conversions at run time for type safety, and does not permit you to deallocate storage directly. Some features found in other languages, such as taking the address of a local variable, are prohibited because they are unsafe and because detecting their misuse at run time would be too costly. These checks and rules avoid many bugs and catch the remaining ones quickly, before their effects can spread. In my experience, the error messages provided by the Modula-3 run-time system are so good that I rarely have to use the debugger to locate the cause of an error.

Of course, systems programmers cannot restrict themselves to "safe" programming at all times. Languages that are too strict about safety may not be usable for writing low-level code, like storage allocators. Therefore, if you declare a module UNSAFE, Modula-3 gives you access to a variety of unsafe but practical features, such as unrestricted type conversions (via function LOOPHOLE), address arithmetic, and the DISPOSE procedure to deallocate storage. The compiler cannot ensure the safety of UNSAFE modules, but at least it makes you isolate and identify unsafe code.

A programming language without good tools is almost useless. As previously mentioned, SRC Modula-3 includes a rich run-time library, including UNIX and X Windows interfaces and an object-oriented X Windows programming system. Program rebuilding is easy in SRC Modula-3 using the supplied m3 driver program. The command line m3 --o Progmake *.i3 *.m3 will cause the driver to inspect all the interfaces (*.i3) and modules (*.m3) in the current directory; compute dependencies based on IMPORT and EXPORT declarations; determine which source files have changed and which interfaces are out of date; recompile anything that needs to be recompiled; and link program Prog. For more complex programs, the m3make utility allows you to describe your program abstractly without computing file dependencies by hand. You can also add arbitrary make-like dependencies to your m3makefile.

Modula-3 brings together the long-term maintainability of Ada, the simplicity of Pascal, and the modern object-oriented programming facilities of C++. The result is a clean language that makes it easy to write robust and maintainable programs.

Harbison, Samuel P. Modula-3. Englewood Cliffs, NJ: Prentice Hall, 1992.

Modula-3 News. Pittsburgh, PA: Pine Creek Software.

Nelson, Greg. Systems Programming with Modula-3. Englewood Cliffs, NJ: Prentice Hall, 1991.

Usenet News Group: comp.lang.modula3.

                       Modula-3   C++    Ada    Modula-2   Turbo    C
                                                         Pascal 5.5

    Generics                yes   no*    yes        no       no     no
    Exceptions              yes   no*    yes        no*      no     no
    Threads                 yes   no     yes        no       no     no
    OOP                     yes   yes    no*        no       yes    no
    User-defined operators  no    yes    yes        no       no     no
    Interfaces              yes   no     yes        yes      yes    no
    Strong typing           yes   some   yes        yes      yes    no
    Run-time safety checks  yes   no     yes        yes      yes    no
    Isolate unsafe features yes   no     yes        yes      no     no
    Procedure types         yes   yes    no         yes      yes    yes
    Case-sensitive names    yes   yes    no         yes      no     yes
    Garbage collection      yes   no     no         no       no     no
    *These features are coming in new versions of the language.

                  Modula-3                           Modula-2

Declarations      Names visible throughout scope     Must declare names
                  can initialize variables.          before use;
                                                     cannot initialize
                                                     variables.

Types             Structural equivalence.            Name equivalence.

Expressions       C-like precedence; A.B             Pascal-like precedence;
                  shorthand for A^.B, and so on.     no shorthand for A^.B.

Statements        FOR loop declares its own          FOR-loop variable must 
                  variable.                          be declared by        
                                                     programmer.

Pointers          Syntax: REF T or REFANY;           Syntax: POINTER TO T; 
                  run-time type testing and          no run-time type  
                  garbage collection.                testing; manual
                                                     deallocation of
                                                     storage.

Built-in          MIN, MAX apply to value pairs,     MIN, MAX apply to
functions         yield smaller and larger values.   types, yield
                                                     smallest and largest
                                                     elements.

Strings           Variable length, read-only;        Fixed maximum length, 
                  different from ARRAY OF CHAR.      read/write, same as
                                                     ARRAY OF CHAR.

Isolation of      UNSAFE keyword reveals             Most unsafe features
unsafe features   unsafe features of language        provided by SYSTEM
                                                     interface.

OOP, generics,    Supported.                         Not currently 
exceptions                                           available.

MODULE Hello EXPORTS Main;   IMPORT Wr, Stdio;
BEGIN
    Wr. PutText(Stdio.stdout, "Hello, World!\n");
    Wr. Close(Stdio.stdout);
END Hello.

Method:
    isANumber (n: FieldNumber) : BOOLEAN RAISES {Error}
Procedure:
    isANumber (self: T; n: FieldNumber) : BOOLEAN RAISES {Error}

PROCEDURE GetReal(ptr: REFANY) : REAL = (* Return ptr^ as a REAL *)
    VAR realPtr:= NARROW(ptr, REF REAL);
    BEGIN
        RETURN realPtr^;
    END GetReal;

PROCEDURE GetReal2(ptr: REFANY) : REAL = (* Return prt^, or 0.0*)
    BEGIN
        IF ptr # NIL AND ISTYPE(ptr, REF REAL) THEN
            RETURN NARROW(ptr, REF REAL)^;
        ELSE
            RETURN 0.0; (* ptr is not what we expected *)
        END;
     END GetReal2;

INTERFACE FieldList;
(* Breaks text lines into a list of fields which can be treated
 as text or numbers. This interface is thread-safe. *)
IMPORT Rd, Wr, Thread;
EXCEPTION Error;
CONST 
    DefaultWS = SET OF CHAR{' ', '\t', '\n', '\f', ','};
    Zero: NumberType = 0.0D0;
TYPE 
    FieldNumber = [0..LAST(INTEGER)]; (* Fields are numbered 0, 1, ... *)
    NumberType = LONGREAL; (* Type of field as floating-point number *)
    T <: Public; (* A field list *)
    Public = MUTEX OBJECT (* The visible part of a field list *)
    METHODS
        init(ws := DefaultWS): T; (* Define whitespace characters. *)
        getLine(rd: Rd.T := NIL) 
           RAISES {Rd.EndOfFile, Rd.Failure, Thread.Alerted};
           (* Reads a line and breaks it into fields that can be 
                   examined by other methods. Default reader is Stdio.stdin. 
        numberOfFields(): CARDINAL; 
           (* The number of fields in the last-read line. *)
        line(): TEXT; (* The entire line. *)
        isANumber(n: FieldNumber): BOOLEAN RAISES {Error};
           (* Is the field some number (either integer or real)? *)
        number(n: FieldNumber): NumberType RAISES {Error};
           (* The field's floating-poinnt value *)
        text(n: FieldNumber): TEXT RAISES {Error}; (* The field's text value *)
    END;
END FieldList.

Copyright © 1994, Dr. Dobb's Journal