r-mail
Subject: Modula-3 Frequently Asked Questions (FAQ)
Date: 7 May 1997 14:25:20 GMT

Archive-name: Modula-3-faq

Modula-3 FAQ, WWW and FTP archive

Last updated 20 March 1997

This tree of documents, programs and binaries references most of the
material available on the Modula-3 language, compiler and libraries. It
should answer all the most frequently asked questions about Modula-3. Items
on this site are submitted by a large number of individuals. Michel Dagenais
(dagenais@vlsi.polymtl.ca) is maintaining this service. Please send him any
suggestions for improvements.

For each file subtree of the www.vlsi.polymtl.ca Modula-3 Web server, a full
text search and a download menu are available. This includes searching the
full tree (http://www.vlsi.polymtl.ca/m3/.ghindex.html#search) .

The postscript version of the FAQ is available on
ftp://www.vlsi.polymtl.ca/pub/m3/faq/faq.ps and the ascii version on
ftp://www.vlsi.polymtl.ca/pub/m3/faq/faq.txt. An hypertext WWW version is
found on http://www.vlsi.polymtl.ca/m3.

For submitting new items or improving existing items please upload files by
ftp to ftp://www.vlsi.polymtl.ca/pub/m3/incoming and send e-mail to
dagenais@vlsi.polymtl.ca.

Introduction

What is new?

The latest release is SRC Modula-3 3.6. Since then, a few improvements have
been made available in the bugs and patches section of the Modula-3 home
page (http://www.research.digital.com/SRC/modula-3/html/home.html) . The
port to Win32 (Windows NT and Windows 95) is now in good shape. Commercial
support is available and large industrial applications have been developed
using Modula-3, outside of the research and university environment.

What is Modula-3?

Modula-3 is a systems programming language that descends from Mesa,
Modula-2, Cedar, and Modula-2+. It also resembles its cousins Object Pascal,
Oberon, and Euclid.

The goal of Modula-3 is to be as simple and safe as it can be while meeting
the needs of modern systems programmers. Instead of exploring new features,
they studied the features of the Modula family of languages that have proven
themselves in practice and tried to simplify them into a harmonious
language. They found that most of the successful features were aimed at one
of two main goals: greater robustness, and a simpler, more systematic type
system.

Modula-3 retains one of Modula-2's most successful features, the provision
for explicit interfaces between modules. It adds objects and classes,
exception handling, garbage collection, lightweight processes (or threads),
and the isolation of unsafe features.

Where can I get a description of Modula-3?

The language definition and most electronically available Modula-3
information can be accessed on the Modula-3 home page
(http://www.research.digital.com/SRC/modula-3/html/home.html)

For some of these documents, including the language definition, is available
a Postscript version (http://www.vlsi.polymtl.ca/m3/document/src-m3-doc/)

What is SRC Modula-3?

SRC-Modula-3 (file://gatekeeper.dec.com/pub/DEC/Modula-3/) was built by the
DEC Systems Research Center and is freely available and redistributable,
with source code. In Europe it is also available from
ftp-i3.informatik.rwth-aachen.de in pub/Modula-3. The most recent version is
release 3.6

The DEC SRC Modula-3 contains the following:

   * A native code compiler: uses the GCC backend; on machines/operating
     systems that have self-describing stacks, an optimized exception
     handling mechanism is provided, on other architectures, setjmp/longjmp
     is used. A very fast integrated backend is available on some platforms
     (currently NT386 and Linux i386).

     The compilation system provides for minimal recompilation. Only those
     units that depend on the modified interface item will be recompiled.

   * m3build: tool that performs dependency analysis and builds the Modula-3
     programs and libraries.
   * m3gdb: a Modula-3 aware version of GDB.
   * Several tools for performance and coverage analysis.
   * A large standard library (libm3) providing

        o A multithread, incremental, generational, conservative garbage
          collector
        o Text manipulation.
        o Generic Containers: Lists, Sequences, Tables, SortedLists,
          SortedTables
        o Atoms and Symbolic expressions (Lisp like lists)
        o An extensible stream IO system
        o Typesafe binary object transcription (persistent objects)
        o Operating system interfaces
        o Portable interfaces to the language runtime

     All standard libraries are thread-friendly. Modula-3 can readily link
     with existing C libraries; many libraries including X11R4 and various
     UNIX libraries are available as part of libm3.

   * Several other libraries for designing graphical user interfaces and
     distributed applications.

Browsing Modula-3 packages

A large number of Modula-3 packages may be accessed in formatted source code
form.

   * Modula-3 packages (with source code files formatted)
     (http://www.vlsi.polymtl.ca/m3/pkgf/)
   * Browsing Modula-3 packages, interfaces, modules and types
     (http://www.vlsi.polymtl.ca:3829/)

Supported platforms

Two implementations are available, SRC Modula-3 and a PC version of it
(m3pc).

As far as we know, implementations are not available for VMS and for the
Macintosh.

There are versions for the architectures listed below. While SRC can test on
DS3100, ALPHA/OSF, Windows NT and LINUX, it can only rely on what users on
other platforms tell them to integrate all the platform specific code.

   * AIX386: IBM PC running AIX/PS2,
   * AOSF: DEC Alpha AXP running OSF/1
   * AP3000: Apollo DN4500 running Domain/OS
   * ARM: Acorn R260 running RISC iX 1.21
   * DS3100: DECstation 3100 and 5000 running Ultrix 4.0 and 4.2
   * HP300: HP 9000/300 running HP-UX 8.0
   * HPPA: HP 9000/700, 9000/800 running HP-UX 8.0
   * IBMR2: IBM R6000 running AIX 3.1,
   * IBMRT: IBM RT running IBM/4.3,
   * LINUX: Intel 386 running LINUX
   * NEXT: NeXT running ??
   * NT386: Intel 386 running Windows NT
   * OKI: Okidata 7300 (i860) running UNIX SVR4.0
   * SEQUENT: Sequent computers running ??
   * SOL2: Sparc running Solaris 2.x
   * SPARC: SPARCstation running SunOS 4.1.x
   * SUN3: SUN3 running SunOS
   * SUN386: Sun 386i running SunOS 4.0.1
   * UMAX: Encore Multimax running UMAX 4.3 (R4.1.1)
   * VAX: VAX running Ultrix 3.1

The new native compiler is based on GCC and should be fairly easy to port.
Except for the very lowest levels of the thread implementation, the entire
system is written in Modula-3.

A number of binaries are available for FTP. If you are willing to provide
binaries for other architectures, please contact dagenais@vlsi.polymtl.ca;
they may be put on his FTP server or links to your server can be included.
The full SRC Modula-3 source code tree
(http://www.vlsi.polymtl.ca/m3/binaries/../pkg/SRC-m3) is available on-line.

Special instructions exist for installing SRC Modula-3 on a SPARC Solaris
computer with the GNU C compiler [SOLGnu]
(http://www.research.digital.com/SRC/modula-3/html/installingSOLgnu.html) .

Modula-3/PC Klagenfurt 96 (for DOS)

We have updated our Modula-3/PC environment. It is based on the DJGPP port
of the gcc to DOS PC's. Our system still uses version 2.09 of the
SRC/Modula-3 compiler, which compiles to C code.

M3/PC is very easy to install and to use. It runs on a plain DOS-PC, and in
a DOS box of Windows 3.11 and Windows95. You do not have to write
m3makefiles, Modula-3 programs are compiled and linked automatically. Our
version is especially useful if your aim is to learn Modula-3. We distribute
it together with more than 130 example modules, the examples of our book
"Programming in Modula-3, an Introduction in Programming with Style"
(B=F6sz=F6rm=E9nyi, Weich).

We are using this system in our introduction courses at the University of
Klagenfurt. You cannot use it to compile the SRC library (because we still
have the out-dated 2.09 Modula-3 library). We have not ported Trestle and
Network Objects and others.

For more information see:

http://www.ifi.uni-klu.ac.at/Modula-3/m3pc/m3pc.html

For information about the book and the example programs see:

English: http://www.ifi.uni-klu.ac.at/Modula-3/m3book/m3book.html
German: http://www.ifi.uni-klu.ac.at/Modula-3/m3buch/m3book.html

Changes to the previous versions:

   * Uses new (and a lot improved) DJGPP gnu C compiler.
   * Configuration files instead of hard-coded filenames. You can now
     install Modula-3 and C compiler on different disc drives.
   * Full support for DOS-filenames (including the drive letters).
   * Better support for runtime errors and the CTRL-C interrupt.
   * Now based on a POSIX C-library.
   * The graphical development environment is no longer available (sorry,
     the changes in the libraries made more porting efforts necessary than
     we have resources available at the moment).

PS: I am going to leave university at the end of this year. Wolfgang Stroh
(wolf@ifi.uni-klu.ac.at) will take care of M3/PC in future.

Carsten Weich Universit=E4t Klagenfurt
Universit=E4tsstr. 65-67
A-9020 Klagenfurt
AUSTRIA

tel: (43) 463 2700 511
www: http://www.ifi.uni-klu.ac.at/cgi-bin/staff_home?carsten
email: carsten@ifi.uni-klu.ac.at

Wolfgang Stroh
wolf@ifi.uni-klu.ac.at
http://www.ifi.uni-klu.ac.at/cgi-bin/staff_home?wolf

Directory contents:

   * Book examples (http://www.vlsi.polymtl.ca/m3/binaries/DOS/book) in
     english (http://www.vlsi.polymtl.ca/m3/binaries/DOS/book/m3book) and in
     german (http://www.vlsi.polymtl.ca/m3/binaries/DOS/book/m3buch) .
   * A few additions to libm3, libm3local
     (http://www.vlsi.polymtl.ca/m3/binaries/DOS/libm3local) .
   * Latest release of m3pc, m3pc.96
     (http://www.vlsi.polymtl.ca/m3/binaries/DOS/m3pc.96) .
   * Earlier release of m3pc, including a graphical development environment,
     m3pc.94 (http://www.vlsi.polymtl.ca/m3/binaries/DOS/m3pc.94) .

   * README (738 bytes) (http://www.vlsi.polymtl.ca/m3/binaries/DOS/README)

   * Subdirectory 'm3pc' (30 files, 19551110 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/DOS/m3pc/)
   * Subdirectory 'm3pc.94' (89 files, 23334384 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/DOS/m3pc.94/)
   * Subdirectory 'm3pc.96' (30 files, 19551110 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/DOS/m3pc.96/)
   * Subdirectory 'libm3local' (16 files, 42441 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/DOS/libm3local/)
   * Subdirectory 'book' (478 files, 1762611 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/DOS/book/)

Modula-3 on LINUX (i386-a.out)

Michel Dagenais (dagenais@vlsi.polymtl.ca) is providing binaries for LINUX.

   * SRC Modula-3 3.4 for LINUX (10 files, 28742358 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/LINUX/m3-3.4/)

Modula-3 on LINUXELF (i386-linuxelf)

Michel Dagenais (dagenais@vlsi.polymtl.ca) is providing binaries for LINUX
using the new ELF binary format; shared libraries are much easier to build
under ELF.

With the slackware-elf-beta distribution, the following patch is required to
compile SRC Modula-3. The problem is that the stat and fstat functions are
now directly inlined by gcc.

Carsten Weich suggests to add the following file in the m3core library:

/* Carsten Weich, June 1995
 *
 * "stat" and "fstat" are declared as "__inline__" in "/usr/include/sys/stat.h"
 * These inline calls are not accessable to the linker, so Modula-3 routines
 * can not call them.
 *
 * This hack replicates the inline calls as regular functions. See <sys/stat.h>
!
 */

int stat (p1, p2)
char *p1, *p2;
{
        return _xstat(1, p1, p2);
}

int fstat (f, p)
int f;
char *p;
{
        return _fxstat(1, f, p);
}

   * SRC Modula-3 3.5.4-B LINUX ELF release (13 files, 42633828 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/LINUXELF/3.5.4-B/)

Modula-3 on SPARC

Farshad Nayeri (nayeri@gte.com) is maintaining release notes
(ftp://ftp.gte.com/pub/m3) for the SPARC port. Michel Dagenais
(dagenais@vlsi.polymtl.ca) offers binaries.

   * SRC Modula-3 3.4 for SPARC (2 files, 23714671 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/SPARC/m3-3.4/)

Modula-3 on FreeBSD

Olaf Wagner (olaf@logware.de) is offering binaries on the i386 FreeBSD
platform.

   * SRC Modula-3 3.3 binaries for FreeBsd (11 files, 11334659 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/FREEBSD/m3-3.3/)
   * SRC Modula-3 3.5.1 for FreeBsd (11 files, 13138898 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/FREEBSD/m3-3.5.1/)

Modula-3 on HP Precision Architecture

Bert Laverman (laverman@cs.rug.nl) is providing binaries for HPPA
workstations.

   * SRC Modula-3 3.3 for HP Precision Architecture (HPPA) (36 files,
     24149950 bytes) (http://www.vlsi.polymtl.ca/m3/binaries/HPPA/m3-3.3/)

Modula-3 on the NeXT (68000)

Thomas Neumann (tom@smart.ruhr.de) is providing binaries for Modula-3 on
NeXT.

   * SRC Modula-3 3.3 for NEXT (680x0) (6 files, 8089080 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/NEXT/m3-3.3/)

Modula-3 on OS/2

The current port is the work of Klaus Preschern (klausp@ping.at). With the
availability of X windows for OS/2, the port is pretty much fully
functional.

   * Modula-3 3.6c for OS/2 (51 files, 6550337 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/OS2/3.6/)
   * Modula-3 3.6c for OS/2 (51 files, 6550337 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/OS2/3.6c/)
   * Modula-3 3.6d for OS/2 (43 files, 6924972 bytes)
     (http://www.vlsi.polymtl.ca/m3/binaries/OS2/3.6d/)

Modula-3 on AIX

Bob Barton (barton@chopin.eche.ualberta.ca) is working on a port to AIX
3.2.5 for RISC/6000.

Modula-3 documents

Hardcopy versions of the DEC SRC research reports
(http://www.research.digital.com/SRC/publications/src-rr.html) can be
ordered by e-mail; send your request including a postal mail address to
src-reports@src.dec.com.

From the language designers: System Programming with Modula-3

   * System Programming with Modula-3 Edited by Greg Nelson Prentice Hall
     Series in Innovative Technology ISBN 0-13-590464-1 L.C. QA76.66.S87
     1991

also known as SPwM3. Here is the table of contents:

  1. Introduction
  2. Language Definition
  3. Standard Interfaces
  4. An Introduction to Programming with Threads
  5. Thread Synchronization: A Formal Specification
  6. I/O Streams: Abstract Types, Real Programs
  7. Trestle Window System Tutorial
  8. How the Language Got its Spots

Chapters 2 and 3 have been reprinted in Sigplan Notices, Volume 27, Number
8, August 1992, pp 15-42.

Usenet news group

There is a Usenet newsgroup, comp.lang.modula3. If you do not have access to
Usenet, there is a relay mailing list; send a message to
m3-request@src.dec.com to be added to it.

Archives of that group are maintained and are available by FTP
(file://gatekeeper.dec.com/pub/DEC/Modula-3/comp.lang.modula3)

Past postings may be searched easily through the dejanews server
(http://xp8.dejanews.com/filter.xp?groups=comp.lang.modula3*) .

Introducing Modula-3 (Linux Journal)

``Introducing Modula-3'', Geoff Wyant, Linux Journal, December 1994, also in
electronic form (ftp://ftp.gte.com/pub/m3/linux-journal.html) .

Safe programming with Modula-3 (Dr. Dobbs journal)

``Safe Programming with Modula-3'', Sam Harbison, Dr. Dobb's Journal, Vol.
17, No. 10, October 1992, pp 88+.

Modula-3 (Byte magazine)

``Modula-3'', Sam Harbison, Byte, Vol. 15, No. 12, November 1990, pp 385+.

The Modula-3 treatment of floating-point values (ACM LOPLAS)

``The Design of Floating-Point Data Types'', David Goldberg, ACM Letters on
Programming Languages and Systems (LOPLAS), June 1992, Vol 1, no.2, pp
138-151

Description of the Modula-3 type system (POPL Conference)

``The Modula-3 Type System'', Luca Cardelli, Jim Donahue, Mick Jordan, Bill
Kalsow, Greg Nelson, Conference Record of the Sixteenth Annual ACM Symposium
on Principles of Programming Languages (POPL), Austin Texas, January 11-13
1989, pp 202-212.

Pickles: serialization of typed values (read write objects from disk)

``Pickles: a system for automatic serialization of typed values'', Andrew
Birrell, Greg Nelson, Susan Owicki, Edward Wobber, Systems Research Center,
Digital Equipment Corp., in preparation.

Some useful Modula-3 interfaces, the core libraries

``Some Useful Modula-3 Interfaces'', Jim Horning, Bill Kalsow, Paul McJones,
Greg Nelson, SRC Research report 113
(file://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-113.ps.Z)

The Trestle tutorial

``Trestle Tutorial'', Mark S. Manasse and Greg Nelson, SRC Research Report
69, May 1, 1992.

VBTkit: a toolkit for Trestle

``VBTkit Reference Manual: A toolkit for Trestle'', edited by Marc H. Brown
and James R. Meehan. (to be a SRC Research Report). A draft version is
available in VBTKit
(file://gatekeeper.dec.com/pub/DEC/Modula-3/contrib/vbtkit.25Mar93.ps.Z)

The Trestle window system toolkit (on X windows or Win32)

``Trestle Reference Manual'', Mark S. Manasse and Greg Nelson, SRC Research
report 68
(file://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-068.ps.Z) ,
December 1991.

FormsVBT: user interface building with VBTkit

``The FormsVBT Reference Manual'', Marc H. Brown and James R. Meehan, (to be
a SRC Research Report). A draft version is available in VBTKit library
(file://gatekeeper.dec.com/pub/DEC/Modula-3/contrib/formsvbt.25Mar93.ps.Z)
and VBTKit applications
(file://gatekeeper.dec.com/pub/DEC/Modula-3/contrib/formsvbt.AppC.26Mar93.ps.Z)

Zeus: a system for algorithm animation

``Zeus: A System for Algorithm Animation and Multi-View Editing'', Marc H.
Brown, February 28, 1992, SRC research report 75
(file://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-075.ps.Z)

Color and Sound in Zeus Algorithm Animation

``Color and Sound in Algorithm Animation'', Marc H. Brown and John
Hershberger, August 30, 1991, SRC research report 76a
(file://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-076a.ps.Z)

Network objects

``Network Objects'', Andrew Birrell, Greg Nelson, Susan Owicki, and Edward
Wobber, February 28, 1994, SRC Research report 115
(file://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-115.ps.Z)

The 1992 Zeus algorithm animation festival

``The 1992 SRC Algorithm Animation Festival'', Marc H. Brown, March 27,
1993, SRC research report 98
(file://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-098.ps.Z)

Distributed garbage collection for network objects

``Distributed garbage collection for Network Objects'', Andrew Birrell,
David Evers, Greg Nelson, Susan Owicki, and Edward Wobber, December 1993,
SRC Research report 116
(file://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-116.ps.Z)

Obliq: a lightweight embeddable language for network objects

``Obliq: A lightweight language for network objects'', Luca Cardelli, User's
Manual, Systems Research Center, Digital Equipment Corp., 1994, by FTP
(file://gatekeeper.dec.com/pub/DEC/Modula-3/contrib/Obliq.ps)

A tutorial book: Modula-3

Sam Harbison has written a tutorial book about Modula3:

   * Modula-3 Samuel P. Harbison Prentice Hall, 1992 ISBN 0-13-596396-6

The table of contents is as follows:

  1. Introduction
  2. Declarations
  3. Statements
  4. Basic Types
  5. Structured Types
  6. Procedures
  7. Exceptions
  8. Interfaces and Modules
  9. Generics
 10. Dynamic Programming
 11. Objects
 12. Threads
 13. Low-Level Programming
 14. Programming Conventions
 15. SRC Modula-3
 16. Modula-3 Syntax
 17. Answers to Selected Exercises

The errata (file://gatekeeper.dec.com/pub/DEC/Modula-3/errata) sheet is
available.

Algorithms in Modula-3 (Sedgewick)

Sedgewick's classic text on computer algorithms is presented in Modula-3 in:

   * Algorithms in Modula-3 Robert Sedgewick Addison-Wesley, 1993 ISBN
     0-201-53351-0

Threads: A Modula-3 Newsletter

Published once or twice a year, Threads (http://www.cmass.com/threads/)
features articles on various aspects of Modula-3.

Modula-3 Reference and Tutorials in Universities and Colleges

Such documents have been prepared at Columbia University
(http://www.cs.columbia.edu/graphics/modula3/tutorial/www/m3_toc.html) ,
Concordia University
(http://www.cs.concordia.ca/~faculty/manas/comp346/features.html) ,
University of Kent at Canterbury
(http://stork.ukc.ac.uk/computer_science/Html/Courses/djb/ProblemSolving/doc0.html)

A book on Programming with style in Modula-3

Laszlo Boeszoermenyi and Carsten Weich wrote a book entitled Programming in
Modula-3, An Introduction in Programming with Style, (english)
(http://www.ifi.uni-klu.ac.at/Modula-3/m3book/m3book.html) (german)
(http://www.ifi.uni-klu.ac.at/Modula-3/m3buch/m3book.html)

Slides presenting Modula-3 and tools

   * The language (in french)
     (http://www.vlsi.polymtl.ca/m3/faq/document/m3-present/present-m3-french-1.0.tar.gz)
   * A brief overview of the libraries and tools
     (http://www.vlsi.polymtl.ca/m3/faq/document/m3-present/present-src-m3-1.0.tar.gz)

(http://www.vlsi.polymtl.ca/m3/faq/document/m3-present/)

Some Modula-3 reference manuals in postscript

   * Modula-3 language definition
     (http://www.vlsi.polymtl.ca/m3/faq/document/src-m3-doc/Modula3.ps.gz)
   * SRC Modula-3 3.3 reference manual
     (http://www.vlsi.polymtl.ca/m3/faq/document/src-m3-doc/SRCm3-3.3.ps.gz)
   * Some Useful Modula-3 Interfaces
     (http://www.vlsi.polymtl.ca/m3/faq/document/src-m3-doc/Libm3.ps.gz)
   * Obliq A language with distributed scope
     (http://www.vlsi.polymtl.ca/m3/faq/document/src-m3-doc/ObliqPaper.ps.gz)
   * The FormsVBT reference manual
     (http://www.vlsi.polymtl.ca/m3/faq/document/src-m3-doc/FormsVBT.ps.gz)
   * The Modula-3 network objects reference manual
     (http://www.vlsi.polymtl.ca/m3/faq/document/src-m3-doc/Netobj.ps.gz)

   * Libm3.ps.gz (149907 bytes)
     (http://www.vlsi.polymtl.ca/m3/faq/document/src-m3-doc/Libm3.ps.gz)
   * SRCm3-3.3.ps.gz (95592 bytes)
     (http://www.vlsi.polymtl.ca/m3/faq/document/src-m3-doc/SRCm3-3.3.ps.gz)
   * ObliqPaper.ps.gz (677877 bytes)
     (http://www.vlsi.polymtl.ca/m3/faq/document/src-m3-doc/ObliqPaper.ps.gz)
   * FormsVBT.ps.gz (350616 bytes)
     (http://www.vlsi.polymtl.ca/m3/faq/document/src-m3-doc/FormsVBT.ps.gz)
   * Modula3.ps.gz (121444 bytes)
     (http://www.vlsi.polymtl.ca/m3/faq/document/src-m3-doc/Modula3.ps.gz)
   * Netobj.ps.gz (112825 bytes)
     (http://www.vlsi.polymtl.ca/m3/faq/document/src-m3-doc/Netobj.ps.gz)

Presentation on Modula-3: Language, Tools and Libraries

This presentation contains slightly over 120 transparencies and may be used
for a 2 or 3 days intensive couse on developping applications with Modula-3.
It does not present the underlying concepts of object oriented programming,
for example. It introduces the important tools and libraries (libm3,
formsvbt, network and stable objects) but cannot cover all the libraries
available (obliq, zeus...).

(http://www.vlsi.polymtl.ca/m3/faq/document/LangToolsLibs/)

Archives for Usenet Newsgroup comp.lang.modula3

(http://www.vlsi.polymtl.ca/m3/faq/document/CompLangM3/)

Frequently asked questions and answers

Recovering from running out of virtual memory

This turns out to be quite a thorny problem. I think the best thing I can do
is by attaching to this message the dialog that went on during the "beta
test" of the new library interfaces (SRC Research Report 113, "Some Useful
Modula-3 Interfaces). The parties are Xerox PARC's David Goldberg, Hans
Boehm, Alan Demers, and David Nichols, and SRC's John DeTreville, who
designed and implemented the garbage collector in SRC Modula-3. The dialog
covers many of the issues, and apparently ends when the participants run out
of steam.

Paul McJones mcjones@src.dec.com (editor of SRC 113)

RTAllocator should allow handling out of memory

David Goldberg: ... there is one system problem that is not currently
handled, namely running out of memory. I would very, very much like to see
this handled in RTAllocator. One approach was suggested by Roy Levin a while
back: Have a RegisterNoMemory(proc) routine that causes proc() to be called
when memory is gone (or very low). Example of use: in the 'Solitaire'
program, the 'Hint' button generates a tree of possible moves. If this tree
gets very big and consumes all memory, the RegisterNoMemory proc could
abandon the search down the current branch, NIL-out that branch, and ask for
a garbage collection. Currently what happens is that Solitaire crashes if
you bug 'Hint' and memory is low.

Interface Police: Ok, make a concrete proposal and we'll talk. How low
should memory be before the runtime complains? Before or after a collection?
Is it ok to call your procedure from inside a runtime critical section
(after all, you're probably in the middle of a NEW)? Are multiple
notification procedures allowed to be registered? Shouldn't a routine that
consumes arbitrary amounts of memory be coded to poll the allocator to ask
how much memory is available?

Hans Boehm/Alan Demers/David Goldberg/David Nichols: We believe that
programs wishing to handle allocation failures will be able to do so with
high (but not perfect) reliability if the interface provides two features:
versions of the RTAllocator.New routines that report if the allocation is
not possible (either by returning NIL or raising an exception), and a way to
register a callback when memory is low. Both features are necessary. Here
are two typical scenarios:

   * The Solitaire program. Before starting, Solitaire allocates a 'safety
     net' block of memory, and registers a callback. When memory is
     exhausted, the callback frees the safety net, sets a flag, and returns.
     In the Solitaire program proper, the inner loop of the move generator
     checks the flag immediately after allocating a new node. If the flag is
     set, it abandons the search. It would not work for Solitiare to
     allocate new tree nodes with RTAllocator.New() and check for an error:
     as memory gets low, a library routine in some other package could cause
     an allocation failure.

     Unfortunately, there is a race condition since another thread could run
     and do an allocation between the time the faulting NEW returns and all
     references to the search tree are NIL'ed. This can be mimimized by
     adding some slop to the safety net.

   * An editor that allocates O(n) bytes of memory when opening an n-byte
     file. If the users tries to open a huge file, you don't want to crash,
     but rather tell the user that the file can't be opened (in UNIX, the
     user can then kill some processes to regain swap space and try again,
     or in an emacs-style editor he can delete some buffers and try again).
     A callback won't work for this, because when attempting to open a huge
     file, the allocation must be aborted: there just isn't enough memory to
     go around. Instead an RTAllocator.New() routine should be used for this
     allocation.

     However, the editor will also want to register a callback proc to guard
     against NEW()s in other parts of the program that can't be satisfied.
     If the callback is passed the size of the memory allocation that can't
     be satisfied, the callback will be able to pick between two strategies.
     If there is a 'safety net' which is larger than the block to be
     allocated, the callback can free it and set a "low on memory" flag,
     with the editor cleaning up properly later. If the safety net is not
     big enough, the callback itself can attempt an emergency save before
     crashing.

Here's a specific proposal that embodies these ideas. We're not wedded to
the details. Note that RTCollector.LimitRelative is not essential: it just
lifts some of the functionality currently in RTHeapPolicy.

   * Add the following to RTCollector.i3:

           PROCEDURE LimitAbsolute(n: CARDINAL);

           (* Don't let the heap grow beyond n bytes.  The collector/allocator
              should observe this in all heap growth decisions.  *)

           [Comment from Hans: I don't think there is a way to write
           programs that are reasonable citizens on a shared system without
           some such facility.]

           PROCEDURE LimitRelative(x: REAL);

           (* Advisory.  Try to keep the heap size at roughly x times the
              amount of live data. (For ref counting it affects only the
              backup collector for cycles.)  *)

           [Comments from Hans: The performance of all collectors with
           which I am familiar depends crucially on such a parameter.  Thus
           it might as well be exposed in some portable interface.  (The
           allocator should of course use less memory if it gains no time
           advantage from using more.)  The "amount of live data" is, of
           course, implementation defined, as are the minimum values of x
           that have any chance of being observed.]

   * In RTAllocator.i3, add OutOfMemory to RAISES clauses of all the New
     routines, and add the following:

           EXCEPTION OutOfMemory;

           TYPE
              CallBackObj = OBJECT notify(bytes: CARDINAL) END;

           PROCEDURE RegisterHeapFullCallback(obj: CallBackObj);

           (* Add obj.notify to the list of procs to be called if an
              allocation request is about to fail, either because of lack
              of memory, or due to violation of an
              RTCollector.LimitAbsolute imposed limit.  The notify method
              will be called with an argument specifying the size in bytes
              of the allocate call that triggered the callback.  The notify
              method may not allocate or acquire locks, or call any
              procedures that do.  It may be invoked synchronously with any
              combination of locks held.  (Should there be a way to delete
              a registered callback?).  If a garbage collection after this
              callback fails to reclaim enough memory to allocate the
              requested object, an exception will be raised if the
              allocation was through RTAllocator.  Otherwise a checked
              runtime error will result.  The notify proc is not called
              when memory fails from an RTAllocator.New call (these
              failures can be caught by the user).

              Typical actions by notify would include one of the following:

              1) Clearing pointers to reduce the amount of accessible memory.
              2) Calling RTCollector.LimitAbsolute with a larger limit.
           *)

   * Variations on this proposal:

     Might want to consider adding:

           PROCEDURE GetLimitAbsolute(): CARDINAL;
           (* Return the current absolute heap limit *)

     The usefulness of RTCollector.LimitAbsolute in the callback would be
     increased if there was a way to tell if this actually freed up any more
     memory. One approach would be to change CallBackObj to

           TYPE
              CallBackObj = OBJECT
                               notify(bytes: CARDINAL; retry: BOOLEAN): BOOLEAN
                            END;

     and change the action of RegisterHeapFullCallback to:

           (* If a garbage collection after all callbacks have been
              executed fails to reclaim enough memory to allocate the
              requested object, then any notify() procs that returned TRUE
              will be called again with retry := TRUE.  Otherwise an
              exception will be raised if the allocation was through
              RTAllocator, or else a checked runtime error will result. *)

     Thus, if you wanted to first try and get more memory in the callback by
     calling RTCollector.LimitAbsolute, you could return TRUE and wait for a
     callback with retry = TRUE. If this second callback occurs, you will
     need to clear some pointers to free up memory. Or another variation:
     add

           PROCEDURE GetTotalBytesAllocated(): CARDINAL;
           (* Returns the total number of bytes allocated since the program
              begin.  A CARDINAL may not be big enough, perhaps this should
              be a LONGREAL? *)

     Then the retry argument to the notify method can be eliminated, since a
     call is a retry only if GetTotalBytesAllocated() shows no additional
     allocations since the last callback.

John DeTreville: When I read your March proposal for handling running out of
memory on the traced heap, I didn't quite see how to implement the details
you gave. I've been iterating to create mechanisms that are simpler and more
implementable, and I've now arrived at quite a simple interface.

In particular, I now believe that (almost) all the functionality you ask for
is already provided by the current interface. I say "almost" because there's
a few status calls to be added, and because some of the current mechanisms
are clunky, but I believe I can tell a convincing story. Note that these
mechanisms are or would be in SRC-specific interfaces (currently called
RTAllocatorSRC, RTCollectorSRC, and RTHeapRep); I don't think we understand
them well enough to put them into the public IP interfaces.

Let's first distinguish VM limits from application-imposed limits. The
amount of VM available to the application is a hard limit, although not one
that can easily be predicted. In the current SRC M3 implementation, both the
allocator and the collector allocate VM from the kernel when necessary. If
the collector tries to allocate VM and fails, the program must crash: there
is no way to reestablish the necessary invariants to let it continue.

I propose treating VM exhaustion as a checked runtime error, in the
allocator and in the collector. The goal is then to establish and maintain
an application-imposed limit that is uniformly stricter than the VM limit,
whatever that may be.

You propose a mechanism to allow calls to the New* procedures to fail if
they would exceed the application-imposed limit. Of course, only a small
part of the code would take advantage of this facility. This code could
equally well query the heap to determine the current size, and compare it
against the limit; if the program can also predict the size of the object to
be allocated, it can decide whether or not to proceed.

This approach requires some collector-dependent code in the application, but
I doubt that it would be very much. It also allows possible race conditions,
but I believe they're not much worse in practice than in the original
proposal.

You also propose a mechanism to notify the program whenever the limit is
about to be exceeded. It's quite complicated to get such immediate
notification. First, the procedures notified can't acquire locks or call
most procedures in other modules. Second, it requires a new collection to
run synchronously after the procedures to see if enough space has been freed
and whether some of the procedures must be called again; this causes an
interruption of service.

Here's a different proposal, which might not allow space bounds as tight as
in the original proposal, but which seems simpler. We would add a mechanism
for an application thread to wait for the next collection to finish. This
mechanism could replace the current mechanisms for registering and
unregistering synchronous monitors, which have numerous complex and poorly
documented constraints on what actions they can perform.

Each time through, the thread could compare the amount of space still
reachable to the application-imposed limit, and either free some data before
the next collection (the ability to hold locks would be handy here) or
increase "gcRatio" to make the collector work harder and keep the total heap
size under control, or both.

There is still the danger that the application could allocate so rapidly
that this asynchronous thread might not be able to keep up, but otherwise
asynchronous actions seem a lot more reasonable than synchronous.

This is one approach, and there are others. What's nice about this design is
that it requires almost no changes to the interface, only better status
reporting and a replacement of the mechanisms for registering and
unregistering synchronous collection monitors. Maybe you could even work
around the current lack of these facilities. Let me know what you think.

Hans: One quick comment, without having thought much about the rest:

"This code could equally well query the heap to determine the current size,
and compare it against the limit; if the program can also predict the size
of the object to be allocated, it can decide whether or not to proceed."

Is this really true? Since the collector can't move some objects, there are
presumably fragmentation issues. Am I guaranteed to be able to allocate 1 MB
if the current heap size is 1 MB below the limit? This is certainly false in
PCR, and I'm not sure how you could guarantee it without remapping pages.

John: Hans Boehm notes that I was wrong about the client of New* being able
to predict whether an allocation would succeed or fail, because of likely
page-level fragmentation. This needs to be fixed in my proposal.

To expand on my earlier message, let me outline a completely different
approach for handling heap overflow, that perhaps has more in common with
the original PARC proposal, but which seems far too complex and unwieldy to
me. This complexity is why I tried to work out a simpler approach, even at
the cost of providing fewer guarantees.

We start by imagining that we want to be able to continue to run even if we
exhaust VM. First, this means that we can never allocate VM from inside the
collector. The implication is that whenever we allocate VM in the allocator,
we allocate enough extra to tide us over through the next collection, no
matter how much of the heap it retains. This suggests that we will
significantly overallocate VM. For example, with a stop-and-copy collector
and gcRatio set to 1, a program with a stably-sized reachable set currently
requires 3 times as much space as the reachable set, but the "failsafe gc"
would require 4 times.

(Doing even this well depends crucially upon the SRC implementation detail
that the current collector never copies objects bigger than one page, but
leaves them in place. Otherwise, the possibility of fragmentation would make
it much more difficult to determine how much memory to leave free for the
collector, and in what sizes of runs of pages. It will also take some work
to avoid off-by-one errors in predicting how much memory a collection could
take.)

Of course, if the client decreases gcRatio, or switches from sort-and-copy
collection to concurrent collection, that would require allocating more VM,
to ensure that the collector cannot run out of VM. That means that these
operations can also fail, just like allocator operations.

Only some programs will want to be able to back off when they reach VM
limits. Others won't mind getting a checked runtime error; in return, they
will require less VM. Therefore, we need procedures to switch back and forth
between these two modes. Again, attempting to switch to failsafe mode can
fail.

The collector currently allocates its own space on the traced heap during
collections, which will have to be moved to the untraced heap if we are to
predict how much traced heap a collection can use. Note that in general,
once VM is exhausted, allocations on the untraced heap may start to fail,
and so programs will probably die very quickly once VM is exhausted. But
let's move on.

In addition to the VM limit, we also want an application-imposed limit on
heap size. The allocator and collector will guarantee that the heap size
will never exceed this limit. Again, we will overallocate VM in the
allocator to avoid exceeding the limit in the collector. Again, setting the
limit may fail.

So what happens when a NEW fails, or a New*, or switching to concurrent
collection, or setting the application-imposed limit, or whatever? This
happens whenever performing the operation would exceed the
application-imposed limit, or when attempts to allocate enough extra VM
fail.

Some of these can signal an error, and the client can chose to do something
else instead. In some cases, such as setting gcRatio, it might make sense
for the failing operation to tell the client how close to the impossible
value would be possible.

NEW, though, should not signal an error; this would require massive changes
in all existing modules that would not be add value to most clients. In this
case, I can't think of anything much better than the original proposal.
Before attempting to allocate the object, the collector will try to free up
some storage. First, it can perform a collection, or finish the current one.
If that doesn't do it, it can call one or more procedures registered by the
application to drop links to some storage, or to change collector
parameters. If that doesn't do it, we can perform another collection. And so
on and so on, until the procedures say to give up.

Note that these collections must be synchronous, since no allocations may be
possible until this mechanism completes, and the collections will therefore
cause interruptions of service. Note also that the procedures cannot acquire
locks, cannot allocate storage, cannot call thread primitives, and so on,
and therefore cannot call into most libraries; they are essentially
restricted to reading and writing data structures whose implementations they
know, and changing collector parameters. This seems excessively restrictive,
but also unavoidable in this approach.

In short, this seems like a lot of extra mechanism to add to the allocator
and collector, that doesn't seem to do quite what you want; it gives you
strict limits, but at a cost. My proposal of this morning is at least much
simpler, although it can give looser limits.

John, continuing: Thinking a little more about the problem of running out of
storage in the untraced heap, it seems that the only reasonable thing to do
is to merge the implementation of the untraced heap with the traced heap.
This was, untraced NEWs that fail can be handled exactly the same way as
traced NEWs, with a synchronous cleanup routine that frees enough VM to
proceed, or resets parameters.

This means that the allocator and collector cannot use the untraced heap,
but must either use a static amount of storage which they could overflow, or
must allocate enough extra in response to client applications that they
cannot possibly run out of space. The potential space overhead for
maximum-sized stacks, for example, is huge.

The more this proposal is fleshed out, it more it seems that doing a good
job of recovering from heap overflows is quite tricky, which is why I
suggest a lower-tech approach for now.

Hans: I just went over the last few messages in this thread again. I think
the bottom line is, as you say:

It's hard to implement an out-of-memory call-back on top of the current
collector. Given the current collector, a collector call-back that allows
polling is probably the best you can reasonably do, and should certainly be
provided.

The remaining question, which also seems to be motivated by other concerns
here, is: To what extent are you tied to this collector design? The problem
here seems to be mainly caused by copying old generation objects, since you
could perhaps bound the size of the young generation? My suspicion, based
unfortunately only on anecdotes, is that this is not a good idea anyway,
since it uses too much space, and is also fairly expensive in copying cost.
(PARCPlace seems to have arrived at the same conclusion, so there's probably
at least one other supporter of this position. Some recent complaints here
about space usage of Modula-3 programs also point a bit in this direction.)

Do you agree? If so, should the interface be designed ignoring current
constraints, and should we initially accept a partial implementation?

John: It's been a while, so let me recap where we are, or at least where I
am.

We've been discussing mechanisms for Modula-3 programs to manage their
memory better. In particular, we have proposed ways that programs could
bound the heap size and recover from heap overflow.

I think this topic is complicated enough, and new enough, that we shouldn't
try to get it into the current set of portable interfaces. The Interface
Police concur.

We've floated two broad (families of) proposals for attacking this problem:

   * Allow strong guarantees on the heap size; these guarantees would never
     be broken.
   * Allow the program to monitor its memory usage, discarding excess data
     as necessary.

I think that the first is achievable. Adapting the current SRC Modula-3
(allocator and) collector to allow such guarantees would take a month or so.
The principal problem is that the current collector tries to maximize
space/time performance, and giving such guarantees will probably require
extra memory to be set aside that will never be used. The collector would
have two modes: with or without guarantees. Most programs would run without
guarantees.

I also think that a usable version of the second is possible with almost no
change to the current collector. The programmer would have to do more work,
and wouldn't get any strong guarantees, but this approach should work for
many programs.

We've also been discussing a third family of proposals, that seem to combine
the worst features of the first and second: they require significant changes
to the current collector, but son't give very strong guarantees. These seem
much less interesting to me.

Here's two pieces of opinion.

First, I propose that we work out the details of #2, and you use it for a
couple of programs. Get some experience with it. This could help inform a
heavier-weight solution.

Second, I wonder whether any of these solutions is a good candidate for a
portable interface. It's one thing not to be strictly incompatible with a
given collector strategy, but quite another to be easy to plug into an
existing collector. Modula-3 currently doesn't require very much from its
collector; making these proposals standard would significantly increase the
requirements on a Modula-3 implementor.

Is Modula-3 a superset of Modula-2?

No; valid Modula-2 programs are not valid Modula-3 programs. However, there
is a tool to help convert Modula-2 programs to Modula-3.

Meeting with other Modula-3 users

Modula-3 users meetings are held informally from time to time. A report from
the last meeting is available by FTP
(ftp://ftp.gte.com/pub/m3/m3ug/m3ug.html)

Why is Hello World so large?

Modula-3 programs are larger than C programs for the following reasons:

  1. The fixed runtime is substantially larger. It contains a garbage
     collector, a thread runtime, and exception support. Note that Hello
     World is virtually all runtime. For larger programs the runtime is not
     an issue.
  2. The generated code includes runtime checks for out-of-bound array
     references and NIL pointer. Many of these checks could be removed by a
     more sophisticated compiler.

Comparisons between Modula-3 and other languages?

From: laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI)

A Comparison of Modula-3 and Oberon-2 by myself in Structured Programming
1993, 14:15-22

From: nayeri@gte.com

Robert Henderson, Benjamin Zorn, A Comparison of Object-Oriented Programming
in Four Modern Languages, Department of Computer Science, University of
Colorado, Boulder, Colorado, Technical Report CU-CS-641-93
(ftp://ftp.cs.colorado.edu/pub/cs/techreports/zorn/CU-CS-641-93.ps.Z) .

The paper evaluates Oberon, Modula-3, Sather, and Self in the context of
object-oriented programming. While each of these programming languages
provide support for classes with inheritance, dynamic dispatch, code reuse,
and information hiding, they do so in very different ways and with varying
levels of efficiency and simplicity. A single application was coded in each
language and the experience gained forms the foundation on which the
subjective critique is based.

What is the story with Trestle and OpenWindows?

Mark Manasse says:

I think that the OpenWindows release should be enough (no need to get the
MIT X release), although there are a few things in Trestle that trigger
devastating bugs in OpenWindows. But the only library we depend on is Xlib,
R4 or later.

The main thing I know that crashes OW 2.0 is the code where we call GrabKey
specifying AnyKey. You can either loop over all of the keys, or you can just
comment out the call; programs won't run exactly the same, but you probably
won't notice the difference.

Linking with C++ code

Apparently there is no problem to call C++ functions declared as extern C.

From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)

You must use your C++ compiler as the linker, rather than /bin/cc or
/bin/ld.

You need to call the function '_main'. The easiest way to do this is to have
the following set of interfaces and implementations:

        INTERFACE CXXMain;
          <*EXTERN "_main"*> CxxMain;
        END CXXMain;

        MODULE CXXMain;
        BEGIN
          CxxMain();
        END;

and then import CXXMain into your M3 main module. This will ensure that the
C++ function _main gets called.

Flushing writers to see the output immediately

Modula-3 Writers are buffered. Thus, you need to issue a Wr.Flush when the
output should appear immediately, for instance to prompt the user for some
input. Since this can become annoying, libraries in other languages
sometimes offer the option of unbuffered writes. In Modula-3, an equivalent
behavior is obtained with AutoFlushWr which gets a background thread to
flush a writer at a specified interval.

Problems with threads and VTALARM

The threads are implemented using the virtual timer interrupt. Normally, the
run time environment will catch the interrupt and determine if thread
switching is appropriate. However, if a new process is created with fork, it
will have the virtual timer activated and no interrupt handler to receive
it, resulting in a core dump. If you use the standard procedure
Process.Create to fork new processes, this will be handled automatically for
you. If you insist on using fork, you need to disable the timer, fork and
then reenable the timer.

What is the purpose of BRANDED and REVEAL

Allan Heydon writes:

These two keywords are necessary because of two quite different features of
the language. REVEAL is necessary because Modula-3 has opaque types and
partial revelations. BRANDED is necessary because the Modula-3 type system
uses structural equivalence instead of name equivalence.

In Modula-3, the concrete structure of a type can be hidden from clients in
an interface. A common idiom is:

  INTERFACE I;

  TYPE
    T <: TPublic;
    TPublic = OBJECT
      (* fields *)
    METHODS
      (* methods *)
    END;

  END I.

The line "T <: TPublic" introduces the type "I.T" as an opaque subtype of
the type "I.TPublic". It does not reveal any of the other details of the
concrete structure of "I.T" to clients. Hence, "I.T" is said to be an opaque
type. Put another way, the structure of "I.T" is only partially revealed to
clients.

In addition, it is possible to reveal more of "I.T"'s structure in other
interfaces, like this:

  INTERFACE IRep;

  IMPORT I;

  TYPE
    TPrivate = I.TPublic OBJECT
      (* more fields *)
    METHODS
      (* more methods *)
    END;

  REVEAL
    I.T <: TPrivate;

  END IRep.

This interface declares a type "IRep.TPrivate" that is a subtype of
"I.TPublic". It also asserts that "I.T" is also a subtype of
"IRep.TPrivate". A client that imports only the interface "I" has access
only to the fields and methods in "I.TPublic" when accessing an object of
type "I.T", but a client that imports both "I" and "IRep" also has access to
the fields and methods in "IRep.TPrivate" when accessing an object of type
"I.T".

The "REVEAL" statement in this module simply asserts a subtype relation.
Unlike type declarations, revelations introduce no new names. Hence, we
could not have used the "TYPE" keyword in this case because the type "I.T"
has already been declared once (albeit opaquely) in interface "I".

Every opaque type must have a complete revelation. A complete revelation has
the form:

  REVEAL
    T = TConcrete;

The revelation specifies that "TConcrete" is the concrete type for the
opaque type "T".

The Modula-3 type system uses structural equivalence instead of name
equivalence. This means that two types are equal iff they have the same
structure. One consequence of this rule is that two types you might intend
to be distinct may actually be equal. This can have unintended effects on
the run-time behavior of your program. For example, if both types that you
expect to be distinct are actually structurally equivalent and the two types
guard two arms of a TYPECASE statement, the arm for the second type will
never be taken.

If you want to avoid accidental equalities between two types, you can brand
one (or both) of them with the BRANDED keyword. A branded type is equivalent
to no other type, even if it is structurally equivalent to some other type.
In essence, the BRANDED keyword adds a bit of virtual structure to the type
that guarantees it will be distinct from every other type.

The Modula-3 syntax allows you to supply a text constant as a name for the
brand. If you don't supply an explicit brand, the compiler will make one up;
however, the implicit brand invented by the compiler is not guaranteed to be
chosen deterministically. Hence, explicit brands are useful if you are
communicating types from one process to another and if you want to be sure
that the branded type written by one process matches the branded type read
in by the other.

Any two opaque types in a program must be distinct. Otherwise, it would be
too easy for clients to accidentally trip over type collisions like the
TYPECASE example mentioned above. To enforce the restriction that all opaque
types are distinct, the language requires that the type "TConcrete" in the
complete revelation above must be a branded type.

Why uppercase keywords

Some people prefer uppercase keywords others hate them. Another possibility
is to accept both forms for keywords. This topic has been discussed at
length and there is no solution that will completely satisfy everyone's
tastes. Fortunately this is a very minor issue and you can easily have
lowercase keywords automatically converted for you using an emacs macro
package like m3su (file://pion.lcs.mit.edu/pub/m3su) .

M3build versus Make or why m3 does not work

The Modula-3 compiler m3 does a much finer grained dependency analysis than
possible with make. For this reason, a very flexible front end, m3build,
reads the program description files, m3makefile, and generates the commands
required to compile and link Modula-3 programs and libraries. The m3makefile
content is documented in the m3build documentation. Calling the m3 compiler
directly is difficult and thus not recommended.

Missing RTHooks or similar messages

The standard library, libm3, is not included by default. You need in your
m3makefiles to import(``libm3'') or to import a library which imports libm3.
Otherwise, messages about run time procedures such as RTHooks not being
available are produced. See the information on m3build
(http://www.research.digital.com/SRC/modula-3/html/m3build/m3build.html)

The program receives a SEGV signal under the debugger

The garbage collector on some platforms uses the SEGV (segmentation
violation) signal to detect modified portions of the dynamically allocated
space. It is possible to disable this feature or to inform the debugger to
let these signals propagate. See the debugging tips
(http://www.research.digital.com/SRC/modula-3/html/debugging.html)

Exceptions raised by X or Network Objects applications

Graphical applications (based on Trestle/X Windows) raise the
TrestleComm.Failure exception when the DISPLAY environment variable is
incorrect or the X server is refusing the connection. They raise
MachineIDPosix.Failure if the network configuration files are incorrectly
set up, especially on LINUX; /etc/hosts must contain at least a loopback
address (127.0.0.1) and the /etc/rc scripts an appropriate ifconfig command
(/etc/ifconfig lo 127.0.0.1; /etc/route add 127.0.0.1). Applications with
Network Objects may also raise exceptions or consume all the CPU time
available when the network configuration files are incorrect.

X libraries not found

The position of X libraries is stored in, for instance for pre-compiled
LINUX binaries, the template file m3build/templates/LINUX as well as in
X11R4/LINUX/.M3EXPORTS. Thus you may want to edit these files if your X
libraries are located in an uncommon place.

Calling Modula-3 procedures from a C program

Calling Modula-3 from C is tricky because M3 has a more elaborate run-time
environment. The simplest solution is to make the main program M3 and then
call C via EXTERNAL routines. Calling back into M3 is then relatively
straightforward.

Here's an example. It calls the C code to lodge the identity of the M3
procedure to be called back which avoids having to know the actual name used
by the linker.

First a little M3 module to be called from C (M3code), then a C module
called by the M3 main and calling the M3 module (Ccode), and finally the
main program (Main):

(* M3code.i3 *)

INTERFACE M3code;
IMPORT Ctypes;
PROCEDURE put (a: Ctypes.char_star);
END M3code.

(* M3code.m3 *)

UNSAFE MODULE M3code;
IMPORT Ctypes, IO, M3toC;

PROCEDURE put (a: Ctypes.char_star) =
  BEGIN
    IO.Put (M3toC.StoT (a) & "\n");
  END put;

BEGIN
END M3code.

(* Ccode.i3 *)

<*EXTERNAL*> INTERFACE Ccode;
IMPORT Ctypes;
PROCEDURE set (p: PROCEDURE (a: Ctypes.char_star));
PROCEDURE act (a: Ctypes.char_star);
END Ccode.

/* Ccode.c */

typedef void (*PROC)();
static PROC action;

void set (p)
  PROC p;
  {
    action = p; /* register the M3 procedure */
  }

void act (a)
  char *a;
  {
    action (a); /* call the M3 procedure */
  };

(* Main.m3 *)

UNSAFE MODULE Main;

IMPORT Ccode, M3code, M3toC;

BEGIN
  Ccode.set (M3code.put);
  Ccode.act (M3toC.TtoS ("Hello world"));
END Main.

(* m3makefile *)

import(libm3)

interface ("Ccode")
c_source ("Ccode")
module ("M3code")
implementation("Main")
program("mixed")

How to copy heap objects?

Deep copies are easily performed using Pickles. An object graph is Pickled
to a text writer into a TEXT. Then, a copy is created by unpickling a new
object graph from a text reader created from the TEXT.

Shallow copies are less often needed but may be performed with the following
procedure:

PROCEDURE Duplicate (r: REFANY): REFANY =
  VAR
    tc     := TYPECODE (r);
    n_dims : INTEGER;
    res    : REFANY;
    shape  : RTHeapRep.ArrayShape;
  BEGIN
    IF (r = NIL) THEN RETURN NIL END;

    (* allocate a new object of the same type (and shape) as the old one *)
    RTHeapRep.UnsafeGetShape (r, n_dims, shape);
    IF (n_dims <= 0)
      THEN res := RTAllocator.NewTraced (tc);
      ELSE res := RTAllocator.NewTracedArray (tc, SUBARRAY(shape^, 0, n_dims));
    END;

    (* copy the old data into the new object *)
    RTMisc.Copy (RTHeap.GetDataAdr (r), RTHeap.GetDataAdr (res),
                 RTHeap.GetDataSize (r));

    RETURN res;
  END Duplicate;

Strange pragmas for Locking levels and other properties

The Trestle (ui library) interfaces contain Locking level pragmas. The base
interfaces (libm3 library) contain SPEC pragmas. These are not processed by
the compiler. Instead the Extended Static Checker, currently under
development at DEC SRC, will report on problems detected based on the
program content and the information specified in these pragmas [ESC]
(http://gatekeeper.dec.com/pub/misc/detlefs/escover.ps) . The Extended
Static Checker is not yet available, it may be some time in the future.

Reading a single character as soon as typed

Characters typed on the keyboard are usually buffered. They become visible
to the reading program only when the buffer is full or after, for example, a
carriage return is received. This is not specific to Modula-3. To access the
characters as they are typed, single character commands in a full screen
editor for example, the input reader must be configured properly.

From: rrw1000@cus.cam.ac.uk
(http://www.vlsi.polymtl.ca/m3/faq/questions/rrw1000@cus.cam.ac.uk) (Richard
Watts)

The POSIX way of doing it is to use tcsetattr(), and here is some code that
does it under Solaris 2.x (this was written for serial ports, but the same
thing applies) :

PROCEDURE Open(port : CHAR; timeout : INTEGER := 30) : T RAISES {Error} =
  VAR
    term : TcPosix.termios;
    file : TEXT;
    fd : T;
    rc : INTEGER;
  BEGIN
    (* Figure out which device we want to open : *)

    CASE port OF
      'A' => file := "/dev/ttya";
    | 'B' => file := "/dev/ttyb";
    ELSE RAISE Error("Invalid port " & Fmt.Char(port) & " specified.\n");
    END;

    (* Open it. 700 is a good default mode for serial ports. *)
    fd := Unix.open(M3toC.TtoS(file),  Unix.O_RDWR
                                            , 8_700);
    IF fd = -1 THEN
      RAISE Error("Open() on " & file & " failed.\n");
    END;

    (* Get the termios structure for it *)
    rc := TcPosix.tcgetattr(fd, ADR(term));
    IF rc # 0 THEN
      EVAL Unix.close(fd);
      RAISE Error("Couldn't get terminal attributes for " & file & ".\n");
    END;

    (* Modify the termios structure *)

    (* The default baud rate is right, but we'd better set it anyway
       in case someone left it set up wrong : *)
    rc := TcPosix.cfsetospeed(ADR(term), TcPosix.B9600);

    IF rc # 0 THEN
      EVAL Unix.close(fd);
      RAISE Error("Couldn't set output speed for " & file & "\n");
    END;

    rc := TcPosix.cfsetispeed(ADR(term), TcPosix.B9600);

    IF rc # 0 THEN
      EVAL Unix.close(fd);
      RAISE Error("Couldn't set input speed for " & file & "\n");
    END;

    (* Modify the line discipline - reset ECHO and ICANON *)
    term.c_lflag := Word.And( term.c_lflag,
                              Word.Not(
                                  Word.Or(TcPosix.ICANON,
                                          TcPosix.ECHO)));
    term.c_cc[TcPosix.VMIN] := 0;
    term.c_cc[TcPosix.VTIME] := 0; (* Set up timing right *)

    (* Now reset the terminal attributes *)
    rc := TcPosix.tcsetattr(fd, TcPosix.TCSANOW, ADR(term));

    IF rc # 0 THEN
      EVAL Unix.close(fd);
      RAISE Error("Can't set attributes for " & file & "\n");
    END;
    RETURN fd;
  END Open;

(TcPosix.i3 is one of my interfaces, not libm3's, and I'll supply it if you
like, but it's just a wrapper to tcgetattr and friends. The baud rate stuff
shouldn't be necessary for terminals (or serial ports..) ). You should be
able to somehow get an Rd.T out of this, I think, but it may involve a bit
of hacking. The University of Cambridge can't have these opinions even if it
wants them.

CONST Comments in Variables Declarations

John Kominek (kominek@links.uwaterloo.ca) wrote: Sprinkled throughout SRC m3
you'll find "constant" variables exported in interfaces. For instance,


   VAR (*CONST*) Grain: LONGREAL;

where Grain is assigned during module initialization. Instead, did the
modula-3 designers consider doing this.


   READONLY Grain: LONGREAL;

Here the keyword permits only exporting modules to modify the Grain
variable. Is there a problem with this proposal? The READONLY keyword is
successfully used at procedure boundaries, so why not also at interface
boundaries?

Bill Kalsow replies:

A problem with this proposal is that any module can claim to export the
interface containing the variable, hence any module could modify the
variable. Note that CONST says more than just READONLY. CONST implies that
the variable should not be modified by clients and that once it is
initialized, it won't be changed later by the implementation. READONLY would
only mean that clients should not modify the variable. IMO, the "right"
solution would have been to allow:

    INTERFACE Foo;
    CONST x: T;

    MODULE Foo;
    CONST x: T := <value>;

In the same way it checks revelations for opaque types, the compiler could
check that only one module provided a value for the constant. But, this
proposal doesn't quite hang together either. Consider this example:

    CONST x: INTEGER;
    VAR   v: [0..x];

The language definition says that "v"s definition is illegal if "x < 0"
because its type is "empty". The system could refuse to run the program by
delaying the check until it had seem the corresponding implementation
module. But, I think you'll agree that it could quickly turn into a mess.
The most flexible handling of opacity I've seen is in Christian Collberg's
PhD Thesis, "Flexible Encapsulation". It was published Dec 5, 1992 by the CS
Dept at Lund University, Lund Sweden. If I remember correctly, his system
was capable of deferring all checks and decisions imposed by opaque
declarations until link time.

Commercial offerings

Prime Time Freeware offers Modula-3 sources on CD-ROM

Prime Time Freeware (PTF) includes Modula-3. PTF is a set of two ISO-9660
CDroms filled with 3GB of freeware, issued semi-annually. PTF is distributed
via bookstores and mail. You can reach PTF using:

        Email:  ptf@cfcl.com
        Fax:    [1] (408) 738 2050
        Voice:  [1] (408) 738 4832
        Mail:   Prime Time Freeware
                415-112 N. Mary Ave., Suite 50
                Sunnyvale, CA 94086
                USA

Bookstores

If you cannot find some of the Modula-3 books at your favorite bookstore,
here are bookstores connected to the net known to carry them: UCI Bookstore
(http://bookweb.cwis.uci.edu:8042/HomeTest.html) , Roswell Electronic
Computer Bookstore
(gopher://owl.nstn.ns.ca/11/Other%20Gophers%20in%20Nova%20Scotia/Roswell%20Electronic%20Computer%20Bookstore)
(rjames@fox.nstn.ns.ca)

Commercial Support

Critical Mass Corporation offers an integrated development environment for
Modula-3, Reactor (http://www.cmass.com/reactor/) , as well as training and
consulting services CM (http://www.cmass.com/)

Modula-3 for teaching

Modula-3 is very well suited for teaching: simple yet powerful, and safe. It
avoids the complexity of legacy languages. It can be used to demonstrate
modules and interfaces, object oriented programming, multi-threading
(concurrency issues), graphical user interfaces (Trestle, VBTKit, FormsVBT)
and even distributed programming (Network Objects, Obliq). Since less time
is spent by students and teaching assistants chasing dangling pointers and
corrupted data, more time is available for learning the important concepts.

Several informal studies seem to corroborate the previous observation. At
Ecole Polytechnique de Montreal, the introductory course was taught in both
C and Pascal to different presumably equivalent groups. The marks followed a
normal distribution in the Pascal groups while there was a long thick tail
in the C groups. The interpretation of the instructors was that very good
students did well irrespective of the language while average students got
stuck in the language problems and failed to learn/use a number of important
programming concepts. More to the point, a project class at the Royal
Institute of Technology of Sweden offered a choice of three languages
(Modula-3, Borland Pascal, C++) to the students and the completion rates
were measured.

Modula-3 is used for teaching in a number of universities. This list is far
from complete, send corrections and additions to dagenais@vlsi.polymtl.ca.

An interesting discussion about Modula-3 for teaching appeared in the
Threads newsletter (http://www.cmass.com/threads/2/#academia) .

University of Waterloo, Ontario

From: Carsten Whimster (bcrwhims@undergrad.math.uwaterloo.ca)

University of Waterloo:

CS246 - Third introductory course in computer science. Software engineering
and software systems. Medium size projects. Uses Modula-3 to demonstrate
proper OO programming, as well as general programming practices.

CS241 - Fourth and final intro course to CS. Focuses mainly on compilers and
languages. Various assignments has students create most of the different
parts of a compiler. Also introduces Scheme (lisp).

University of Cambridge

From: Peter.Robinson@cl.cam.ac.uk

University of Cambridge, England.

The Computer Science course at the University of Cambridge teaches ML as an
introductory language at the beginning of the freshman year, and then uses
Modula-3 to develop imperative programming at the end of that year. Further
lectures on advanced features of the language are given early in the second
year, together with separate lectures on other, specialised languages.

The course has been given to about 70 students each year since 1990, and has
developed with the language. It ties in with other lectures on data
structures and algorithms, software engineering and concurrency. Modula-3 is
used for student group projects in the second year and for about a quarter
of individual projects in the final year (where, interestingly, students
using Modula-3 tend to earn higher grades than those using C/C++).

Modula-3 is also used in the Computer Laboratory at Cambridge for a number
of research projects on distributed computing, human-computer interaction
and electronic CAD.

Queen Mary and Westfield College, London

From: Matthew.Huntbach@dcs.qmw.ac.uk

We have used it for three years here at Queen Mary and Westfield College,
London. The main problem I find with the language is the slow compilation
speed on our teaching machines (Macs running A/UX), otherwise it's a nice
language to teach with.

University Klagenfurt

From: laszlo@ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI)

Modula-3 is used at the following courses: Undergraduate:
Softwaretechnology-1 (actually an introduction into programming) (on PCs)
Softwaretechnology-2 (data structures and algorithms) (on PCs) Graduate:
Computer Networks (on a network of DECs and SUNs) Parallel Programming (on
an DEC-Alpha Farm)

Modula-3 has been in use since ca. one year, with very good experiences.

Lehrstuhl fuer Informatik III

From: pk@i3.informatik.rwth-aachen.de (Peter Klein) Lehrstuhl fuer
Informatik III, RWTH Aachen, Germany: Software Development Projects, now
held for the second time using Modula-3. Aim of these projects is to
introduce different aspects of software development to graduate students.
This includes project planning, supervision, design, and cooperative
implementation of small but usable software systems. Central ideas of
software design and object-oriented implementation are presented and
discussed with the concepts of Modula-3, which is also the implementation
language.

Future plans: Maybe Modula-3 will replace Modula-2 in some undergraduate
programming lectures in the future.

Royal Institute of Technology, Sweden

From: viggo@nada.kth.se

Royal Institute of Technology. Several courses at the computer science
department use Modula-3. The courses contain programming projects, and many
students choose to use Trestle. (Dr. Viggo Kann, viggo@nada.kth.se)

Last year we had a programming project course where we recommended the
students to use Modula-3, but some project groups chose to use C++ or
Borland Pascal. Most of the groups using Modula-3 did complete the course in
time, while many of the others did not:

Modula-3:
     85 % in time (22 of 26)
Borland Pascal
     67 % in time (2 of 3)
C++
     0 % in time (0 of 4)

All the students that considered themselves "not so good programmers" chose
Modula-3, and all the students that chose C++ already knew the language, and
were quite experienced programmers. In spite of this the Modula-3 groups
completed their work long before the C++ groups! And I must say that the
code the Modula-3 groups wrote was much better than the code of the C++
groups.

University of Manchester

From: Dave Snelling (snelling@cs.man.ac.uk)

Department of Computer Science, University of Manchester, Manchester U.K. We
have a small, interdisciplinary collection of people using Modula-3 for a
variety of activities. Our major production code is a hardware architecture
simulator (about 120 modules). Smaller projects include a Lattice Gass model
and a Shallow Water model.

University of Massachusetts at Amherst

At: University of Massachusetts at Amherst

Modula-3 is used as an input language for the Computer Science course on
Compilation techniques. The professor is Eliot Moss.

Ecole Polytechnique de Montreal

From: Michel Dagenais (dagenais@vlsi.polymtl.ca)

Modula-3 is used as the main example in an undergraduate course on object
oriented programming and in a graduate course on ``Algorithmic Aspects of
CAD'', which includes a large portion on OO programming and databases.

State University of New York at Stony Brook

From: pbh@cs.sunysb.edu (Peter Henderson)

Modula-3 is currently used for teaching Computer Science I and Computer
Science II at SUNY at Stony Brook. We are currently developing a sequence of
laboratory assignments and case studies introducing OO techniques and
software reuse in these two courses.

The first course for computer science majors at Stony Brook is "Foundations
of Computer Science" which emphasizes general problem solving, mathematics
and the relationships between mathematics and computer science. There is an
extensive laboratory component using theorem provers, Prolog and Standard
ML.

Vassar College

From: miclemen@cs.vassar.edu (M. Keith Clemens)

Vassar College has been using Modula-3 in its computer science curriculum
for a few years now.

Computer Science II is taught in Modula-3 as an introduction to imperative
languages. Many students use it in later courses. A Ray Tracer and a couple
Compilers have been written in M3.

A course in interpreters and functional languages also uses Modula-3.

University of Kent at Canterbury

From: Richard Jones <R.E.Jones@ukc.ac.uk>

M3 is also used as the first imperative language on the Computer Science
specialist degrees at the University of Kent at Canterbury. For more
details, see http://stork.ukc.ac.uk/computer_science/
(http://stork.ukc.ac.uk/computer_science/)

Concordia University

Modula-3 is used throughout the assignments for the course Comp346
(http://www.cs.concordia.ca/~teaching/comp346) on Operating Systems Concepts
at Concordia University.

Universita Ca Foscari, Venice

Modula-3 is used throughout the assignments for the programming course
Laboratorio di Programmazione
(http://www.dsi.unive.it/~cortesi/Modula3/tamc.html) at Universita Ca
Foscari, Venice.

Colorado State University

Students have a choice of Modula-3 or C++ for the computer science course
CS370 (http://www.cs.colostate.edu/~cs370/syllabus.html) at Colorado State
University.

Modula-3 In Industry

A number of programming teams in industry selected Modula-3 for their
project. It encourages good programming practices and comes with excellent
libraries for distributed programming and graphical user interfaces.

This includes projects such as a fault tolerant client-server application
for 911 emergency call handling, entirely written in Modula-3, and featuring
computer integrated telephony, access to local and remote databases and
hypertext documents.

Geoffrey Wyant, Sun Microsystems Labs BOS

Sun Microsystems Laboratories, Inc. (East) is using Modula-3 (Network
Objects, FormsVBT) as the basis for its research in large scale distributed
object systems. (gwyant@cloyd.East.Sun.COM)

Farshad Nayeri, GTE Labs

Distributed Object Computing, GTE Labs, Waltham, Massachusetts USA Modula-3
(FormsVBT, Sx, Netobj libraries) is used to prototype distributed object
management. (Farshad Nayeri nayeri@gte.com). See the report
(file://ftp.gte.com/pub/dom/reports/NAYE93c.ps)

Modula-3 related projects

ILU, an object-oriented multi-lingual RPC-capable module system

WHAT'S ILU?

ILU (pronounced eye'-loo) is a system that promotes software
interoperability via interfaces. Interfaces between what? Whatever units of
program structure are desired; we call them by the generic term "modules".
They could be parts of one process, all written in the same language; they
could be parts written in different languages, sharing runtime support in
one memory image; they could be parts running in different memory images on
different machines (on different sides of the planet). A module could even
be a distributed system implemented by many programs on many machines. Calls
across ILU interfaces involve only as much mechanism as necessary for the
calling and called modules to interact. In particular, when the two modules
are in the same memory image and use the same data representations, the
calls are direct local procedure calls - no stubs or other RPC mechanisms
are involved.

ILU modules are known by their interfaces. A module interface is specified
once in ILU's object-oriented Interface Specification Language (called,
simply, ISL). For each of the particular programming languages supported by
ILU (currently Common Lisp, ANSI C, C++, and Modula-3; Python, Tcl, and GNU
Emacs-Lisp are in the works), a version of the interface in that particular
programming language can be generated. The ILU kernel library provides
services which may be used by the language-specific interface to overcome
intermodule language or address space differences.

GETTING THE RELEASE

The release is only available via FTP from the PARC ftp server. Perhaps the
simplest way is to go through our World Wide Web home page, ILU
(ftp://parcftp.parc.xerox.com/pub/ilu/ilu.html)

CONTRIBUTORS

Antony Courtney, Doug Cutting, Bill Janssen, Denis Severson, Mike Spreitzer,
Mark Stefik, Farrell Wymore

ILU was ported to SRC Modula-3 3.5, (ILU-M3)
(http://www.cc.gatech.edu/gvu/people/Phd/Ian/ilu-m3.html) at Georgia Tech.

Extended Static Checking for Modula-3

Through the use program flow analysis, with the help of formal properties
asserted for Modula-3 modules using a language similar to Larch for Modula-3
(http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-072.html)
, the extended static checker, esc
(http://www.research.digital.com/SRC/esc/Esc.html) , can detect problems and
remove unneeded instructions (bounds and pointer checks).

idlm3: An OMG IDL to Modula-3 Translator

Using "idlm3" you can translate OMG IDL definitions into Modula-3
interfaces, which can be used to build "CORBA-compliant" distributed
applications. We suggest using DEC SRC's Modula-3 Network Objects as your
interprocess communication mechanism, and we automate part of that process
for you. You can also invoke CORBA-style dynamic invocations on top of
IDL-defined Network Objects using idlm3 (ftp://ftp.gte.com/pub/m3/idlm3) .

SPIN: an extensible operating system written in Modula-3

From: savage@gyrate.cs.washington.edu (Stefan Savage)

I'd like to contribute the positive experience that we've had at the
University of Washington building SPIN, an extensible OS kernel written
almost entirely in Modula-3.

We found that creating a minimal version of the M3 runtime library (which we
call libm3s) we actually quite easy and straightforward. The basic runtime
services require very little OS infrastructure (basically, a way to switch
register state, print and allocate memory). We use both threads and garbage
collection and neither of these posed significant implementation problems.
As a caveat, since we aren't building SPIN within a legacy system, we don't
have as many problems wrt unprotected data movement between the GC'd
Modula-3 environment and C's explicit storage management environment as one
might have in Linux. For those few cases where we did need to call M3 code
from C (bootstrap code mainly) we added a simple feature to the compiler to
generate .h files that associate a name with the proper offset from the
module symbol, eg: #define Module__Procedure (*(_PROC*)((char
*)(&MI_Module)+88)) which gives us a convenient C syntax for invoking
Modula-3 procedures from C code.

SPIN supports the use of arbitrary language programs (ie you can write in C,
or Scheme if you are so inclined) running in user space which is
straighforward since these programs only use the services provided by the
kernel, not the language, runtime or storage model.

We haven't experienced any performance problems associated with using
Modula-3, in fact our performance numbers are quite good (check our Web page
it you're interested in the details). For latency critical applications we
expect to see some impact from the current GC infrastructure which is
leading us to look at some alternative automatic storage tehcniques.

Our only significant problems with Modula-3 as a systems language have had
nothing to do with performance, size, threads or GC, but rather the
relationship between the type system and IO. The implicit relationship in
memory between typecells and their data makes it difficult to manage data
layout independent of type (you may find a UDP typecode rudely appearing
where you expected your IP destination address to be). Also, when processing
storage from outside the type system (eg from a hardware device) we require
a way to impose structure on this raw memory, and we're loath to require the
use of LOOPHOLE for an operation which is not inherently unsafe.

For those interested in the project, please feel free to contact me or any
of our other members. See the SPIN home page
(http://www.cs.washington.edu:80/research/projects/spin/www) .

Juno-2 Constraint-Based Drawing Editor

Juno (http://www.research.digital.com/SRC/juno-2/) is a sophisticated
constraint based drawing editor.

M3NA: Modula-3 Numerical Analysis Library

This library, m3na (http://www.eskimo.com/~hgeorge/m3na) , contains a large
number of fully documented mathematical functions such as polynomials,
roots, vectors, matrices, statistics, Fast Fourier Transforms...

CVSup: replicating CVS code repositories

This interesting project is entirely coded in Modula-3 (CVSup)
(ftp://freefall.freebsd.org/pub/CVSup) .

Work In Progress

The purpose of this section is to let everyone know what is being worked on.
This is not a commitment to a quick release or even to completion. However
it may enable parties interested in the same topics to pool their efforts,
avoid duplication or better integrate their packages.

To find more information about the names mentioned, see the Who's Who
section.

Integrated Development Environment

A number of groups have made experiments in this area. Tools such as VBTkit
for the user interface, m3tk for syntax and dependency analysis, dynamic
linking... could be used to produce such an environment. It is worth noting
that precompiled interfaces are much easier to achieve in M3 than in several
other popular languages.

Peter Klein is working on a Modula-3 development environment and associated
user interface. See the report
(file://ftp.informatik.rwth-aachen.de/pub/reports/1994/94-16.ps.gz) entitled
``Designing Software with Modula-3'', it describes a software architecture
description language based on Modula-3.

Klaus Preschern, Carsten Weich, Laszlo Boszormenyi have made the port of
Modula-3 to the PC. The M3-PC environment will be enhanced, especially with
threads and graphics, including a student-friendly environment.

David N. Gray of Lucid Inc. has been experimenting with connecting the
Modula-3 compiler with the Lucid Energize Programming System (currently sold
as a development environment for C and C++ on Sun SPARCstations). The
modified compiler
(ftp://lucid.com/pub/hacks/energize/energize-modula-3.html) is available as
an unsupported as-is hack, to accompany the new Energize release that it
works with.

Rotated Text

X11R6 now supports rotated text. Each character is individually rotated in
the font but the baseline remains horizontal. Facilities to position each
character appropriately could be added to Trestle.

Postscript VBT

It is often useful to display Postscript files in a VBT, for example for an
included diagram in a document editor.

This can be achieved by using the ghostscript Postscript interpreter as a
rasterizer. A prototype has been programmed by Alain Dube (contact Michel
Dagenais) but the performance is not too good when large color bitmaps are
handled. An alternative implementation is to convert Postscript files into
display lists (Bezier curves and text) as a preprocessing step. Further
displaying and even editing becomes very simple. A prototype implementation
of this has been done by Benoit Poirier (contact Michel Dagenais).

Abstract Syntax Tree Tools (M3 Parser)

The m3tk library can be used to analyze Modula-3 source code in order to
find specific constructions (use of OBSOLETE facilities, un-handled
exceptions), build source code browser and analysis tools, stubs generators
for network or persistent objects... Mick Jordan is working on the
documentation, in his spare time.

From: hudson@yough.ucs.umass.edu (Rick Hudson)

If anyone is interested we have developed a Bison grammar that parses the
Modula-3 language input. If interested please feel free to contact me
hudson@cs.umass.edu.

Persistence through reachability

Tony Hosking and Eliot Moss are working on persistent Modula-3 objects
(ftp://ftp.cs.umass.edu/pub/osl/papers) . The main features are persistence
through reachability, load on demand and a very low overhead for using
persistent objects. The high performance is obtained by modifying the
compiler and run-time. Initially a modified version of GCC, GNU M3, was
being worked on. However, with the release of the SRC native compiler, the
modifications are being moved to the SRC compiler instead.

Presentations, Tutorials And Teaching Material

Modula 3 is used for teaching in a number of Universities. Some Modula-3
related teaching material may be shared between interested parties.

Geoff Wyant has prepared a tutorial on Modula-3 for OOPSLA.

Computer Assisted Learning Tools (Algorithm Animation)

The Zeus Algorithm Animation package may be used to quickly develop
graphical and animated teaching aids. Most of the algorithms described in
Robert Sedgewick's Algorithms book have been animated at DEC SRC through the
work of Marc H. Brown.

Animation of compilation techniques have been produced by students at
University of Illinois with the help of Marc Najork.

From: Arnulf Mester (mester@ls4.informatik.uni-dortmund.de)

As part of a studental project advised by a college of mine and me a
Mentor-like collection of Zeus-based animations of typical distributed
algorithms and communication protocols (termed ZADA) has been compiled.
Hopefully I'll get to include more information and access during the next
weeks into our ZADA home page
(http://ls4-www.informatik.uni-dortmund.de/RVS/zada.html)

Reports And Books

Sam Harbison is preparing a revised version of his existing book on
Modula-3. He may include more material on the new libraries.

Laszlo Boszormenyi, Roland Mittermeir and Carsten Weich are working on a
book (it will be published in German and in English) with the work-title:

Programming in Style - An Introduction into Programming with Modula-3

The book will be published at Springer (in German in October 1994, in
English maybe or December, or January 1995). For the book, the M3-PC
environment will be enhanced, especially with threads and graphics,
including a student-friendly environment.

From: BERGINF@PACEVM.DAC.PACE.EDU (Joseph Bergin)

I am also at work on a Modula-3 college level textbook. It will cover the
data structures course and will stress data abstraction. It will be similar
to my current book: Data Abstraction: The Object-Oriented Approach using
C++, published by McGraw Hill. Status: The software has been built and I am
currently writing the text itself. Joe Bergin, berginf@pacevm.dac.pace.edu,
Pace University

Parallel Programming

From: Ernst A. Heinz, University of Karlsruhe, F.R. Germany (email:
heinze@ira.uka.de)

I would like to inform you about our ongoing Modula-3* project here at the
University of Karlsruhe. At the moment, we are actively involved in adding
sophisticated dependence and data flow analysis to DEC's Modula-3 compiler
(release 3.x!). The Modula-3* compiler will be able to generate code for
real parallel machines, for networks of workstations, and for standard
sequential execution. (Our new IPD Modula-2* system available by FTP
(ftp://ftp.ira.uka.de/pub/programming/modula2star) may give you an initial
feeling about it!)

For all interested folks I have made my JSPP'93 paper publicly available by
anonymous ftp. The title of the paper
(file://i41s10.ira.uka.de/pub/m3s/jspp93.ps) reads as follows: Modula-3*: An
Efficiently Compilable Extension of Modula-3 for Problem-Oriented Explicitly
Parallel Programming.

More recent work includes

E.A. Heinz. Sequential and parallel exception handling in Modula-3*: A
unifying semantics specification. In P. Schulthess (editor). Advances in
Modular Languages: Proceedings of the Joint Modular Languages Conference,
pages 31-49, Ulm, Germany, September 28-30, 1994, electronic version
(file://i41s10.ira.uka.de/pub/m3s/jmlc94.ps.gz)

Wanted list

The Modula-3 development environment now contains a large number of very
good tools and libraries that work nicely together. The purpose of this
section is to help contributors determine what additions would be helpful to
others. It may get you in contact with people that would like to use your
contribution or with people that may provide some items on your wanted list
or team with you for their development.

(http://www.vlsi.polymtl.ca/m3/faq/wanted/)

List of Modula-3 contributors and enthusiasts

(http://www.vlsi.polymtl.ca/m3/faq/who/)

Modula-3 packages

A large number of Modula-3 packages are available in source code form. You
are invited to contribute some more, either at the Modula-3 home at DEC SRC
(m3@src.dec.com) or here (dagenais@vlsi.polymtl.ca).

Miscellaneous in progress Modula-3 packages

   * Second release of the LINUXELF backend (2 files, 562417 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/beta/m3backelf/)
   * Modula 3 compiler generating the _m3main.o file without gcc (485 files,
     2151860 bytes) (http://www.vlsi.polymtl.ca/m3/pkg/beta/m3-new/)
   * Modula-3 HTML package (74 files, 535398 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/beta/htmlkit/)

SRC Modula-3 packages

These packages were developed by the DEC Systems Research Center. The latest
version is release 3.6. A number of fixes and enhancements are included
here.

   * README (349 bytes) (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/README)

   * Subdirectory 'PEX' (6 files, 260496 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/PEX/)
   * Subdirectory 'X11R4' (31 files, 438863 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/X11R4/)
   * Subdirectory 'anim3D' (183 files, 845486 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/anim3D/)
   * Subdirectory 'badbricks' (6 files, 29775 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/badbricks/)
   * Subdirectory 'bicycle' (17 files, 98481 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/bicycle/)
   * Subdirectory 'buildlectern' (32 files, 299739 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/buildlectern/)
   * Subdirectory 'calculator' (7 files, 10635 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/calculator/)
   * Subdirectory 'cg-burs' (24 files, 406534 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/cg-burs/)
   * Subdirectory 'codeview' (18 files, 81007 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/codeview/)
   * Subdirectory 'columns' (18 files, 53610 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/columns/)
   * Subdirectory 'coverage' (8 files, 28315 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/coverage/)
   * Subdirectory 'cube' (17 files, 179432 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/cube/)
   * Subdirectory 'deckscape' (44 files, 94459 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/deckscape/)
   * Subdirectory 'digraph' (21 files, 153850 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/digraph/)
   * Subdirectory 'dps' (65 files, 241141 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/dps/)
   * Subdirectory 'dpsslides' (9 files, 15491 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/dpsslides/)
   * Subdirectory 'editlectern' (11 files, 41891 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/editlectern/)
   * Subdirectory 'fisheye' (51 files, 450394 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/fisheye/)
   * Subdirectory 'formsedit' (24 files, 114144 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/formsedit/)
   * Subdirectory 'formsvbt' (21 files, 332375 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/formsvbt/)
   * Subdirectory 'formsvbtpixmaps' (14 files, 40028 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/formsvbtpixmaps/)
   * Subdirectory 'fours' (13 files, 72891 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/fours/)
   * Subdirectory 'gnuemacs' (29 files, 479953 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/gnuemacs/)
   * Subdirectory 'http' (25 files, 207639 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/http/)
   * Subdirectory 'images' (11 files, 99468 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/images/)
   * Subdirectory 'jvideo' (60 files, 201833 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/jvideo/)
   * Subdirectory 'lectern' (64 files, 440160 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/lectern/)
   * Subdirectory 'lecternclient' (21 files, 40833 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/lecternclient/)
   * Subdirectory 'lecterndoc' (6 files, 21516 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/lecterndoc/)
   * Subdirectory 'lecterntohtml' (15 files, 35543 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/lecterntohtml/)
   * Subdirectory 'libm3' (527 files, 1487121 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/libm3/)
   * Subdirectory 'llscan' (18 files, 106699 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/llscan/)
   * Subdirectory 'm3' (20 files, 136878 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3/)
   * Subdirectory 'm3back' (14 files, 251044 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3back/)
   * Subdirectory 'm3browser' (12 files, 120651 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3browser/)
   * Subdirectory 'm3build' (55 files, 433899 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3build/)
   * Subdirectory 'm3build2' (5 files, 17906 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3build2/)
   * Subdirectory 'm3bundle' (6 files, 17634 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3bundle/)
   * Subdirectory 'm3core' (1457 files, 5477479 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3core/)
   * Subdirectory 'm3front' (376 files, 1494497 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3front/)
   * Subdirectory 'm3linker' (30 files, 121664 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3linker/)
   * Subdirectory 'm3loader' (26 files, 134961 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3loader/)
   * Subdirectory 'm3markup' (22 files, 103812 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3markup/)
   * Subdirectory 'm3middle' (47 files, 369661 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3middle/)
   * Subdirectory 'm3objfile' (12 files, 79058 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3objfile/)
   * Subdirectory 'm3quake' (20 files, 90470 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3quake/)
   * Subdirectory 'm3ship2' (5 files, 16741 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3ship2/)
   * Subdirectory 'm3staloneback' (5 files, 7627 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3staloneback/)
   * Subdirectory 'm3tests' (2191 files, 933021 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3tests/)
   * The Toolkit for Modula-3 code Parsing and Analysis (502 files, 2486386
     bytes) (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3tk/)
   * Subdirectory 'm3tohtml' (24 files, 90644 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3tohtml/)
   * Subdirectory 'm3tohtmlf' (4 files, 4074 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3tohtmlf/)
   * Subdirectory 'm3tools' (11 files, 45414 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3tools/)
   * Subdirectory 'm3totex' (10 files, 26914 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3totex/)
   * Subdirectory 'm3where2' (5 files, 16525 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3where2/)
   * Subdirectory 'm3zume' (37 files, 112858 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/m3zume/)
   * Subdirectory 'mentor' (614 files, 1753337 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/mentor/)
   * Subdirectory 'metasyn' (13 files, 83287 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/metasyn/)
   * Subdirectory 'mg' (40 files, 219950 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/mg/)
   * Subdirectory 'mgkit' (36 files, 270823 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/mgkit/)
   * Subdirectory 'motif' (24 files, 160311 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/motif/)
   * Subdirectory 'mtex' (17 files, 122017 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/mtex/)
   * Subdirectory 'netobj' (119 files, 332826 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/netobj/)
   * Subdirectory 'netobjd' (9 files, 14059 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/netobjd/)
   * Subdirectory 'obliq' (49 files, 87461 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliq/)
   * Subdirectory 'obliqbin3D' (6 files, 8127 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqbin3D/)
   * Subdirectory 'obliqbinanim' (6 files, 7526 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqbinanim/)
   * Subdirectory 'obliqbinmin' (6 files, 7108 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqbinmin/)
   * Subdirectory 'obliqbinstd' (6 files, 7318 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqbinstd/)
   * Subdirectory 'obliqbinui' (6 files, 7380 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqbinui/)
   * Subdirectory 'obliqlib3D' (207 files, 614835 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqlib3D/)
   * Subdirectory 'obliqlibanim' (6 files, 73817 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqlibanim/)
   * Subdirectory 'obliqlibm3' (6 files, 49137 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqlibm3/)
   * Subdirectory 'obliqlibui' (7 files, 93721 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqlibui/)
   * Subdirectory 'obliqparse' (15 files, 80465 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqparse/)
   * Subdirectory 'obliqprint' (10 files, 49286 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqprint/)
   * Subdirectory 'obliqrt' (34 files, 252360 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqrt/)
   * Subdirectory 'obliqsrvstd' (6 files, 7739 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqsrvstd/)
   * Subdirectory 'obliqsrvui' (6 files, 7825 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/obliqsrvui/)
   * Subdirectory 'ocr' (21 files, 85442 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/ocr/)
   * Subdirectory 'opengl' (15 files, 143460 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/opengl/)
   * Subdirectory 'parseparams' (6 files, 19067 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/parseparams/)
   * Subdirectory 'pkgfprint' (11 files, 24988 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/pkgfprint/)
   * Subdirectory 'pkgobj' (45 files, 128753 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/pkgobj/)
   * Subdirectory 'pkgq' (8 files, 117429 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/pkgq/)
   * Subdirectory 'pkgsrv' (49 files, 282013 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/pkgsrv/)
   * Subdirectory 'pkgtool' (7 files, 92575 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/pkgtool/)
   * Subdirectory 'postcard' (64 files, 515008 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/postcard/)
   * Subdirectory 'pp' (35 files, 582501 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/pp/)
   * Subdirectory 'quake' (52 files, 173626 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/quake/)
   * Subdirectory 'realgeometry' (16 files, 85716 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/realgeometry/)
   * Subdirectory 'recordheap' (6 files, 5994 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/recordheap/)
   * Subdirectory 'rehearsecode' (9 files, 25562 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/rehearsecode/)
   * Subdirectory 'replayheap' (6 files, 15488 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/replayheap/)
   * Subdirectory 'set' (11 files, 26059 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/set/)
   * Subdirectory 'sharedboard' (69 files, 161317 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/sharedboard/)
   * Subdirectory 'showheap' (6 files, 28386 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/showheap/)
   * Subdirectory 'shownew' (8 files, 27009 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/shownew/)
   * Subdirectory 'showthread' (6 files, 15612 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/showthread/)
   * Subdirectory 'sil' (33 files, 111825 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/sil/)
   * Subdirectory 'slisp' (14 files, 86885 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/slisp/)
   * Subdirectory 'smalldb' (8 files, 26451 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/smalldb/)
   * Subdirectory 'solitaire' (13 files, 95287 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/solitaire/)
   * Subdirectory 'src' (4 files, 54375 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/src/)
   * Subdirectory 'stable' (42 files, 134266 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/stable/)
   * Subdirectory 'stablegen' (31 files, 145740 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/stablegen/)
   * Subdirectory 'stubgen' (33 files, 144537 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/stubgen/)
   * Subdirectory 'synex' (9 files, 88828 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/synex/)
   * Subdirectory 'synloc' (8 files, 16015 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/synloc/)
   * Subdirectory 'table-list' (7 files, 11149 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/table-list/)
   * Subdirectory 'tcl' (17 files, 56538 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/tcl/)
   * Subdirectory 'tcp' (33 files, 105529 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/tcp/)
   * Subdirectory 'tcpextras' (16 files, 24428 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/tcpextras/)
   * Subdirectory 'tempfiles' (6 files, 10798 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/tempfiles/)
   * Subdirectory 'tetris' (6 files, 54989 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/tetris/)
   * Subdirectory 'ui' (346 files, 1760633 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/ui/)
   * Subdirectory 'vbtkit' (243 files, 1632840 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/vbtkit/)
   * Subdirectory 'videovbt' (18 files, 74547 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/videovbt/)
   * Subdirectory 'visualobliq' (98 files, 484569 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/visualobliq/)
   * Subdirectory 'vocgi' (10 files, 51879 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/vocgi/)
   * Subdirectory 'voquery' (5 files, 7120 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/voquery/)
   * Subdirectory 'vorun' (12 files, 82216 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/vorun/)
   * Subdirectory 'web' (6 files, 28583 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/web/)
   * Subdirectory 'webcard' (68 files, 547989 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/webcard/)
   * Subdirectory 'webcat' (7 files, 17840 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/webcat/)
   * Subdirectory 'webscape' (8 files, 20297 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/webscape/)
   * Subdirectory 'webvbt' (83 files, 283490 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/webvbt/)
   * Subdirectory 'zeus' (50 files, 284608 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/SRC-m3/zeus/)

Miscellaneous Modula-3 packages

   * m3tcl: a thin Modula-3 veneer on the TCL library (version 7.x). (11
     files, 41533 bytes) (http://www.vlsi.polymtl.ca/m3/pkg/contrib/m3tcl/)
   * Computer cache memory simulation and graphical animation (4 files,
     170876 bytes) (http://www.vlsi.polymtl.ca/m3/pkg/contrib/cacheanim/)
   * Subdirectory 'm3na' (163 files, 857298 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/contrib/m3na/)
   * When NEW Fails ... Exception is Raised (10 files, 128512 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/contrib/whenNEWfails/)
   * Simple Modula-3 Reader/Writer Modules (9 files, 30058 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/contrib/RdWr/)
   * Experimental New Pickler for SRC M3 (18 files, 237699 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/contrib/pickle/)
   * Regex: Regular Expression Matching in Modula-3 (13 files, 31433 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/contrib/regex/)
   * M3IDE a simple environment for M3 development (15 files, 108374 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/contrib/m3ide/)
   * Index of M3emacs utilities (3 files, 5088 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/contrib/m3emacs/)
   * Subdirectory 'ktrees' (25 files, 153323 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/contrib/ktrees/)
   * Closure queues, insertable sequences, file listings, runtime statistics
     (48 files, 204973 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/contrib/m3misc/)

Miscellaneous non free Modula-3 packages

   * HyperNet rel 0.1 - A Hypertext Editor and some Useful Libraries (3
     files, 133007 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/non-free/hypernet-0.1/)

Modula-3 packages Derived from the GNU Project

   * Subdirectory 'm3cc' (4408 files, 30079492 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/gnu/m3cc/)
   * Subdirectory 'm3gdb' (2704 files, 32887837 bytes)
     (http://www.vlsi.polymtl.ca/m3/pkg/gnu/m3gdb/)

Other contributed Modula-3 packages

m3rpc a Sun RPC system from Xerox Parc

Was developed for SRC Modula-3 2.x. A small amount of work is required to
get it updated for SRC M3 3.x.

m3rpc (file://gatekeeper.dec.com/pub/DEC/Modula-3/contrib/m3rpc-1.3.tar.Z)

m2tom3: A Modula-2 to Modula-3 converter

                             m2tom3 version 2.03
          (C) 1991-1995 Lehrstuhl fuer Informatik III, RWTH Aachen
                             All Rights Reserved

                Peter Klein (pk@i3.informatik.rwth-aachen.de)
                                 04.09.1995
This is the README file for m2tom3 2.03. This system is free software; you
can redistribute it and/or modify it under the terms of the GNU Library
General Public License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.

What is m2tom3?

m2tom3 is a system to port Modula-2 programs to Modula-3. It consists of two
parts:

   * A conversion program which tries to create a Modula-3 source text with
     the same semantics as the Modula-2 input while retaining the original
     look and feel as good as possible.
   * A base library which tries to emulate the Modula-2 standard library
     using the Modula-3 standard library.

Requirements

The system was developed and tested with Modula-3 3.3 on SPARC/SunOS 4.1.3.
The conversion program should be quite platform-independent, since no
low-level operations are used. The base library, however, depends in parts
on an underlying Unix system and might be unusable on other platforms. From
version 2.03 on, m2tom3 and m2libs should work with Solaris 2.4 and Modula-3
3.5.x as well.

Installation

  1. Get m2tom3
     (ftp://ftp-i3.informatik.rwth-aachen.de/pub/Modula-3-Contrib/m2tom3/) .
  2. Unpack the distribution in an appropriate directory.
  3. To build the base library, run m3build in the m2libs subdirectory.
  4. To build the converter, run m3build in the m2tom3 subdirectory.

For more information, refer to the enclosed README file
(ftp://ftp-i3.informatik.rwth-aachen.de/pub/Modula-3-Contrib/m2tom3/README.m2tom3-2.03)
or write e-mail to pk@i3.informatik.rwth-aachen.de
(http://www.vlsi.polymtl.ca/m3/faq/pkg/pk@i3.informatik.rwth-aachen.de) .

m23gdb a newer version of m3gdb with important fixes for most platforms.

Peter Klein maintains a combined Modula-2 and Modula-3 version of gdb. See
the README.m23gdb file for details in the m23gdb release
(ftp://ftp-i3.informatik.rwth-aachen.de/pub/Modula-3-Contrib/m23gdb) .

Demo of Analysis and Development environment for Modula-3

Peter Klein writes: A demo version of the development environment we are
working on in the ADT (Analysis and Development Tool) project
(ftp://ftp-i3.informatik.rwth-aachen.de/pub/Modula-3-Contrib/adt) is now
available.

m3tomif

m3tomif converts Modula-3 program to Maker Interchange Format (MIF) source.
m3tomif is based on m3totex, and follows the same gudelines for typesetting
text.

It is available electronically
(http://info.gte.com/ftp/doc/software/m3tomif.html)

(http://www.vlsi.polymtl.ca/m3/)
-- 

Prof. Michel Dagenais        http://www.vlsi.polymtl.ca/dagenais/home/home.html
Dept of EE and Computer Eng.        dagenais@vlsi.polymtl.ca
Ecole Polytechnique de Montreal     tel: (514) 340-4029
