View source for Modula-3

{{Short description|Programming language}}
{{Infobox programming language 
| name                   = Modula-3 
| logo                   = Modula-3.svg
| paradigms              = [[Imperative programming|imperative]], [[Structured programming|structured]], [[Procedural programming|procedural]], [[Modular programming|modular]], [[Concurrent computing|concurrent]], [[object-oriented programming|object-oriented]], [[generic programming|generic]]
| typing                 = [[Strong and weak typing|strong]], [[Static typing|static]], [[Type system#Safely and unsafely typed systems|safe]] or if [[Type system#Safely and unsafely typed systems|unsafe]] explicitly safe isolated
| scope                  = [[Scope (computer science)|Lexical]]
| family                 = [[Niklaus Wirth|Wirth]]/[[Modula]]
| designers              = [[Luca Cardelli]], James Donahue, Lucille Glassman, Mick Jordan; Bill Kalsow, [[Greg Nelson (computer scientist)|Greg Nelson]]
| developers             = [[Digital Equipment Corporation|DEC]]<br/>[[Olivetti]]<br/>{{Not a typo|elego}} Software Solutions GmbH
| released               = {{Start date and age|1988}}
| latest release version = 5.8.6
| latest release date    = {{Start date and age|2010|07|14}}
| latest preview version = 5.8.6
| latest preview date    = {{Start date and age|2010|07|14}}
| implementations        = [[DEC Systems Research Center|SRC]] Modula-3, CM3,<ref>{{Cite web |url=https://modula3.elegosoft.com/cm3/ |title=Critical Mass Modula-3 (CM3) |website=Critical Mass Modula-3 |publisher=elego Software Solutions GmbH |access-date=2020-03-21}}</ref> PM3,<ref>{{cite web |url=https://modula3.elegosoft.com/pm3/ |title=Polytechnique Montréal Modula-3 (PM3): What is it |author=<!--Unstated--> |date=<!--Undated--> |website=Polytechnique Montréal Modula-3 |publisher=elego Software Solutions GmbH |access-date=2020-03-21}}</ref> EZM3,<ref>{{cite web |url=http://www.cvsup.org/ezm3/ |title=Ezm3: An Easier Modula-3 Distribution |last=Polstra |first=John D. |date=November 9, 2006 |website=CVSup.org |url-status=dead |archive-url=https://web.archive.org/web/20130410151327/http://www.cvsup.org/ezm3/ |archive-date=April 10, 2013 |access-date=2020-03-21}}</ref> M3/PC Klagenfurt<ref>{{cite web |url=http://www.ifi.uni-klu.ac.at/Modula-3/m3pc/m3pc.html |title=M3/PC Klagenfurt 96: a Modula-3 environment for MS-DOS |last=Weich |first=Carsten |date=<!-- Undated. --> |website=Department of Informatics |publisher=University of Klagenfurt |url-status=dead |archive-url=https://web.archive.org/web/20000520073936/http://www.ifi.uni-klu.ac.at/Modula-3/m3pc/m3pc.html |archive-date=20 May 2000 |access-date=2020-03-21}}</ref>
| influenced by          = [[ALGOL]], [[Euclid (programming language)|Euclid]], [[Mesa (programming language)|Mesa]], [[Modula-2]], [[Modula-2+]], [[Oberon (programming language)|Oberon]], [[Pascal (programming language)|Pascal]]
| influenced             = [[C Sharp (programming language)|C#]], [[Java (programming language)|Java]], [[Nim (programming language)|Nim]],<ref>{{Cite web |url=http://nim-lang.org/question.html |title=Frequently Asked Questions |last1=Picheta |first1=Dominik |last2=Locurcio |first2=Hugo |date=<!-- Undated. --> |access-date=2020-03-21}}</ref> [[OCaml]], [[Rust (programming language)|Rust]], [[Python (programming language)|Python]]<ref>{{Cite web |url=https://www.python.org/doc/essays/foreword/ |title=Programming Python: Foreword (1st ed.) |last=van Rossum |first=Guido |date=May 1996 |website=Python.org |access-date=2020-03-21}}</ref>
| platform               = [[IA-32]], [[x86-64]], [[PowerPC]], [[SPARC]]
| operating system       = [[Cross-platform]]: [[FreeBSD]], [[Linux]], [[Darwin (operating system)|Darwin]], [[SunOS]]
| website                = {{URL|www.modula3.org}}
}}

'''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 (programming language)|Java]], [[C Sharp (programming language)|C#]], [[Python (programming language)|Python]]<ref>{{Cite web |url=https://docs.python.org/3/faq/design.html#why-self |title=Design and History FAQ: Why must 'self' be used explicitly in method definitions and calls? |date=March 21, 2020 |website=Python.org |access-date=2020-03-21}}</ref> and [[Nim (programming language)|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 (computer scientist)|Greg Nelson]] at the [[Digital Equipment Corporation]] (DEC) [[DEC Systems Research Center|Systems Research Center]] (SRC) and the [[Olivetti]] Research Center (ORC) in the late 1980s.

Modula-3's main features are [[modular programming|modularity]], simplicity and safety while preserving the power of a systems-programming language. Modula-3 aimed to continue the [[Pascal (programming language)|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 [[Template (programming)|templates]]), [[Thread (computer science)|multithreading]], [[exception handling]], [[Garbage collection (computer science)|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 (programming language)|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 [[Takeover|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)|ARX]] operating system project of [[ARM architecture|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 (programming language)|Mesa]], [[Cedar (programming language)|Cedar]], [[Object Pascal]], [[Oberon (programming language)|Oberon]] and [[Euclid (programming language)|Euclid]].<ref name=DecSrcRr052>[http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-52.html 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)</ref>

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 {{not a typo|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 {{not a typo|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, {{not a typo|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==
{{Expand section|date=July 2011}}<!-- Still needs some fleshing out. -->
A common example of a language's [[Syntax (programming languages)|syntax]] is the [["Hello, World!" program]].

<syntaxhighlight lang="modula2">
MODULE Main; 
IMPORT IO;
BEGIN
  IO.Put("Hello World\n")
END Main.
</syntaxhighlight>

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 [[Modular programming|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 <code>EXPORT</code> to export the Main module. <syntaxhighlight lang="modula2">MODULE Foo EXPORTS Main</syntaxhighlight> 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 <code>T</code>, since types are usually qualified by their full names, so a type <code>T</code> inside a module named Foo will be named <code>Foo.T</code>. This aids in readability. Another similar convention is naming a public object <code>Public</code> as in the OOP examples below.

==Language features==

===Modularity===
First and foremost, all compiled units are either <code>INTERFACE</code> or implementation <code>MODULE</code>s, of one flavor or another. An interface compiled unit, starting with the keyword <code>INTERFACE</code>, defines constants, types, variables, exceptions, and procedures. The implementation module, starting with the keyword <code>MODULE</code>, 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 <code>EXPORT</code> to a module not of the same name. For example, the main program exports an implementation module for the Main interface.

<syntaxhighlight lang="modula2">
MODULE HelloWorld EXPORTS Main; 
IMPORT IO;
BEGIN
  IO.Put("Hello World\n")
END HelloWorld.
</syntaxhighlight>

Any compiled unit may <code>IMPORT</code> 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 <code>FROM Module IMPORT Item [, Item]*</code> syntax:

<syntaxhighlight lang="modula2">
MODULE HelloWorld EXPORTS Main; 
FROM IO IMPORT Put;
BEGIN
  Put("Hello World\n")
END HelloWorld.
</syntaxhighlight>

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 <code>MyModule.T</code>.

In the event of a name collision between an imported module and other entity within the module, the reserved word
<code>AS</code> can be used as in <code>IMPORT CollidingModule AS X;</code>

===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 (programming language)|C]] language. The keyword <code>UNSAFE</code> prefixed in front of <code>INTERFACE</code> or <code>MODULE</code>, 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 <code>LOOPHOLE</code> to copy the bits of an integer into a floating point <code>REAL</code> 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 [[Library (computing)|libraries]], where two interfaces are built: one unsafe, the other safe.

===Generics===
A generic interface and its corresponding generic module, 
prefix the <code>INTERFACE</code> or <code>MODULE</code> keyword with <code>GENERIC</code>, and take as formal arguments other interfaces. Thus (like [[Template (C++)|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 <code>IntegerElem</code>, or <code>RealElem</code>, or even interfaces to Objects, as long as each of those interfaces defines the properties needed by the generic modules.

The bare types <code>INTEGER</code>, or <code>REAL</code> 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'''

<syntaxhighlight lang="modula2" highlight="1">
INTERFACE IntegerElem;
CONST Name = "Integer";
TYPE T = INTEGER;
PROCEDURE Format(x: T): TEXT;
PROCEDURE Scan(txt: TEXT; VAR x: T): BOOLEAN;
END IntegerElem.
</syntaxhighlight>

'''FILE: GenericStack.ig'''

<syntaxhighlight lang="modula2" highlight="1">
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.
</syntaxhighlight>

'''FILE: GenericStack.mg'''

<syntaxhighlight lang="modula2" highlight="1">
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.
</syntaxhighlight>

'''FILE: IntegerStack.i3'''

<syntaxhighlight lang="modula2">
INTERFACE IntegerStack = GenericStack(IntegerElem) END IntegerStack.
</syntaxhighlight>

'''FILE: IntegerStack.m3'''

<syntaxhighlight lang="modula2">
MODULE IntegerStack = GenericStack(IntegerElem) END IntegerStack.
</syntaxhighlight>

===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 <code>IMPORT</code> statement. Even enumerations make use of the same 'dot' notation as used when accessing a field of a record.

<syntaxhighlight lang="modula2" highlight="1">
INTERFACE A;

TYPE Color = {Black, Brown, Red, Orange, Yellow, Green, Blue, Violet, Gray, White};

END A;
</syntaxhighlight>
<syntaxhighlight lang="modula2">
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.
</syntaxhighlight>

===Dynamic allocation===
Modula-3 supports the allocation of data at [[Runtime (program lifecycle phase)|runtime]]. There are two kinds of memory that can be allocated, <code>TRACED</code> and <code>UNTRACED</code>, the difference being whether the [[Garbage collection (computer science)|garbage collector]] can see it or not. <code>NEW()</code> is used to allocate data of either of these classes of memory. In an <code>UNSAFE</code> module, <code>DISPOSE</code> 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 <code>OBJECT</code> declaration, which has essentially the same syntax as a <code>RECORD</code> 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:

<syntaxhighlight lang="modula2" highlight="1">
INTERFACE Person;

TYPE T <: Public;
  Public = OBJECT 
  METHODS
    getAge(): INTEGER;
    init(name: TEXT; age: INTEGER): T;
  END;

END Person.
</syntaxhighlight>
This defines an interface <code>Person</code> with two types, <code>T</code>, and <code>Public</code>, which is defined as an object with two methods, <code>getAge()</code> and <code>init()</code>. <code>T</code> is defined as a subtype of <code>Public</code> by the use of the <code><:</code> operator.

To create a new <code>Person.T</code> object, use the built in procedure <code>NEW</code> with the method <code>init()</code> as 
<syntaxhighlight lang="modula2">
VAR jim := NEW(Person.T).init("Jim", 25);
</syntaxhighlight>

=== Revelation ===
Modula-3's <code>REVEAL</code> 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 <code>REVEAL T = V</code> can be used to show the full implementation of the <code>Person</code> interface from above. A partial revelation of the form <code>REVEAL T <: V</code> merely reveals that T is a supertype of V without revealing any additional information on T.<ref>{{Cite journal |last1=Cardelli |first1=Luca |last2=Donahue |first2=James |last3=Glassman |first3=Lucille |last4=Jordan |first4=Mick |last5=Kalsow |first5=Bill |last6=Nelson |first6=Greg |date=August 1992 |title=Modula-3 language definition |url=https://dl.acm.org/doi/10.1145/142137.142141 |journal=ACM SIGPLAN Notices |language=en |volume=27 |issue=8 |pages=15–42 |doi=10.1145/142137.142141 |issn=0362-1340|url-access=subscription }}</ref>

<syntaxhighlight lang="modula2">
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.
</syntaxhighlight>

Note the use of the <code>BRANDED</code> keyword, which "brands" objects to make them unique as to avoid structural equivalence. <code>BRANDED</code> 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 <code>A</code> to the object <code>x</code> exported from module <code>B</code> must take the form <code>B.x</code>. 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 <code>TRY</code>...<code>EXCEPT</code> block system, which has since{{citation needed|date=March 2014}} become common.  One feature that has not been adopted in other languages{{citation needed|date=March 2014}}, with the notable exceptions of [[Delphi (programming language)|Delphi]], [[Python (programming language)|Python]][https://www.python.org/doc/faq/general/#why-was-python-created-in-the-first-place], [[Scala (programming language)|Scala]][http://scala.epfl.ch] and [[Visual Basic.NET]], is that the <code>EXCEPT</code> construct defined a form of [[switch statement]] with each possible exception as a case in its own EXCEPT clause. Modula-3 also supports a <code>LOOP</code>...<code>EXIT</code>...<code>END</code> construct that loops until an <code>EXIT</code> occurs, a structure equivalent to a simple loop inside a <code>TRY</code>...<code>EXCEPT</code> 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 <code>[[Lock (computer science)|MUTEX]]</code> is used to synchronize multiple threads and protect data structures from simultaneous access with possible corruption or race conditions. The <code>LOCK</code> statement introduces a block in which the mutex is locked. Unlocking a <code>MUTEX</code> is implicit by the code execution locus's leaving the block. The <code>MUTEX</code> 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.
<!-- Needs expansion -->

===Summary===
In summary, the language features:
*[[Modularity (programming)|Modules]] and [[Interface (computer science)|interfaces]]
*Explicit marking of unsafe code
*[[Generic programming|Generics]]
*Automatic [[Garbage collection (computer science)|garbage collection]]
*[[strongly-typed programming language|Strong typing]], structural equivalence of types
*[[Object (computer science)|Objects]]
*[[Exception handling|Exceptions]]
*[[Thread (computer science)|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 <code>READONLY</code>.

==Standard library features==
Continuing a trend started with the [[C (programming language)|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<ref name=DecSrcRr113>[http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-113.pdf Some Useful Modula-3 Interfaces] {{Webarchive|url=https://web.archive.org/web/20160304040009/http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-113.pdf |date=2016-03-04 }} Jim Horning, Bill Kalsow, Paul McJones, Greg Nelson. [[DEC Systems Research Center]] (SRC) Research Report 113 (December 1993)</ref>

Standard libraries providing the following features. These are called standard interfaces and are required (must be provided) in the language.
* Text: Operations on immutable string references, called <code>TEXT</code>s
* Thread: Operations relating to threading, including <code>MUTEX</code>, condition variable, and thread pausing.  The threading library provides pre-emptive threads switching
* Word: Bitwise operations on unsigned integers (or machine words). Normally implemented directly by the compiler
* Floating-point interfaces
Some recommended interfaces implemented in the available implementations but are not required
* Lex: For parsing number and other data
* Fmt: Formatting various datatypes for printing
* Pkl (or Pickle): [[Object serialization]] of any reference types reachable by the garbage collector
* Table: Generic modules for [[Map (computer science)|maps]]

As in C, I/O is also provided via libraries, in Modula-3 called <code>Rd</code> and <code>Wr</code>. 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]])<ref name=DecSrcRr072>[http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-072.pdf LM3] {{Webarchive|url=https://web.archive.org/web/20160303215535/http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-072.pdf |date=2016-03-03 }} Kevin D. Jones. [[DEC Systems Research Center]] (SRC) Research Report 72 (June 1991)</ref> and [[Extended static checking]]<ref name=CompaqSrcRr159>[http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-159.pdf Extended Static Checking] {{Webarchive|url=https://web.archive.org/web/20170705054838/http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-159.pdf |date=2017-07-05 }}  David L. Detlefs, K. Rustan M. Leino, Greg Nelson, [[James B. Saxe]]. Compaq SRC Research Report 159 (December 1998)</ref> projects at [[DEC SRC|DEC Systems Research Center]].

==Implementations==
Several compilers are available, most of them [[Open-source model|open source]].

*DEC-SRC M3, the original.<ref>[ftp://ftp.u-aizu.ac.jp/pub/lang/Modula/m3/faq/document/src-m3-doc/SRCm3-3.3.ps.gz SRC Modula-3 3.3]{{dead link|date=May 2025|bot=medic}}{{cbignore|bot=medic}} Bill Kalsow and Eric Muller. Digital Equipment Corporation (January 1995)</ref>
*Olivetti Research Center (ORC) Modula-3 toolkit, originally a compiler, now available as a library for syntactic, lexical and semantic analysis of Modula-3 programs.<ref>{{Cite journal
| doi = 10.1145/99278.99285
| volume = 15
| issue = 6
| pages = 66–76
| last = Jordan
| first = Mick
| title = An extensible programming environment for Modula-3
| journal = SIGSOFT Softw. Eng. Notes
| year = 1990
| doi-access = free
}}</ref>
*Critical Mass CM3, a different successor of DEC-SRC M3
*Polytechnique Montreal Modula-3 PM3, a successor of DEC-SRC M3, currently merging with CM3
*EzM3, an independent lightweight and easily portable implementation, developed in connection with [[CVSup]]
*HM3, a successor of the pm3-1.1.15 release of PM3, with support of native threading using [[NPTL]]
*CM3,<ref>[http://www.opencm3.net  Critical Mass Modula-3 Web]</ref><ref>[https://github.com/modula3/cm3 CM3 repo]</ref> the successor to Critical Mass CM3. Based on an old version of [[GNU Compiler Collection|GCC]], PM3 and CAM3 derive from SRC M3. This is the only up to date, maintained and developed implementation.

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 [[Array data structure|arrays]] and [[Record (computer science)|structs]].

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

*Greg Nelson, ed., ''Systems Programming with Modula-3'' The definitive reference on the Modula-3 language with interesting articles on object-oriented systems software construction and a documentation of the discussion leading to the final features of the language. There are some formerly (see<ref name=DecSrcRr052 /> for Chapter two,<ref name=DecSrcRr035>[http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-035.pdf An Introduction to Programming with Threads] {{Webarchive|url=https://web.archive.org/web/20170705054620/http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-035.pdf |date=2017-07-05 }} Andrew D. Birrell. [[DEC Systems Research Center]] (SRC) Research Report 35 (January 1989)</ref> for chapter four,<ref name=DecSrcRr020>[http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-020.pdf Synchronization Primitives for a Multiprocessor: A Formal Specification] {{Webarchive|url=https://web.archive.org/web/20160304040003/http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-020.pdf |date=2016-03-04 }} A. D. Birrell, J. V. Guttag, J. J. Horning, R. Levin. [[DEC Systems Research Center]] (SRC) Research Report 20 (August 1987)</ref> for chapter five,<ref name=DecSrcRr053>[http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-053.pdf IO Streams: Abstract Types, Real Programs] {{Webarchive|url=https://web.archive.org/web/20160303224416/http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-053.pdf |date=2016-03-03 }} Mark R. Brown and Greg Nelson. [[DEC Systems Research Center]] (SRC) Research Report 53 (November 1989)</ref> for chapter six) and some posteriorly (see<ref name=DecSrcRefMan95>[http://www.minet.uni-jena.de/www/fakultaet/schukat/Inf1/Praktikum/Modula-3-refman.ps Modula-3 Reference Manual] Luca Cardelli, James Donahue, Lucille Glassman, Mick Jordan, Bill Kalsow, Greg Nelson. [[DEC Systems Research Center]] (SRC) (February 1995)</ref> for Chapter one and more updated two, thus of both prior versions of language definition<ref name=DecSrcRr052 /> and,<ref name=DecSrcRr113 /> for chapter three and<ref name=DecSrcRr069>[http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-069.pdf Trestle Tutorial] {{Webarchive|url=https://web.archive.org/web/20160303213053/http://apotheca.hpl.hp.com/ftp/pub/dec/SRC/research-reports/SRC-069.pdf |date=2016-03-03 }} Mark S. Manasse and Greg Nelson. [[DEC Systems Research Center]] (SRC) Research Report 69 (May 1992)</ref> for chapter seven) of publishing versions of the majority of its eight chapters individually available from prior [[DEC Systems Research Center]] (SRC) as research reports for download.
*Samuel P. Harbison, ''Modula-3''  Easy to use class textbook.
*[[Robert Sedgewick (computer scientist)|Robert Sedgewick]], ''Algorithms in Modula-3''
*Laszlo Boszormenyi & Carsten Weich, ''Programming in Modula-3: An Introduction in Programming with Style''
*Renzo Orsini, Agostino Cortesi ''Programmare in Modula-3: introduzione alla programmazione imperativa e a oggetti'' an Italian book of the language explaining its main features.

==Projects using Modula-3==
Software which is programmed with Modula-3 includes:
*The [[SPIN (operating system)|SPIN]] operating system
*The [[CVSup]] [[software repository]] synchronizing program
*The [[Obliq]] language, which uses Modula-3 network objects ability to migrate objects over local networks transparently, allowing a distributed ability to Modula-3 object-oriented programming paradigm. It has been used to build distributed applications, computer animations, and web programming applications in the form of scripting extension to Modula-3.

==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 [[General Inter-ORB Protocol|IIOP based protocol]] was it dropped. The Java documentation on [[Garbage collection (computer science)|garbage collection]] of remote objects still refer to the pioneering work done for Modula-3 Network Objects.<ref>[http://docs.oracle.com/javase/8/docs/platform/rmi/spec/rmi-arch4.html ''Garbage Collection of Remote Objects''], Java Remote Method Invocation Documentation for Java SE 8.</ref>  Python's implementation of classes was also inspired by the class mechanism found in C++ and Modula-3.<ref>[https://docs.python.org/3/tutorial/classes.html#classes ''Classes''], Official Python Documentation.</ref>
Also the language [[Nim (programming language)|Nim]] makes use of some aspects of Modula-3, such as [[#Dynamic allocation|traced vs untraced]] pointers.

==References==
{{Reflist}}

==External links==
*{{Official website|www.modula3.org}}
*{{GitHub|modula3|Modula3}}
*[http://www.opencm3.net CM3 Implementation Website]
*[http://www.research.compaq.com/SRC/modula-3/html/home.html Modula-3 Home Page] (now long dead, [https://web.archive.org/web/20050220025439/http://www.research.compaq.com/SRC/modula-3/html/home.html mirror])
*[http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-52.html Modula-3: Language definition]
*[http://www.elegosoft.com elego Software Solutions]
*[news:comp.lang.modula3 Modula-3 newsgroup], mostly deserted
*[https://web.archive.org/web/20120326171529/https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel Modula-3 Development Mailing List], active
*[https://web.archive.org/web/20091203151748/http://www.mikanystrom.com/cs2/ Notes from Caltech's CS2 class, taught in Modula-3 in 2002 and 2003]
*{{webarchive |url=https://web.archive.org/web/20130523220501/http://www.ugcs.caltech.edu/~se/ |date=May 23, 2013 |title=Caltech's CS3 class 2009}}
*[https://web.archive.org/web/19970814162826/http://www.ifi.uni-klu.ac.at/Modula-3/m3book/examples.html mirror ''Programming in Modula-3'': program examples]
*[https://web.archive.org/web/20120227030339/http://www.professeurs.polymtl.ca/michel.dagenais/pkg/BDAM3alpha.ps ''Building Distributed OO Applications: Modula-3 Objects at Work''. Michel R. Dagenais. Draft Version (January 1997)]
*[ftp://ftp.u-aizu.ac.jp/pub/lang/Modula/m3/faq/document/LangToolsLibs/root.ps ''Modula-3: Language, Libraries and Tools''. Presentation on Modula-3 over 120 slides. Michael R. Dagenais]{{dead link|date=May 2025|bot=medic}}{{cbignore|bot=medic}}, dead
*[http://csis.pace.edu/~bergin/M3text ''Object-Oriented Data Abstraction in Modula-3''. Joseph Bergin (1997)]
*[https://web.archive.org/web/20190418023749/http://www.techworld.com.au/article/252531/a-z_programming_languages_modula-3/ Computerworld Interview with Luca Cardelli on Modula-3]

{{Modula, Oberon}}
{{Authority control}}

[[Category:Modula programming language family]]
[[Category:Object-oriented programming languages]]
[[Category:Systems programming languages]]
[[Category:Programming languages created in 1988]]
[[Category:Statically typed programming languages]]