IntroductionHistoryGoals and FeaturesModules and interfacesType systemAssignability and CompatibilityStructural Equivalence of TypesLayered Abstractions and Information HidingObjectsSafety and Support for Unsafe FeaturesGarbage CollectorConclusionBibliographyModula-3CS 520 Final ReportSwaminathan Sankararaman and Bojan DurickovicMay 14, 20081 IntroductionModula-3 is a successor of Modula-2 and Modula-2+, and influenced, among others, by Mesa, Cedarand Object Pascal. The main design goals were simplicity and safety, while preserving the powerof a system-level language. The machine-level abilities combined with garbage collection makeit well suited for system programming, while the explicit interfaces and safety features supportdevelopment of large-scale projects.Modula-3 has features of both functional programming and BCPL-like languages. Its key fea-tures include objects, modules and interfaces, automatic garbage collection, strong typing, generics,safety, exception handling, and multithreading. Similarly to C/C++, the language itself was keptminimal, leaving common operations such as input and output functionality to the standard library.2 HistoryThe story of Modula-3 begins in 1986, when Maurice Wilkes contacted Niklaus Wirth, suggestinga revision of Modula-2/Modula-2+. Wirth had already moved on to work on Oberon, but gavehis consent to Wilkes for using the Modula name. The team gathered for designing the languageinlcuded Luca Cardelli, Jim Donahue, Mick Jordan, Bill Kalsow and Greg Nelson, and the projectwas sponsored by Digital Equipment Corporation (DEC) and Olivetti. The language definition wascompleted in August 1988, and revised in January 1989.The contribution of the Modula-3 team goes beyond the language definition itself, as the processof developing the language through committee discussions and voting was thoroughly documented[1], and represents a unique reference of that kind.The first compiler came out of the DEC Systems Research Center soon after the languagedefinition, and several third-party compilers were made available in the 1990s. The 1990s, however,also saw both sponsoring companies go through a series of acquisitions1, and the language’s life inthe industry never quite got started. It was mostly used for research and teaching.Modula-3 was also used for a few notable projects, such as the SPIN OS2, and CVSup3. It is1After most of DEC’s assets were sold between 1994 and 1997 to various companies (including Oracle, QuantumCorp oration, and Intel), what remained of the company was sold in 1998 to Compaq, which was acquired by Hewlett-Packard in 2002. (“Digital Equipment Corporation,” Wikipedia: The Free Encyclopedia, accessed May 10, 2008)Olivetti, having sold away its PC business in 1997, was acquired by a Luxemburg-based company Bell S.A. in 1999,and sold to an Italian consortium two years later. In 2003, it was absorbed into the Telecom Italia group. (“Olivetti,”Wikipedia: The Free Encyclopedia, accessed May 10, 2008)2http://www.cs.washington.edu/research/projects/spin/www/3http://www.cvsup.org/1interesting to note, however, that both of these projects developed their own compilers with slightmodifications of Modula-3, which was partly motivated by the weakness of the available compilers.In 2000, the company behind one of the major compilers (CM3) for Modula-3 ceased operations,and was acquired by a German company Elegosoft, which later acquired also another Modula-3compiler, PM3.3 Goals and FeaturesThe motto of the Modula-3 committee when it was formed was to select simple, safe and provenfeatures to include in Modula-3. Ultimately, Modula-3 has ended up with a mixture of featuresselected from other languages and a few features of its own. The features selected by the committeewere geared towards the following goals, as outlined in [2]:1. support for structuring of large programs2. maximizing safety and robustness of programs3. support for machine-level programming when required4. simplicityThe above goals were geared towards a compromise between BCPL-like languages and lisp-like lan-guages. One provided the efficiency and flexibility and the other provides a beautiful programmingmodel while compromising on efficiency. Modula-3 attempts to eliminate the dangers of BCPL-likelanguages using a strong type system, while efficiency can be achieved when required by writingunsafe code which may be machine-dependent.We will now outline the features of Modula-3 ([2], [3], [4]). Modula-3 assimilated the followingfeatures from other languages simplifying them to a large extent.Table 1: Modula-3’s ancestryFeature LanguageGarbage Collection lispClosures lispObjects simula, smalltalkThreads mesa, cedarExceptions cluGenerics adaModules modula-2In addition, Modula-3 possesses a few novel features which are unique to itself:• isolation of safe and unsafe code,• powerful and clean type system,• layered abstractions.Overall, objects, interfaces and modules, threads and generics are those which contribute to thegoal of structuring large programs and the rest of the features are useful for safety and robustnessand for system-level programming. The goal of simplicity is followed in the inclusion of all of thesefeatures. In the following subsections we focus on those features which we think are either uniqueto Modula-3 or are more important in contributing towards its goals.23.1 Modules and interfacesModules are main building blocks of Modula-3 programs. They provide the outermost scope: inaddition to variables declared within a module, only names in imported interfaces are visible.Modules are interrelated through interfaces. An interface defines parts of a module that arepublicly visible. An interface contains declarations only, implementation is always within themodule that exports it.The file structure of a program is parallel to its module/interface structure: each module islocated in a .m3 file by the same name, and each interface in a .i3 file by the same name as theinterface.A typical module looks like the following:MODULE m EXPORTS i1 ;IMPORT i2 ;PROCEDURE f ();VAR x;BEGIN(* module body *)END m.Here, i1 is an interface implemented in the module m, while i2 is an interface implemented else-where.By convention, the main program is in a module named Main. Alternatively, any name can beused for the main module as long as it exports the Main interface.A module can export one or more interfaces. If no interface is explicitly exported by the module,the