======================================================================== 1 ===
Date:    4 Sep 91 14:00:43 GMT
From:    comrade@uniwa.uwa.oz.au (Peter Cooper)
Subject: Porting m3 to a boring BSD-VAX

I noticed that vaxen running plain BSD don't seem to be supported on the
FAQ list.  But I use Ultrix a bit, and Sunos doesn't seem very divergent
from plain 4.3, so I thought I might try compiling it (I'm a sysadmin of
a machine used by a lot of anti-C programmers, and they had been
clamouring for Modula for yonks and eventually I gave in...).

It doesn't look like it's ever been attempted before, from the look of
the changes I had to make.  (I'm used to not having vfprintf, etc)

My site doesn't have xargs ... but does anyone have any suggestions on
where to get it?  Archie didn't help at all.

Finally, when I got most of it compiling (after replaing make with gnu
make, as bsd make was complaining about 'overlength lines') I hit the
problem in system/compiler/values/Module.m3 where it gives the error
message (and it's as clear as mud to me)
"Module.m3", line 238: compiler error: Schain botch

What does it mean?  I need help, or I may be lynched...!
;-)
com
-- 
email:	comrade@uniwa.uwa.oz.au	snail:	Peter Cooper, box 22
fax:	+61 9 380 1041			c/- Guild of Undergraduates
phone:	+61 9 380 3901			University of Western Australia
Constable Egg says: "Don't cook rice with a nuclear device!"


======================================================================== 2 ===
Date:    Wed, 4 Sep 91 16:12:02 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Porting m3 to a boring BSD-VAX

In article <1991Sep4.140043.6400@uniwa.uwa.oz.au>, Peter Cooper writes:

> My site doesn't have xargs ... but does anyone have any suggestions on
> where to get it?  Archie didn't help at all.

Try gatekeeper.dec.com:pub/comp.sources.unix/volume3/xargs.Z. 

> Finally, when I got most of it compiling (after replaing make with gnu
> make, as bsd make was complaining about 'overlength lines') I hit the
> problem in system/compiler/values/Module.m3 where it gives the error
> message (and it's as clear as mud to me)
> "Module.m3", line 238: compiler error: Schain botch
> 
> What does it mean?  I need help, or I may be lynched...!

This seems like an error from your C compiler.  I have no idea of what
it means.  You could try gcc (also available on gatekeeper.dec.com:pub/GNU/).

-- 
Eric.



======================================================================== 3 ===
Date:    Thu, 5 Sep 1991 14:28:10 -0400 
From:    Dick Orgass <do12+@andrew.cmu.edu>
Subject: Re: Trouble with m3tk under IBMR2

As Mick reported, I did successfully build m3tk for RISC/6000.  I don't
remember which file but there was one file that caused me to run out of
some kind of space.  Couldn't get my personal limits high enough
(possibly because of ignorance) so ran as root and then used ulimit to
set my limits to match the total system resources.  For some reason
unknown to me, ordinary users are more restricted than root so this
can't be done as an ordinary user.

Dick


======================================================================== 4 ===
Date:    Fri, 6 Sep 1991 04:13:44 GMT
From:    treese@crl.dec.com (Win Treese)
Subject: Re: Porting m3 to a boring BSD-VAX


In article <1991Sep4.161202.18099@src.dec.com> muller@src.dec.com (Eric Muller)
 writes:

>   > Finally, when I got most of it compiling (after replaing make with gnu
>   > make, as bsd make was complaining about 'overlength lines') I hit the
>   > problem in system/compiler/values/Module.m3 where it gives the error
>   > message (and it's as clear as mud to me)
>   > "Module.m3", line 238: compiler error: Schain botch
>   > 
>   > What does it mean?  I need help, or I may be lynched...!

>   This seems like an error from your C compiler.  I have no idea of what
>   it means.  You could try gcc (also available on gatekeeper.dec.com:pub/GNU/
).

"Schain botched" was a well-known bug in the 4.3 C compiler; it was fixed
in later versions of 4.3.

Win Treese						Cambridge Research Lab
treese@crl.dec.com					Digital Equipment Corp.


======================================================================== 5 ===
Date:    6 Sep 91 16:08:15 GMT
From:    norbert@informatik.uni-bremen.de (Norbert Beckmann)
Subject: Porting m3 to HP-RISC?


Has anyone  experience porting m3 to HP RISC stations,
especially Hewlett Packard 9000/7xx 9000/8xx ?


======================================================================== 6 ===
Date:    6 Sep 91 16:50:37 GMT
From:    tom@mbf.UUCP (Tom Watson)
Subject: How to get Modula3

I am new to this group and have not seen an FAQ yet.

Could someone tell me how/where to get modula-3 ?


======================================================================== 7 ===
Date:    Mon, 9 Sep 91 13:26:48 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Modula-3 FAQ

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: greaterrobustness, 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 definition 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

   Previous definitions were published as SRC Reports # 31 and 52 and
   can be obtained from SRC by sending a message to src-report@src.dec.com.


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.  The messages sent to
   comp.lang.modula3 are relayed to a mailing list; send a message to
   m3-request@src.dec.com to be added to it.

   Also, Pine Creek Software publishes a free newsletter and various
   announcements about Modula-3 products and activities.  To be added
   to their mailing list, send a message to modula3@bert.pinecreek.com
   or send regular mail to:

	Pine Creek Software
	Suite 300
	305 South Craig Street
	Pittsburgh, PA 15213
	Phone & Fax: [1] (412) 681 9811
	Email: modula3@bert.pinecreek.com
   

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/m3-1.6. 

   The current version, 1.6, implements the language defined in the 
   SRC report # 52.  Version 2.0 is in the works and will implement the 
   latest definition.

   Version 1.6 runs on:
	   Acorn R260 running RISC iX 1.21
           Apollo DN4500 running Domain/OS,
           DECstation 3100 and 5100 running Ultrix 3.1
           Encore Multimax running UMAX 4.3 (R4.1.1)
           HP 9000/300 running HP-UX 8.0
           IBM PC running AIX/PS2,
           IBM RT running IBM/4.3, 
           IBM R6000 running AIX 3.1, 
           VAX running Ultrix 3.1
           SPARCstation running SunOS 4.1.x
           SUN3 running SunOS

   SRC Modula-3 includes a user manual, compiler, runtime library,
   core library, pretty-printer, and a few other goodies.  The
   libraries include interfaces for X11R4, I/O streams, string
   functions, access to command line arguments, random numbers, and
   operating system access.

   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 ?

   You can contact Pine Creek Software (see the address above).


---
Eric.



======================================================================== 8 ===
Date:    Wed, 11 Sep 1991 17:16:20 GMT
From:    rhoover@watson.ibm.com (Roger Hoover)
Subject: SRC Modula-3 Copyright


The SRC Modula-3 COPYRIGHT file says:

>                SRC Modula-3 Non-commercial License

>SRC Modula-3 is distributed by Digital Equipment Corporation ("DIGITAL"),
>a corporation of the Commonwealth of Massachusetts.  DIGITAL hereby grants
>to you a non-transferable, non-exclusive, royalty free worldwide license
>to use, copy, modify, prepare integrated and derivative works of and
>distribute SRC Modula-3 for non-commercial purposes, subject to your
>agreement to the following terms and conditions:


What does 'Non-commercial License' and 'for non-commercial purposes'
mean? Does this mean that:

o  I cannot distribute SRC Modula-3 for commercial purposes?
o  I cannot sell SRC Modula-3?
o  I cannot sell programs written with SRC Modula-3?
o  I cannot use SRC Modula-3 when doing work for a commercial organization?

rhoover@watson.ibm.com


======================================================================== 9 ===
Date:    Tue, 17 Sep 1991 22:36:29 GMT
From:    chalmers@EuroPARC.Xerox.COM (Matthew Chalmers)
Subject: M3 and the Isis Distributed Programming Toolkit

Greetings and salutations -

I just posted to the comp.sys.isis board the following message and
the successor it mentions. To sum up, Steve Freeman (of the Cambridge U.
Computing Lab.) and I put together a *very* simple interface to
Cornell's Isis Distributed Programming Toolkit. I suppose I got into
doing this because I wanted a multicast tool and some slightly higher
level of abstraction for communication between parallel/distributed
processes than bog-standard RPC. Yes, it's still clunky and yes it 
covers only the basic features of Isis. 

So.. if you are interested then grab that stuff from the Isis board and 
take a look. 

Lang may yer lum reek,

--Matthew

P.S. May I take this opportunity to exhort you never to listen to Dire
Straits again? I think we British owe the world an apology for their 
blandness. Simple Minds too.. And T`Pau. All very regrettable.

--------------------------------------
From parc!EuroPARC.Xerox.COM!chalmers Tue Sep 17 23:14:01 1991
Article: 629 of comp.sys.isis
Newsgroups: comp.sys.isis
Path: parc!EuroPARC.Xerox.COM!chalmers
From: chalmers@EuroPARC.Xerox.COM (Matthew Chalmers)
Subject: Modula-3 and Isis
Message-ID: <1991Sep17.220534.19747@parc.xerox.com>
Keywords: Modula-3, Isis, tasks
Lines: 71
Sender: news@parc.xerox.com
Reply-To: chalmers@EuroPARC.Xerox.COM (Matthew Chalmers)
Organization: Rank Xerox EuroPARC, Cambridge, UK
Date: Tue, 17 Sep 91 23:05:34 BST

Hello -

I am about to post a file which contains a uuencoded compressed tar file.
It contains the bits and pieces we used to make a version of Isis v2.1 
usable with Modula-3. [For the uninitiated, Modula-3 is the progeny of
Modula-2, Modula-2+, Cedar and a few other languages. DEC SRC is its home.]
I must point out that this is a *very* simple version which undoubtedly
could be made neater, faster, etc. Right now it just makes available the 
most basic communication facilities, and it runs on our Suns with m3 v1.6.
Steve Freeman (of EuroPARC and also of the Computing Laboratory of Cambridge
University) was my collaborator.

Sloth is a primary reason for it not being neater and faster, along with my
commitments to other work. I have used it for some simple work of my own,
and am reasonably content with it, but basically I thought that those with
more time might find it interesting and perhaps improve it beyond its 
simple state.

The basic idea is to change libisis2.a to use M3's task system, then do some
interface modules to describe the M3 interface. 
Below my signature is the contents of the file 'intro', one of the files
in the tar file package. If I have missed something out, or you want to
ask me about this stuff, then mail me.

Regards,

--Matthew

Matthew Chalmers, Rank Xerox EuroPARC, 61 Regent St, Cambridge CB2 1AB, U.K.
eMail: chalmers.europarc@rx.xerox.com
tel: [44] 223 341546   fax: [44] 223 341510

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

First of all, we took a copy of the the isisv2.1/SUN4 tree of directories,
 and so we had to change the makefile to account for this new version. 
See top.Makefile.diff

We had to make some changes to include/cl_task.h.
See task.h.diff

We changed isisv2.1/clib/makefile in order to link in to our own extra M3
files, and to ensure that only libisis2.a was worked on. We use a link
from SUN4M3/clib/ over into the SUN4 version of libisis1.a. We make our
own libisis2.a, though.
See clib.makefile.diff

In this SUN4M3 directory we had to change the makefile to set up the
definitions for the M3-specific #defines. 
See SUN4M3.Makefile.diff

I made a directory (utils) with the basic m3 interfaces and modules for
wrapping up the Thread interface (ThreadWrap), and also a few of the
standard Isis calls (Isis).
See contents of subdir "utils"

In m3 itself I have a simple pair of example programs which send and
receive mesages respectively.
See sender.m3, receiver.m3, Makefile







======================================================================== 10 ===
Date:    20 Sep 91 13:28:25 GMT
From:    miron@chevre.cs.wisc.edu (Miron Livny)
Subject: Problem with threads

I have ported my simulation environment from Modula2 to Modula3.
The environment is based on processes that were implemented as co-routines   
in the Modula2 version. In Modula3 each process is represented by a thread.
The following program captures the structure of the Modula3 version

MODULE test EXPORTS Main;
IMPORT Thread;
VAR
    simMutex : Thread.Mutex := NEW(Thread.Mutex);
    simCon   : Thread.Condition := NEW(Thread.Condition);
    procCon  : ARRAY [0..10] OF Thread.Condition ;
    process  : Thread.Closure;
    simMode  : BOOLEAN;
    nodeId   : INTEGER;
    count    : INTEGER;
PROCEDURE Process(SELF : Thread.Closure) : REFANY RAISES {} = 
VAR
    myNodeId : INTEGER;
BEGIN
    myNodeId := nodeId;
    Thread.Acquire(simMutex);
    LOOP
        Thread.Signal(simCon);
        Thread.Wait(simMutex,procCon[myNodeId]);
    END;
END Process;

BEGIN
    count := 0;
    Thread.Acquire(simMutex);
    FOR I :=  1 TO 10 DO
	process := NEW(Thread.Closure, apply := Process);
        procCon[I] := NEW(Thread.Condition);
	nodeId := I;
	EVAL Thread.Fork(process);
	Thread.Wait(simMutex,simCon);
    END;
    LOOP
	FOR I := 1 TO 10 DO
	    INC(count);
	    Thread.Signal(procCon[I]);
	    Thread.Wait(simMutex,simCon);
	END;
    END;
END test.

Like the full version of the Modula3 implementation, this program
deadlocks after a random number of events. The following script
demonstrates the non-deterministic behavior of the program

chevre:1> m3 -o test test.m3
chevre:2> test
M3 runtime error: Deadlock !

Quit (core dumped)
8.3u 9.1s 0:19.75 88.6% 102+158k 2+56io 29pf+0w
chevre:3> dbx test core
dbx version 2.10.1
Type 'help' for help.
Corefile produced from file "test"
Child died at pc 0x427688 of signal : Quit
reading symbolic information ...
[using memory image in core]
(dbx) print _test__count
47102 
(dbx) quit
chevre:4> test
M3 runtime error: Deadlock !

Quit (core dumped)
24.5u 30.2s 0:56.48 97.0% 99+158k 0+56io 9pf+0w
chevre:5> dbx test core
dbx version 2.10.1
Type 'help' for help.
Corefile produced from file "test"
Child died at pc 0x427688 of signal : Quit
reading symbolic information ...
[using memory image in core]
(dbx) print _test__count
148080 
(dbx) quit

Is there anything wrong in the way I use the threads or is it a
Modula3 bug?

Thanks

Miron Livny


======================================================================== 11 ===
Date:    Fri, 20 Sep 91 09:03:16 PDT
From:    msm@src.dec.com (Mark S. Manasse)
Subject: Re: Problem with threads

Eric Muller and I recently tracked down this bug in the scheduler; it turns
out that in the implementation of Thread.Wait there is a gap between the 
release of the MUTEX and blocking on the condition variable where a
pre-emptive context switch can cause the waiting thread to miss a wakeup.
Perhaps Eric can be persuaded to post the diff; it's just a couple of lines.

Mark




======================================================================== 12 ===
Date:    Fri, 20 Sep 91 11:43:42 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Problem with threads

In article <1991Sep20.090316.7873@src.dec.com>, Mark S. Manasse writes:

> Eric Muller and I recently tracked down this bug in the scheduler; it turns
> out that in the implementation of Thread.Wait there is a gap between the 
> release of the MUTEX and blocking on the condition variable where a
> pre-emptive context switch can cause the waiting thread to miss a wakeup.
> Perhaps Eric can be persuaded to post the diff; it's just a couple of lines.

Well, what we found is a bug in the most recent version at SRC.  The
1.6 release seems ok (at least for that bug).  I'll investigate.

-- 
Eric.



======================================================================== 13 ===
Date:    Fri, 20 Sep 91 14:24:10 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Problem with threads

In article <1991Sep20.132825.11499@spool.cs.wisc.edu>, miron@chevre.cs.wisc.edu
 (Miron Livny) writes:
> I have ported my simulation environment from Modula2 to Modula3.
> ...
> Like the full version of the Modula3 implementation, this program
> deadlocks after a random number of events.

I suspect that you are running on a DECstation; is that true ?  Also,
what optimization do you have (both for your program and the SRC
libraries) ?

-- 
Eric.



======================================================================== 14 ===
Date:    20 Sep 91 21:16:24 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Modula-3 help at OOPSLA

This is a reminder of the Modula-3 activities at OOPSLA '91, and a
request for your help there.

The Conference on Object-Oriented Programming Systems, Languages, and
Applications (OOPSLA '91) will be held October 6-11 in Phoenix. There
will be several Modula-3 related activities:

+ I will give an intermediate-level Modula-3 OOP tutorial Sunday morning.

+ Pine Creek Software will be exhibiting Modula-3 (booth 218) and
attempting to convert a few C++ programmers. Maybe we'll even have
some Modula-3 souvenirs--real collector's items!

+ There will be a Modula-3 BOF (Birds-of-a-Feather session) one
evening--watch the BOF bulletin board.

+ Prentice Hall will have lots of copies of Greg Nelson's Modula-3
book in their booth, and will have order forms for (and a display copy
of) my Modula-3 book. (For you closet C programmers, you can also get
your copy of H&S autographed at the Pine Creek booth.)

Advance registration for OOPSLA '91 ends Sept. 27, so don't delay.

Now, listen up! I'm desperately in need of some help in the Pine Creek
booth at OOPSLA. If you are going to be at OOPSLA and would be willing
to spend a couple of hours handing out Modula-3 literature and
answering easy questions ("Is there a PC compiler for Modula-3?"
"No."), please send me a note.  You'll be paid $10/hr for your time,
and maybe get the chance to meet some nice people.

Sam Harbison 
Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213;
USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com.


======================================================================== 15 ===
Date:    17 Sep 91 21:58:24 GMT
From:    hudson@cs.umass.edu (Rick Hudson)
Subject: Type equivalence and initial values.

"Two types are the same if their definitions become the same when expanded;
that is, when all constant expressions are replaced by their values and all
type names are replaced by their definitions."  pg 12

"A record is a member of T if it has fields with the given names and types, in
the given order, and no other fields." pg 16

I am somewhat confused about whether the following two types are equivalent or
not. The book seems to be less than clear about when default initialization
constants are part of the type or not.

TYPE
r1 = RECORD
       a: INTEGER := 1;
     END;

r2 = RECORD
       a: INTEGER := 2;
     END;

I would be hard pressed to argue that these are different types, pg 16
supports this but page 12 doesn't.

I becomes even less clear when dealing with object. Are the following
equivalent types.

TYPE
o1 = OBJECT
       METHODS
         m() := proc1;
       END;

o2 = OBJECT
       METHODS
         m(): PROCEDURE (x: o2);
       END;

PROCEDURE proc1 (x: o1) = BEGIN END proc1;

The only difference is that o1.m has an initial value of proc1 and o2.m has an
initial value of NIL. Are initial values used to determine type equivalence?

                Richard L. Hudson, Research Associate
                Object Oriented Systems Lab
                University of Massachusetts
                Amherst, MA  01003
                (413) 545-1220; Hudson@cs.umass.edu



--

                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


======================================================================== 16 ===
Date:    22 Sep 91 23:02:25 GMT
From:    MM0F@NS.CC.LEHIGH.EDU (Mary Elizabeth Rudis)
Subject: Need address

Can someone e-mail me the address where I can write to obtain
Modula-3 for the PC and Mac. I need to get these through snail-mail
if possible.

MM0F@LEHIGH.BITNET


======================================================================== 17 ===
Date:    23 Sep 91 08:26:21 GMT
From:    mgallo@zeus.calpoly.edu (M. Gallo)
Subject: Re: Need address

In article <22099118.02.06MM0F@lehigh.bitnet> MM0F@NS.CC.LEHIGH.EDU (Mary Eliza
beth Rudis) writes:
>Can someone e-mail me the address where I can write to obtain
>Modula-3 for the PC and Mac. I need to get these through snail-mail
>if possible.
>
>MM0F@LEHIGH.BITNET

If there is such a beast, please post!  If there are any plans for
such a thing, please post!  Alas, though, I fear the worst.
-- 
                                                           _   /|
Miguel                                                     \'o.O'
mgallo@ares.calpoly.edu                                    =(___)=
"C is its own virus."                                         U


======================================================================== 18 ===
Date:    Mon, 23 Sep 91 11:57:34 PDT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: Type equivalence and initial values.

In article <HUDSON.91Sep17175824@yough.cs.umass.edu>, hudson@cs.umass.edu (Rick
 Hudson) writes:
> "Two types are the same if their definitions become the same when expanded;
> that is, when all constant expressions are replaced by their values and all
> type names are replaced by their definitions."  pg 12
> 
> "A record is a member of T if it has fields with the given names and types, i
n
> the given order, and no other fields." pg 16
> 
> I am somewhat confused about whether the following two types are equivalent o
r
> not. The book seems to be less than clear about when default initialization
> constants are part of the type or not.
> 
> TYPE
> r1 = RECORD
>        a: INTEGER := 1;
>      END;
> 
> r2 = RECORD
>        a: INTEGER := 2;
>      END;
> 
> I would be hard pressed to argue that these are different types, pg 16
> supports this but page 12 doesn't.
> 

I think the book is in fact clear, but your intuition is causing you to
ignore the definitions. I must say that I sympathise with your confusion
and also add that the committee did argue at some length over whether
default values should be considered in the definition of "same". 

Anyway, r1 and r2 are not the same. However a variable of type r2 is a member
of r1, by the definition on page 11. "If a value can be represented by some
variable of type T, then we say that the value is a member of type T and
T contains the value". Because of the subtyping rules, there are many times
when variables declared with one type are members of another type, and are 
assignable by the subtype rules. However, there is NO subtype rule between 
records, so membership doesnt help any. 

You use the term "equivalent" but you dont define precisely what it means. 
Modula-3 does not define the term "equivalent", instead it defines "same"
"subtype", "member", and "assignable". Since r1 and r2 are not the "same"
and there is no subtype rule between records, you will find, e.g. that
a variable declared with type r2 is not assignable to one declared with type
r1.

> I becomes even less clear when dealing with object. Are the following
> equivalent types.
> 
> TYPE
> o1 = OBJECT
>        METHODS
>          m() := proc1;
>        END;
> 
> o2 = OBJECT
>        METHODS
>          m(): PROCEDURE (x: o2);
>        END;
> 
> PROCEDURE proc1 (x: o1) = BEGIN END proc1;
> 
> The only difference is that o1.m has an initial value of proc1 and o2.m has a
n
> initial value of NIL. Are initial values used to determine type equivalence?

Default values for methods are just like other default values. Actually your se
cond
declaration should read:

  o2 = OBJECT
         METHOD
           m();
         END;

In any event, these two types are not the "same" and there is no subtype
rule that relates object types which only differ in their method defaults.
So a variable declared with type o1 is not assignable to a variable
declared with type o2.

Mick Jordan



======================================================================== 19 ===
Date:    Mon, 23 Sep 91 17:37:51 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Need address

> >Can someone e-mail me the address where I can write to obtain
> >Modula-3 for the PC and Mac. I need to get these through snail-mail
> >if possible.
> 
> If there is such a beast, please post!  If there are any plans for
> such a thing, please post!  Alas, though, I fear the worst.

Unfortunately, there is no such thing today.  The only implementation
is SRC Modula-3.  It runs on:

	   Acorn R260 running RISC iX 1.21
           Apollo DN4500 running Domain/OS,
           DECstation 3100 and 5000 running Ultrix 4.x
           Encore Multimax running UMAX 4.3 (R4.1.1)
           HP 9000/300 running HP-UX 8.0
           IBM PC running AIX/PS2,
           IBM RT running IBM/4.3, 
           IBM R6000 running AIX 3.1, 
           VAX running Ultrix 4.x
           SPARCstation running SunOS 4.1.x
           SUN3 running SunOS

-- 
Eric.



