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); 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; 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 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 VAR jim := NEW(Person.T).init("Jim", 25);
Revelation Modula-3's REVEAL construct provides a conceptually simple and clean yet very powerful mechanism for hiding implementation details from clients, with arbitrarily many levels of
friendliness. A full revelation of the form REVEAL T = V can be used to show the full implementation of the Person interface from above. A partial revelation of the form REVEAL T merely reveals that T is a supertype of V without revealing any additional information on T. MODULE Person; REVEAL T = Public BRANDED OBJECT name: TEXT; (* These two variables *) age: INTEGER; (* are private. *) OVERRIDES getAge := Age; init := Init; END; PROCEDURE Age(self: T): INTEGER = BEGIN RETURN self.age; END Age; PROCEDURE Init(self: T; name: TEXT; age: INTEGER): T = BEGIN self.name := name; self.age := age; RETURN self; END Init; BEGIN END Person. Note the use of the BRANDED keyword, which "brands" objects to make them unique as to avoid structural equivalence. BRANDED can also take a string as an argument, but when omitted, a unique string is generated for you. Modula-3 is one of a few programming languages which requires external references from a module to be strictly qualified. That is, a reference in module A to the object x exported from module B must take the form B.x. In Modula-3, it is impossible to import
all exported names from a module. Because of the language's requirements on name qualification and
method overriding, it is impossible to break a working program simply by adding new declarations to an interface (any interface). This makes it possible for large programs to be edited concurrently by many programmers with no worries about naming conflicts; and it also makes it possible to edit core language libraries with the firm knowledge that no extant program will be
broken in the process.
Exceptions Exception handling is based on a TRY...EXCEPT block system, which has since become common. One feature that has not been adopted in other languages, with the notable exceptions of
Delphi,
PythonScala[http://scala.epfl.ch and
Visual Basic.NET, is that the EXCEPT construct defined a form of
switch statement with each possible exception as a case in its own EXCEPT clause. Modula-3 also supports a LOOP...EXIT...END construct that loops until an EXIT occurs, a structure equivalent to a simple loop inside a TRY...EXCEPT clause.
Multi-threaded The language supports the use of multi-threading, and synchronization between threads. There is a standard module within the
runtime library (
m3core) named Thread, which supports the use of multi-threaded applications. The Modula-3 runtime may make use of a separate thread for internal tasks such as garbage collection. A built-in data structure
MUTEX is used to synchronize multiple threads and protect data structures from simultaneous access with possible corruption or race conditions. The LOCK statement introduces a block in which the mutex is locked. Unlocking a MUTEX is implicit by the code execution locus's leaving the block. The MUTEX is an object, and as such, other objects may be derived from it. For example, in the
input/output (I/O) section of the library
libm3, readers and writers (Rd.T, and Wr.T) are derived from MUTEX, and they lock themselves before accessing or modifying any internal data such as buffers.
Summary In summary, the language features: •
Modules and
interfaces • Explicit marking of unsafe code •
Generics • Automatic
garbage collection •
Strong typing, structural equivalence of types •
Objects •
Exceptions •
Threads In
Systems Programming with Modula-3, four essential points of the language design are intensively discussed. These topics are: structural vs. name equivalence, subtyping rules, generic modules, and parameter modes like READONLY. ==Standard library features==