Modula-3 is a programming language conceived as a successor to an upgraded version of Modula-2 known as Modula-2+. It has been influential in research circles (influencing the designs of languages such as Java, C#, Python and Nim), but it has not been adopted widely in industry. It was designed by Luca Cardelli, James Donahue, Lucille Glassman, Mick Jordan (before at the Olivetti Software Technology Laboratory), Bill Kalsow and Greg Nelson at the Digital Equipment Corporation (DEC) Systems Research Center (SRC) and the Olivetti Research Center (ORC) in the late 1980s.
Modula-3's main features are modularity, simplicity and safety while preserving the power of a systems-programming language. Modula-3 aimed to continue the Pascal tradition of type safety, while introducing new constructs for practical real-world programming. In particular Modula-3 added support for generic programming (similar to templates), multithreading, exception handling, garbage collection, object-oriented programming, partial revelation, and explicit marking of unsafe code. The design goal of Modula-3 was a language that implements the most important features of modern imperative programming languages in quite basic forms. Thus allegedly dangerous and complicating features such as multiple inheritance and operator overloading were omitted.
Historical development The Modula-3 project started in November 1986 when Maurice Wilkes wrote to Niklaus Wirth with some ideas for a new version of Modula. Wilkes had been working at DEC just prior to this point, and had returned to England and joined Olivetti's Research Strategy Board. Wirth had already moved on to Oberon, but had no problems with Wilkes's team continuing development under the Modula name. The language definition was completed in August 1988, and an updated version in January 1989. Compilers from DEC and Olivetti soon followed, and 3rd party implementations after that.
Its design was heavily influenced by work on the Modula-2+ language in use at SRC and at the Acorn Computers Research Center (ARC, later ORC when Olivetti acquired Acorn) at the time, which was the language in which the operating system for the DEC Firefly multiprocessor VAX workstation was written and in which the Acorn Compiler for Acorn C and Modula Execution Library (CAMEL) at ARC for the ARX operating system project of ARM based Acorn Archimedes range of computers was written. As the revised Modula-3 Report states, the language was influenced by other languages such as Mesa, Cedar, Object Pascal, Oberon and Euclid.Modula-3 report (revised) Luca Cardelli, James Donahue, Lucille Glassman, Mick Jordan, Bill Kalsow, Greg Nelson. DEC Systems Research Center (SRC) Research Report 52 (November 1989)
During the 1990s, Modula-3 gained considerable currency as a teaching language, but it was never widely adopted for industrial use. Contributing to this may have been the demise of DEC, a key Modula-3 supporter (especially when it ceased to maintain it effectively before DEC was sold to Compaq in 1998). In any case, in spite of Modula-3's simplicity and power, it appears that there was little demand for a procedural compiled language with restricted implementation of object-oriented programming. For a time, a commercial compiler named CM3 maintained by one of the chief implementors prior at DEC SRC who was hired before DEC being sold to Compaq, an integrated development environment (IDE) named Reactor and an extensible Java virtual machine (licensed in binary code and source code formats and buildable with Reactor) were offered by Critical Mass, Inc., but that company ceased active operations in 2000 and gave some of the source code of its products to Software Solutions GmbH. Modula-3 is now taught in universities mostly in comparative programming language courses, and its textbooks are out of print. Essentially the only corporate supporter of Modula-3 is , which inherited the sources from Critical Mass and has since made several releases of the CM3 system in source and binary code. The Reactor IDE has been open source released after several years it had not, with the new name CM3-IDE. In March 2002, also took over the repository of another active Modula-3 distribution, PM3, until then maintained at the École Polytechnique de Montréal but which later continued by the work on HM3 improved over the years later until it was obsoleted.
Syntax
A common example of a language's syntax is the "Hello, World!" program.
MODULE Main; IMPORT IO; BEGIN IO.Put("Hello World\n") END Main.
All programs in Modula-3 have at least a module file, while most also include an interface file that is used by clients to access data from the module. As in some other languages, a Modula-3 program must export a Main module, which can either be a file named Main.m3, or a file can call EXPORT to export the Main module. MODULE Foo EXPORTS Main Module file names are advised to be the same as the name in source code. If they differ, the compiler only emits a warning.
Other conventions in the syntax include naming the exported type of an interface T, since types are usually qualified by their full names, so a type T inside a module named Foo will be named Foo.T. This aids in readability. Another similar convention is naming a public object Public as in the OOP examples below.
Language features
Modularity First and foremost, all compiled units are either INTERFACE or implementation MODULEs, of one flavor or another. An interface compiled unit, starting with the keyword INTERFACE, defines constants, types, variables, exceptions, and procedures. The implementation module, starting with the keyword MODULE, provides the code, and any further constants, types, or variables needed to implement the interface. By default, an implementation module will implement the interface of the same name, but a module may explicitly EXPORT to a module not of the same name. For example, the main program exports an implementation module for the Main interface.
MODULE HelloWorld EXPORTS Main; IMPORT IO; BEGIN IO.Put("Hello World\n") END HelloWorld.
Any compiled unit may IMPORT other interfaces, although circular imports are forbidden. This may be resolved by doing the import from the implementation MODULE. The entities within the imported module may be imported, instead of only the module name, using the FROM Module IMPORT Item [, Item]* syntax:
MODULE HelloWorld EXPORTS Main; FROM IO IMPORT Put; BEGIN Put("Hello World\n") END HelloWorld.
Typically, one only imports the interface, and uses the 'dot' notation to access the items within the interface (similar to accessing the fields within a record). A typical use is to define one data structure (record or object) per interface along with any support procedures. Here the main type will get the name 'T', and one uses as in MyModule.T.
In the event of a name collision between an imported module and other entity within the module, the reserved word AS can be used as in IMPORT CollidingModule AS X;
Safe vs unsafe Some ability is deemed unsafe, where the compiler can no longer guarantee that results will be consistent; for example, when interfacing to the C language. The keyword UNSAFE prefixed in front of INTERFACE or MODULE, may be used to tell the compiler to enable certain low level features of the language. For example, an unsafe operation is bypassing the type system using LOOPHOLE to copy the bits of an integer into a floating point REAL number.
An interface that imports an unsafe module must also be unsafe. A safe interface may be exported by an unsafe implementation module. This is the typical use when interfacing to external libraries, where two interfaces are built: one unsafe, the other safe.
Generics A generic interface and its corresponding generic module, prefix the INTERFACE or MODULE keyword with GENERIC, and take as formal arguments other interfaces. Thus (like C++ templates) one can easily define and use abstract data types, but unlike C++, the granularity is at the module level. An interface is passed to the generic interface and implementation modules as arguments, and the compiler will generate concrete modules.
For example, one could define a GenericStack, then instantiate it with interfaces such as IntegerElem, or RealElem, or even interfaces to Objects, as long as each of those interfaces defines the properties needed by the generic modules.
The bare types INTEGER, or REAL can't be used, because they are not modules, and the system of generics is based on using modules as arguments. By comparison, in a C++ template, a bare type would be used.
FILE: IntegerElem.i3
INTERFACE IntegerElem; CONST Name = "Integer"; TYPE T = INTEGER; PROCEDURE Format(x: T): TEXT; PROCEDURE Scan(txt: TEXT; VAR x: T): BOOLEAN; END IntegerElem.
FILE: GenericStack.ig
GENERIC INTERFACE GenericStack(Element); (* Here Element.T is the type to be stored in the generic stack. *) TYPE T = Public OBJECT; Public = OBJECT METHODS init(): TStack; format(): TEXT; isEmpty(): BOOLEAN; count(): INTEGER; push(elm: Element.T); pop(VAR elem: Element.T): BOOLEAN; END; END GenericStack.
FILE: GenericStack.mg
GENERIC MODULE GenericStack(Element); < ... generic implementation details... > PROCEDURE Format(self: T): TEXT = VAR str: TEXT; BEGIN str := Element.Name & "Stack{"; FOR k := 0 TO self.n -1 DO IF k > 0 THEN str := str & ", "; END; str := str & Element.Format(self.arr[k]); END; str := str & "};"; RETURN str; END Format; < ... more generic implementation details... > END GenericStack.
FILE: IntegerStack.i3
INTERFACE IntegerStack = GenericStack(IntegerElem) END IntegerStack.
FILE: IntegerStack.m3
MODULE IntegerStack = GenericStack(IntegerElem) END IntegerStack.
Traceability Any identifier can be traced back to where it originated, unlike the 'include' feature of other languages. A compiled unit must import identifiers from other compiled units, using an IMPORT statement. Even enumerations make use of the same 'dot' notation as used when accessing a field of a record.
INTERFACE A;
TYPE Color = {Black, Brown, Red, Orange, Yellow, Green, Blue, Violet, Gray, White};
END A; MODULE B;
IMPORT A; FROM A IMPORT Color;
VAR aColor: A.Color; (* Uses the module name as a prefix *) theColor: Color; (* Does not have the module name as a prefix *) anotherColor: A.Color;
BEGIN aColor := A.Color.Brown; theColor := Color.Red; anotherColor := Color.Orange; (* Can't simply use Orange *) END B.
Dynamic allocation Modula-3 supports the allocation of data at runtime. There are two kinds of memory that can be allocated, TRACED and UNTRACED, the difference being whether the garbage collector can see it or not. NEW() is used to allocate data of either of these classes of memory. In an UNSAFE module, DISPOSE is available to free untraced memory.
Object-oriented Object-oriented programming techniques may be used in Modula-3, but their use is not a requirement. Many of the other features provided in Modula-3 (modules, generics) can usually take the place of object-orientation.
Object support is intentionally kept to its simplest terms. An object type (termed a "class" in other object-oriented languages) is introduced with the OBJECT declaration, which has essentially the same syntax as a RECORD declaration, although an object type is a reference type, whereas RECORDs in Modula-3 are not (similar to structs in C). Exported types are usually named T by convention, and create a separate "Public" type to expose the methods and data. For example:
INTERFACE Person;
TYPE T <: Public; Public = OBJECT METHODS getAge(): INTEGER; init(name: TEXT; age: INTEGER): T; END;
END Person. This defines an interface Person with two types, T, and Public, which is defined as an object with two methods, getAge() and init(). T is defined as a subtype of Public by the use of the <: operator.
To create a new Person.T object, use the built in procedure NEW with the method init() as