Modula-3

Last updated
Modula-3
Modula-3.svg
Paradigms imperative, structured, procedural, modular, concurrent, object-oriented, generic
Family Wirth/Modula
Designed by Luca Cardelli, James Donahue, Lucille Glassman, Mick Jordan; Bill Kalsow, Greg Nelson
Developers DEC
Olivetti
elego Software Solutions GmbH
First appeared1988;36 years ago (1988)
Stable release
5.8.6 / July 14, 2010;13 years ago (2010-07-14)
Preview release
5.8.6 / July 14, 2010;13 years ago (2010-07-14)
Typing discipline strong, static, safe or if unsafe explicitly safe isolated
Scope Lexical
Platform IA-32, x86-64, PowerPC, SPARC
OS Cross-platform: FreeBSD, Linux, Darwin, SunOS
Website www.modula3.org
Major implementations
SRC Modula-3, CM3, [1] PM3, [2] EZM3, [3] M3/PC Klagenfurt [4]
Influenced by
ALGOL, Euclid, Mesa, Modula-2, Modula-2+, Oberon, Pascal
Influenced
C#, Java, Nim, [5] OCaml, Rust, [6] Python [7]

Modula-3 is a programming language conceived as a successor to an upgraded version of Modula-2 known as Modula-2+. While it has been influential in research circles (influencing the designs of languages such as Java, C#, Python [8] and Nim) 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.

Contents

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. [9]

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 elego 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 elego, 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, elego 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.

MODULEMain;IMPORTIO;BEGINIO.Put("Hello World\n")ENDMain.

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.

MODULEFooEXPORTSMain

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.

MODULEHelloWorldEXPORTSMain;IMPORTIO;BEGINIO.Put("Hello World\n")ENDHelloWorld.

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:

MODULEHelloWorldEXPORTSMain;FROMIOIMPORTPut;BEGINPut("Hello World\n")ENDHelloWorld.

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

INTERFACEIntegerElem;CONSTName="Integer";TYPET=INTEGER;PROCEDUREFormat(x:T):TEXT;PROCEDUREScan(txt:TEXT;VARx:T):BOOLEAN;ENDIntegerElem.

FILE: GenericStack.ig

GENERICINTERFACEGenericStack(Element);(* Here Element.T is the type to be stored in the generic stack. *)TYPET=PublicOBJECT;Public=OBJECTMETHODSinit():TStack;format():TEXT;isEmpty():BOOLEAN;count():INTEGER;push(elm:Element.T);pop(VARelem:Element.T):BOOLEAN;END;ENDGenericStack.

FILE: GenericStack.mg

GENERICMODULEGenericStack(Element);<...genericimplementationdetails...>PROCEDUREFormat(self:T):TEXT=VARstr:TEXT;BEGINstr:=Element.Name&"Stack{";FORk:=0TOself.n-1DOIFk>0THENstr:=str&", ";END;str:=str&Element.Format(self.arr[k]);END;str:=str&"};";RETURNstr;ENDFormat;<...moregenericimplementationdetails...>ENDGenericStack.

FILE: IntegerStack.i3

INTERFACEIntegerStack=GenericStack(IntegerElem)ENDIntegerStack.

FILE: IntegerStack.m3

MODULEIntegerStack=GenericStack(IntegerElem)ENDIntegerStack.

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.

INTERFACEA;TYPEColor={Black,Brown,Red,Orange,Yellow,Green,Blue,Violet,Gray,White};ENDA;
MODULEB;IMPORTA;FROMAIMPORTColor;VARaColor:A.Color;(* Uses the module name as a prefix *)theColor:Color;(* Does not have the module name as a prefix *)anotherColor:A.Color;BEGINaColor:=A.Color.Brown;theColor:=Color.Red;anotherColor:=Color.Orange;(* Can't simply use Orange *)ENDB.

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:

INTERFACEPerson;TYPET<:Public;Public=OBJECTMETHODSgetAge():INTEGER;init(name:TEXT;age:INTEGER):T;END;ENDPerson.

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

VARjim:=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 <: V merely reveals that T is a supertype of V without revealing any additional information on T. [10]

MODULEPerson;REVEALT=PublicBRANDEDOBJECTname:TEXT;(* These two variables *)age:INTEGER;(* are private. *)OVERRIDESgetAge:=Age;init:=Init;END;PROCEDUREAge(self:T):INTEGER=BEGINRETURNself.age;ENDAge;PROCEDUREInit(self:T;name:TEXT;age:INTEGER):T=BEGINself.name:=name;self.age:=age;RETURNself;ENDInit;BEGINENDPerson.

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[ citation needed ] become common. One feature that has not been adopted in other languages[ citation needed ], with the notable exceptions of Delphi, Python , Scala 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:

Modula-3 is one of the rare languages whose evolution of features is documented.

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

Continuing a trend started with the C language, many of the features needed to write real programs were left out of the language definition and instead provided via a standard library set. Most of the interfaces below are described in detail in [11]

Standard libraries providing the following features. These are called standard interfaces and are required (must be provided) in the language.

Some recommended interfaces implemented in the available implementations but are not required

As in C, I/O is also provided via libraries, in Modula-3 called Rd and Wr. The object-oriented design of the Rd (readers) and Wr (writers) libraries is covered in detail in the book by Greg Nelson. An interesting aspect of Modula-3 is that it is one of few programming languages which standard libraries have been formally verified not to contain various types of bugs, including locking bugs. This was done under the auspices of the Larch/Modula-3 (see Larch family) [12] and Extended static checking [13] projects at DEC Systems Research Center.

Implementations

Several compilers are available, most of them open source.

Since the only aspect of C data structures that is missing from Modula-3 is the union type, all extant Modula-3 implementations are able to provide good binary code compatibility with C language type declarations of arrays and structs.

Books

None of these books are still in print, although used copies are obtainable and some are digitized, partly or fully, and some chapters of one them have prior or posterior versions obtainable as research reports from the web.

Projects using Modula-3

Software which is programmed Modula-3 includes:

Influences on other programming languages

Although Modula-3 did not gain mainstream status, several parts of the DEC-SRC M3 distribution did. Probably the most influential part was the Network Objects library, which formed the basis for Java's first Remote Method Invocation (RMI) implementation, including the network protocol. Only when Sun moved from the Common Object Request Broker Architecture (CORBA) standard to the IIOP based protocol was it dropped. The Java documentation on garbage collection of remote objects still refer to the pioneering work done for Modula-3 Network Objects. [21] Python's implementation of classes was also inspired by the class mechanism found in C++ and Modula-3. [22] Also the language Nim makes use of some aspects of Modula-3, such as traced vs untraced pointers.

Related Research Articles

<span class="mw-page-title-main">Dylan (programming language)</span> Multi-paradigm programming language

Dylan is a multi-paradigm programming language that includes support for functional and object-oriented programming (OOP), and is dynamic and reflective while providing a programming model designed to support generating efficient machine code, including fine-grained control over dynamic and static behaviors. It was created in the early 1990s by a group led by Apple Computer.

Mesa is a programming language developed in the mid 1970s at the Xerox Palo Alto Research Center in Palo Alto, California, United States. The language name was a pun based upon the programming language catchphrases of the time, because Mesa is a "high level" programming language.

<span class="mw-page-title-main">Oberon (programming language)</span> General-purpose programming language

Oberon is a general-purpose programming language first published in 1987 by Niklaus Wirth and the latest member of the Wirthian family of ALGOL-like languages. Oberon was the result of a concentrated effort to increase the power of Modula-2, the direct successor of Pascal, and simultaneously to reduce its complexity. Its principal new feature is the concept of type extension of record types. It permits constructing new data types on the basis of existing ones and to relate them, deviating from the dogma of strictly static typing of data. Type extension is Wirth's way of inheritance reflecting the viewpoint of the parent site. Oberon was developed as part of the implementation of an operating system, also named Oberon at ETH Zurich in Switzerland. The name was inspired both by the Voyager space probe's pictures of the moon of the planet Uranus, named Oberon, and because Oberon is famous as the king of the elfs.

OCaml is a general-purpose, high-level, multi-paradigm programming language which extends the Caml dialect of ML with object-oriented features. OCaml was created in 1996 by Xavier Leroy, Jérôme Vouillon, Damien Doligez, Didier Rémy, Ascánder Suárez, and others.

Java and C++ are two prominent object-oriented programming languages. By many language popularity metrics, the two languages have dominated object-oriented and high-performance software development for much of the 21st century, and are often directly compared and contrasted. Java's syntax was based on C/C++.

Generic programming is a style of computer programming in which algorithms are written in terms of data types to-be-specified-later that are then instantiated when needed for specific types provided as parameters. This approach, pioneered by the ML programming language in 1973, permits writing common functions or types that differ only in the set of types on which they operate when used, thus reducing duplicate code.

Multiple dispatch or multimethods is a feature of some programming languages in which a function or method can be dynamically dispatched based on the run-time (dynamic) type or, in the more general case, some other attribute of more than one of its arguments. This is a generalization of single-dispatch polymorphism where a function or method call is dynamically dispatched based on the derived type of the object on which the method has been called. Multiple dispatch routes the dynamic dispatch to the implementing function or method using the combined characteristics of one or more arguments.

In computer science, reflective programming or reflection is the ability of a process to examine, introspect, and modify its own structure and behavior.

<span class="mw-page-title-main">Oberon-2</span> Programming language

Oberon-2 is an extension of the original Oberon programming language that adds limited reflection and object-oriented programming facilities, open arrays as pointer base types, read-only field export, and reintroduces the FOR loop from Modula-2.

Obliq is an interpreted, object-oriented programming language designed to make distributed, and locally multithreaded, computing simpler and easier to program, while providing program safety and an implicit type system. The interpreter is written in Modula-3, and provides Obliq with full access to Modula-3's network objects abilities. A type inference algorithm for record concatenation, subtyping, and recursive types has been developed for Obliq. Further, it has been proved to be NP-complete and its lowest complexity to be Ο(n3) or if under other modeling up to certain conditions down to Ο(n2) and its best known implementation runs in Ο(n5). Obliq's syntax is very similar to Modula-3, the biggest difference being that Obliq has no need of explicit typed variables (i.e., a variable can hold any data type allowed by the type checker and if does not accepts one, i.e., a given expression execution error will display) although explicit type declarations are allowed and ignored by the interpreter. The basic data types in the language include booleans, integers, reals, characters, strings, and arrays. Obliq supports the usual set of sequential control structures (conditional, iteration, and exception handling forms), and special control forms for concurrency (mutexes and guarded statements). Further, Obliq's objects can be cloned and safely copied remotely by any machine in a distributed network object and it can be done safely and transparently.

In computer science, type safety and type soundness are the extent to which a programming language discourages or prevents type errors. Type safety is sometimes alternatively considered to be a property of facilities of a computer language; that is, some facilities are type-safe and their usage will not result in type errors, while other facilities in the same language may be type-unsafe and a program using them may encounter type errors. The behaviors classified as type errors by a given programming language are usually those that result from attempts to perform operations on values that are not of the appropriate data type, e.g., adding a string to an integer when there's no definition on how to handle this case. This classification is partly based on opinion.

This article compares two programming languages: C# with Java. While the focus of this article is mainly the languages and their features, such a comparison will necessarily also consider some features of platforms and libraries. For a more detailed comparison of the platforms, see Comparison of the Java and .NET platforms.

In compiler construction, name mangling is a technique used to solve various problems caused by the need to resolve unique names for programming entities in many modern programming languages.

IP Pascal is an implementation of the Pascal programming language using the IP portability platform, a multiple machine, operating system and language implementation system. It implements the language "Pascaline", and has passed the Pascal Validation Suite.

<span class="mw-page-title-main">Oxygene (programming language)</span> Object Pascal-based programming language

Oxygene is a programming language developed by RemObjects Software for Microsoft's Common Language Infrastructure, the Java Platform and Cocoa. Oxygene is based on Delphi's Object Pascal, but also has influences from C#, Eiffel, Java, F# and other languages.

Modula-2 is a structured, procedural programming language developed between 1977 and 1985/8 by Niklaus Wirth at ETH Zurich. It was created as the language for the operating system and application software of the Lilith personal workstation. It was later used for programming outside the context of the Lilith.

<span class="mw-page-title-main">ParaSail (programming language)</span>

Parallel Specification and Implementation Language (ParaSail) is an object-oriented parallel programming language. Its design and ongoing implementation is described in a blog and on its official website.

Objective-C is a high-level general-purpose, object-oriented programming language that adds Smalltalk-style messaging to the C programming language. Originally developed by Brad Cox and Tom Love in the early 1980s, it was selected by NeXT for its NeXTSTEP operating system. Due to Apple macOS’s direct lineage from NeXTSTEP, Objective-C was the standard programming language used, supported, and promoted by Apple for developing macOS and iOS applications until the introduction of the Swift programming language in 2014.

<span class="mw-page-title-main">Nim (programming language)</span> Programming language

Nim is a general-purpose, multi-paradigm, statically typed, compiled high-level systems programming language, designed and developed by a team around Andreas Rumpf. Nim is designed to be "efficient, expressive, and elegant", supporting metaprogramming, functional, message passing, procedural, and object-oriented programming styles by providing several features such as compile time code generation, algebraic data types, a foreign function interface (FFI) with C, C++, Objective-C, and JavaScript, and supporting compiling to those same languages as intermediate representations.

References

  1. "Critical Mass Modula-3 (CM3)". Critical Mass Modula-3. elego Software Solutions GmbH. Retrieved 2020-03-21.
  2. "Polytechnique Montréal Modula-3 (PM3): What is it". Polytechnique Montréal Modula-3. elego Software Solutions GmbH. Retrieved 2020-03-21.
  3. Polstra, John D. (November 9, 2006). "Ezm3: An Easier Modula-3 Distribution". CVSup.org. Archived from the original on April 10, 2013. Retrieved 2020-03-21.
  4. Weich, Carsten. "M3/PC Klagenfurt 96: a Modula-3 environment for MS-DOS". Department of Informatics. University of Klagenfurt. Archived from the original on 20 May 2000. Retrieved 2020-03-21.
  5. Picheta, Dominik; Locurcio, Hugo. "Frequently Asked Questions" . Retrieved 2020-03-21.
  6. "R/Rust - I just learned about Modula-3, a language that had a lot of similar goals to Rust, and there was even an experimental OS that relied on the safety provided by the language".
  7. van Rossum, Guido (May 1996). "Programming Python: Foreword (1st ed.)". Python.org. Retrieved 2020-03-21.
  8. "Design and History FAQ: Why must 'self' be used explicitly in method definitions and calls?". Python.org. March 21, 2020. Retrieved 2020-03-21.
  9. 1 2 3 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)
  10. Cardelli, Luca; Donahue, James; Glassman, Lucille; Jordan, Mick; Kalsow, Bill; Nelson, Greg (August 1992). "Modula-3 language definition". ACM SIGPLAN Notices. 27 (8): 15–42. doi:10.1145/142137.142141. ISSN   0362-1340.
  11. 1 2 Some Useful Modula-3 Interfaces Archived 2016-03-04 at the Wayback Machine Jim Horning, Bill Kalsow, Paul McJones, Greg Nelson. DEC Systems Research Center (SRC) Research Report 113 (December 1993)
  12. LM3 Archived 2016-03-03 at the Wayback Machine Kevin D. Jones. DEC Systems Research Center (SRC) Research Report 72 (June 1991)
  13. Extended Static Checking Archived 2017-07-05 at the Wayback Machine David L. Detlefs, K. Rustan M. Leino, Greg Nelson, James B. Saxe. Compaq SRC Research Report 159 (December 1998)
  14. SRC Modula-3 3.3 [ permanent dead link ] Bill Kalsow and Eric Muller. Digital Equipment Corporation (January 1995)
  15. Jordan, Mick (1990). "An extensible programming environment for Modula-3". SIGSOFT Softw. Eng. Notes. 15 (6): 66–76. doi: 10.1145/99278.99285 .
  16. An Introduction to Programming with Threads Archived 2017-07-05 at the Wayback Machine Andrew D. Birrell. DEC Systems Research Center (SRC) Research Report 35 (January 1989)
  17. Synchronization Primitives for a Multiprocessor: A Formal Specification Archived 2016-03-04 at the Wayback Machine A. D. Birrell, J. V. Guttag, J. J. Horning, R. Levin. DEC Systems Research Center (SRC) Research Report 20 (August 1987)
  18. IO Streams: Abstract Types, Real Programs Archived 2016-03-03 at the Wayback Machine Mark R. Brown and Greg Nelson. DEC Systems Research Center (SRC) Research Report 53 (November 1989)
  19. Modula-3 Reference Manual Luca Cardelli, James Donahue, Lucille Glassman, Mick Jordan, Bill Kalsow, Greg Nelson. DEC Systems Research Center (SRC) (February 1995)
  20. Trestle Tutorial Archived 2016-03-03 at the Wayback Machine Mark S. Manasse and Greg Nelson. DEC Systems Research Center (SRC) Research Report 69 (May 1992)
  21. Garbage Collection of Remote Objects, Java Remote Method Invocation Documentation for Java SE 8.
  22. Classes, Official Python Documentation.