======================================================================= 1 ===
Date:    Tue, 1 Sep 1992 14:37:11 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Modula3 for Windows

>   ... is that something impossible
>
>   I am a BIG fan of modula2. I have not fallen for modula3 yet since 
>   ...
>   But the last year I have mostly been programming under MS-Windows and
>   therefore been forced to change language.
>   So, does anyone know something? is a Windows version on its way... or it is
>   just a hopeful dream?

Right now nothing is available but this is certainly not impossible. You
need the compiler to work under MS-windows or, more likely, Windows NT.
With the linear address space offered by Windows NT it should be easier to
port DEC SRC Modula 3 or the upcoming GNU Modula 3. Then you also need
Trestle to support Windows NT. The X code in Trestle is well separated
since it has already been ported from the Firefly/Topaz experimental 
workstation. The people at DEC SRC even mentioned the possibility of doing
the port when Windows NT comes out (Windows NT should be supported on DEC's
Alpha architecture).

--
---------------------------------------------------------------------

Prof. Michel Dagenais			    dagenais@vlsi.polymtl.ca
Dept of Electrical and Computer Eng.
Ecole Polytechnique de Montreal		    tel: (514) 340-4029

---------------------------------------------------------------------


======================================================================= 2 ===
Date:    1 Sep 92 14:46:35 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Modula3 for Windows

Well, assuming we get GNU Modula-3 done (gm3), that the djgpp port of gcc can
be used as the basis of a Windows gcc, and that someone undertakes to port gm3
using djgpp's machine description and run-time as a starting point, it could
all be done. But don't hold your breath. Alternatively, perhaps someone has
already done or is working on a port of SRC M3 to windows .....
--

		J. Eliot B. Moss, Associate Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================= 3 ===
Date:    2 Sep 1992 00:28:59 GMT
From:    lim@soda.berkeley.edu (Lincoln Myers)
Subject: What is the current status of GNU Modula 3?

Is someone working right now on gm3?  Is there a way to find out more about
what it is, when it will be, beta testing, all that?

Lincoln (modula 3 groupie)


======================================================================= 4 ===
Date:    Wed, 2 Sep 1992 15:15:19 GMT
From:    hudson@cs.umass.edu (Rick Hudson)
Subject: Re: What is the current status of GNU Modula 3?

>>>>> On 2 Sep 1992 00:28:59 GMT, lim@soda.berkeley.edu (Lincoln Myers) said:
Lincoln> Is someone working right now on gm3?  Is there a way to find out more 
about
Lincoln> what it is, when it will be, beta testing, all that?

Yes, the gm3 project is alive and well. Right now it consists of
the following University of Massachusetts related people:

Eliot Moss, Rick Hudson, Amer Diwan, Tony Hosking and Norman Walsh

I will only make estimated of when external alpha testing will begin a month
after it has begun. Ask me again at the first of the year.

The compiler will be a native code compiler utilizing a lot of the gcc
backend.  One technical paper concerning Modula-3 garbage collection support
is easily available

@InProceedings{DMH91,
  author = 	 "Amer Diwan and J. Eliot B. Moss and Richard L. Hudson",
  title = 	 "Compiler Support for Garbage Collection in a Statically
  Typed Language",
  pages = 	 "273--282",
  booktitle = "Conference on Programming Language Design and Implementation",
  year = 	 1992,
  organization = "SIGPLAN",
  publisher = "ACM Press",
  address = 	 "San Francisco, California",
  month = 	 "June"
}

Hope this helps.
--

                Richard L. Hudson, Research Associate
                University Computing Services
                Lederle Graduate Research Center
                University of Massachusetts
                Amherst, MA  01003
                (413) 545-1220; Hudson@cs.umass.edu


======================================================================= 5 ===
Date:    2 Sep 92 22:22:19 GMT
From:    rhyspj@occs.cs.oberlin.edu (Rhys Price Jones)
Subject: Soliciting names for ACM/SIGCSE panelists

I am looking for participants in a panel discussion  for next year's
SIGCSE to discuss issues affecting choice of language in CS1 - the
introductory CS course.  Please e-mail me suggested names for
advocates of your particular favorite introductory language.
Anybody know any advocates for oberon?

Thanks

--
Rhys Price Jones                            
Cyd-athro Cyfrifiaduriaeth                   ____
Associate Professor Computer Science        /   / /
Oberlin College                            /   / /
King 223C                                 /___/ /__      __
Oberlin OH 44074 - USA - UDA             / \   /  / / / (
(216) 775 8697                          /   \_/  /_/_/ __)
<rhyspj@occs.cs.oberlin.edu>                      __/_/


======================================================================= 6 ===
Date:    3 Sep 92 02:35:34 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: What is the current status of GNU Modula 3?

I can expand on Rick Hudson's comments a bit. We have substantial parts of the
language compiling the VAX code using the gcc back end. The front end is gcc
changed to accept Modula-3 syntax, and considerably enhanced to do two passes
to resolve names (as required by Modula-3) and to implement/enforce Modula-3
semantics. Much of the data structure and some of the algorithms are retained
from gcc. The back end has been enhanced only to support things not present in
C, such as exceptions and garabge collection. Those hard things are all
working. It's the raft of little things, such as complete floating point and
string support, all the built in functions, etc., etc., that we're mostly into
now. With two of us moving to CMU for the year (sabbatical) and a new person
being trained up, there's been some disruption, but things are still getting
done and I think you might see something without threads by the end of the
calendar year. We had hoped for September, but vacations and things had more
effect than we anticipated. The garbage collector is indeed running, though,
which is more than we could say in June.
--

		J. Eliot B. Moss, Associate Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================= 7 ===
Date:    Thu, 3 Sep 92 02:27:04 GMT
From:    muller@bismol.pa.dec.com (Eric Muller)
Subject: Modula-3 Frequently Asked Questions (FAQ)


		 Modula-3 Frequently Asked Questions
		 ===================================


What is Modula-3 ?

   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, we studied the features of the Modula
   family of languages that have proven themselves in practice and
   tried to simplify them into a harmonious language.  We 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 descends from Mesa, Modula-2, Cedar, and Modula-2+.  It
   also resembles its cousins Object Pascal, Oberon, and Euclid.

   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.


Is Modula-3 a superset of Modula-2 ?

   No; valid Modula-2 programs are not valid Modula-3 programs.


Where can I get a description of Modula-3 ? 
   
   The definition of Modula-3 is contained in:

        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.

   Sam Harbison has written a book about Modula3:

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

   as well as an overview article, "Modula-3", in Byte, Vol. 15,
   Number 12, October 1990, p 385.


Where can I get information on Modula-3 ?

   There is a Usenet newsgroup, comp.lang.modula3.  The archives of
   that group are available via anonymous ftp from gatekeeper.dec.com
   in pub/DEC/Modula-3/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.


Where can I get an implementation ?

   There is only one implementation available today.  It has been built
   by SRC and is available via anonymous ftp from gatekeeper.dec.com in
   pub/DEC/Modula-3/release.  Contributed software can be found
   in pub/DEC/Modula-3/contrib.

   The current version, 2.07, implements the language defined in SPwM3.
   There are versions for the following machines:

        AIX386  IBM PC running AIX/PS2,
        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
        IBMR2   IBM R6000 running AIX 3.1, 
        IBMRT   IBM RT running IBM/4.3, 
        NEXT    NeXT running ?
        SPARC   SPARCstation running SunOS 4.1.x
        SUN3    SUN3 running SunOS
        UMAX    Encore Multimax running UMAX 4.3 (R4.1.1)
        VAX     VAX running Ultrix 3.1

   SRC Modula-3 includes a user manual, compiler, runtime library,
   some libraries and a few other goodies (see below).

   The compiler generates C as an intermediate language 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.


What if I don't have ftp access ?

   Unfortunately, we cannot deliver Modula-3 other than by 
   anonymous ftp.  Your best bet is to post a message to
   comp.lang.modula3, in the hope that somebody with ftp
   access can make a tape or floppy for you.
      

Can I contribute Modula-3 software ?

   Certainly.  Send us what you are willing to share, be it programs,
   libraries or other things.  We'll put them in the distribution. 

-- 
Eric.





-- 
Eric.



======================================================================= 8 ===
Date:    Thu, 3 Sep 1992 16:04:03 -0400
From:    "Vinay K. Chaudhri" <vinay@ai.toronto.edu>
Subject: Re: Modula-3 Frequently Asked Questions (FAQ)

Would you have any information about the modula2 compiler for 
SUN SPARC stations?

thanks,
vinay.




======================================================================= 9 ===
Date:    3 Sep 92 17:23:04 GMT
From:    do12+@andrew.cmu.edu (Dick Orgass)
Subject: RISC 6000 Binaries for SRC M3 v 2.06

I know that this is somewhat late, but the result may be useful to
a few people.

A set of binaries (and the public interface sources) for the SRC compiler
and all libraries is available for anonymous ftp from emsworth.andrew.cmu.edu
in directory m3.  The compressed tar file is the only file in the directory
so mget * will work just fine.

The system is built on the assumption that it is installed in /u/decsrc.  If
you put it someplace else, just install a symbolic link from /u/decsrc to the
actual location.

Hope these are a bit useful to a few people.

Dick


======================================================================= 10 ===
Date:    Wed, 9 Sep 92 16:42:31 EDT
From:    Geoff.Wyant@East.Sun.COM (Geoffrey Wyant - Sun BOS SunLabs)
Subject: OpenWindows patches for Trestle ?

It seems that Trestle causes the OpenWindows
X server to crash. While this is undoubtably
a bug in OpenWindows, does anyone have any
patches to Trestle to work around this ?

thanks,

geoff

Geoff Wyant
Sun Laboratories, Inc.
wyant@suneast.east.sun.com


======================================================================= 11 ===
Date:    Wed, 9 Sep 1992 20:23:55 GMT
From:    ryan@ponder.csci.unt.edu (Ryan Stansifer)
Subject: Syntax of WITH and TRY

After programming some in Modula-3 I have come to think that the WITH
and TRY statements are wordy, especially in conjunction with other
blocks.  In thinking about the language syntax it occurred to me that
some simplification may be possible.  So, for the sake of argument I
offer the following 2 suggestions for expanding the block statement to
encompass both the WITH and the TRY statements.

Instead of
    WITH x = e DO S END
add a new kind declaration, say, WITH.
Now we write:
    WITH x = e BEGIN S END
Now we can mix VAR, CONST, WITH declarations and use only one
BEGIN/END block.  I think the WITH declarations should be separated
by semicolons like other declarations.

(There is another, perhaps more important, issue.  WITH declarations
seem to be used in two distinct ways.  One, as READONLY constant
r-values.  Two, as aliases.  Adding READONLY constants is
unproblematic, but I would hate to add a new "alias" declaration when
they are really READONLY constants of type reference, reference in the
C++ sense.)

Instead of
    TRY S EXCEPTION Handler END
we could follow the example of Ada and tack on an exception part
to the block.  Now we write
    BEGIN S EXCEPTION Handler END
This permits declarations can be added to the block without
extra BEGIN/END pairs.

I do not wish to touch off another language-changing war.  I'm just
curious about the advantages and disadvantages of different approaches.



======================================================================= 12 ===
Date:    10 Sep 92 11:14:21 GMT
From:    joachim@nada.kth.se (Joachim Hollman)
Subject: Standard interfaces in M3 - no I/O?


After reading Nelson's ``Systems Prpgramming with Modula-3'' I have the 
impression that the standard intefaces in M3 are

1. Text
2. Thread
3. Word
4. Floating-point

while the RECOMMENDED intefaces are

1. Fmt    (Textual formatting)
2. Pkl    (``pickles'' - binary files, depends on Wr and Rd, see below)
3. Table  (Generic hash tables).

SRC Modula-3 also provides interfaces for input and output
(Wr, Rd, Stdio, FileStream and WrClass), but these are not
part of the standard.

So the question is: 
*** Why are the interfaces for input and output not part of the standard? ***


-------------------------------------------------------------------------------
Joachim Hollman         Royal Institute of Technology                    
Tel. +46 8- 790 7188    Dept of Numerical Analysis and Computing Science  
                        Theoretical CS
                        S-100 44 Stockholm                               
                        Sweden                                           
                        joachim@nada.kth.se
-- 

-------------------------------------------------------------------------------
Joachim Hollman         Royal Institute of Technology                    
Tel. +46 8- 790 7188    Dept of Numerical Analysis and Computing Science  
                        Theoretical CS - Symbolic Computation Group
                        S-100 44 Stockholm                               


======================================================================= 13 ===
Date:    Thu, 10 Sep 1992 15:56:11 GMT
From:    shri@sol.acs.unt.edu (Shrinand Desai)
Subject: Re: Modula3 for Windows

MBLOMQVIST@finabo.abo.fi (Mikael Blomqvist INF) writes:

>... is that something impossible

>I am a BIG fan of modula2. I have not fallen for modula3 yet since I have been
>using jensen&partner's TopSpeed M2 which includes LONGCARD and such useable
>data types. 
> But the last year I have mostly been programming under MS-Windows and
>therefore been forced to change language.
> So, does anyone know something? is a Windows version on its way... or it is
>just a hopeful dream?

>Micke

Hello,
I am in process(in very initial stages) of porting a subset of M3 on IBM-PC
(386 and above using MS_DOS) with the help of DJGPP 32-bit c compiler (which
does not support windows 3.1) but does support deskview. But I thought,even
a subset of M3 would be very good for PC-world(no threads).
Dr. Moss is writing a native compiler for modula-3 using gcc which would
be easier to port then DEC M3(IMO).
But it is fun anyway.

--shri



======================================================================= 14 ===
Date:    14 Sep 92 06:17:27 GMT
From:    andru@concerto.lcs.mit.edu (Andrew Myers)
Subject: Constructors in Modula-3


I am very fond of Modula-3, but it has one lack that periodically
annoys me: it doesn't have constructors. A constructor, in C++
parlance, is a special initializer associated with a class. Objects of
that class cannot be created except by using one of the constructors of
the class. This restriction allows a class designer to ensure that
objects of the class will always be properly initialized.

By contrast, if I see the Modula-3 declaration

    TYPE T <: U;

I can write the statement

    VAR x := NEW(T);

and obtain an object that has not been initialized. Maybe it's a valid
object of that type; maybe not.

Modula-3 programmers, in my experience, handle this problem through the
use of conventions and careful documentation. Any interface that
describes a Modula-3 type should clearly state what is needed to
obtain a valid object of the type.

The most obvious and common convention is a "New" procedure. To create
an object of type Interface$T, we say

    VAR x := Interface$New(...)

where the "..." represents the arguments that are needed to initialize
an object. The approach works until you try to subclass, since the
"New" procedure of type "S" with S<:T cannot use T's New to initialize
the T part of S.

Another standard convention I've seen used is an "init" method. This
method is used in the following way:

    VAR x := NEW(T).init(...)

The "init" method is seldom overridden, and doing so is never useful.
Consider that "NEW(T).init(...)" is identical to "T.init(NEW(T), ...)"
if T reveals that it overrides the "init" method.  The fact that "init"
is made a method is a matter of convenient notation.  Though less
efficient, "NEW(T).init()" is easier to type and read than
"Interface_T$Init(NEW(T))".

Both of these variants avoid the limitations of "New", since the
subtype's "Init" procedure can be written as

PROCEDURE Init(x: S, S_args...) =
BEGIN
    Interface_T$Init(x, T_args...) (* or Interface_T.T.init(x, T_args...) *)
    (* Rest of S initialization here *)
END Init;

All of these solutions require careful programming, since an
initialization method must be sure to properly initialize all of the
fields of an object, and to properly initialize the supertype. Since
Modula-3 guarantees that each field of an object is initialized by the
NEW operator to some value of its declared type, all of these solutions
also overwrite existing values in the fields. This reinitialization is
only a potential inefficiency, since any old garbage is considered to
be a valid value of any type. If future implementations choose a more
intermediate point on the debuggability/performance curve, the
inefficiency will become real.

More importantly, ensuring that variables and values are properly
initialized is a major source of programming errors, and it is
unfortunate that Modula-3 doesn't help the programmer out more.

Here is a proposal for constructors in Modula-3, just as food for
thought:

In any module that fully reveals (i.e., contains "REVEAL T = ... ") an
object type T, a "constructor" may be declared. A constructor looks
much like a procedure, but it may only be used in the place of the NEW
operator, or within another constructor's body . Thus, to create a new
object of the type T with a constructor named "Make", we could say

    VAR x := Make(...)

Let T have a supertype named U with a constructor named Make_U and
a method named "index", fields named "a" and "b" of types "A" and "B",
and a field "i" of type "INTEGER". The constructor implementation syntax
looks like:

CONSTRUCTOR T Make(a_: A) =
VAR tmp := Make_B();
    (
	Make_U(a_, ....),
	a := a_,
	b := tmp,
	i := tmp.index()
    )

A constructor body contains a list of comma-separated items. At most
one item may be a constructor invocation for some supertype of T.  Call
this supertype "U".  All of the subtypes of U must be fully revealed in
the scope of the constructor, implying that a supertype constructor
must be used on a subtype of T's closest opaque supertype, if any.

Each of the remaining items is an assignment to a field belonging to T,
or to a local variable of the constructor.  Every field of T that is
not contained in U and does not have a default value must be assigned
to within the constructor body.

Because the object being constructed cannot be named, this
approach avoids the problem of defining the semantics of method
invocations on a partially constructed object, and the consequent
inefficiency that C++ creates during object construction.

A constructor can be declared in an interface, and the syntax is
similar to procedure-declaration syntax, e.g.:

CONSTRUCTOR T Make(a_: A);

A call to NEW is just like a constructor body: in addition to the usual
override assignments, one of the arguments to NEW(T, ...) may be a
constructor invocation. NEW may only be called on an opaque type if a
constructor is used. A call to NEW is required to initialize all of T,
just as a constructor body is.

Thus, 

    x := Make(...)

is really just shorthand for

    x := NEW(T, Make(...))

if "Make" is a constructor for "T".

Andrew


======================================================================= 15 ===
Date:    Mon, 14 Sep 92 17:29 MSK
From:    "MICHAEL I. TROFIMOV" <L447%SUEARN2.BITNET@SEARN.SUNET.SE>
Subject: OOP VS NON-OOP?



             "INTER-BRIDGE  TO  OBJECT  WORLD."
                   (Preliminary project)

In relation to Object Oriented Technologies, the current situation in
computing may be characterized by the following.

1) Wide distribution of different Object Oriented approaches.
2) Combining efforts in development of Object Orientation.
3) Many people do not use any Object Oriented technology yet.
4) There is a lot of existent and developed non Object Oriented
   software.

Under these conditions the following attitudes are possible.

1) "agressive":   OOP vs (other) programming;
2) "indifferent": non-OO directions are ignored like wrong;
3) "interactive": competition and/or consolidation (integration).

The second (indifferent) looks like the least optimal and the
third like the most optimal for Object Oriented progress.
Support of different interactions between different objects
produced from different sources is significant achievement of
Object Oriented computing. The possibility to make a bridge
between objects is provided by standards and specifications.
Special standard and specifications would be necessary to make
a bridge between Object Oriented and Procedure Oriented paradigms.
The bridge would be useful for adaptation of old applications in
modern Object Oriented environment as well as to redesign old
sources into Object Oriented design (i.e. to support of continuous
processes of software evolution: from Procedure Oriented to Object
Oriented paradigm).

The   very   attractive   base   for   the   future
projects  is  investigation  of  common
limitations of OOP and of practical troubles, defined with the
theoretical restrictions, because just those very cases are the
most interesting for comparative analysis of different methodologies
to concentrate efforts on non-trivial problems of reality.
The enumeration of the typical cases would be interesting also
as challenge for Object Oriented industry to promote its progress.

There is a theoretical challenge, too.
What types of portability between Object Oriented environment and
non-OO applications are possible and which of them can support a
good OO style? For example, there are well-known hybrid computer
languages and tools (Oberon, Turbo Pascal v.6.0, Modula-3 etc.)
to support both paradigms. However, it seems as first step only,
but not as sufficient decision.

Also, it should be pointed out that some important unsolved problems
of computer education are closely connected with the subject.

                                              MICHAEL I. TROFIMOV,
                                 LABORATORY OF COMPUTER CHEMISTRY,
                                           N.D.ZELINSKY INSTITUTE
                                             OF ORGANIC CHEMISTRY,
                                                  ACADEMY OF SCI.,
                                            LENINSKY PROSPECT, 47,
                                           117913, MOSCOW, RUSSIA.

FAX: (095) 135-5328
E-MAIL: L447@SUEARN2.BITNET

                 =================
                  ===============
                 =================
===================================================================



======================================================================= 16 ===
Date:    Mon, 14 Sep 1992 18:33:41 GMT
From:    mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: Re: Constructors in Modula-3


I proposed what I think is a simple solution to this problem a couple
months ago, but got no response.  My solution was to add a pragma, say
<*NO NEW*>, that can be affixed to type declarations in an interface.
E.g.,

        INTEFACE foo
           <*NO NEW*> TYPE T <: U;
           PROCEDURE New(x: INTEGER): T;
        END foo.

In the presence of this type declaration, NEW cannot be used to create
objects of type T.  This forces the user of the interface to use
whatever constructor procedures are supplied in the interface; in this
case "New".  (Of course, NEW could still be used inside a module that
implements foo.)

What I would really like to see is a keywork, say PRIVATE, that does
what <*NO NEW*> does.  I think it is a mistake in the language design
that Modula-3 tries to guess whether NEW should be allowed based on
how much is known about a type.  Whether NEW is allowed is really
orthogonal to whether a type is completely opaque, partly revealed, or
fully revealed.

-mike





======================================================================= 17 ===
Date:    Mon, 14 Sep 92 15:00:57 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Constructors in Modula-3

An obvious solution (though not very elegant) to the constructor problem is
to have an "initialized" flag in the object. This can be set to FALSE by the
default initialization. Every method should check this flag and either raise
an exception if the flag is unset, or it can dynamically init the object at
the first use. Especially the last solution makes NEW act like a constructor,
since the actual init method is not exported.

Now, if you don't like this, I think we should handle the problem in a more
general way. Your suggestion might work for constructors, but at the cost
of introducing pretty much new syntax. This overhead could be reduced
dramatically if we think of constructors as class methods, i.e. methods
which can be applied to non-existing objects. This might look something
like
TYPE A = OBJECT
           <fields>
         CLASS
           <class methods>
         METHODS
           <object methods>
         OVERRIDES
           <class & object method overrides>
         END;
Maybe the distinction between class and object methods could be dropped
altogether; I'm not sure if I'd like this.

In this case, NEW would loose it's status as standard operator and would
become a default for a class constructor. Any new class declaration could
override this NEW method by doing a NEW on the superclass and then perform
initializations on the object fields.

Peter
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany



======================================================================= 18 ===
Date:    15 Sep 92 12:22:37 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Constructors in Modula-3

In article 92Sep14133341@tolstoy.uwaterloo.ca, mhcoffin@tolstoy.uwaterloo.ca (M
ichael Coffin) writes:
>
>I proposed what I think is a simple solution to this problem a couple
>months ago, but got no response.  My solution was to add a pragma, say
><*NO NEW*>, that can be affixed to type declarations in an interface.
>E.g.,
>
>        INTEFACE foo
>           <*NO NEW*> TYPE T <: U;
>           PROCEDURE New(x: INTEGER): T;
>        END foo.
>
>In the presence of this type declaration, NEW cannot be used to create
>objects of type T.  This forces the user of the interface to use
>whatever constructor procedures are supplied in the interface; in this
>case "New".  (Of course, NEW could still be used inside a module that
>implements foo.)
>
No, *please* no more pragmas. If you want to have a feature in the
language standard, then introduce a new keyword. Everything else leads
to portability problems. I see a certain use for pragmas if they don't
change the semantics of a program, like <* OBSOLETE *> or <* INLINE *>.
(What about INLINE anyway? Will it ever be supported?) But what you suggest
definetely changes the semantics, and should therefore be a keyword (just 
like <* EXTERNAL *>, which is actually no pragma either).

>What I would really like to see is a keywork, say PRIVATE, that does
>what <*NO NEW*> does.  I think it is a mistake in the language design
>that Modula-3 tries to guess whether NEW should be allowed based on
>how much is known about a type.  Whether NEW is allowed is really
>orthogonal to whether a type is completely opaque, partly revealed, or
>fully revealed.
>
Yes. For constructors, this would be an acceptable solution.

Peter
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany


======================================================================= 19 ===
Date:    Mon, 14 Sep 1992 05:45:41 GMT
From:    yost@adobe.com (David Yost)
Subject: Re: What is the current status of GNU Modula 3?

In article <MOSS.92Sep2223534@ibis.cs.umass.edu> moss@cs.umass.edu writes:
>It's the raft of little things, such as complete floating point and string
>support, all the built in functions, etc., etc., that we're mostly into now
>... I think you might see something without threads by the end of the
>calendar year.

Hmmm, sounds like you've decided to do floating point before threads.
Here's a vote that says you should get something running and out there
first, then add threads, then floating point.

 --dave yost


======================================================================= 20 ===
Date:    Wed, 16 Sep 1992 07:29:43 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: Constructors in Modula-3


Peter Klein writes:
> An obvious solution (though not very elegant) to the constructor problem is
> to have an "initialized" flag in the object. [... rest of paragraph deleted]
This is the automagic init. The user does not have to know whether initializati
on
is required, and never notices it. I don't think I'ld like to have to put check
s
in all methods. Also, what if I call a method in an object which doesn't
use any methods defined by its ancestors. Then I cannot initialize, unless
I can force propagation of the initialization upwards. i.e. I _must_ be
able to call the init() method of my ancestors. This can become bothersome
if I do not know the full hierarchy, as can happen with partial revelations.

> Now, if you don't like this, I think we should handle the problem in a more
> general way. Your suggestion might work for constructors, but at the cost
> of introducing pretty much new syntax. This overhead could be reduced
> dramatically if we think of constructors as class methods, i.e. methods
> which can be applied to non-existing objects.
> [...]
> Maybe the distinction between class and object methods could be dropped
> altogether; I'm not sure if I'd like this.
In POOL there were METHODs and ROUTINEs. The former were called as object.metho
d(),
the latter as classname.subr(). The Modula-3 approach is to put Class-methods,
or subroutines in the interface exporting the type. Together with the conventio
n
of calling that type `T', while letting the interface have the descriptive name
,
the net effect is the same.

> In this case, NEW would loose it's status as standard operator and would
> become a default for a class constructor. Any new class declaration could
> override this NEW method by doing a NEW on the superclass and then perform
> initializations on the object fields.
I think the difference to having a function procedure called New in the interfa
ce
is minimal.

Greetings, Bert
-- 
#include <std/disclaimer>

  Bert Laverman,  Dept. of Computing Science, Groningen University
  Friendly mail to: laverman@cs.rug.nl      The rest to: /dev/null


======================================================================= 21 ===
Date:    Wed, 16 Sep 92 14:14:58 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Constructors in Modula-3

In article 92Sep15145854@tolstoy.uwaterloo.ca, mhcoffin@tolstoy.uwaterloo.ca (M
ichael Coffin) writes:
>In article <1992Sep15.122237.271@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.in
formatik.rwth-aachen.de (Peter Klein) writes:
>> ...
>> No, *please* no more pragmas. If you want to have a feature in the
>> language standard, then introduce a new keyword. Everything else leads
>> to portability problems. I see a certain use for pragmas if they don't
>> change the semantics of a program, like <* OBSOLETE *> or <* INLINE *>.
>> (What about INLINE anyway? Will it ever be supported?) But what you suggest
>> definetely changes the semantics, and should therefore be a keyword (just 
>> like <* EXTERNAL *>, which is actually no pragma either).
>
>I, too, like a new keyword, but that would involve changing the
>standard, which is pretty difficult.  Adding a pragma can be done by
>merely changing a single implementation.  Furthermore, if successfully
>implemented and tested, it would add ammunition for introducing a new
>keyword in the next version of the standard (if there is one). 
>
I've contributed quite enough about my opinion concerning language changes.
Unfortunately, the language designers seem so content about the current
state of Modula-3 that I never received an authoritative response to that
thread.

>And, as pragmas go, <*NO NEW*> is fairly benign. It doesn't introduce
>any portability problems that I can see.  If you write a program using
>a compiler that supports <*NO NEW*>, you can compile it on another
>compiler that ignores <*NO NEW*> and everything will work just fine.
>On the other hand, if you develop a program using a compiler that
>doesn't support <*NO NEW*>, it will certainly work on one that does.
>
Well, the portability problem that I see is just what you said above:
it can be done by changing an implementation instead of changing the
standard.

>The point is that <*NO NEW*> restricts the language, which merely
>makes some otherwise-legal programs illegal.  In contrast,
><*EXTERNAL*>, makes some otherwise-illegal programs legal, which is
>far more serious and *does* cause portability problems.
>
Right. EXTERNAL is even worse. 

Peter
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany



======================================================================= 22 ===
Date:    Tue, 15 Sep 1992 19:58:54 GMT
From:    mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: Re: Constructors in Modula-3

In article <1992Sep15.122237.271@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.inf
ormatik.rwth-aachen.de (Peter Klein) writes:
> ...
> No, *please* no more pragmas. If you want to have a feature in the
> language standard, then introduce a new keyword. Everything else leads
> to portability problems. I see a certain use for pragmas if they don't
> change the semantics of a program, like <* OBSOLETE *> or <* INLINE *>.
> (What about INLINE anyway? Will it ever be supported?) But what you suggest
> definetely changes the semantics, and should therefore be a keyword (just 
> like <* EXTERNAL *>, which is actually no pragma either).

I, too, like a new keyword, but that would involve changing the
standard, which is pretty difficult.  Adding a pragma can be done by
merely changing a single implementation.  Furthermore, if successfully
implemented and tested, it would add ammunition for introducing a new
keyword in the next version of the standard (if there is one). 

And, as pragmas go, <*NO NEW*> is fairly benign. It doesn't introduce
any portability problems that I can see.  If you write a program using
a compiler that supports <*NO NEW*>, you can compile it on another
compiler that ignores <*NO NEW*> and everything will work just fine.
On the other hand, if you develop a program using a compiler that
doesn't support <*NO NEW*>, it will certainly work on one that does.

The point is that <*NO NEW*> restricts the language, which merely
makes some otherwise-legal programs illegal.  In contrast,
<*EXTERNAL*>, makes some otherwise-illegal programs legal, which is
far more serious and *does* cause portability problems.

-mike


======================================================================= 23 ===
Date:    16 Sep 92 19:24:22 GMT
From:    andru@concerto.lcs.mit.edu (Andrew Myers)
Subject: Constructors in Modula-3


Michael Coffin defines <* NO NEW *>:

...
> In the presence of this type declaration, NEW cannot be used to create
> objects of type T.
...

Presumably this isn't what you actually mean. If you can't call NEW, you
can't create objects of type T. Perhaps you wanted to allow NEW within the
module implementing the interface in which the <* NO NEW *> pragma
occurred? Or within any module in which the type T is revealed?

In any case, this pragma doesn't help much. Once you subtype from type
T, you are faced with the problem of initializing the "T" part of the
subtype. Having a "New" procedure is useless for this task.

Andrew


======================================================================= 24 ===
Date:    17 Sep 92 15:26:40 GMT
From:    jml@visus.com (Jim Large)
Subject: Re: Constructors in Modula-3

In article <ANDRU.92Sep14011727@concerto.lcs.mit.edu>  
andru@concerto.lcs.mit.edu (Andrew Myers) writes:
> 
> I am very fond of Modula-3, but it has one lack that periodically
> annoys me: it doesn't have constructors.
> [...]
> Modula-3 programmers, in my experience, handle this problem through the
> use of conventions and careful documentation.
> [...]
> [A] standard convention I've seen used is an "init" method. This
> method is used in the following way:
> 
>     VAR x := NEW(T).init(...)
>
> [This approach requires] careful programming, since an
> initialization method must be sure to properly initialize all of the
> fields of an object, and to properly initialize the supertype.
>
> [reasons why M3 should have C++-like "constructors" deleted]

The "init method" technique is used throughout the NeXTStep (Objective-C)
programming environment.  It is a WELL established convention.  No 
experienced programmer would ever think of allocating an object without
calling one of it's "initializer"s on the same line.  Nor would (s)he
ever write an initializer that fails to call the super-class's
"designated initializer".

The init method technique adds *NOTHING* to the language.  Compare with
C++'s "constructors" which add a pile of semantic baggage, and provide
less power in return.

----------------+------------------+------------------------------------
     |\ /|      |  Jim Large       |  Visual Understanding Systems, Inc.
     | V |      |  jml@visus.com   |  2100 Wharton St.                  
   \_|   |__    |  (412)488-3600   |  Pittsburgh, PA  15203             


======================================================================= 25 ===
Date:    22 Sep 92 19:12:23 GMT
From:    frederic@parc.xerox.com (Ron Frederick)
Subject: Re: Another installation problem (long)

elliottm@beach.csulb.edu (Mike Elliott) writes:

>Although I feel I've gotten closer, now I get the message 
>
>***
>*** runtime error:
>***    ASSERT failed
>***    file "OS.m3", line 109
>
>followed by a stack dump of the exception handler.  Well, what do I do
>now, boss?

This problem indicates that the compiler isn't finding one of the programs it
runs for intermediate processing. Check your "config" file where you define the
various PASS0, PASS1, etc. variables for each of these steps.

In particular, note the use of "@" as the separator. This means you can't use
"@" in your pathnames, such as "@sys" in AFS. If you need to put in something
like @sys, change the separator character to something else.

Also, you might want to try running m3 with the -? option to see what all of
these things are presently defined as.

Hope this helps...
--
Ron Frederick
frederick@parc.xerox.com


======================================================================= 26 ===
Date:    23 Sep 92 03:34:57 GMT
From:    mdixon@parc.xerox.com (Mike Dixon)
Subject: yet another installation problem (seg violation compiling RT0.i3)

ok, i've managed to get the driver and compiler running on my NeXT machine,
but i'm losing when i try to make libm3.  here's the (tail of the) output
from m3make with -debug:

------------------------------------------------------------
  ...
new source -> compile ../C/src/generic/M3toC.i3
/m3/lib/m3/m3compiler -F.m3path -w1 -oM3toC_i.c -xM3toC.ix ../C/src/generic/M3t
oC.i3
/bin/cc -g -O -I../Csupport/src/generic -I../Csupport/src/NEXT -I/m3/lib/m3 -c 
M3toC_i.c
mv M3toC_i.o M3toC.io
rm M3toC_i.c
reading final link info for ../C/src/generic/M3toC.i3
reading "M3toC.ix": 0 seconds
merging final link info for ../C/src/generic/M3toC.i3
searching library: 
merging: 0 seconds
adding object: M3toC.io

new source -> compile ../runtime/src/generic/RT0.i3
/m3/lib/m3/m3compiler -F.m3path -w1 -oRT0_i.c -xRT0.ix ../runtime/src/generic/R
T0.i3
/bin/cc -g -O -I../Csupport/src/generic -I../Csupport/src/NEXT -I/m3/lib/m3 -c 
RT0_i.c
mv RT0_i.o RT0.io
rm RT0_i.c
reading final link info for ../runtime/src/generic/RT0.i3


***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x601
***

*** Quit
Stop.
------------------------------------------------------------

any suggestions?  thanks...
--

                                             .mike.


======================================================================= 27 ===
Date:    23 Sep 92 03:28:28 GMT
From:    mdixon@parc.xerox.com (Mike Dixon)
Subject: Re: Another installation problem (long)

well, i just tried installing m3 on my NeXT machine, and ran into
exactly this problem (assert failed on line 109 of OS.m3).  in my case
i figured out that the problem was that the installation of m3compiler
had been interrupted, and it had been left with the wrong mode (for
some reason the makefile installs it with mode 644, and then changes
it to 755 in a separate operation).  since it didn't have the execute
bit set, the execvp was failing, which in turn caused the assert
failure.
                                             .mike.

--

                                             .mike.


======================================================================= 28 ===
Date:    23 Sep 92 13:42:46 GMT
From:    andersen@reality (Robert Andersen)
Subject: Re: Another installation problem (long)

In article <mdixon.717218908@thelonius> mdixon@parc.xerox.com (Mike Dixon)  
writes:
> well, i just tried installing m3 on my NeXT machine, and ran into

Hey Mike,

  Where did you get that copy of Modual-3.  Don't try to send this to me  
directly as my mail system is F$$$$$.

Robert John Andersen           
(919) 380-6523 (v,w)
andersen%reality@glv.com - NeXT mail!

Outside of a dog, a book is man's best friend.
Inside of a dog it's to dark to read.


======================================================================= 29 ===
Date:    Thu, 24 Sep 1992 23:31:00 GMT
From:    cosc18g7@elroy.uh.edu (92F06820)
Subject: size of modula3 compiler and source




======================================================================= 30 ===
Date:    Fri, 25 Sep 1992 13:33:37 GMT
From:    andersen@reality (Robert Andersen)
Subject: Re: verifying correct installation

In article <Bv3o99.A7s@beach.csulb.edu> werts@piggy.cecs.csulb.edu (Michael  
Werts) writes:
> I appear to have finally gotten Modula-3 installed for our DECsystem
> 5000/200 at school.

Where did you get it from?
 
--
Robert John Andersen           
(919) 380-6523 (v,w)
andersen%reality@glv.com - NeXT mail!

Outside of a dog, a book is man's best friend.
Inside of a dog it's too dark to read.


======================================================================= 31 ===
Date:    25 Sep 92 20:14:56 GMT
From:    rro@CS.ColoState.EDU (Rod Oldehoeft)
Subject: Data structures text using M3?

We intend to use Modula-3 in the second CS course (data structures)
here beginning in the Spring, 1993 semester.  It would be fine if
there were an appropriate text that also uses M3, but we're having
trouble finding such a thing.

Perhaps it's too early in the life of M3 to expect this.

If you know of one, please let me know.  If you know of a manuscript
for a book that could benefit from our test-driving it, we'd like
to have a discussion about that.


======================================================================= 32 ===
Date:    25 Sep 92 17:57:06 GMT
From:    werts@piggy.cecs.csulb.edu (Michael Werts)
Subject: Re: verifying correct installation

In article <1992Sep25.133337.186@glv.uucp>  writes:
> In article <Bv3o99.A7s@beach.csulb.edu> werts@piggy.cecs.csulb.edu (Michael  
> Werts) writes:
> > I appear to have finally gotten Modula-3 installed for our DECsystem
> > 5000/200 at school.
> 
> Where did you get it from?
>  
> --
> Robert John Andersen           
> (919) 380-6523 (v,w)
> andersen%reality@glv.com - NeXT mail!
> 

anonymous ftp from gatekeeper.dec.com. Look in DEC/Modula-3 I think.
Check the FAQ for this group.

Mike


======================================================================= 33 ===
Date:    Sat, 26 Sep 92 05:03:26 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: yet another installation problem (seg violation compiling RT0.i3)

In article <mdixon.717219297@thelonius>, mdixon@parc.xerox.com (Mike Dixon) wri
tes:
|> ok, i've managed to get the driver and compiler running on my NeXT machine,
|> but i'm losing when i try to make libm3.  
[...]
|> any suggestions?  thanks...

Unfortunately, we do not have access to NeXT machines to see what is
going on.  You may want to contact Gary Frederick
<jsoft!ggf@uunnet.uu.net> or Drew Dean <ddean@risc.uni-linz.ac.at>,
who have worked on the NeXT port.

-- 
Eric.



======================================================================= 34 ===
Date:    Sat, 26 Sep 92 12:31:08 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: verifying correct installation

In article A7s@beach.csulb.edu, werts@piggy.cecs.csulb.edu (Michael Werts) writ
es:
>I appear to have finally gotten Modula-3 installed for our DECsystem
>5000/200 at school. The "Hello World" example program described in
>"How to Use the System" compiled and ran.
>
>Unfortunately, it also appeared to give an error message during the
>compile.
>
>
>   cheetah.cecs.csulb.edu> m3 -make -why -o hello Main.m3 A.m3 A.i3
>   new source -> compile A.i3
>   new source -> compile Main.m3
>   new source -> compile A.m3
>   program missing -> link hello
>
>
>Is the last line of this message anything to be concerned about?
>

No, not at all. Due to the -why option you passed to the driver, it explains
to you what it is doing and why. And the reason for linking the program hello 
is simply that the the program didn't exist (just like the reason for compiling
the sources was that they were new). So this is no error message, just
an explanation.

Peter
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany



======================================================================= 35 ===
Date:    Thu, 24 Sep 1992 20:43:55 GMT
From:    werts@piggy.cecs.csulb.edu (Michael Werts)
Subject: verifying correct installation

I appear to have finally gotten Modula-3 installed for our DECsystem
5000/200 at school. The "Hello World" example program described in
"How to Use the System" compiled and ran.

Unfortunately, it also appeared to give an error message during the
compile.


   cheetah.cecs.csulb.edu> m3 -make -why -o hello Main.m3 A.m3 A.i3
   new source -> compile A.i3
   new source -> compile Main.m3
   new source -> compile A.m3
   program missing -> link hello


Is the last line of this message anything to be concerned about?

Thanks in advance.

Mike
(werts@csulb.edu)


======================================================================= 36 ===
Date:    28 Sep 92 11:06:05 GMT
From:    rh@ecs.soton.ac.uk (Rachel Harrison)
Subject: Re: verifying correct installation

In article <1992Sep26.123108.16975@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.i
nformatik.rwth-aachen.de writes:
>In article A7s@beach.csulb.edu, werts@piggy.cecs.csulb.edu (Michael Werts) wri
tes:
>>I appear to have finally gotten Modula-3 installed for our DECsystem
>>5000/200 at school. The "Hello World" example program described in
>>"How to Use the System" compiled and ran.
>>.........
>>Is the last line of this message anything to be concerned about?
>
>No, not at all. Due to the -why option you passed to the driver, it explains

I've compiler and run this program as well. The only problem is the size
of the object file generated, which is nearly 1Mb ! (for "hello world" !)
Can anyone tell me how to reduce this ?

Rachel Harrison                           email:  rh@ecs.soton.ac.uk 
Dept. of Electronics and Computer Science, 
307 Mountbatten Building, 
University of Southampton  
Southampton, SO9 5NH, UK 
Tel: +44 703 593249  Messages: +44 703 593649 Fax: +44 703 593045



======================================================================= 37 ===
Date:    Mon, 28 Sep 92 12:43:06 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: large M3 executables (was: verifying correct installation)

In article 12942@ecs.soton.ac.uk, rh@ecs.soton.ac.uk (Rachel Harrison) writes:
>I've compiler and run this program as well. The only problem is the size
>of the object file generated, which is nearly 1Mb ! (for "hello world" !)
>Can anyone tell me how to reduce this ?
>
The problem is the pretty large part of the M3 standard library which
is linked into *every* executable, even the "hello world" one: garbage
collector, thread scheduler, etc. Although the code size for small
examples seems unreasonable, remember that this overhead won't grow
with the size of your application.

Well, to reduce the size, there are a few possibilities:
 - compile libm3 with optimization. With gcc, this reduces the code size
   almost to a half.
 - strip your executable.
 - the most elegant way to solve the problem once and for all is to use
   shared libraries. In this case, libm3 is not linked statically into
   the executable, so the size of the executable is proportional to the
   sum of your object file sizes. Unfortunately, not all operating systems
   can handle shared libraries, but I don't know which.
   To use shared libraries, you can either extend the m3make templates
   as suggested some weeks ago in this group. This will give you a
   shared_library target in the m3makefiles.
   Personally, I use the following little script for converting the static
   library into a shared one:

#! /usr/public/bin/zsh
/bin/ld -o $1:r.so.$2 $(/bin/nm -pg $1 | awk '/^[0-9a-f]* D/{printf " -u " $3 }
') $1
rm $1
touch $1

   This works on SunOS, I don't know about others. The script takes two
   parameters: the name of the static library to be converted and the
   revision number for the shared library.
   Note that the static library is reduced to 0 bytes.

Peter
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany



======================================================================= 38 ===
Date:    Tue, 29 Sep 92 21:41:02 -0700
From:    <mhb@src.dec.com>
Subject: Re: Data structures text using M3?


On 9/25, rro@CS.ColoState.EDU (Rod Oldehoeft) posted the following:

  We intend to use Modula-3 in the second CS course (data structures) 
  here beginning in the Spring, 1993 semester.  It would be fine 
  if there were an appropriate text that also uses M3, but we're 
  having trouble finding such a thing. 

  Perhaps it's too early in the life of M3 to expect this.

  If you know of one, please let me know.  If you know of a manuscript 
  for a book that could benefit from our test-driving it, we'd like 
  to have a discussion about that. 

There are two books in the works: 

- Bob Sedgewick at Princeton is doing "Algorithms in M3". It will 
  be similar to the Pascal, C, and C++ version of his text, with 
  the snippits of code in M3. 
  
- Joe Bergin at Pace is writing a test for course in Data Abstraction 
  in Modula-3. 

The latter is probably more what you are after. I don't know the 
status of the project. Joe's email is BERGINF%PACEVM.bitnet@CUNYVM.CUNY.EDU 


