======================================================================== 1 ===
Date:    Mon, 2 Dec 91 16:02:17 -0500
From:    Norman Ramsey <nr@Princeton.EDU>
Subject: Seekable text readers and writers

As someone pointed out recently, it's impossible to send a pickle down
a pipe since pickles require seekable readers and writers.  I have
written seekable versions of TextRd.T and TextWr.T, the text readers
and writers that come with SRC Modula-3.  These can be used to pickle
something into a TEXT, and the TEXT can then be sent down a pipe.
While I was at it I saved a couple of procedure calls by importing the
private representation of TEXT.

The implementations are small, so I include them with this message.  I
did minimal testing using small buffer sizes (7 and 10 bytes); 
I successfully pickled and unpickled a TEXT.


# To unbundle, "sed '1,/^# To unbundle/d' < thisfile | sh"
# To unbundle, make sure both lines appear in the file
# Wed Nov 20 17:41:50 EST 1991
echo TextRd.m3 1>&2
sed 's/^-//' >'TextRd.m3' <<'End of TextRd.m3'
-MODULE TextRd;
-
-IMPORT Rd, RdClass, Text, TextF;
-FROM Thread IMPORT Alerted;
-FROM Rd IMPORT Failure, Error;
-
-REVEAL
-  T = Rd.T BRANDED "seekable TextRd.T" OBJECT text: TEXT; len: CARDINAL; END;
-
-  (* src(rd)=rd.text, with the terminating 0 in rd.text == eof
-     len(rd)=rd.len=LAST(rd.text^)
-   *)  
-
-CONST
-  BuffSize = 500;
-
-PROCEDURE New (t: Text.T): T =
-  BEGIN
-    RETURN NEW(T, st := 0, lo := 0, cur := 0, hi := 0,
-         buff := NEW (REF ARRAY OF CHAR , BuffSize),
-         closed := FALSE, seekable := TRUE, intermittent := FALSE,
-         seek := Seek, length := Length, close := Close,
-         text := t, len := LAST(t^));
-  END New;
-
-PROCEDURE Seek (rd: T; <*UNUSED*> dontBlock: BOOLEAN): RdClass.SeekResult 
-     RAISES {Failure, Alerted, Error} =
-  VAR
-    charsRead: INTEGER;
-  BEGIN
-    IF rd.len <= rd.cur THEN
-      RETURN RdClass.SeekResult.Eof; 
-    ELSE
-      charsRead := MIN (NUMBER (rd.buff^), rd.len-rd.cur);
-      SUBARRAY(rd.buff^, 0, charsRead) := SUBARRAY(rd.text^, rd.cur, charsRead
);
-      rd.lo := rd.cur;
-      rd.hi := rd.lo + charsRead;
-      RETURN RdClass.SeekResult.Ready;
-    END;
-  END Seek;
-
-PROCEDURE Length (rd: T): CARDINAL RAISES {Failure, Alerted, Error} =
-  BEGIN
-    RETURN rd.len;
-  END Length;
-
-PROCEDURE Close (rd: T) RAISES {Failure, Alerted, Error} =
-  BEGIN
-    rd.buff := NIL;
-    rd.text := NIL;
-  END Close;
-
-BEGIN
-END TextRd.
-
End of TextRd.m3
echo TextWr.m3 1>&2
sed 's/^-//' >'TextWr.m3' <<'End of TextWr.m3'
-MODULE TextWr;
-IMPORT Wr, WrClass, Text, TextF;
-FROM Wr IMPORT Failure;
-
-REVEAL
-  T = Wr.T BRANDED "seekable TextWr.T" OBJECT text: TEXT; END;
-  
-CONST BuffSize = 500; 
-
-(* The representation invariant for a text writer wr is
-        len(wr) = MAX(LAST(wr.text^), wr.cur);
-	target(wr) = wr.text & SUBARRAY(wr.buff^, LAST(wr.text^) - wr.lo, 
- *)
-
-PROCEDURE New(): T =
-  BEGIN
-    RETURN
-      NEW(T, 
-        st := 0,
-        lo := 0,
-        cur := 0,
-        hi := BuffSize,
-        buff := NEW(REF ARRAY OF CHAR, BuffSize),
-        closed := FALSE,
-        seekable := TRUE,
-        buffered := TRUE,
-        seek := Seek, 
-        close := Close,
-        flush := Flush, 
-        text := "")
-  END New;
-
-
-PROCEDURE Flush(wr: T) RAISES {} =
-BEGIN
-  IF wr.cur # wr.lo THEN
-    IF wr.cur > LAST(wr.text^) THEN
-      VAR new := TextF.New(wr.cur); (* hold through wr.cur-1, plus trailing nu
ll *)
-      BEGIN
-        SUBARRAY(new^,0,wr.lo) := SUBARRAY(wr.text^,0,wr.lo);
-        wr.text := new;
-      END;
-    END;
-    <* ASSERT wr.cur <= LAST(wr.text^) *>
-    SUBARRAY(wr.text^, wr.lo, wr.cur - wr.lo) := SUBARRAY(wr.buff^, 0, wr.cur 
- wr.lo);
-  END;
-END Flush;
-
-PROCEDURE Seek(wr: T; n: CARDINAL) RAISES {Failure} =
-BEGIN
-  Flush(wr);
-  wr.lo := MIN(n,LAST(wr.text^));
-  wr.cur := wr.lo;
-  wr.hi := wr.lo + NUMBER(wr.buff^)
-END Seek;
-
-PROCEDURE Close(wr: T) RAISES {} =
-  BEGIN wr.buff := NIL; wr.text := NIL END Close;
-
-
-PROCEDURE ToText(wr: T): TEXT =
-  VAR 
-    result: Text.T;
-  BEGIN
-    WrClass.Lock(wr);
-    TRY
-      IF wr.lo = 0 AND LAST(wr.text^) <= wr.cur THEN (* fast path () *)
-        result := TextF.New(wr.cur);
-        SUBARRAY(result^, 0, wr.cur) := SUBARRAY(wr.buff^, 0, wr.cur);
-      ELSE
-        wr.flush();
-        result := wr.text;
-      END;
-      wr.text := "";
-      wr.cur := 0;
-      wr.lo := 0;
-      wr.hi := NUMBER(wr.buff^)
-    FINALLY 
-      WrClass.Unlock(wr)
-    END;
-    RETURN result;
-  END ToText;
-
-BEGIN END TextWr.
End of TextWr.m3
-- 
Norman Ramsey
nr@princeton.edu




======================================================================== 2 ===
Date:    Mon, 2 Dec 91 13:16:55 PST
From:    muller@src.dec.com (Eric Muller)
Subject: archive of comp.lang.modula3 for November 1991

The archive of the messages sent to comp.lang.modula3 in November 1991
are now available in:

    gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3/91-11.Z

Enjoy,
Eric.


======================================================================== 3 ===
Date:    Mon, 2 Dec 91 13:09:55 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Modula-3 Frequently Asked Questions (FAQ)

Archive-name: Modula-3-faq
Last-modified: Fri Nov  1 1991


			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: 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.

   There is an overview article "Modula-3", by Sam Harbison, in 
   Byte, Vol. 15, Number 12, October 1990, p 385.


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 on paper from SRC by sending a message to
   src-report@src.dec.com.  Report # 52 is also available in
   PostScript format via anonymous ftp from gatekeeper.dec.com in
   pub/DEC/Modula-3/report. 


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 email or US 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 5000 running Ultrix 4.0 and 4.2
           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.



======================================================================== 4 ===
Date:    3 Dec 91 13:53:58 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Modula-3 Frequently Asked Questions (FAQ)

In the process of learning more about Modula 3, i had several questions
which could be included at the end of the FAQ for those who want more
details before buying and reading the excellent SPwM3 book. I now have
answers for pretty much all these questions but the people at DEC are
likely to provide more accurate ones for the FAQ. Here it goes:


- Implications of having/ not having: garbage collection, built-in support
  for threads, exception handling, explicit interfaces, isolation of unsafe
  features, operator overloading and function name overloading (a la C++).

- How do other popular procedural object oriented languages stand with 
  respect to the above features: C++, Eiffel and Oberon.

- Why type equivalence.

- How one obtains the equivalent of private/protected/public with the more
  general mecanisms of opaque types and import/export.

- More details about the available libraries, like Pickles and Trestle.

For instance, i especially enjoyed the paragraph about C/C++ in the
introduction. It is simple and precise without being arrogant. The chapter
about how some features got into the language is also most informative.

After dealing with the intricacies and promises (build your own garbage
collector, persistent objects...) of C++ for over two years, i certainly
hope that Modula 3 will succeed.

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

Michel Dagenais				    dagenais@vlsi.polymtl.ca
Ecole Polytechnique de Montreal		    tel: (514) 340-4029

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


======================================================================== 5 ===
Date:    3 Dec 91 19:07:21 GMT
From:    rstenbro.bbs@shark.cse.fau.edu
Subject: Oberon

Does anybody have any information on Oberon compilers and/or modula-3
compilers for msdos , os/2 or Unix.
Does anybody have public available source for those compilers.
Please mail me if you have any hints.
I am also traying to write my own oberon compilers. Any hints?


======================================================================== 6 ===
Date:    2 Dec 91 23:16:41 GMT
From:    mff@cs.Princeton.EDU (Mary F. Fernandez)
Subject: Intermediate Rep. Lang. & Optimizations

I would like to find out into what intermediate language(s)
Modula-3 is compiled; whether any global optimizers have
been written for these languages; and if there are any optimization 
problems unique to Modula-3.  Any information on these
questions or pointers to sources would be greatly appreciated.

Mary Fernandez
mff@cs.princeton.edu 


======================================================================== 7 ===
Date:    Wed, 4 Dec 91 09:13:39 -0500
From:    Mary F. Fernandez <mff@Princeton.EDU>
Subject: Intermediate Representation & Optimization


I'd like to find out about the intermediate representation
language(s) used by the Modula-3 compiler and whether
any global optimizations are provided by the compiler.  
I'm also interested in any optimization problems that
might be unique to Modula-3.  Information regarding
these questions or pointers to sources would be appreciated. 

This may be a duplicate posting -- sorry for redudancy.

Thanks
Mary Fernandez, mff@cs.princeton.edu  


======================================================================== 8 ===
Date:    Wed, 4 Dec 91 09:27:55 PST
From:    <kalsow@src.dec.com>
Subject: Re: Intermediate Representation & Optimization

The SRC Modula-3 compiler generates C as its intermediate language.
Generally, we stay away from the C optimizers.

There are optimization problems associated with GC and exceptions.
They're not unique to Modula-3.  For example:

  Biased pointers vs. GC:
     Optimizers like to keep pointers to virtual "zero" elements of arrays.
     Conservative garbage collectors require that a pointer exist
     into or near an object to keep it alive.  Consider:

         VAR a: REF ARRAY [1000..2000] OF X;
         FOR i := FIRST (a^) TO LAST (a^) DO
             ..... something with a[i] ...
         END;

     The optimizer may want to keep a pointer to "a[0]" and
     drop the pointer to a[1000].  If there are no other references
     to a, the collector may reclaim it before the loop finishes.

  Derived pointers vs. GC:
     A similar problem occurs when the optimizer decides to keep only
     an internal pointer, but the collector demands that the original
     pointer be kept alive.  Consider:

         PROCEDURE P (VAR i: INTEGER) = ...

         VAR x: REF RECORD a, b, c: INTEGER END;
         ....  P (x.b) ...

     If the call to P is the last reference to x, the optimizer
     may compute the address of x.b and pass it to P without
     keeping the value x alive.

  Data flow vs. exceptions: 
     Exceptions introduce all sorts of non-apparent control flow.
     Consider:

         TRY
            i := 1;
            ... some code that may raise an exception ...
            i := 2;
         FINALLY
            ... T ...
         END;

     What's the location of variable i when the handler T is entered?
     Can the definition 'i := 1' reach T?

Many intermediate languages don't deal with these issues.

 - Bill Kalsow


======================================================================== 9 ===
Date:    5 Dec 91 20:46:43 GMT
From:    del@cs.brown.edu (David E. Langworthy)
Subject: TCP Question

I am considering using modula-3 for distributed application so I am
writing a small test application.  What I would like to have is a
server with one thread and one TCP connection per client.  I've
figured out how to do the scheduling with RTScheduler.IOselect, but I
can't figure out how to get a TCP port.  All I think I need right now
is a translation of the include file "netinet/in.h" into a .i3 file.
Does anyone have one or experience programming distributed
applications in modula-3?  I could also use a stream interface to TCP,
but that's not so important.  Any help will be greatly appreciated.

Dave



======================================================================== 10 ===
Date:    5 Dec 91 21:39:52 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Intermediate Representation & Optimization

Just to ease everyone's mind about the GNU Modula-3 compiler we're developing,
all the hazards Bill Kalsow mentioned w.r.t. GC and exceptions are handled
properly by our compiler. We have a submission to the SIGPLAN conference about
the GC approach; the exception handling involved adding what amount to
additional conditional control flow edges to program graph (from places where
exceptions may occur to the appropriate handler arm). Both GC and exceptions
were designed and implemented according to the maxim "no additional code in
the normal case". Of course, various things make this not *quite* true (e.g.,
the presence of exception handlers may require an additional branch around
them, or different register handling), but it's a great approximation. The
main exception is code for store checks for our scavenging collector (and yes,
the gc approach will be controlled with compiler flags so you don't *have* to
do it our way). Regards ---					Eliot
--

		J. Eliot B. Moss, Assistant 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


======================================================================== 11 ===
Date:    5 Dec 91 14:03:52 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Lilac two-view document editor

A while back there was an article in the IEEE Computer magazine about
Lilac, an experimental document editor offering both programmability and
WYSIWYG output. It ended saying that Lilac runs on a Firefly running 
Topaz and was written in Modula2+ under the Trestle window system. 
It all seemed too exotic back then, but since there is a converter (i
think) from Modula2+ to Modula3 and Trestle runs under X windows... 
it should run on conventional hardware. The author, Kenneth Brooks,
apparently now works for DEC SRC. Does anyone there knows if Lilac can be 
made available and would run on any workstation supported by DEC SRC Modula3 ?

Thanks for any info! By the way, is anybody else in Montreal using Modula 3?
--
---------------------------------------------------------------------------

Michel Dagenais				    dagenais@vlsi.polymtl.ca
Ecole Polytechnique de Montreal		    tel: (514) 340-4029

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


======================================================================== 12 ===
Date:    Fri, 6 Dec 91 10:37:19 PST
From:    <mhb@src.dec.com>
Subject: Re: Lilac two-view document editor


Ken Brooks stopped working on Lilac after his thesis was compleleted 
(summer, 1988). At that point, he had a working system, accurately 
portrayed in the recent IEEE Computer article. The system had a few 
users at that time, but there are currently no Lilac users here, 
primarily because it isn't a full TeX and it isn't maintained. 

After his thesis,Ken then worked with me here at DEC SRC on my FormsVBT 
system, a multi-view GUI. We have a "mini" version of that system 
mostly running in Modula-3, but it's months before that will be ready 
for public distribution. Stay tuned to this newsgroup for details.

Ken left SRC about a year ago for personal reasons. He is currently 
working in the Palo Alto area as a private consultant for PC users. 
I don't have an email address for him, but he's listed in the phone 
book. 

I don't know who "owns" the source code to Lilca (the work was done 
by Ken as an employee of DEC), but if you are interested in porting 
it Modula 3, I'd be surprised if the "owners" would not be delighted.


======================================================================== 13 ===
Date:    Fri, 6 Dec 1991 12:40:09 PST
From:    David Nichols <nichols@parc.xerox.com>
Subject: Re: TCP Question

I have translated netinet/in.h to Uin.i3 and Uin.m3.  I'm enclosing a
copy here; I've also sent one to the SRC guys for inclusion in a future
release.  The impls of ntohl and friends assume a big-endian machine. 
You'll need to change them if yours is little-endian.

To use this, get a socket from Usocket.socket.  Here's a routine to
connect to another host:

(* Get a connected socket to a given host & port.  Assumes both host and
   port are in host byte order (this is slightly unusual). *)
PROCEDURE GetClientSocket (host, port: INTEGER): INTEGER
  RAISES {RPC.Failed} =
  VAR
    addr: Uin.struct_sockaddr_in;
    s   : INTEGER;
  BEGIN
    addr.sin_family := Usocket.AF_INET;
    addr.sin_addr := Uin.union_in_addr{Uin.htonl(host)};
    addr.sin_port := Uin.htons(port);
    FOR i := FIRST(addr.sin_zero) TO LAST(addr.sin_zero) DO
      addr.sin_zero[i] := VAL(0, CHAR);
    END;
    s := Usocket.socket(Usocket.AF_INET, Usocket.SOCK_STREAM, 0);
    IF s = -1 THEN
      RAISE RPC.Failed(NEW(RPC.CommFailure,
                           info := "Couldn\'t get TCP socket."));
    END;
    IF Usocket.connect(s, ADR(addr), BYTESIZE(addr)) = -1 THEN
      RAISE RPC.Failed(NEW(RPC.CommFailure,
                           info := "Connect to remote address failed.\n"));
    END;
    RETURN s;
  END GetClientSocket;

I then use UFileRdWr.CreateFileReader and CreateFileWriter to get an
Rd.T and Wr.T, but you can also wing it yourself with
RTScheduler.IOSelect.

Marvin Theimer and I have implemented SunRPC for M3 along with a
stub-generator (adapted from Sun's rpcgen).  We're busy trying to get
this cleared for release, but I don't know how long that will take. 
Stay tuned.

	David
================================
#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  Uin.i3 Uin.m3
# Wrapped by nichols@osprey on Fri Dec  6 11:17:06 1991
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'Uin.i3' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'Uin.i3'\"
else
echo shar: Extracting \"'Uin.i3'\" \(3860 characters\)
sed "s/^X//" >'Uin.i3' <<'END_OF_FILE'
X(* Uin.i3 -- M3 interface to Unix facilities in netinet/in.h. *)
X(* David Nichols, Xerox PARC *)
X
XINTERFACE Uin;
X
XFROM Ctypes IMPORT short;
XFROM Utypes IMPORT u_short, u_long;
XIMPORT Word;
X
X(* Constants and structures defined by the internet system,
X   Per RFC 790, September 1981. *)
X
XCONST
X  IPPROTO_IP = 0;		(* dummy for IP *)
X  IPPROTO_ICMP = 1;		(* control message protocol *)
X  IPPROTO_IGMP = 2;		(* group control protocol *)
X  IPPROTO_GGP = 3;		(* gateway^2 (deprecated) *)
X  IPPROTO_TCP = 6;		(* tcp *)
X  IPPROTO_EGP = 8;		(* exterior gateway protocol *)
X  IPPROTO_PUP = 12;		(* pup *)
X  IPPROTO_UDP = 17;		(* user datagram protocol *)
X  IPPROTO_IDP = 22;		(* xns idp *)
X  IPPROTO_HELLO = 63;		(* "hello" routing protocol *)
X  IPPROTO_ND = 77;		(* UNOFFICIAL net disk proto *)
X
X  IPPROTO_RAW = 255;		(* raw IP packet *)
X  IPPROTO_MAX = 256;
X
X(* Port/socket numbers: network standard functions *)
X  IPPORT_ECHO = 7;
X  IPPORT_DISCARD = 9;
X  IPPORT_SYSTAT = 11;
X  IPPORT_DAYTIME = 13;
X  IPPORT_NETSTAT = 15;
X  IPPORT_FTP = 21;
X  IPPORT_TELNET = 23;
X  IPPORT_SMTP = 25;
X  IPPORT_TIMESERVER = 37;
X  IPPORT_NAMESERVER = 42;
X  IPPORT_WHOIS = 43;
X  IPPORT_MTP = 57;
X
X(* Port/socket numbers: host specific functions *)
X  IPPORT_TFTP = 69;
X  IPPORT_RJE = 77;
X  IPPORT_FINGER = 79;
X  IPPORT_TTYLINK = 87;
X  IPPORT_SUPDUP = 95;
X
X(* UNIX TCP sockets *)
X  IPPORT_EXECSERVER = 512;
X  IPPORT_LOGINSERVER = 513;
X  IPPORT_CMDSERVER = 514;
X  IPPORT_EFSSERVER = 520;
X
X(* UNIX UDP sockets *)
X  IPPORT_BIFFUDP = 512;
X  IPPORT_WHOSERVER = 513;
X  IPPORT_ROUTESERVER = 520;	(* 520+1 also used *)
X
X(* Ports < IPPORT_RESERVED are reserved for privileged processes (e.g. root).
X   Ports > IPPORT_USERRESERVED are reserved for servers, not necessarily
X   privileged. *)
X  IPPORT_RESERVED = 1024;
X  IPPORT_USERRESERVED = 5000;
X
X(* Link numbers *)
X  IMPLINK_IP = 155;
X  IMPLINK_LOWEXPER = 156;
X  IMPLINK_HIGHEXPER = 158;
X
X(* Internet address
X   The old obsolete fields are gone.  Only s_addr remains. *)
XTYPE
X  union_in_addr = RECORD
X    s_addr: u_long;
X  END;
X
X
X(* Definitions of bits in internet address integers.
X   On subnets, the decomposition of addresses to host and net parts
X   is done according to subnet mask, not the masks here. *)
XPROCEDURE IN_CLASSA(i: INTEGER): BOOLEAN;
XCONST
X  (* Compiler bug/feature forces us to use Word.Shift *)
X  IN_CLASSA_NET: u_long = Word.Shift(16_ff0000, 8);
X  IN_CLASSA_NSHIFT = 24;
X  IN_CLASSA_HOST = 16_00ffffff;
X  IN_CLASSA_MAX = 128;
X
XPROCEDURE IN_CLASSB(i: INTEGER): BOOLEAN;
XCONST
X  IN_CLASSB_NET = Word.Shift(16_ffff00, 8);
X  IN_CLASSB_NSHIFT = 16;
X  IN_CLASSB_HOST = 16_0000ffff;
X  IN_CLASSB_MAX = 65536;
X
XPROCEDURE IN_CLASSC(i: INTEGER): BOOLEAN;
XCONST
X  IN_CLASSC_NET = Word.Shift(16_ffffff, 8);
X  IN_CLASSC_NSHIFT = 8;
X  IN_CLASSC_HOST = 16_000000ff;
X
XPROCEDURE IN_CLASSD(i: INTEGER): BOOLEAN;
XPROCEDURE IN_MULTICAST(i: INTEGER): BOOLEAN;
X
XPROCEDURE IN_EXPERIMENTAL(i: INTEGER): BOOLEAN;
XPROCEDURE IN_BADCLASS(i: INTEGER): BOOLEAN;
X
XCONST
X  INADDR_ANY = 16_00000000;
X  INADDR_LOOPBACK = 16_7F000001;
X  INADDR_BROADCAST = Word.Shift(16_ffffff, 8) + 16_ff;
X				(* must be masked *)
X
X  IN_LOOPBACKNET = 127;		(* official! *)
X
X(* Stuff the loopback address into an Internet address. *)
XPROCEDURE IN_SET_LOOPBACK_ADDR(a: struct_sockaddr_in_star);
X
X(* Socket address, internet style. *)
XTYPE
X  struct_sockaddr_in = RECORD
X    sin_family: short;
X    sin_port: u_short;
X    sin_addr: union_in_addr;
X    sin_zero: ARRAY [0..7] OF CHAR;
X  END;
X  struct_sockaddr_in_star = UNTRACED REF struct_sockaddr_in;
X
X(* Options for use with [gs]etsockopt at the IP level. *)
XCONST
X  IP_OPTIONS = 1;		(* set/get IP per-packet options *)
X
X(* Procedures for number representation conversion. *)
XPROCEDURE ntohl(x: u_long): u_long;
XPROCEDURE ntohs(x: u_short): u_short;
XPROCEDURE htonl(x: u_long): u_long;
XPROCEDURE htons(x: u_short): u_short;
X
XEND Uin.
END_OF_FILE
if test 3860 -ne `wc -c <'Uin.i3'`; then
    echo shar: \"'Uin.i3'\" unpacked with wrong size!
fi
# end of 'Uin.i3'
fi
if test -f 'Uin.m3' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'Uin.m3'\"
else
echo shar: Extracting \"'Uin.m3'\" \(1809 characters\)
sed "s/^X//" >'Uin.m3' <<'END_OF_FILE'
X(* Uin.m3 -- M3 interface to Unix facilities in netinet/in.h. *)
X(* David Nichols, Xerox PARC *)
X
X(* Big-endian version. *)
X
XUNSAFE MODULE Uin EXPORTS Uin;
X(* Only unsafe because it needs Usocket.AF_INET and Usocket is unsafe. *)
X
XFROM Utypes IMPORT u_long, u_short;
XIMPORT Usocket, Word;
X
XPROCEDURE IN_CLASSA(i: INTEGER): BOOLEAN =
X  BEGIN
X    RETURN Word.And(i, Word.Shift(16_800000, 8)) = 0;
X  END IN_CLASSA;
X
XPROCEDURE IN_CLASSB(i: INTEGER): BOOLEAN =
X  BEGIN
X    RETURN Word.And(i, Word.Shift(16_c00000, 8)) = Word.Shift(16_800000, 8);
X  END IN_CLASSB;
X
XPROCEDURE IN_CLASSC(i: INTEGER): BOOLEAN =
X  BEGIN
X    RETURN Word.And(i, Word.Shift(16_e00000, 8)) = Word.Shift(16_c00000, 8);
X  END IN_CLASSC;
X
XPROCEDURE IN_CLASSD(i: INTEGER): BOOLEAN =
X  BEGIN
X    RETURN Word.And(i, Word.Shift(16_f00000, 8)) = Word.Shift(16_e00000, 8);
X  END IN_CLASSD;
X
XPROCEDURE IN_MULTICAST(i: INTEGER): BOOLEAN =
X  BEGIN
X    RETURN IN_CLASSD(i);
X  END IN_MULTICAST;
X
XPROCEDURE IN_EXPERIMENTAL(i: INTEGER): BOOLEAN =
X  BEGIN
X    RETURN Word.And(i, Word.Shift(16_e00000, 8)) = Word.Shift(16_e00000, 8);
X  END IN_EXPERIMENTAL;
X
XPROCEDURE IN_BADCLASS(i: INTEGER): BOOLEAN =
X  BEGIN
X    RETURN Word.And(i, Word.Shift(16_f00000, 8)) = Word.Shift(16_f00000, 8);
X  END IN_BADCLASS;
X
XPROCEDURE IN_SET_LOOPBACK_ADDR(a: struct_sockaddr_in_star) =
X  BEGIN
X    a.sin_addr.s_addr := htonl(INADDR_LOOPBACK);
X    a.sin_family := Usocket.AF_INET;
X  END IN_SET_LOOPBACK_ADDR;
X
X(* Big-endian versions; simply return the argument. *)
XPROCEDURE ntohl(x: u_long): u_long =
X  BEGIN
X    RETURN x;
X  END ntohl;
X
XPROCEDURE ntohs(x: u_short): u_short =
X  BEGIN
X    RETURN x;
X  END ntohs;
X
XPROCEDURE htonl(x: u_long): u_long =
X  BEGIN
X    RETURN x;
X  END htonl;
X
XPROCEDURE htons(x: u_short): u_short =
X  BEGIN
X    RETURN x;
X  END htons;
X
XBEGIN
XEND Uin.
END_OF_FILE
if test 1809 -ne `wc -c <'Uin.m3'`; then
    echo shar: \"'Uin.m3'\" unpacked with wrong size!
fi
# end of 'Uin.m3'
fi
echo shar: End of shell archive.
exit 0



======================================================================== 14 ===
Date:    Sat, 7 Dec 1991 17:20:21 GMT
From:    nr@atomic (Norman Ramsey)
Subject: Word of caution using sockets in m3


The 1.6 runtime cannot close both a reader and writer created from a
single socket.  The first close closes the underlying file descriptor,
making the second close barf.  If you have enough open file
descriptors, you can solve the problem by duplicating the socket and
using one descriptor for the reader and the other one for the writer.



======================================================================== 15 ===
Date:    Sat, 7 Dec 91 12:22:32 -0500
From:    Norman Ramsey <nr@Princeton.EDU>

Newsgroups: comp.lang.modula3
Subject: Word of caution using sockets in m3
Summary:
References: <95205@brunix.UUCP> <EdDy0dsB0bE901huBF@osprey.parc.xerox.com>
Distribution: 
Reply-To: nr@princeton.edu (Norman Ramsey)
Organization: Princeton University, Dept. of Computer Science


The 1.6 runtime cannot close both a reader and writer created from a
single socket.  The first close closes the underlying file descriptor,
making the second close barf.  If you have enough open file
descriptors, you can solve the problem by duplicating the socket and
using one descriptor for the reader and the other one for the writer.



======================================================================== 16 ===
Date:    Mon, 9 Dec 91 09:40:53 EST
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Lilac two-view document editor

Thanks for your reply. My interest in Lilac is the following. My
current reasearch interests are in the area of CAD frameworks,
with emphasis on Object orientation and Incremental algorithms
for interactive applications. Incremental text (and graphics)
formatting is both an interesting and useful application. I
easily foresee a number of tools for viewing "source language",
"formatted text" as well spell checking.

While defining the research topic for a new (known good) Ph.D.
candidate, i went back to the Lilac paper and thought it could be
an excellent starting point. I understand that it is now only a
prototype that it even needs work to run under Modula-3. But for
such a project it is just fine. I believe that with some care it
can both become a good Ph.D. topic and the kind very useful
applications that a language like Modula3 needs to get going.

You mention that you are working on a Multi-view GUI? Would that
replace Lilac altogether? of should text formatting be an
extension of this work rather than starting from Lilac? In any
case i would be highly interested in getting whichever you
consider would be the best starting point. In return i can
promise that it will be ensured that anything useful that comes
out of this project (hopefully a completely usable system) will
be redistributed freely with proper credit to all the contributors.

Thus, which system do you think is the best starting point? Who
should i contact to determine if it can be made available? Thanks !


======================================================================== 17 ===
Date:    Mon, 9 Dec 91 15:07:22 EST
From:    wyant@saber.com
Subject: Lilac two-view document editor

If you're not wed to Modula-3 (or even if you are),
you should take a look at the "glyph" abstraction
in the InterViews UI toolkit for C++ (gack Heresy !!!)
. Glyphs provide a lightweight framework for building 
among other things document formatters and renders. 
The InterViews 'doc' editor provides a multifont 
document editor with embedded tables, figures, and text 
which wraps around figures (in real time) . This is done 
in ~10K lines of code. It might be a interesting 
starting point. It would be a really interesting project 
to support someof the 'glyph' mechanism in Trestle.

--geoff


======================================================================== 18 ===
Date:    Mon, 9 Dec 91 15:07:15 EST
From:    wyant@saber.com
Subject: Lilac two-view document editor

If you're not wed to Modula-3 (or even if you are),
you should take a look at the "glyph" abstraction
in the InterViews UI toolkit for C++ (gack Heresy !!!)
. Glyphs provide a lightweight framework for building 
among other things document formatters and renders. 
The InterViews 'doc' editor provides a multifont 
document editor with embedded tables, figures, and text 
which wraps around figures (in real time) . This is done 
in ~10K lines of code. It might be a interesting 
starting point. It would be a really interesting project 
to support someof the 'glyph' mechanism in Trestle.

--geoff


======================================================================== 19 ===
Date:    10 Dec 91 18:39:34 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: $1,000 prize for PC Modula-3


          Press Release 12/10/91
          Pine Creek Software

Pine Creek Software today announced that it is offering a $1,000 prize
for the first PC-compatible Modula-3 compiler. The prize will be
awarded to the developers who demonstrate a compiler that runs on PCs
under DOS or Microsoft Windows and produces stand-alone applications.

Sam Harbison, President of Pine Creek Software, explained that the
compiler must implement the full Modula-3 language and pass the test
suite accompanying Digital Equipment Corp's Modula-3 compiler (SRC
Modula-3). It must be able to compile small programs on PC's that have
no more than 1 megabyte of memory. Only 386 processors need be
supported, and the compiler can produce native code, C source code, or
abstract machine code as output.  The compiler can be an original
effort or a port of an existing Modula-3 compiler.

Finally, the compiler must be available for sale or distribution to
educational institutions and other non-commercial developers.
Employees of Digital and Pine Creek Software are not eligible for the
prize.

For more information, contact Sam Harbison, harbison@bert.pinecreek.com.


======================================================================== 20 ===
Date:    10 Dec 91 17:26:29 GMT
From:    rstenbro.bbs@shark.cse.fau.edu
Subject: OBERON

Does anybody have source listings for ETZ Oberon compiler?
Can anybody mail it to me??  I want to make a Oberon compiler
for MSDOS or OS/2.
Thank you!!


======================================================================== 21 ===
Date:    Tue, 10 Dec 91 22:47:31 PST
From:    <mhb@src.dec.com>
Subject: Re: Lilac two-view document editor


    You mention that you are working on a Multi-view GUI? Would that
    replace Lilac altogether? 

The two projects are very independent. Lilac provides two views of 
a document: a TeX-like "source" view and the WYSIWYG "result" view. 
FormsVBT is a GUI that builds user interfaces (read: dialog boxes). 
It has multiple views, include a WYSIWYG graphics editor, a runtime 
result view, and a text view. See the SIGGRAPH 89 proceedings for 
a description of FormsVBT. 

    Thus, which system do you think is the best starting point? 

I'm not sure what exactly you want to do. For incremental update 
algorithms, the Lilac paper is excellent. Also, Ken's thesis is available 
as a SRC research report; email  to "src-report@pa.dec.com" will 
work. 
    
    Who should i contact to determine if it can be made available? 

To find out about obtaining the source code to Lilac, you you should 
start by contacting Ken Brooks. The article should contain his preferred 
way mode of contact. I'll inquire locally about the logistics. 

Marc


======================================================================== 22 ===
Date:    11 Dec 91 13:47:36 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Lilac two-view document editor

We have an interest in Lilac in Modula-3, namely as a substantial real
application program for stress testing our compiler and for use in
benchmarking. I doubt we're up for proting it ourselves, though ....
--

		J. Eliot B. Moss, Assistant 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


======================================================================== 23 ===
Date:    Wed, 11 Dec 91 19:11:57 -0500
From:    Roger Hoover <rhoover@watson.ibm.com>
Subject: M3 + Trestle + Sun


I'm trying to run trestle with SRC Modula-3 1.6 as distributed
on gatekeeper.dec.com.  I've been getting lots and lots of
runtime errors such as:

M3 runtime error, "RTHeap.m3":460: Value out of range

and

sendsig: bad signal stack pid=1353, sig=11
sigsp = 0x315678, action = 0xf7702d80, upc = 0x286d24
Illegal instruction (core dumped)

and

M3 runtime error: Deadlock !

These are not reproducible, but I have yet to finish a game of
BadBricks without a crash.  I'm running SunOs 4.0.3c and
compiled Modula-3 with gcc.

I'd like to hear from anyone out there who has found similar
problems as well as those who are having better success on a
Sun.  What are you doing differently?


======================================================================== 24 ===
Date:    12 Dec 91 10:08:46 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Modula-3 Library collectors/Programming Style


Hello *,
  First Question:
	Is somebody collecting Modula-3 modules for a repository/db?
  Second Question:
	Has anybody ever laid out some kind of style sheet for
    Modula-3 modules/interfaces?

  Related to this second question is my own attempt at writing a binary
tree module, to be followed up with an AVL tree module (AVL trees are
depth balanced trees). My styling problem concerns descendents of
BinTree.Tree. Suppose I made one for binary trees over integers; the
TreeAction procedure type is specified below as having a Tree parameter,
which means that I have to TYPECASE this parameter, or assign it to an
IntTree variable, before I can access the value in the Tree node. Another
possibility would be to use NARROW(), but I'ld have to repeat that for
each time I want to use the value field.
  What is the suggested method?

My current BinTree interface looks like this:

INTERFACE BinTree;

(* BinTree - A binary tree object class module
 *
 * $Id$
 *
 *  The sorting order in the trees is determined by a method
 * in BinTree.Tree. This method will default to NIL, and _MUST_ be
 * overridden for descendents.
 * 
 * Started 28 nov 1991 by Bert Laverman
 * $Log$
 *)

EXCEPTION
(* xNotFound is raised in the methods find() and remove() if the wanted
 * element was not found.
 *)
  xNotFound;

(* xStopTraverse should be raised by a TreeAction procedure to stop
 * the traversal of the tree.
 *)
  xStopTraverse(Tree);


TYPE
(* CompareResult is used for comparing tree elements. *)
  CompareResult = [-1..1] ;

(* A TreeAction procedure can be called to do something on a tree *)
  TreeAction	= PROCEDURE (READONLY t : Tree) RAISES {xStopTraverse};

(* Tree is the actual object class for trees. *)
  Tree = OBJECT
	   left, right	: Tree;

	 METHODS
	(* compare(x) will compare the node with the given node
	 * Returns:
	 *	-1 if self comes before x
	 *	 0 if self equals x
	 *	 1 if self comes after x
	 *)
	  compare(READONLY x : Tree): CompareResult
		:= NIL;

	(* traverse(pre, ino, post, leftfirst) traverses the tree.
	 * If leftfirst is TRUE, the left branch will be taken first.
	 * If pre is non-NIL, it is called before entering the branches.
	 * If ino is non-NIL, it is called between entering the branches.
	 * If post is non-NIL, it is called after entering the branches.
	 *)
	   traverse(pre, ino, post : TreeAction := NIL;
		    READONLY leftfirst: BOOLEAN := TRUE)
		RAISES {xStopTraverse}
		:= BTTraverse;

	(* preorder(action, leftfirst) is equal to:
	 *	traverse(action, NIL, NIL, leftfirst);
	 *)
	   preorder(action : TreeAction;
		    READONLY leftfirst : BOOLEAN := TRUE)
		RAISES {xStopTraverse}
		:= BTPreOrder;

	(* inorder(action, leftfirst) is equal to:
	 *	traverse(NIL, action, NIL, leftfirst);
	 *)
	   inorder(action : TreeAction;
		    READONLY leftfirst : BOOLEAN := TRUE)
		RAISES {xStopTraverse}
		:= BTInOrder;

	(* postorder(action, leftfirst) is equal to:
	 *	traverse(NIL, NIL, action, leftfirst);
	 *)
	   postorder(action : TreeAction;
		    READONLY leftfirst : BOOLEAN := TRUE)
		RAISES {xStopTraverse}
		:= BTPostOrder;

	(* find(x) will search for `x' in the tree.
	 * Returns: The searched for object. xNotFound is raised if the
	 *	    object is not found.
	 *)
	   find(READONLY x : Tree): Tree
		RAISES {xNotFound}
		:= BTFind;

	(* insert(x) will add `x' in the tree.
	 * Returns: The entire tree.
	 *)
	   insert(READONLY x : Tree): Tree
		:= BTInsert;

	(* remove(x) removes x from the tree.
	 * Returns: The entire tree. xNotFound is raised if x is
	 * not found in the tree.
	 *)
	   remove(READONLY x : Tree): Tree
		RAISES {xNotFound}
		:= BTRemove;

	(* depth() returns the depth of the tree.
	 *)
	  depth(): CARDINAL
		:= BTDepth;

	END;

PROCEDURE BTTraverse(self : Tree;
		     pre, ino, post : TreeAction	:= NIL;
		     READONLY leftfirst : BOOLEAN	:= TRUE)
	RAISES {xStopTraverse};


PROCEDURE BTPreOrder(self : Tree;
		     action : TreeAction;
		     READONLY leftfirst : BOOLEAN := TRUE)
	RAISES {xStopTraverse};


PROCEDURE BTInOrder(self : Tree;
		    action : TreeAction;
		    READONLY leftfirst : BOOLEAN := TRUE)
	RAISES {xStopTraverse};


PROCEDURE BTPostOrder(self : Tree;
		      action : TreeAction;
		      READONLY leftfirst : BOOLEAN := TRUE)
	RAISES {xStopTraverse};


PROCEDURE BTFind(self : Tree; READONLY x : Tree): Tree
	RAISES {xNotFound};


PROCEDURE BTInsert(self : Tree; READONLY x : Tree): Tree;


PROCEDURE BTRemove(self : Tree; READONLY x : Tree): Tree
	RAISES {xNotFound};


PROCEDURE BTDepth(self : Tree): CARDINAL;


END BinTree .
-- 
#include <std/disclaimer>

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


======================================================================== 25 ===
Date:    12 Dec 91 13:22:27 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Modula-3 Library collectors/Programming Style

The case presented (binary trees over integers and a desire to have binary
trees over other data types) sounds like a good application for generics to
me, so I suggest you head in that direction (even though the current release,
if I recall correctly, does not support generics). (By the way, the GNU M3
compiler under development currently does handle generics; unfortunately,
there are lots of niddly little things it doesn't do yet, so it doesn't
compile substantial programs; we're making progress, though!)
--

		J. Eliot B. Moss, Assistant 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


======================================================================== 26 ===
Date:    12 Dec 91 17:29:36 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Re: Modula-3 Library collectors/Programming Style

If you have some Modula-3 code you would like to share, you can send
it to me for inclusion in the Pine Creek Modula-3 Library.  I will
publicize it and place it on gatekeeper.dec.com.  I'd prefer that all
submissions have a test/demonstration program, makefile, and some
documentation.

My new book on Modula-3 has a chapter on M3 programming style, but it's
mainly things like naming and indentation conventions. There was a
Modula-3 mode for GNU emacs announced some time ago; it had various 
templates but (if I remember) no standard comment-blocks for units and
procedures. Has anyone updated M3-mode to include auto-formatting?


======================================================================== 27 ===
Date:    12 Dec 91 15:01:36 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Modula-3 Library collectors/Programming Style


> Hello *,
>   First Question:
> 	Is somebody collecting Modula-3 modules for a repository/db?

The group at DEC SRC possibly is and/or Sam Harbinson of Pine Creek
Software, although i have not seen any formal announcement for such a
thing.

If not, i agree that Modula 3 will succeed only if  

a) it is significantly better (simpler, safer...) than its main competitor 
   (that part hopefully is done)

b) there is a free reference implementation to try it out 
   (coming out well with the upcoming SRC 2.0 and GNU M3)

c) there is a well organized and sufficiently complete library. Given that
   garbage collection, exceptions and threads are already included, adding
   Pickles, RTType, Trestle and the likes, a very good base is there.

Because there are fewer M3 users and developpers at the present time 
than, for instance, C++, it is important to be more efficient in producing a
good library. This means avoiding duplicates as much as possible.

Therefore, unless DEC SRC or Pine Creek is already doing so (and should
probably announce it more clearly), i am willing to coordinate the
gathering of useful library modules. This means offering ftp disk space,
maintaining a "wanted" list and trying to obtain some consensus on recommended
formatting and documenting style, and module interfaces or implementations 
when duplicates arise. Especially since i am relatively new to M3,
i would act more as a coordinator than anything else.

How does it sound?
--
---------------------------------------------------------------------------

Michel Dagenais				    dagenais@vlsi.polymtl.ca
Ecole Polytechnique de Montreal		    tel: (514) 340-4029

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


======================================================================== 28 ===
Date:    Thu, 12 Dec 91 17:31:35 EST
From:    wyant@saber.com
Subject: 2.0 Trestle ?

Has Trestle changed significantly for
the 2.0 release ? The version that is
on gatekeeper seems like it could
provide the basis of a good toolkit,
but needed a fair amount of work to 
make it truely useful. Well, perhaps
thats a little strong, but it definitely
seemed like a snapshot of work in 
progress.

-geoff wyant
wyant@centerline.com


======================================================================== 29 ===
Date:    12 Dec 91 21:19:02 GMT
From:    lins@Apple.COM (Chuck Lins )
Subject: Re: OBERON

In article <ua3qcB1w164w@shark.cse.fau.edu> rstenbro.bbs@shark.cse.fau.edu writ
es:
>Does anybody have source listings for ETZ Oberon compiler?

Yes, I do (for OP2 the portable Oberon front-end).

>Can anybody mail it to me??  I want to make a Oberon compiler

No. You must purchase the front-end. The license prohibits redistribution of
the source. I believe the front-end costs 1000 Swiss francs (about $700). Send
email to Regis Crelier (crelier@cs.inf.ethz.ch) for more info.


-- 
Chuck Lins               | "Shut up! Be happy!" -- Jello Biafra
Apple Computer, Inc.     | Oberon-2 Paladin 
20525 Mariani Avenue     | 
Mail Stop 58-C           | Internet: lins@apple.com
Cupertino, CA 95014      | Applelink: lins@apple.apple.com


======================================================================== 30 ===
Date:    12 Dec 91 22:18:19 GMT
From:    ms@cs.brown.edu (Manojit Sarkar)
Subject: M3 1.6 Link time error


When I include this following routine in my M3 code I get a an
ld error :

ld: Undefined symbol
ld:    _INCL
linking
*** Error code 1

I am using M3 version 1.6. My guess it is something to
do with set operations, but I may be wrong. Can any one help?

PROCEDURE ComputeDistance(v: T; s: CARDINAL) =
VAR
  S, Q: SetOfNodes;
  u1, u2: CARDINAL;
BEGIN
  InitializeSingleSource(v, s);
  S := SetOfNodes{};
  Q := SetOfNodes{0..(v.maxNodes-1)};
  WHILE (Q # SetOfNodes{}) DO
    u1 := ExtractMin(v, Q);
    S := S + SetOfNodes{u1};
    FOR u2 := 0 TO v.maxNodes-1 DO
      IF (Adjacent(v, u1, u2) = TRUE) THEN
        Relax(v, u1, u2);
      END;
    END;
  END; 
END ComputeDistance;



======================================================================== 31 ===
Date:    Thu, 12 Dec 91 12:10:18 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Modula-3 Library collectors/Programming Style

In article <1991Dec12.100846.1011@cs.rug.nl>, laverman@cs.rug.nl (Bert Laverman
) writes:
> 
> Hello *,
>   First Question:
> 	Is somebody collecting Modula-3 modules for a repository/db?

You can send us (m3-request@src.dec.com) code to be included in the
SRC Modula-3 distribution.  We will do the integration work (i.e.
putting it somewhere in the distribution, and do whatever needs to be
done to the makefiles).  We already have integrated a greatly improved
version of the prettyprinter, contributed by Dave Nichols from Xerox
Parc; thanks a lot for that piece.

Starting with SRC Modula-3 2.0, the libraries will be unbundled.  That
is, you won't have to reinstall the full system to add/update
libraries.  This should make it much easier to contribute software.

By the way, 2.0 is the standard Modula-3 system at SRC now, and we are
actively working on a snapshot of that.  It should be available for
Christmas on gatekeeper.  It will have the 1.6 libraries (some of them
fixed), as well as Trestle. 

>   Second Question:
> 	Has anybody ever laid out some kind of style sheet for
>     Modula-3 modules/interfaces?
> 
>   Related to this second question is my own attempt at writing a binary
> tree module, to be followed up with an AVL tree module (AVL trees are
> depth balanced trees). My styling problem concerns descendents of
> BinTree.Tree. Suppose I made one for binary trees over integers; the
> TreeAction procedure type is specified below as having a Tree parameter,
> which means that I have to TYPECASE this parameter, or assign it to an
> IntTree variable, before I can access the value in the Tree node. Another
> possibility would be to use NARROW(), but I'ld have to repeat that for
> each time I want to use the value field.
>   What is the suggested method?

This will be much simpler with generics.  To give an idea of what you
can do, I have included a shar file of the generic queue package.  The
shapes directory contains only documentation: the files are standard
models of what generic interfaces and modules are expecting for their
arguments; these files are not used for compilation.  The base
directory contains basic modules to be used as the actuals of generic
modules.  Finally, queue is the generic queue module, together with
instances for the basic modules.  I also have bag, sets, stacks,
priority queues on the same model.  Note that this code is not
completely polished yet, but the basic organization is there.

This code will be included in 2.0.   Comments are more than welcome.

eric.


#!/bin/sh
# This is a shell archive (shar 3.32)
# made 12/12/1991 20:05 UTC by muller@procope.pa.dec.com
# Source directory /tmp_mnt/flimflam/r/flimflam/dlusers5/muller/asdf
#
# existing files WILL be overwritten
#
# This shar contains:
# length  mode       name
# ------ ---------- ------------------------------------------
#    519 -rw-r--r-- shapes/Elt.s3
#    449 -rw-r--r-- shapes/Hash.s3
#    506 -rw-r--r-- shapes/Order.s3
#     51 -rw-r--r-- shapes/m3makefile
#    448 -rw-r--r-- base/Int.i3
#    498 -rw-r--r-- base/Int.m3
#    444 -rw-r--r-- base/Reel.i3
#    577 -rw-r--r-- base/Reel.m3
#    440 -rw-r--r-- base/Txt.i3
#    503 -rw-r--r-- base/Txt.m3
#     40 -rw-r--r-- base/m3makefile
#     60 -rw-r--r-- queue/IntQueue.i3
#     57 -rw-r--r-- queue/IntQueue.m3
#     56 -rw-r--r-- queue/IntQueueADT.i3
#     53 -rw-r--r-- queue/IntQueueADT.m3
#    334 -rw-r--r-- queue/Queue.ig
#   2831 -rw-r--r-- queue/Queue.mg
#   1745 -rw-r--r-- queue/QueueADT.ig
#    277 -rw-r--r-- queue/QueueADT.mg
#     64 -rw-r--r-- queue/ReelQueue.i3
#     61 -rw-r--r-- queue/ReelQueue.m3
#     59 -rw-r--r-- queue/ReelQueueADT.i3
#     56 -rw-r--r-- queue/ReelQueueADT.m3
#     60 -rw-r--r-- queue/TxtQueue.i3
#     57 -rw-r--r-- queue/TxtQueue.m3
#     56 -rw-r--r-- queue/TxtQueueADT.i3
#     53 -rw-r--r-- queue/TxtQueueADT.m3
#    318 -rw-r--r-- queue/m3makefile
#
if touch 2>&1 | fgrep 'amc' > /dev/null
 then TOUCH=touch
 else TOUCH=true
fi
# ============= shapes/Elt.s3 ==============
if test ! -d 'shapes'; then
    echo "x - creating directory shapes"
    mkdir 'shapes'
fi
echo "x - extracting shapes/Elt.s3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > shapes/Elt.s3 &&
X(* Last modified on Thu Dec 12 12:10:58 PST 1991 by muller *)
X
XSHAPE Elt;
X
X(* This interface is not intended to be compiled.  Rather, it
X   describes the shape that is expected by some generic interfaces and
X   modules.
X
X   This is the most basic shape for container interfaces.  There is a
X   basic type, T, and two operations on values on that type.  *)
X
XTYPE
X  T;
X
XPROCEDURE Equal (x, y: T): BOOLEAN; 
X  (* return 'TRUE' if 'x' and 'y' are equal *)
X 
XPROCEDURE Copy (x: T): T;
X  (* return a copy of 'x' *)
X
XEND Elt.
SHAR_EOF
$TOUCH -am 1212120491 shapes/Elt.s3 &&
chmod 0644 shapes/Elt.s3 ||
echo "restore of shapes/Elt.s3 failed"
set `wc -c shapes/Elt.s3`;Wc_c=$1
if test "$Wc_c" != "519"; then
	echo original size 519, current size $Wc_c
fi
# ============= shapes/Hash.s3 ==============
echo "x - extracting shapes/Hash.s3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > shapes/Hash.s3 &&

X
XSHAPE Hash EXTENDS Elt;
X
X(* This interface is not intended to be compiled.  Rather, it
X   describes the shape that is expected by some generic interfaces and
X   modules.
X
X   In addition to the basics of Elt, provide a Hash function on
X   values of type T. *)
X
XPROCEDURE Hash (x: Elt.T; lessThan: CARDINAL): CARDINAL;
X  (* return a hash value for 'x', less than 'lessThan' *)
X
XEND Hash.
SHAR_EOF
$TOUCH -am 1212120491 shapes/Hash.s3 &&
chmod 0644 shapes/Hash.s3 ||
echo "restore of shapes/Hash.s3 failed"
set `wc -c shapes/Hash.s3`;Wc_c=$1
if test "$Wc_c" != "449"; then
	echo original size 449, current size $Wc_c
fi
# ============= shapes/Order.s3 ==============
echo "x - extracting shapes/Order.s3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > shapes/Order.s3 &&

X
XSHAPE Order EXTENDS Elt;
X
X(* This interface is not intended to be compiled.  Rather, it
X   describes the shape that is expected by some generic interfaces and
X   modules.
X
X   In addition to the basics of Elt, provide a Compare function on
X   values of type T. *)
X
XPROCEDURE Compare (x, y: Elt.T): [-1..1];
X   (* return: 
X        -1 if 'x' is less than 'y'
X         0 if 'x' is equal to 'y'
X        +1 if 'x' is greater than 'y' *)
X
XEND Order.
SHAR_EOF
$TOUCH -am 1212120491 shapes/Order.s3 &&
chmod 0644 shapes/Order.s3 ||
echo "restore of shapes/Order.s3 failed"
set `wc -c shapes/Order.s3`;Wc_c=$1
if test "$Wc_c" != "506"; then
	echo original size 506, current size $Wc_c
fi
# ============= shapes/m3makefile ==============
echo "x - extracting shapes/m3makefile (Text)"
sed 's/^X//' << 'SHAR_EOF' > shapes/m3makefile &&
Xsource (Elt.s3)
Xsource (Hash.s3)
Xsource (Order.s3)
SHAR_EOF
$TOUCH -am 1212120491 shapes/m3makefile &&
chmod 0644 shapes/m3makefile ||
echo "restore of shapes/m3makefile failed"
set `wc -c shapes/m3makefile`;Wc_c=$1
if test "$Wc_c" != "51"; then
	echo original size 51, current size $Wc_c
fi
# ============= base/Int.i3 ==============
if test ! -d 'base'; then
    echo "x - creating directory base"
    mkdir 'base'
fi
echo "x - extracting base/Int.i3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > base/Int.i3 &&

X
XINTERFACE Int;
X
X(* This interface is intended to be used as an actual argument of
X   generic interfaces and modules.  It provides both the Elt, Hash and
X   Order shapes based on the type INTEGER. *)
X
X
XTYPE
X  T = INTEGER;
X
XPROCEDURE Equal (t, u: T): BOOLEAN;
XPROCEDURE Copy (t: T): T;
XPROCEDURE Compare (t, u: T): [-1..1];
XPROCEDURE Hash (t: T; lessThan: CARDINAL): CARDINAL;
X
XEND Int.
SHAR_EOF
$TOUCH -am 1212115991 base/Int.i3 &&
chmod 0644 base/Int.i3 ||
echo "restore of base/Int.i3 failed"
set `wc -c base/Int.i3`;Wc_c=$1
if test "$Wc_c" != "448"; then
	echo original size 448, current size $Wc_c
fi
# ============= base/Int.m3 ==============
echo "x - extracting base/Int.m3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > base/Int.m3 &&

X
XMODULE Int;
X
XPROCEDURE Equal (t, u: T): BOOLEAN = 
X  BEGIN
X    RETURN t = u;
X  END Equal;
X
XPROCEDURE Copy (t: T): T =
X  BEGIN
X    RETURN t;
X  END Copy;
X
XPROCEDURE Compare (t, u: T): [-1..1] =
X  BEGIN
X    IF t < u THEN
X      RETURN -1;
X    ELSIF t = u THEN
X      RETURN 0;
X    ELSE
X      RETURN 1; END;
X  END Compare;
X
XPROCEDURE Hash (t: T; lessThan: CARDINAL): CARDINAL =
X  BEGIN
X    RETURN t MOD lessThan;
X  END Hash;
X
XBEGIN
XEND Int.
SHAR_EOF
$TOUCH -am 1212115991 base/Int.m3 &&
chmod 0644 base/Int.m3 ||
echo "restore of base/Int.m3 failed"
set `wc -c base/Int.m3`;Wc_c=$1
if test "$Wc_c" != "498"; then
	echo original size 498, current size $Wc_c
fi
# ============= base/Reel.i3 ==============
echo "x - extracting base/Reel.i3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > base/Reel.i3 &&

X
XINTERFACE Reel;
X
X(* This interface is intended to be used as an actual argument of
X   generic interfaces and modules.  It provides both the Elt, Hash and
X   Order shapes based on the type REAL. *)
X
X
XTYPE
X  T = REAL;
X
XPROCEDURE Equal (t, u: T): BOOLEAN;
XPROCEDURE Copy (t: T): T;
XPROCEDURE Compare (t, u: T): [-1..1];
XPROCEDURE Hash (t: T; lessThan: CARDINAL): CARDINAL;
X
XEND Reel.
SHAR_EOF
$TOUCH -am 1212115991 base/Reel.i3 &&
chmod 0644 base/Reel.i3 ||
echo "restore of base/Reel.i3 failed"
set `wc -c base/Reel.i3`;Wc_c=$1
if test "$Wc_c" != "444"; then
	echo original size 444, current size $Wc_c
fi
# ============= base/Reel.m3 ==============
echo "x - extracting base/Reel.m3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > base/Reel.m3 &&

X
XMODULE Reel;
X
XPROCEDURE Equal (t, u: T): BOOLEAN = 
X  BEGIN
X    RETURN t = u;
X  END Equal;
X
XPROCEDURE Copy (t: T): T =
X  BEGIN
X    RETURN t;
X  END Copy;
X
XPROCEDURE Compare (t, u: T): [-1..1] =
X  BEGIN
X    IF t < u THEN
X      RETURN -1;
X    ELSIF t = u THEN
X      RETURN 0;
X    ELSE
X      RETURN 1; END; 
X  END Compare;
X
XPROCEDURE Hash (t: T; lessThan: CARDINAL): CARDINAL =
X  (* A trivial hash function.  Probably needs to be made better. *)
X  BEGIN
X    RETURN ROUND (t) MOD lessThan;
X  END Hash;
X
XBEGIN
XEND Reel.
SHAR_EOF
$TOUCH -am 1212115991 base/Reel.m3 &&
chmod 0644 base/Reel.m3 ||
echo "restore of base/Reel.m3 failed"
set `wc -c base/Reel.m3`;Wc_c=$1
if test "$Wc_c" != "577"; then
	echo original size 577, current size $Wc_c
fi
# ============= base/Txt.i3 ==============
echo "x - extracting base/Txt.i3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > base/Txt.i3 &&

X
XINTERFACE Txt;
X
X(* This interface is intended to be used as an actual argument of
X   generic interfaces and modules.  It provides both the Elt, Hash and
X   Order shapes based on the type Text.T. *)
X
XIMPORT Text;
X
XTYPE
X  T = Text.T;
X
XCONST
X  Equal = Text.Equal;
X  Compare = Text.Compare;
X
XPROCEDURE Copy (t: T): T;
XPROCEDURE Hash (t: T; lessThan: CARDINAL): CARDINAL;
X
XEND Txt.
SHAR_EOF
$TOUCH -am 1212115991 base/Txt.i3 &&
chmod 0644 base/Txt.i3 ||
echo "restore of base/Txt.i3 failed"
set `wc -c base/Txt.i3`;Wc_c=$1
if test "$Wc_c" != "440"; then
	echo original size 440, current size $Wc_c
fi
# ============= base/Txt.m3 ==============
echo "x - extracting base/Txt.m3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > base/Txt.m3 &&

X
XMODULE Txt;
X
XIMPORT Text;
X
XPROCEDURE Copy (t: T): T =
X  (* Text.T's are immutable, so there is no need to copy them *)
X  BEGIN
X    RETURN t;
X  END Copy;
X
XPROCEDURE Hash (t: T; lessThan: CARDINAL): CARDINAL =
X  (* A trivial hash function.  Probably needs to be made better *)
X  BEGIN
X    IF t = NIL OR Text.Length (t) < 1 THEN
X      RETURN 0;
X    ELSE 
X      RETURN ORD (Text.GetChar (t, 0)) MOD lessThan; END;
X  END Hash;
X
XBEGIN
XEND Txt.
X 
SHAR_EOF
$TOUCH -am 1212115991 base/Txt.m3 &&
chmod 0644 base/Txt.m3 ||
echo "restore of base/Txt.m3 failed"
set `wc -c base/Txt.m3`;Wc_c=$1
if test "$Wc_c" != "503"; then
	echo original size 503, current size $Wc_c
fi
# ============= base/m3makefile ==============
echo "x - extracting base/m3makefile (Text)"
sed 's/^X//' << 'SHAR_EOF' > base/m3makefile &&
XModule (Int)
XModule (Reel)
XModule (Txt)
SHAR_EOF
$TOUCH -am 1212115991 base/m3makefile &&
chmod 0644 base/m3makefile ||
echo "restore of base/m3makefile failed"
set `wc -c base/m3makefile`;Wc_c=$1
if test "$Wc_c" != "40"; then
	echo original size 40, current size $Wc_c
fi
# ============= queue/IntQueue.i3 ==============
if test ! -d 'queue'; then
    echo "x - creating directory queue"
    mkdir 'queue'
fi
echo "x - extracting queue/IntQueue.i3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/IntQueue.i3 &&
XINTERFACE IntQueue = Queue (Int, IntQueueADT) END IntQueue.
SHAR_EOF
$TOUCH -am 1212120091 queue/IntQueue.i3 &&
chmod 0644 queue/IntQueue.i3 ||
echo "restore of queue/IntQueue.i3 failed"
set `wc -c queue/IntQueue.i3`;Wc_c=$1
if test "$Wc_c" != "60"; then
	echo original size 60, current size $Wc_c
fi
# ============= queue/IntQueue.m3 ==============
echo "x - extracting queue/IntQueue.m3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/IntQueue.m3 &&
XMODULE IntQueue = Queue (Int, IntQueueADT) END IntQueue.
SHAR_EOF
$TOUCH -am 1212120091 queue/IntQueue.m3 &&
chmod 0644 queue/IntQueue.m3 ||
echo "restore of queue/IntQueue.m3 failed"
set `wc -c queue/IntQueue.m3`;Wc_c=$1
if test "$Wc_c" != "57"; then
	echo original size 57, current size $Wc_c
fi
# ============= queue/IntQueueADT.i3 ==============
echo "x - extracting queue/IntQueueADT.i3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/IntQueueADT.i3 &&
XINTERFACE IntQueueADT = QueueADT (Int) END IntQueueADT.
SHAR_EOF
$TOUCH -am 1212120091 queue/IntQueueADT.i3 &&
chmod 0644 queue/IntQueueADT.i3 ||
echo "restore of queue/IntQueueADT.i3 failed"
set `wc -c queue/IntQueueADT.i3`;Wc_c=$1
if test "$Wc_c" != "56"; then
	echo original size 56, current size $Wc_c
fi
# ============= queue/IntQueueADT.m3 ==============
echo "x - extracting queue/IntQueueADT.m3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/IntQueueADT.m3 &&
XMODULE IntQueueADT = QueueADT (Int) END IntQueueADT.
SHAR_EOF
$TOUCH -am 1212120091 queue/IntQueueADT.m3 &&
chmod 0644 queue/IntQueueADT.m3 ||
echo "restore of queue/IntQueueADT.m3 failed"
set `wc -c queue/IntQueueADT.m3`;Wc_c=$1
if test "$Wc_c" != "53"; then
	echo original size 53, current size $Wc_c
fi
# ============= queue/Queue.ig ==============
echo "x - extracting queue/Queue.ig (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/Queue.ig &&

X
XGENERIC INTERFACE Queue (Elt, EltQueueADT);
X
X(* The queue elements are stored in a link list.
X
X   This interface has the shape of Elt. *)
X
XTYPE
X  T <: EltQueueADT.T OBJECT METHODS
X         new (): T; 
X         END;
X
XCONST
X  Equal = T.equal;
X  Copy  = T.copy;
X
XEND Queue.
SHAR_EOF
$TOUCH -am 1212120291 queue/Queue.ig &&
chmod 0644 queue/Queue.ig ||
echo "restore of queue/Queue.ig failed"
set `wc -c queue/Queue.ig`;Wc_c=$1
if test "$Wc_c" != "334"; then
	echo original size 334, current size $Wc_c
fi
# ============= queue/Queue.mg ==============
echo "x - extracting queue/Queue.mg (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/Queue.mg &&

X
XGENERIC MODULE Queue (Elt, EltQueueADT);
X
XTYPE
X  Node = REF RECORD
X           first: Elt.T;
X           rest: Node; END;
X
XREVEAL 
X  T = EltQueueADT.T OBJECT METHODS
X        new (): T; END
X      BRANDED OBJECT
X        front, back: Node;
X      OVERRIDES
X        new     := new;
X        insert  := insert;
X        first   := first;
X        delete  := delete;
X        equal   := equal;
X        isEmpty := isEmpty;
X        size    := size;
X        copy    := copy;
X        map     := map;
X      END;
X
XPROCEDURE new (self: T): T = 
X  BEGIN
X    IF self = NIL THEN
X      self := NEW (T); END;
X
X    EVAL EltQueueADT.T.new (self);
X
X    self.front := NIL;
X    self.back := NIL;
X
X    RETURN self;
X  END new;
X
XPROCEDURE insert (self:T; e: Elt.T) =
X  BEGIN
X    WITH e = NEW (Node, first := e, rest := NIL) DO
X      IF self.back = NIL THEN
X        self.front := e;
X        self.back :=  e;
X      ELSE
X        self.back.rest := e;
X        self.back := e; END; END;
X  END insert;
X
XPROCEDURE first (self: T): Elt.T RAISES {EltQueueADT.Empty} =
X  BEGIN
X    IF self.front = NIL THEN
X      RAISE EltQueueADT.Empty; 
X    ELSE
X      RETURN self.front.first; END;
X  END first;
X
XPROCEDURE delete (self: T): Elt.T RAISES {EltQueueADT.Empty} =
X  VAR x: Elt.T;
X  BEGIN
X    IF self.front = NIL THEN
X      RAISE EltQueueADT.Empty;
X    ELSE
X      x := self.front.first;
X      self.front := self.front.rest;
X      IF self.front = NIL THEN
X        self.back := NIL; END;
X      RETURN x; END;
X  END delete;
X
XPROCEDURE equal (self: T; t: EltQueueADT.T): BOOLEAN =
X  VAR u := self.front;
X      tt := t.copy ();
X  BEGIN
X    TRY
X      WHILE u # NIL DO
X        IF NOT Elt.Equal (u.first, tt.delete ()) THEN
X          RETURN FALSE; END;
X        u := u.rest; END;
X      RETURN tt.isEmpty ();
X    EXCEPT
X      | EltQueueADT.Empty => RETURN FALSE; END;
X  END equal;
X
XPROCEDURE isEmpty (self: T): BOOLEAN =
X  BEGIN
X    RETURN self.front = NIL;
X  END isEmpty;
X    
XPROCEDURE size (self: T): CARDINAL =
X  VAR count: CARDINAL := 0; u := self.front;
X  BEGIN
X    WHILE u # NIL DO 
X      INC (count);
X      u := u.rest; END;
X    RETURN count;    
X  END size;
X
XPROCEDURE copy (self: T): EltQueueADT.T =
X  VAR t := self.front; res := new (NIL);
X  BEGIN
X    IF t = NIL THEN
X      RETURN res;
X    ELSE
X      res.front := NEW (Node, first := Elt.Copy (t.first), rest := NIL);
X      res.back  := res.front;
X      t := t.rest;
X      WHILE t # NIL DO
X        WITH e = NEW (Node, first := Elt.Copy (t.first), rest := NIL) DO
X          res.back.rest := e;
X          res.back := e;
X          t := t.rest; END; END;
X      RETURN res; END;
X  END copy;
X
XPROCEDURE map (self: T; f: EltQueueADT.F) RAISES ANY =
X  VAR u := self.front;
X  BEGIN
X    WHILE u # NIL DO
X      f (u.first);
X      u := u.rest; END;
X  END map;
X
XBEGIN
XEND Queue.
SHAR_EOF
$TOUCH -am 1212120291 queue/Queue.mg &&
chmod 0644 queue/Queue.mg ||
echo "restore of queue/Queue.mg failed"
set `wc -c queue/Queue.mg`;Wc_c=$1
if test "$Wc_c" != "2831"; then
	echo original size 2831, current size $Wc_c
fi
# ============= queue/QueueADT.ig ==============
echo "x - extracting queue/QueueADT.ig (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/QueueADT.ig &&

X
XGENERIC INTERFACE QueueADT (Elt);
X
X(* The Queue abstract data TYPE.
X
X   The type 'T' defines the basic operations available from all 
X   implementations of queues.  The 'new' operation may be redefined with
X   a different signature in subtypes of 'T'.  Also, subtypes may
X   define additional methods.  
X
X   Interfaces that define implementations of Queue may require actual 
X   arguments that are more strict than Elt.
X
X   A simple implementation is provided by the Queue interface. *)
X
XEXCEPTION
X  Empty;
X
XTYPE
X  F = PROCEDURE (x: Elt.T) RAISES ANY;
X        (* to iterate over the elements of a queue *)
X
X  T = OBJECT METHODS
X        new (): T := new;
X          (* create (self = NIL) or initialize (self # NIL) a Stack.T *)
X
X        insert (e: Elt.T);
X          (* insert 'e' at the end of 'self' *)
X        delete (): Elt.T RAISES {Empty};
X          (* if 'self' is not emtpy, remove the element at the front
X             of 'self' and return that element.  Otherwise, raise Emtpy. *)
X        first  (): Elt.T RAISES {Empty};
X          (* if 'self' is not emtpy, return the element at the front
X             of 'self'.  Otherwise, raise Emtpy. *)
X
X        equal (t: T): BOOLEAN;
X          (* TRUE iff 'self' and 't' are equal *)
X        isEmpty (): BOOLEAN;
X          (* TRUE iff 'self' is empty *)
X        size (): CARDINAL;
X          (* return the number of elements in 'self' *)
X        copy (): T;
X          (* return a copy of 'self' *)
X        map (f: F) RAISES ANY;
X          (* apply 'f' to each element of 'self'.  It is an unchecked runtime
X             error to modify 'self' while this procedure is active *)
X        END;
X
XPROCEDURE new (self: T): T;
X
XEND QueueADT.
SHAR_EOF
$TOUCH -am 1212120291 queue/QueueADT.ig &&
chmod 0644 queue/QueueADT.ig ||
echo "restore of queue/QueueADT.ig failed"
set `wc -c queue/QueueADT.ig`;Wc_c=$1
if test "$Wc_c" != "1745"; then
	echo original size 1745, current size $Wc_c
fi
# ============= queue/QueueADT.mg ==============
echo "x - extracting queue/QueueADT.mg (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/QueueADT.mg &&

X
XGENERIC MODULE QueueADT (Elt);
X
XEXCEPTION
X  AbstractObjectType;
X  
XPROCEDURE new (self: T): T =
X  BEGIN
X    IF self = NIL THEN
X       RAISE AbstractObjectType; END;
X    RETURN self;
X  END new;
X
XBEGIN
XEND QueueADT.
SHAR_EOF
$TOUCH -am 1212120291 queue/QueueADT.mg &&
chmod 0644 queue/QueueADT.mg ||
echo "restore of queue/QueueADT.mg failed"
set `wc -c queue/QueueADT.mg`;Wc_c=$1
if test "$Wc_c" != "277"; then
	echo original size 277, current size $Wc_c
fi
# ============= queue/ReelQueue.i3 ==============
echo "x - extracting queue/ReelQueue.i3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/ReelQueue.i3 &&
XINTERFACE ReelQueue = Queue (Reel, ReelQueueADT) END ReelQueue.
SHAR_EOF
$TOUCH -am 1212120091 queue/ReelQueue.i3 &&
chmod 0644 queue/ReelQueue.i3 ||
echo "restore of queue/ReelQueue.i3 failed"
set `wc -c queue/ReelQueue.i3`;Wc_c=$1
if test "$Wc_c" != "64"; then
	echo original size 64, current size $Wc_c
fi
# ============= queue/ReelQueue.m3 ==============
echo "x - extracting queue/ReelQueue.m3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/ReelQueue.m3 &&
XMODULE ReelQueue = Queue (Reel, ReelQueueADT) END ReelQueue.
SHAR_EOF
$TOUCH -am 1212120091 queue/ReelQueue.m3 &&
chmod 0644 queue/ReelQueue.m3 ||
echo "restore of queue/ReelQueue.m3 failed"
set `wc -c queue/ReelQueue.m3`;Wc_c=$1
if test "$Wc_c" != "61"; then
	echo original size 61, current size $Wc_c
fi
# ============= queue/ReelQueueADT.i3 ==============
echo "x - extracting queue/ReelQueueADT.i3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/ReelQueueADT.i3 &&
XINTERFACE ReelQueueADT = QueueADT (Reel) END ReelQueueADT.
SHAR_EOF
$TOUCH -am 1212120091 queue/ReelQueueADT.i3 &&
chmod 0644 queue/ReelQueueADT.i3 ||
echo "restore of queue/ReelQueueADT.i3 failed"
set `wc -c queue/ReelQueueADT.i3`;Wc_c=$1
if test "$Wc_c" != "59"; then
	echo original size 59, current size $Wc_c
fi
# ============= queue/ReelQueueADT.m3 ==============
echo "x - extracting queue/ReelQueueADT.m3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/ReelQueueADT.m3 &&
XMODULE ReelQueueADT = QueueADT (Reel) END ReelQueueADT.
SHAR_EOF
$TOUCH -am 1212120091 queue/ReelQueueADT.m3 &&
chmod 0644 queue/ReelQueueADT.m3 ||
echo "restore of queue/ReelQueueADT.m3 failed"
set `wc -c queue/ReelQueueADT.m3`;Wc_c=$1
if test "$Wc_c" != "56"; then
	echo original size 56, current size $Wc_c
fi
# ============= queue/TxtQueue.i3 ==============
echo "x - extracting queue/TxtQueue.i3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/TxtQueue.i3 &&
XINTERFACE TxtQueue = Queue (Txt, TxtQueueADT) END TxtQueue.
SHAR_EOF
$TOUCH -am 1212120091 queue/TxtQueue.i3 &&
chmod 0644 queue/TxtQueue.i3 ||
echo "restore of queue/TxtQueue.i3 failed"
set `wc -c queue/TxtQueue.i3`;Wc_c=$1
if test "$Wc_c" != "60"; then
	echo original size 60, current size $Wc_c
fi
# ============= queue/TxtQueue.m3 ==============
echo "x - extracting queue/TxtQueue.m3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/TxtQueue.m3 &&
XMODULE TxtQueue = Queue (Txt, TxtQueueADT) END TxtQueue.
SHAR_EOF
$TOUCH -am 1212120091 queue/TxtQueue.m3 &&
chmod 0644 queue/TxtQueue.m3 ||
echo "restore of queue/TxtQueue.m3 failed"
set `wc -c queue/TxtQueue.m3`;Wc_c=$1
if test "$Wc_c" != "57"; then
	echo original size 57, current size $Wc_c
fi
# ============= queue/TxtQueueADT.i3 ==============
echo "x - extracting queue/TxtQueueADT.i3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/TxtQueueADT.i3 &&
XINTERFACE TxtQueueADT = QueueADT (Txt) END TxtQueueADT.
SHAR_EOF
$TOUCH -am 1212120091 queue/TxtQueueADT.i3 &&
chmod 0644 queue/TxtQueueADT.i3 ||
echo "restore of queue/TxtQueueADT.i3 failed"
set `wc -c queue/TxtQueueADT.i3`;Wc_c=$1
if test "$Wc_c" != "56"; then
	echo original size 56, current size $Wc_c
fi
# ============= queue/TxtQueueADT.m3 ==============
echo "x - extracting queue/TxtQueueADT.m3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/TxtQueueADT.m3 &&
XMODULE TxtQueueADT = QueueADT (Txt) END TxtQueueADT.
SHAR_EOF
$TOUCH -am 1212120091 queue/TxtQueueADT.m3 &&
chmod 0644 queue/TxtQueueADT.m3 ||
echo "restore of queue/TxtQueueADT.m3 failed"
set `wc -c queue/TxtQueueADT.m3`;Wc_c=$1
if test "$Wc_c" != "53"; then
	echo original size 53, current size $Wc_c
fi
# ============= queue/m3makefile ==============
echo "x - extracting queue/m3makefile (Text)"
sed 's/^X//' << 'SHAR_EOF' > queue/m3makefile &&
XGeneric_module (QueueADT)
XGeneric_module (Queue)
X
XModule (IntQueueADT)
XModule (IntQueue)
XModule (ReelQueueADT)
XModule (ReelQueue)
XModule (TxtQueueADT)
XModule (TxtQueue)
X
Xgenerate:
X	for t in Int Reel Txt ; do \
X          make_generic $$t QueueADT $$t ; \
X	  make_generic $$t Queue $$t,\ $${t}QueueADT; \
X          done
SHAR_EOF
$TOUCH -am 1212120091 queue/m3makefile &&
chmod 0644 queue/m3makefile ||
echo "restore of queue/m3makefile failed"
set `wc -c queue/m3makefile`;Wc_c=$1
if test "$Wc_c" != "318"; then
	echo original size 318, current size $Wc_c
fi
exit 0




-- 
Eric.



======================================================================== 32 ===
Date:    13 Dec 91 09:38:32 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: Modula-3 Library collectors/Programming Style


Michel Dagenais writes:
> [...]
>
> c) there is a well organized and sufficiently complete library. Given that
>    garbage collection, exceptions and threads are already included, adding
>    Pickles, RTType, Trestle and the likes, a very good base is there.
yes.

> Because there are fewer M3 users and developpers at the present time 
> than, for instance, C++, it is important to be more efficient in producing a
> good library. This means avoiding duplicates as much as possible.
YES.

> Therefore, unless DEC SRC or Pine Creek is already doing so (and should
> probably announce it more clearly), i am willing to coordinate the
> gathering of useful library modules. This means offering ftp disk space,
> maintaining a "wanted" list and trying to obtain some consensus on recommende
d
> formatting and documenting style, and module interfaces or implementations 
> when duplicates arise. Especially since i am relatively new to M3,
> i would act more as a coordinator than anything else.
Well, _that_ was the kind of thing I was looking for. So far I only have the SR
C
compiler to look at for examples, and I had to remove the sources of it immedia
tely
after making it to prevent our system manager from recovering disk space in a
somewhat more drastic fashion.

  A style sheet would certainly be a 'good thing'(tm) to discuss. Even for C
there is one. Now I'm not proposing we fix things like indentation and spacing
in parameter lists, but some kind of standard style is needed. Also, how about
Modula-3 pretty printers for PostScript or LaTeX? And do we adopt things like R
CS
or SCCS?

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


======================================================================== 33 ===
Date:    Fri, 13 Dec 91 00:20:43 PST
From:    msm@src.dec.com (Mark S. Manasse)
Subject: Re: 2.0 Trestle ?

The Trestle release that we put out a few months ago was definitely a work-in-p
rogress; the version you'll be getting soon is still incomplete, but much close
r to what we really mean Trestle to be.  There are still a few pieces of what w
e consider to be core functionality that are unimplemented (non-text selections
, cursor tracking outside your top-level window, and icon window come to mind, 
although we hope to fix at least one of those next week), and quite a bit of no
n-core functionality that's missing (
cursor warping, raw painting to/from an X pixmap so that you can use X extensio
ns sensibly, etc.), but we think that we have a solid base.  We certainly hope 
that you'll let us know where we've missed the boat; we'll try to keep the rele
ase process shorter in the future.

The interactor libraries that you'll see are still fairly sparse; most of the i
nteresting interactors come with FormsVBT, which won't make this release (altho
ugh an extremely stripped-down version might).  The main thing that's in there 
that you might want is a text editing interactor; I hope we'll be able to get t
hat out soon.  And we're eager to receive new splits and leaves to add to our c
ollection.

And, even if you don't want to program, we now have three different games in th
e Trestle release: BadBricks, Solitaire, and dddssss (a 3-dimensional Tetris).

Mark


======================================================================== 34 ===
Date:    Fri, 13 Dec 91 09:30:29 EST
From:    wyant@saber.com
Subject: M3 + Trestle + Sun

Awhile back I had most of Trestle demos running fine
under SunoS 4.0.3. Some of the test programs gave my
problems but nothing like you described. Since you
compiled with gcc, I'd suspect that gcc's optimizations
are biting you.

-geoff wyant
wyant@centerline.com


======================================================================== 35 ===
Date:    Fri, 13 Dec 91 17:37:32 GMT
From:    jmr9398@ultb.rit.edu (J.M. Robinson )
Subject: HELP Sun3/50

Hello,
 I am currently trying to compile the dist-1.6 version of Modula3 on a
Sun 3/50 with Sunos 4.1.1. The compile runs fine until it starts to 
compile the libs/Ultrix-3-1/os directory. The
.ROOT/system/compiler/m3compiler respons with an error 3.
 Does anyone know what night be wrong? or does anyone aready have a
version running that I might be able to recieve.

		Thanks

	James M Robinson
	Student- RIT Rochester NY
	marcus@ritcsh.csh.rit.edu
	jmr9398@ultb.isc.rit.edu


======================================================================== 36 ===
Date:    13 Dec 91 20:38:05 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Re: Modula-3 Library collectors/Programming Style

Re: Libraries.

Yes, I started a Pine Creek Modula-3 Library, which was announced a
few weeks ago with its first member, FieldList. I didn't really want
to duplicate other sources, and perhaps if SRC is really being so open
about including "everything" in the M3 library distribution, it would
be better to do that. In any case the Pine Creek Library is available
on gatekeeper.dec.com in Modula-3/pinecreek/library. (Eric: if you
want to put FieldList into the distribution, swell.)

If Michael Dagenais wants to maintain a list of "wanted libraries," I think
that would be great. In fact, a collection of "Modula-3 Projects" to give
students some suggestions of things to do would be nice, also.

Re: Style

The "style sheet" in my book is a modified version of the DEC SRC
style sheet for Modula-2+. It's pretty thin.  There has just been
released a new version of a much larger document for Ada:

	Ada Quality and Style:
	Guidelines for Professional Programmers (2nd edition)

	SPC#91061#N
	VERSION 02.00.02

	SOFTWARE PRODUCTIVITY CONSORTIUM

	(~170 pages)

This is available on ajpo.sei.cmu.edu in public/adastyle/...  I've
skimmed this document, and it is not unreasonable. It would be a nice
exercise (for a student looking for a project?)  to turn it into
"Modula-3 Quality and Style: Guidelines for Professional Programmers."
(The copyright notice seems to permit this.)

Ada and Modula-3 are structurally quite similar, so using this
document as a starting point would be reasonable. One approach is to
keep the SPC "style" intact and just modify it for the differences
in Modula-3 (e.g., case-sensitive identifiers). This approach is easier
but may result in a style that differs somewhat from the current
standard (insofar as there is one).

Another approach is to use the SPC document as an outline and extend
the current M3 style guidelines to cover all the things the Ada
document does. This is more work.


======================================================================== 37 ===
Date:    Fri, 13 Dec 1991 11:54:40 PST
From:    David Nichols <nichols@parc.xerox.com>
Subject: Re: Modula-3 Library collectors/Programming Style

Excerpts from mail.m3: 13-Dec-91 Re: Modula-3 Library collec.. Bert
Laverman@cs.rug.nl (1778)

> Also, how about Modula-3 pretty printers for PostScript or LaTeX?

One thing I've done with the pretty-printer that hasn't made it back to
SRC is to add sort of generic support for variable-font pretty printing.
 The version we have here can pretty-print to Postscript as well as
straight text.  The nice thing is that it makes the line breaking and
alignment decisions based on the real PostScript font widths; the bad
news is that the line breaks don't correspond to the ones in your source
code.  I like it anyway.

I'll make sure this gets into our clearance procedures.  If anyone is
interested, I can send an example of the output.

	David


======================================================================== 38 ===
Date:    12 Dec 91 10:16:10 GMT
From:    UweKloss@lionbbs.bs.open.de ( Uwe Kloss )
Subject: Re: OBERON

In <ua3qcB1w164w@shark.cse.fau.edu>, rstenbro.bbs@shark.cse.fau.edu writes:
> Does anybody have source listings for ETZ Oberon compiler?
> Can anybody mail it to me??  I want to make a Oberon compiler
> for MSDOS or OS/2.
As long as you only need the Compiler not the sourrces, it
already exists. Or at least I some time ago I came across an
ad of a PD - vendor here in Germany. They supply one disk
(binaries only) for I think 12,- DM. It's only the compiler
not the Oberon-system!

As I try the same for ATARI I received mail from
Marc Brandis at ETH, that Wirth has (nearly ?) finished his
book on the Oberon - system which includes source code.
In Oberon! So there is the need to bootstrap the whole
thing in an other language or on an other system.

Well, that's it for now.

Uwe (going to hunt the bookshops now! ;-)
-- 
Uwe Kloss               UUCP: UweKloss@lionbbs.bs.open.de
Fasanenstrasse 65       BTX:  0531336908 0001
3300 Braunschweig       FIDO: not connected


======================================================================== 39 ===
Date:    14 Dec 91 18:47:33 GMT
From:    bevan@cs.man.ac.uk (Stephen J Bevan)
Subject: Re: OBERON

In article <ua3qcB1w164w@shark.cse.fau.edu> rstenbro.bbs@shark.cse.fau.edu writ
es:

   Does anybody have source listings for ETZ Oberon compiler?
   Can anybody mail it to me??  I want to make a Oberon compiler
   for MSDOS or OS/2.
   Thank you!!

This isn't exactly what you want but ...

I'm just finishing up a lex/yacc (flex/bison actually) combo to parse
Oberon-2.  Anybody is welcome to it when it is finished.  If you are
interested, mail me, and I'll send you details when its complete.

Stephen J. Bevan			bevan@cs.man.ac.uk


======================================================================== 40 ===
Date:    15 Dec 91 14:48:55 GMT
From:    carroll@cis.udel.edu (Mark C. Carroll)
Subject: Modula-3 and Oberon


I've seen Modula-3 and Oberon mentioned together constantly, as being
different languages to follow in the Modula tradition of programming
languages.

I've read both the Modula-3 report, and a collection of papers on
Oberon and Oberon-2. But reading the Oberon material, I've had a very
hard time understanding what about the language has created the kind
of interest in it that I see. But a lot of people seem to be very
impressed with the language, so I've become convinced that I must be
missing something.

If you're an Oberon fan, what about Oberon do you like?

I'm a very big fan of Modula-3, because of some features like dynamic
binding of methods, the interface/implementation distinction,
exceptions, and the ability to partially reveal types. All of these
were left out in Oberon - can someone explain what the reasoning
behind it is? I know that I lot of people prefer the simpler Oberon
design, but I'm not sure.


This isn't intended to start a flame war. Please, don't just start tearing
down one language or the other! And don't take this as an insult if you're
an Oberon fan!

Many thanks,
	<MC>

|| Mark Craig Carroll: <MC>     ||"Don't ever think that you can't
|| Univ of Delaware, Dept of CIS||    change the past
|| Grad Student/Labstaff Hacker ||       or the future"
|| carroll@udel.edu             ||  - _Love_and_Anger_, Kate Bush


======================================================================== 41 ===
Date:    15 Dec 91 21:24:59 GMT
From:    schwartz@roke.cs.psu.edu (Scott Schwartz)
Subject: Re: Modula-3 and Oberon


carroll@cis.udel.edu (Mark C. Carroll) writes:
| If you're an Oberon fan, what about Oberon do you like?

It is lean and mean.  The language is simple and makes only modest
requirements of the host system.  Yes, lots of good stuff was left
out, but hopefully no bad stuff was left in.  (Actually, I think there
was, though.  Fooey on scalar-only function return values.)  

Consider that the entire oberon system is about 2M (du -s oberon2.0).
``hello world'' in trellis is bigger than that!  (on a sparc) :-(


======================================================================== 42 ===
Date:    16 Dec 91 06:37:40 GMT
From:    mgallo@zeus.calpoly.edu (M. Gallo)
Subject: Re: Modula-3 and Oberon


In article <72350@nigel.ee.udel.edu> carroll@cis.udel.edu (Mark C. Carroll) wri
tes:
>
>I've seen Modula-3 and Oberon mentioned together constantly, as being
>different languages to follow in the Modula tradition of programming
>languages.
>
>I've read both the Modula-3 report, and a collection of papers on
>Oberon and Oberon-2. But reading the Oberon material, I've had a very
>hard time understanding what about the language has created the kind
>of interest in it that I see. But a lot of people seem to be very
>impressed with the language, so I've become convinced that I must be
>missing something.
>
>If you're an Oberon fan, what about Oberon do you like?
>
>I'm a very big fan of Modula-3, because of some features like dynamic
>binding of methods, the interface/implementation distinction,
>exceptions, and the ability to partially reveal types. All of these
>were left out in Oberon - can someone explain what the reasoning
>behind it is? I know that I lot of people prefer the simpler Oberon
>design, but I'm not sure.

Wirth, the designer of Modula-2 and Oberon, has often been "accused"
of being a computing minimalist.  Oberon is probably his most
outstanding example of trying to do more with less so far.  It seems
to me that Oberon was meant to be the simplest language that could
still support modern systems programming, which means rethinking what
is really necessary for systems programming.  It's an attempt to
design a language from scratch without inheriting any needless baggage. 
Some people regard it as "lean and mean" while others think it's a
crippled language.

Of the "missing features" that you mentioned, Oberon does have
partially revealed types (public projections) and an
interface/implementation distinction (exported items are specially
marked and can be extracted into a separate text via a browser).
Compiler controlled dynamically bound methods are replaced by
programmer controlled procedure variables.

Oberon-2, designed by one someone else at Wirth's computer systems
lab (H. Moessenboeck), is an extension of Oberon that contains
dynamically bound methods (type-bound procedures) among other
additions.

Neither language has exception handling.
-- 
IMHO, as always                                            _   /|
Miguel                                                     \'o.O'
mgallo@ares.calpoly.edu                                    =(___)=
"C is its own virus."                                         U


======================================================================== 43 ===
Date:    15 Dec 91 21:43:34 GMT
From:    bevan@cs.man.ac.uk (Stephen J Bevan)
Subject: Re: Modula-3 and Oberon

In article <72350@nigel.ee.udel.edu> carroll@cis.udel.edu (Mark C. Carroll) wri
tes:

   I've read both the Modula-3 report, and a collection of papers on
   Oberon and Oberon-2. But reading the Oberon material, I've had a very
   hard time understanding what about the language has created the kind
   of interest in it that I see. But a lot of people seem to be very
   impressed with the language, so I've become convinced that I must be
   missing something.

Well if you are missing something, then so am I.


   If you're an Oberon fan, what about Oberon do you like?


When you say Oberon fan, it depends what you are comparing it against.
Compared to C or Modula II, I think it is an improvement, but then it
should be as it was designed after them.
Compared to a "larger" language like Modula III it can look simplistic
because it doesn't have certain features, e.g. some of the things you
mention :-

   ... dynamic binding of methods, the interface/implementation
   distinction, exceptions, and the ability to partially reveal types.

However, C lacked many of the things that Ada had, but that didn't
stop people prefering Ada to C (I'm not one of them BTW).  My guess is
that some people like Oberon because of its simplicity i.e.

* the syntax is small, simple and regular (this is my opinion after
  writing a YACC parser for it).

* A complete compiler should be quite simple to write (haven't done
  this and don't plan to) as there are no "tricky" bits in the
  language. 

* A lot of thought seems to have been put into what should and
  shouldn't go into the language.  It's not perfect, but those things
  that are there have a good reason for being there (well almost all,
  I can't understand why SET made it in!)

If I remember correctly the ETH compiler is about 5000 LOC.  That's
pretty good in my opinion, and the code it produces is good given that
it doesn't do much optimisation.  (This is based on some simple tests
I did comparing Oberon and C on a SPARC).

Compare that with the size of the Modula III compiler.  I don't even
have enought disk quota to compile up the Modula III compiler!


   This isn't intended to start a flame war. Please, don't just start tearing
   down one language or the other! And don't take this as an insult if you're
   an Oberon fan!

Personally I like Modula III and Oberon-2.  Both have their good
points and both have their bad points.  In the end I would say Modula
III is a "better" language.  However, the Modula III implementation(s)
aren't up to the quality of the ETH Oberon-2 implementation yet.

As a final note I should say I don't write Oberon-2 programs per-se.
The only ones I write are test programs for my context checking
(static semantics) system$ which is part of my Ph.D work.

Any "real" Oberon-2 users out there.  That's beside ETH people and
Chuck Lins that is :-)


   Many thanks,
	   <MC>


Stephen J. Bevan			bevan@cs.man.ac.uk

$ BTW in case you are interested, this isn't available for release so
      don't even ask for it.  I'll announce it when its ready, but
      don't hold your breath!  It's release is about as certain as GNU
      Emacs v19 :-) 


======================================================================== 44 ===
Date:    Mon, 16 Dec 1991 12:56:46 PST
From:    David Nichols <nichols@parc.xerox.com>
Subject: Exception parameters

A while back, I had some questions about exceptions and started quizing
my fellow M3 (and Cedar) programmers here at PARC.  I also found a nice
Roy Levin memo from ancient Cedar history that talked about abstraction
boundaries and what happens to exceptions when they cross them.

As a result of these discussions, several of us (Mike Spreitzer, Carl
Hauser, Alan Demers and I) invented the following conventions for the
argument to an exception, which I am including in the form of an
interface, ExceptionArg.i3.  Any mistakes or confusions in the comments
are my responsibility.  I've used it for our RPC package and have liked
it so far, but I haven't exercised all the purported features yet.

Please let me know what you think.  In particular, I am confused as to
whether the top level object should be branded or not.  You must brand
the subtypes, otherwise the TYPECASE fails.

	David
================================
(*
   ExceptionArg.i3
   David Nichols, Xerox PARC.
   August, 1991
*)

INTERFACE ExceptionArg;

(* This interface defines a single type meant to be used as the argument to
   exceptions.  It should be used as follows.

   Within an "abstraction," a collection of related interfaces and modules,
   ExceptionArg.T is subtyped to create new error codes (don't forget to
   brand the subtypes).  The typecodes of these new objects serve as the
   enumeration that defines the error type, while the "info" field contains
   an explanation meant for human consumption.  An exception handler that
   receives an ExceptionArg.T as the parameter can do a TYPECASE to
   determine the cause at whatever level of detail it likes.

   For example, a file system might define subtypes called ResourceFailure
   and IOFailure, corresponding to running out of some resource or
   encountering a low-level I/O error, respectively.  ResourceFailure could
   have subtypes named DiskFullFailure and QuotaFailure to distinguish
   between the entire disk being full vs a user's quota being exceeded.  A
   program that caught the exception could then use TYPECASE on any of
   these types.

   Each subtype of ExceptionArg.T can add additional fields necessary to
   characterize the situtation.  QuotaFailure could include the user's
   quota, for example.

   When exceptions cross abstraction boundaries, the subArg field is used.
   Often, the calling abstraction will catch the exception and translate it
   to an exception of its own.  In this case, the old ExceptionArg.T can be
   placed in the subArg field, providing the top-level handler or debugger
   with more information about the history of this exception.

   For example, a mail system might catch a file system exception and
   raise an exception describing its inability to deliver a mail message.
   The resultant ExceptionArg.T would have explanations of both the
   delivery failure and the quota failure that caused it.

   A suggested naming convention is to choose a verb (e.g. "to err" or "to
   fail") and to name the exception in the past tense of the verb ("Erred"
   or "Failed").  The first-level subtype of ExceptionArg.T can be named
   with the corresponding noun ("Error" and "Failure").  This leads to noun
   phrases for the other subtypes ("CommunicationsFailure",
   "ParameterError", etc). *)

TYPE
  T = OBJECT
        info  : TEXT;
        subArg: T      := NIL;
      END;

END ExceptionArg.
================================
Here's some code that might implement the examples above:

  INTERFACE Disk;
  ...
  EXCEPTION
    Failed(Failure);
  TYPE
    Failure = ExceptionArg.T BRANDED OBJECT END;
    IOFailure = Failure BRANDED OBJECT END;
    ResourceFailure = Failure BRANDED OBJECT END;
    QuotaFailure = ResourceFailure BRANDED OBJECT
        quota: INTEGER;
      END;
    DiskFullFailure = ResourceFailure BRANDED OBJECT END;

raising one:

  IF blocksUsed > quota THEN
    RAISE Disk.Failed(NEW(Disk.QuotaFailure(
      info := "Quota exceeded.", quota := quota)));
  END;

handling one:

  TRY
    ...
  EXCEPT
    Disk.Failed(v) =>
      TYPECASE v OF
        Disk.QuotaFailure(q) =>
          GetUnderQuota(q.quota);
      ELSE
        VAR e: ExceptionArg.T := v;
        BEGIN
          Wr.PutText(stderr, "Disk error: ");
          WHILE e # NIL DO
            Wr.PutText(stderr, "  " & e.info & "\n");
            e := e.subArg;
          END;
        END;
      END;
  END;


======================================================================== 45 ===
Date:    16 Dec 91 21:58:03 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Modula-3 Library collectors/Programming Style

In article <1991Dec13.203805.690@bert.pinecreek.com> harbison@bert.pinecreek.co
m (Sam Harbison) writes:

>   Yes, I started a Pine Creek Modula-3 Library, which was announced a
>   few weeks ago with its first member, FieldList. I didn't really want
>   to duplicate other sources, and perhaps if SRC is really being so open
>   about including "everything" in the M3 library distribution, it would
>   be better to do that.

Since the people at SRC are willing to include and integrate useful
modules, this is indeed the best approach. When multiple uncoordinated 
libraries exist, each user has to go through the selection and 
integration process. PLEASE MENTION IN THE FAQ that SRC is collecting
contributed modules. I hope that the SRC and GNU Modula 3 distributions
will be able to share such contributed modules.

>   If Michael Dagenais wants to maintain a list of "wanted libraries," I think
>   that would be great. In fact, a collection of "Modula-3 Projects" to give
>   students some suggestions of things to do would be nice, also.

Sure, if no one is already collecting this information, i think
that a list of what's missing (compared to libraries in other languages
among other things) would be helpful. Moreover, this list could include
work in progress (with no deadlines as usual) such that interested parties
could see the activity taking place in the Modula 3 community and
communicate with each other when working on related topics. 

A neutral comparison with related object oriented languages may also be a nice
addition to this "FAQ supplement" since several postings lately requested
such information. 

I will contact Sam Harbinson privately since he has surveyed 
available libraries in other languages and wait for the Christmas
SRC 2.0 release (i must have been a good boy this year because it is just
what i asked Santa for :-). The first posting of the "FAQ supplement" would
come thereafter.

>   The "style sheet" in my book is a modified version of the DEC SRC
>   style sheet for Modula-2+. It's pretty thin.  There has just been
>   released a new version of a much larger document for Ada:

An officially recommended "style sheet" would be an asset for Modula 3.
Could you submit an electronic copy of it for "discussion/integration"
in the SRC release.
--
---------------------------------------------------------------------

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

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


======================================================================== 46 ===
Date:    Tue, 17 Dec 91 11:09:21 PST
From:    <meehan@src.dec.com>
Subject: Re: Exception parameters


I've been doing the same sort of thing that Dave Nichols suggests: if
exceptions can't be objects (*sigh*), then at least their arguments
can.  A couple of related suggestions:

1. ExceptionArg.T should have a 'print' method of one argument, of
   type Wr.T.  Its default method is simply to print the 'info' field.
   Subtypes override the print method to give more detailed information.

   Here's how I would do part of your example: (This is just "code",
   not the interface)

    EXCEPTION E (T);
    
    TYPE
      T = OBJECT info := "" METHODS print (wr: Wr.T) := PrintException END;
      Failure = T OBJECT END;
      ResourceFailure = Failure OBJECT
                        OVERRIDES
                          print := PrintResourceFailure
                        END;
      QuotaFailure = ResourceFailure  OBJECT
                       quota: INTEGER
                     OVERRIDES
                       print := PrintQuotaFailure
                     END;
    
    PROCEDURE PrintException (t: T; wr: Wr.T) =
      BEGIN
        Wr.PutText (wr, t.info & "\n")
      END PrintException;
    
    PROCEDURE PrintQuotaFailure (qf: QuotaFailure; wr: Wr.T) =
      BEGIN
        qf.info := Fmt.F ("Quota of %s has been exceeded", Fmt.Int (qf.quota));
        ResourceFailure.print (qf, wr)
      END PrintQuotaFailure;
    
    PROCEDURE PrintResourceFailure (rf: ResourceFailure; wr: Wr.T) =
      BEGIN
        rf.info := "Resource failure: " & rf.info;
        Failure.print (rf, wr)
      END PrintResourceFailure;

You can see how it works by using this "main" code:

    BEGIN
      TRY
        WITH e = NEW (QuotaFailure, quota := 100) DO RAISE E (e) END
      EXCEPT
      | E (t) => t.print (Stdio.stderr)
      END
    END;

Note that nothing's branded here, because the overridden methods get
you to the right method.

2. What I am really doing is modeling the Common Lisp Condition System,
where "exceptions" really are objects, and the condition-handling system
is not something you couldn't write in the language itself, unlike
TRY/EXCEPT.  The entire hierarchy defined in the second edition of
the Common Lisp manual can be written in Modula-3, with the exception
of a couple that want multiple inheritance, but even those aren't
impossible to model in a singe-inheritance system.

I think this is a better approach than using numerical "error codes"
(cf.  the "C/Unix perror() approach" mentioned by David Emery).  Certainly
any scheme for the uniformity or internationalization can be implemented
with objects, and I believe that customization is even easier in
the o-o world.



======================================================================== 47 ===
Date:    17 Dec 91 15:35:42 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Modula-3 T-Shirts

Goodness, how could a language get to be 2 years old and not have an
official T-shirt? Well, we can fix that! But first, a small poll:
- Would you prefer T-shirts or sweatshirts? Favorite colors?
- The front will have the M3 logo. Should the back have a slogan or be plain?
- If a slogan, what? ("Safe & Effective" is my favorite; suggest others)
- How many would you likely want? Would you want children's sizes?

I haven't decided whether to make these available at cost, give them
away at some of the conferences this winter/spring (USENIX, Software
Development '92, and ACM CSC), or award them for special services
(like contributing Modula-3 code to the community).

Respond to me and I'll summarize to the net.


======================================================================== 48 ===
Date:    17 Dec 91 15:30:22 GMT
From:    emery@Dr_No.mitre.org (David Emery)
Subject: Re: Exception parameters

I'm not sure if placing the info text as part of the Exception
parameter is a good idea.  I prefer the C/Unix perror() approach,
because it provides much better support for internationalization and
customization.  perror() maps an error code into a string message.
This mapping can (I think in POSIX it's supposed to) use the LOCALE
environment variable to decide the language to be used for the error
message.  

Incidentally, this is part of the rationale for replacing the original
error handling approach (1 exception per C error code) in the POSIX
Ada binding with the current approach (a single exception and an
operation that returns an error code enumeration).  The value returned
by the Get_Error_Code function can then be passed to a perror()-like
routine (not currently defined by POSIX P1003.5), to get the
locale-specific error message.  This is also a good example of a case
where I wish Ada exceptions had parameters...

				dave


======================================================================== 49 ===
Date:    17 Dec 91 22:28:21 GMT
From:    emery@Dr_No.mitre.org (David Emery)
Subject: Re: Exception parameters

The issues are:
	1.  "who" (which object/operation) determines the language for
reporting error codes, and
	2.  how do you add a new language (Ukranian, for instance :-)?

If you assume that the set of errors in a system is relatively static,
then it seems to me to be easiest to have a single
routine/place/whatever that, given an error code and a language,
returns the appropriate message in that language.  The alternative is
to go to each exception object, spread across the system, and add the
appropriate text to that object.  This latter approach, although
probably more Object-Oriented "pure", strikes me as a maintenance
headache. 

				dave


======================================================================== 50 ===
Date:    Tue, 17 Dec 1991 17:55:24 PST
From:    David Nichols <nichols@parc.xerox.com>
Subject: Re: Exception parameters

While I'm sympathetic to internationalization problems, I prefer having
the info string right there in the error parameter to both error codes
and print methods.  The advantage is that I don't need a running program
to decode the error, so I can easily debug a core file.  It's still not
too difficult to internationalize; for example, you could assign all
your error messages from a package full of global variables (set at init
time based on LOCALE), or define your own error message methods and call
them.  The error message method style has the advantage of defaulting
the message if you're willing to use the same message (or message
format) each time you use a particular subtype.

You need to brand all the subtypes so that you get unique typecodes to
make your TYPECASEs work.  I suppose the overrides generally do this,
but if you decide that this subtype can live with the parent's print
routine, then you lose.  Better just to brand them all.

	David


======================================================================== 51 ===
Date:    Tue, 17 Dec 1991 19:20:16 GMT
From:    salomon@silver.cs.umanitoba.ca (Dan Salomon)
Subject: Re: Modula-3 and Oberon

In article <BEVAN.91Dec15214334@hippo.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen
 J Bevan) writes:
> My guess is
> that some people like Oberon because of its simplicity i.e.
> . . .
> * A lot of thought seems to have been put into what should and
>   shouldn't go into the language.  It's not perfect, but those things
>   that are there have a good reason for being there (well almost all,
>   I can't understand why SET made it in!)

Sets are important for writing parser generators.  Without sets, stored
as one bit per member, one quickly runs into memory size problems when
representing lookahead sets.  Since language designers are often
involved in implementing parser generators too it makes sense that they
would include their pet features.  I am told however that Wirth does
not use automatic parser generator tools, so I am not sure why he
likes sets enough to include them in Oberon.


======================================================================== 52 ===
Date:    18 Dec 91 09:40:22 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Scanner & Parser Generator


Hello *,

  Practically inevitable is the question about available Scanner and Parser
generators. I haven't heard anyone talk about this subject however, so I'll
do it:
	- Anyone built a Scanner/Parser Generator for Modula-3?

  In the course of the Modular-Pascal project here in Groningen, both a
simple scanner generator, and an LL(1)-parser generator have been built.
Since both are quite small, I think I'll rewrite them for Modula-3.
They will both be distributable.
  If anyone wants to stop me because it's been done, shout!

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


======================================================================== 53 ===
Date:    Wed, 18 Dec 1991 10:09:53 PST
From:    David Nichols <nichols@parc.xerox.com>
Subject: Re: Exception parameters

I agree that you want to centralize the text messages, either with
explicit coding or tools that modify the program (a la xstr).  All I'm
suggesting is that the translation from error code to string happen
before the exception is raised instead of after.

Instead of

  RAISE Failed(NEW(IOFailure(ec := IOFailureEC)));
...
 Failed(f) =>
    Wr.PutText(stderr, ErrMsg.Translate(f.ec));

write

  RAISE Failed(NEW(IOFailure(info := ErrMsg.Translate(IOFailureEC))));
...
  Failed(f) =>
    Wr.PutText(stderr, f.info);


	David


======================================================================== 54 ===
Date:    Wed, 18 Dec 1991 17:24:33 GMT
From:    ulrich@mips.complang.tuwien.ac.at (Ulrich Neumerkel)
Subject: Re: Modula-3 and Oberon

In article <72350@nigel.ee.udel.edu>, carroll@cis.udel.edu (Mark C. Carroll) wr
ites:

[why some people might prefer Oberon over Modula-3]

simplicity:
Oberon is much simpler. Learning Oberon is a < 1 hour effort if You know
Modula. (Suggested reading: From Modula to Oberon; Differences between Oberon &
Oberon2, they are all in source in the oberon-distribution) All rather
complicated things (enumerations etc.) of Modula are avoided. Modula-3 is in
my view more complex to learn. The report is difficult to read compared to the
Oberon(-2) report. But to avoid misunderstandings: Modula-3 is also one of the
simpler/clearer languages.

size & efficiency:
The complete distribution directory including the user interface the editor,
a nearto wysiwyg editor, paint and draw program, demos, browser, fonts,
converted fonts, the reports etc. is small (2.8 MB on a DEC, the original
executable on a CERES is < 200KB). The compiler is fast, efficient (better
than cc -O1) and very compact. The Modula-3 implementation is very big (it's
more portable indeed). The compiler is slow. Not that this is an argument for
the superiority of Oberon over Modula-3.

the environment (i.e. the oberon system):
The *feeling* of an interactive system combined with the advantages of a
type save programming language. Oberon (the system & language) was designed
to be easily extensible. Most parts of the system can be recompiled & reloaded
while the *same* system is running.

|> I'm a very big fan of Modula-3, because of some features like dynamic
|> binding of methods,

Dynamic binding in Oberon is accomplished by extensible records and procedure
variables as methods, thus methods can be changed dynamically. In Oberon-2 you
have in addition type bound procedures.

|> the interface/implementation distinction,
I can imagine that you mean two different things:

1st: there are no definition modules in Oberon: They are implicitely defined
by adding an export*. You can see them anyway with the browser. If you change
the interface you have to acknowlede this to the compiler since this would
mean that you have to recompile more than this module.

2nd: It is not possible for a module to have more than one interface, indeed.

|> exceptions, [maybe you want to mention threads as well]
A procedure is considered an atomic action in the Oberon system.
Only some fatal interrupts (floating point exception, or a special user
key) are possible that basically unroll the whole stack back to the
basic event loop. Strange isn't it? But even with this very unusual approach
Oberon obtains multitasking functionality for the user (not the programmer,
he has to put longer running jobs into slices).

|> and the ability to partially reveal types. All of these
In Oberon you have only partial export of a type and inheritance
(extending records) for finer structurization. 

|> were left out in Oberon - can someone explain what the reasoning
|> behind it is? I know that I lot of people prefer the simpler Oberon
|> design, but I'm not sure.

-- 
Ulrich Neumerkel, ulrich@dec4.wu-wien.ac.at ulrich@mips.complang.tuwien.ac.at
(ulrich@vip.UUCP) +431 58801/4477 fax +431 5057838
TU Inst.f. Computersprachen E185/1 Argentinierstr.8/4, A-1040 Wien Austria


======================================================================== 55 ===
Date:    18 Dec 91 13:10:48 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Scanner & Parser Generator

Do you mean a scanner and parser of Modula-3 source, or one that generates
Modula-3 code for a regular language or grammar of your choice? We have a
Modula-3 scanner and parser working as part of the GNU Modula-3 compiler
project, but I'm guessing that's not what you mean. (If anyone cares, the
scanner is hand written for speed and the parser is generated by bison; the
whole compiler is written in C since it is based on gcc and we hope to share
most of the compiler source files now and in the future.)
--

		J. Eliot B. Moss, Assistant 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


======================================================================== 56 ===
Date:    18 Dec 91 10:43:38 GMT
From:    bevan@cs.man.ac.uk (Stephen J Bevan)
Subject: Re: Modula-3 and Oberon

In article <1991Dec17.192016.21709@ccu.umanitoba.ca> salomon@silver.cs.umanitob
a.ca (Dan Salomon) writes:

   In article <BEVAN.91Dec15214334@hippo.cs.man.ac.uk> bevan@cs.man.ac.uk (Step
hen J Bevan) writes:
   > My guess is
   > that some people like Oberon because of its simplicity i.e.
   > . . .
   > * A lot of thought seems to have been put into what should and
   >   shouldn't go into the language.  It's not perfect, but those things
   >   that are there have a good reason for being there (well almost all,
   >   I can't understand why SET made it in!)

   Sets are important for writing parser generators.  Without sets, stored
   as one bit per member, one quickly runs into memory size problems when
   representing lookahead sets.

Don't get me wrong I'm not arguing against sets, I'm arguing against
the limited version that are implemented in Oberon-2.  For a language
that is supposed to have extensible types, it seems pretty poor to
have sets built into the language and only have them applicable to
integers.  

The only special thing about sets in Oberon-2 is the overloading of
the operations.  If you can live without that (I definitely can), then
the sets as they stand can be implemented as operations on some
integer type.  This could be put in a module and distributed as a
standard library of sorts.  I see no reason to elevate it to a
language feature and give it special syntax.

Yours minimally :-)

bevan


======================================================================== 57 ===
Date:    19 Dec 91 09:13:53 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: Scanner & Parser Generator


Sorry about any confusion because of my choice of words. I was
(and still am) referring to a scanner and parser generator that
generate Modula-3 code. Preferably written in Modula-3.
  If it ain't worth doing _in_ Modula-3 (eventually), then you'ld
better rethink your motives. Bootstrapping is another case altogether,
but I'ld like to be able to get not just a M3 compiler, but the
complete set of programs one uses for the art of programming.

I've started on the csanner-generator; making it produce Modula-3
in stead of Modular-Pascal won't be too big a problem, but I'll
have to do the same for the parser generator before I can convert
the program itself, 'cause both are built using both. ;-)

PS the GNU project is ofcourse most practical in C. I'm not
   attacking that decision.

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


======================================================================== 58 ===
Date:    19 Dec 91 19:06:52 GMT
From:    garnett@cs.utexas.edu (John William Garnett)
Subject: Need a small working example showing how to use Thread.Fork

Hello,

I am attempting to use the Threads facility in the SRC 1.6 Modula-3
compiler.  I am unable to get the OVERRIDES statement to work as expected.
I copied the following small example program from pages 91-92 of
the "Systems Programming in Modula-3" book edited by Greg Nelson.
When I compile it using:

m3 Add.m3

I get the following compiler error:

/projects/ppclass/tmp/garnett/thread: m3 Add.m3
"Add.m3", line 15: syntax error: missing 'END' (OVERRIDES)
1 error encountered

I can only assume there is an error in the compiler, in the book,
or in my interpretation thereof.  I assume there is an error in the
definition of the FClosure type.  Please take a look at the below
code and help me if you will.  Send responses via email to
garnett@cs.utexas.edu and I will summarized.

MODULE Add EXPORTS Main;

IMPORT Stdio, Fmt, Thread;

TYPE
   FClosure = Thread.Closure OBJECT
      arg, result : INTEGER
   OVERRIDES
      apply := ApplyF
   END;

VAR
   Cl : FClosure;
   t : Thread.T;
   f1 : INTEGER;

PROCEDURE F(i : INTEGER):INTEGER =
BEGIN
   RETURN i * i
END F;

PROCEDURE ApplyF(self: FClosure): REFANY =
BEGIN
   self.result := F(self.arg);
   RETURN NIL
END ApplyF;

BEGIN
   cl := NEW(FClosure, arg := 2);
   t := Thread.Fork(cl);
   f1 := F(3);
   EVAL Thread.Join(t);
   RETURN f1 + cl.result
END Add;
-- 
John Garnett
                                           University of Texas at Austin
garnett@cs.utexas.edu                      Department of Computer Science
garnett@gestalt.austin.tx.us (NeXT Mail)   Austin, Texas


======================================================================== 59 ===
Date:    Thu, 19 Dec 91 16:40:35 PST
From:    Pat.Lashley@Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.])
Subject: Re: Exception parameters

|>  The issues are:
|>  	1.  "who" (which object/operation) determines the language for
|>  reporting error codes, and
|>  	2.  how do you add a new language (Ukranian, for instance :-)?
|>  
|>  If you assume that the set of errors in a system is relatively static,
|>  then it seems to me to be easiest to have a single
|>  routine/place/whatever that, given an error code and a language,
|>  returns the appropriate message in that language.  The alternative is
|>  to go to each exception object, spread across the system, and add the
|>  appropriate text to that object.  This latter approach, although
|>  probably more Object-Oriented "pure", strikes me as a maintenance
|>  headache. 


You can get the best of both worlds.  You make your database key
off of some canonical form of the message.  (Usually the text in
the C locale, but it could be anything.)  Provide a standard library
module to set the locale and translate arbitrary strings by looking
them up in the database.  If not found return the original (and
possibly raise an exception).

It is pretty trivial to write a tility that will grovel through a
source file looking for all occurrances of `I18N.GetText("<some string>")'
and extract the string so that it may be placed into the translation
database.  You deliver the database template with your application.

To localize it someone must take the list of extracted strings and
produce a locale-specific set of translations, and place them in some
well-known location where gettext() can find them.



-Pat




======================================================================== 60 ===
Date:    Thu, 19 Dec 91 12:38:49 PST
From:    msm@src.dec.com (Mark S. Manasse)
Subject: Re: Need a small working example showing how to use Thread.Fork

The compiler accepts an older version of Modula-3, in which you list
your overrides as METHODS.

Mark


======================================================================== 61 ===
Date:    Fri, 20 Dec 91 10:11:23 PST
From:    <kalsow@src.dec.com>
Subject: Re: Need a small working example showing how to use Thread.Fork

>  Well, yes, but actually adding new methods and overriding old ones has
>  slightly different syntax: one uses ":=" and the other uses "=". Take a look
>  at the Modula-3 Report (Revised) to see which is which ... (I can't remember
>  off the top of my head and I don't have the Report available where I'm typin
g
>  this response).

Not quite.  In the old syntax the presence or absence of a procedure signature
determined whether a method was an override.

In both versions:

    "Ident (...)"          declares a new method
    "Ident (...) := Expr"  declares a new method and gives it a default value
    "Ident := Expr"        overrides an existing method

In the new syntax overrides are separated from new methods by the
"OVERRIDES" keyword.  We found that the distinction between "m() := P"
and "m := P" was too subtle.  It confused programmers.

 - Bill Kalsow

----------------------------------------------------------------------------
old syntax:

    ObjectType = ... [ METHODS Methods ] ...
    Method     = Ident ( Signature & ":=" ProcedureID )
     << where "( X & Y )" is  defined to be " X Y | X | Y ". >>

new syntax:

    ObjectType = ... [ METHODS Methods ] [ OVERRIDES Overrides ] ...
    Method     = Ident Signature [ ":=" ConstExpr ]
    Overrides  = [ Override { ";" Override } [ ";" ] ]
    Override   = Ident ":=" ConstExpr

both syntaxes:

    Methods    = [ Method { ";" Method } [ ";" ] ]
    Signature  = "(" Formals ")" [ ":" Type ] [ RAISES Raises ]


======================================================================== 62 ===
Date:    Fri, 20 Dec 91 09:34:04 PST
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: Need a small working example showing how to use Thread.Fork

In article <MOSS.91Dec20085331@ibis.cs.umass.edu>, moss@cs.umass.edu (Eliot Mos
s) writes:
> In article <1991Dec19.123849.8310@src.dec.com> msm@src.dec.com (Mark S. Manas
se) writes:
> 
>    The compiler accepts an older version of Modula-3, in which you list
>    your overrides as METHODS.
> 
> Well, yes, but actually adding new methods and overriding old ones has
> slightly different syntax: one uses ":=" and the other uses "=". Take a look
> at the Modula-3 Report (Revised) to see which is which ... (I can't remember
> off the top of my head and I don't have the Report available where I'm typing
> this response).
> --
> 

This is not true, they both use ":=".  The syntax difference is in the
procedure signature, which is always omitted for an OVERRIDE. E.g.

  TYPE T = ST OBJECT METHODS p := P END (* 'st' presumed to define 'p' with sig
nature *)

is now written as:

  TYPE T = ST OBJECT OVERRIDES p := P END;

Mick


======================================================================== 63 ===
Date:    20 Dec 91 13:53:31 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Need a small working example showing how to use Thread.Fork

In article <1991Dec19.123849.8310@src.dec.com> msm@src.dec.com (Mark S. Manasse
) writes:

   The compiler accepts an older version of Modula-3, in which you list
   your overrides as METHODS.

Well, yes, but actually adding new methods and overriding old ones has
slightly different syntax: one uses ":=" and the other uses "=". Take a look
at the Modula-3 Report (Revised) to see which is which ... (I can't remember
off the top of my head and I don't have the Report available where I'm typing
this response).
--

		J. Eliot B. Moss, Assistant 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


======================================================================== 64 ===
Date:    Fri, 20 Dec 1991 18:51:47 GMT
From:    robichau@freedom.msfc.nasa.gov (Paul Robichaux)
Subject: Macintosh port of M3 compiler?

I recently found out about Modula-3 and was happy to see that M2, and now its
successor, isn't dead.

Since the M3 compiler generates C as an IR, porting it should be fairly simple.
I'd like to use it on my MacOS machines, so if anyone out there knows of a
port, or would like to work on one, please respond via email. I'll summarize
if there's any interest.

-Paul

-- 
Paul Robichaux                  | Disclaimer: NTI pays for my skills, not my
robichau@freedom.msfc.nasa.gov  |             opinions.
	     This message printed on recycled phosphors.


======================================================================== 65 ===
Date:    22 Dec 91 01:22:27 GMT
From:    darrell%cse.UCSC.EDU@ucscc.ucsc.edu (Darrell Long)
Subject: Looking for Oberon compiler...

I'm looking for a PD/free Oberon compiler.  Does such a beast exist?  I'd like
to use it in my graduate PL class next quarter.

Thanks, DL

Dr. Darrell Long
Computer & Information Sciences
University of California
Santa Cruz, CA  95064

Office: (408) 459-2616, Laboratory: (408) 459-4458, FAX: (408) 459-4829
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


======================================================================== 66 ===
Date:    22 Dec 91 16:10:56 GMT
From:    bobg+@andrew.cmu.edu (Robert Steven Glickstein)
Subject: Better emacs mode

The world (or at least me) will beat a path to your door if you can
tell me of a better Gnu-Emacs mode for editing Modula-3 code (better,
that is, than the Jordan/Robinson/Schmidt/Perrine/Morris modula3.el,
version 1.10).

Thanks in advance!

______________                  _____________________________
Bob Glickstein                | Internet: bobg@andrew.cmu.edu
Information Technology Center | Bitnet:   bobg%andrew@cmuccvma.bitnet
Carnegie Mellon University    | UUCP:     ...!harvard!andrew.cmu.edu!bobg
Pittsburgh, PA  15213-3890    |
(412) 268-6743                | Sinners can repent, but stupid is forever


======================================================================== 67 ===
Date:    Mon, 23 Dec 91 10:51:45 PST
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Using the INLINE pragma


In the near future I hope to release a tool that will support, amongst other th
ings,
procedure inlining, both inter and intra module. The tool operates at the sourc
e 
(Abstract Syntax Tree) level and is based on the Modula-3 toolkit, which has re
cently
been upgraded to the 2.0 language level. (Incidentally, the code size and perfo
rmance
is much improved due the SRC 2.0 compiler improvements; congrats to Bill and Er
ic).

Initially I only plan to inline procedures that are marked with the INLINE prag
ma,
although, in the future, there is scope for trying to decide this automatically
.

I would like to propose the following conventions for the use of INLINE.

1. In an interface, INLINE is a strong statement that a client can depend on,
for any implementation of the interface. The interface designer should have a 
very high degree of confidence that an implementor can meet the requirement.

2. In a module, private (i.e. non-exported) procedures are marked INLINE at the
discretion of the implementor. 

3. In a module, public procedures that export an interface procedure marked as 
INLINE 
are treated as if they were marked INLINE, regardless of their actual designati
on. 
I.e. they inherit the INLINE attribute from the interface.  An alternative is t
o treat 
the failure of the implementation to meet the INLINE specification in the inter
face as 
an "error". The inlining would not happen and a warning would be generated.

4. In a module, public procedures marked as INLINE, that export an interface no
t marked 
as INLINE, are inlined. I.e., INLINE is propagated to the interface.

Comments?

Mick Jordan




======================================================================== 68 ===
Date:    23 Dec 91 17:51:48 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: T-shirt survey

About 20 people responded to the inquiry about Modula-3 T-shirts.

T-shirts won out over sweatshirts, but a number of people wanted both.
Several people expressed a desire for high quality rather than low
price.  The slogan seemed OK to those who expressed an opinion.  There
were a few color preferences but no two were the same.

So...

I've placed an order for 30 all-cotton T-shirts and 20 top-of-the-line
(11 oz) sweatshirts. The shirt color is "ash," which is a white/gray
mix--very trendy, I'm told. The logo will be maroon. There will be no
slogan on the back. (I couldn't get my act together to design it right
away, and I wanted these shirts before UNIFORUM/USENIX.)

Tee shirt
  size L or XL      $6.00
  XXL                7.00

Sweatshirt
  size L or XL      18.00
  XXL               21.00

Shipping & handling (per sweatshirt, or for up to 3 tees)
  US                 4.00 (priority mail)
  Canada             5.00
  Other              8.00 (surface)

Pennsylvania residents must add 6% sales tax. Send me a check.  

First batch will be sent out Jan. 14. First come, first served. If
orders exceed supply, I'll make a second order, but expect a 3-week
delay.

Sam


======================================================================== 69 ===
Date:    23 Dec 91 21:47:34 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: T-shirts available (was Re: T-shirt survey)

In article <1991Dec23.175148.14857@bert.pinecreek.com> Sam Harbison
stupidly forgot to add his mailing address. Here is the complete info.

Modula-3 T-shirt, 100% cotton, ash with maroon logo
  size L or XL      $6.00
  XXL                7.00

Modula-3 Sweatshirt (heavy), ash with maroon logo
  size L or XL      18.00
  XXL               21.00

Shipping & handling (per sweatshirt, or for up to 3 tees)
  US                 4.00 (priority mail)
  Canada             5.00
  Other              8.00 (surface)

Pennsylvania residents must add 6% sales tax.
First batch will be sent out Jan. 14. 

Send a check or money order to:

Pine Creek Software
Suite 300
305 South Craig Street
Pittsburgh, PA 15213-3706
USA


======================================================================== 70 ===
Date:    24 Dec 91 16:19:48 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Re: Using the INLINE pragma

I have in the past taken issue with the "easy" way out of the
following inlining situation, so I'll do so again:

	INTERFACE Int;
	  INLINE PROCEDURE Easy();
	END Int.

	MODULE Client;
	  IMPORT Int;
	BEGIN
	  Int.Easy();	(* Should/will this be in-lined? *)
	END Client.

Int.Easy cannot *in general* be inlined into Client, because the
implementation of Easy() is not *necessarily* available. However, in
the analagous situation, good Ada compilers *will* inline Easy() into
Client IF they have previously compiled the implementation.
Furthermore, they compute the (re)compilation order for a program so
that the implementation will be compiled before clients *if possible*.
(If not, some clients may get the inlining and some may not. That's
life.) BTW, Ada implementors didn't do this because it was fun--customers
forced them to do it.

Mick Jordan (I think) makes no claims about this case. (That's OK.)
Rick Hudson suggests inlining *never happens*. I hope Modula-3
implementors try to be sophisticated in this case, or else:
 - the C mavens will forever be harping about macros,
 - the C++ folk will be trying to get us to put bodies in interfaces, and
 - the Ada poeple will think that Modula-3 is a toy

Sam ("One note") Harbison


======================================================================== 71 ===
Date:    Mon, 23 Dec 1991 14:58:47 GMT
From:    robichau@lambda.msfc.nasa.gov
Subject: Mac port of Modula-3

I'm doing a quick net.survey to see if there's a Mac version of the DEC/SRC
Modula-3 compiler.

If not, then I intend to port it, and would certainly welcome any help.

Respond via email, and I'll summarize after a much-needed Christmas vacation.

Happy holidays,
-Paul

-- 
Paul Robichaux
robichau@freedom.msfc.nasa.gov
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


======================================================================== 72 ===
Date:    Tue, 24 Dec 91 11:52:34 PST
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: Using the INLINE pragma

In article <1991Dec24.161948.18048@bert.pinecreek.com>, harbison@bert.pinecreek
.com (Sam Harbison) writes:
> I have in the past taken issue with the "easy" way out of the
> following inlining situation, so I'll do so again:
> 
> 	INTERFACE Int;
> 	  INLINE PROCEDURE Easy();
> 	END Int.
> 
> 	MODULE Client;
> 	  IMPORT Int;
> 	BEGIN
> 	  Int.Easy();	(* Should/will this be in-lined? *)
> 	END Client.
> 
> Int.Easy cannot *in general* be inlined into Client, because the
> implementation of Easy() is not *necessarily* available. However, in
> the analagous situation, good Ada compilers *will* inline Easy() into
> Client IF they have previously compiled the implementation.
> Furthermore, they compute the (re)compilation order for a program so
> that the implementation will be compiled before clients *if possible*.
> (If not, some clients may get the inlining and some may not. That's
> life.) BTW, Ada implementors didn't do this because it was fun--customers
> forced them to do it.
> 
> Mick Jordan (I think) makes no claims about this case. (That's OK.)
> Rick Hudson suggests inlining *never happens*. I hope Modula-3
> implementors try to be sophisticated in this case, or else:
>  - the C mavens will forever be harping about macros,
>  - the C++ folk will be trying to get us to put bodies in interfaces, and
>  - the Ada poeple will think that Modula-3 is a toy
> 
> Sam ("One note") Harbison

The Olivetti M3 implementation was designed to behave essentially as the ADA wo
rld,
by virtue of the fact that it "pickled" module ASTs for input to the pre-linker
.
The idea was to also include the bodies of inline procedures and have the compi
ler
unpickle these, if they existed, when compiling clients. However, we never impl
emented
it. I had no plans to be smart about compilation order. 

In any event, in the context of the tool I am proposing, I can punt on the issu
e because it 
is decoupled from the normal development cycle. It takes some set of sources an
d transforms
them into another (smaller) set, which are then compiled and linked into the pr
ogram
instead of the original set. Ideally, if you have enough memory, you operate on
 the
complete set of sources that make up the entire program, at which point some in
teresting
optimisations become possible (because e.g., the complete type hierarchy is kno
wn).

My proposal does indeed require implementors to be sophisticated because it doe
s not permit
knowledge of a particular implementation's inline characteristics to propagate 
into 
the interface. This seems correct if not, perhaps, pragmatic. But it is nearly 
1992 and,
as the Ada community has demonstrated, it is possible.

Mick Jordan
 


======================================================================== 73 ===
Date:    23 Dec 91 22:50:44 GMT
From:    hudson@cs.umass.edu (Rick Hudson)
Subject: Re: Using the INLINE pragma

In article <1991Dec23.105145.15994@src.dec.com> mjordan@src.dec.com (Mick Jorda
n) writes:
   In the near future I hope to release a tool that will support, amongst other
 things,
   procedure inlining, both inter and intra module. The tool operates at the so
urce 
   (Abstract Syntax Tree) level and is based on the Modula-3 toolkit, which has
 recently
   been upgraded to the 2.0 language level. (Incidentally, the code size and pe
rformance
   is much improved due the SRC 2.0 compiler improvements; congrats to Bill and
 Eric).

   Initially I only plan to inline procedures that are marked with the INLINE p
ragma,
   although, in the future, there is scope for trying to decide this automatica
lly.

   I would like to propose the following conventions for the use of INLINE.

   1. In an interface, INLINE is a strong statement that a client can depend on
,
   for any implementation of the interface. The interface designer should have 
a 
   very high degree of confidence that an implementor can meet the requirement.

   2. In a module, private (i.e. non-exported) procedures are marked INLINE at 
the
   discretion of the implementor. 

   3. In a module, public procedures that export an interface procedure marked 
as INLINE 
   are treated as if they were marked INLINE, regardless of their actual design
ation. 
   I.e. they inherit the INLINE attribute from the interface.  An alternative i
s to treat 
   the failure of the implementation to meet the INLINE specification in the in
terface as 
   an "error". The inlining would not happen and a warning would be generated.

   4. In a module, public procedures marked as INLINE, that export an interface
 not marked 
   as INLINE, are inlined. I.e., INLINE is propagated to the interface.

   Comments?

   Mick Jordan

I have no problems if I am reading this right. You are making no claim about
what happens in a MODULE that IMPORTs an INTERFACE that has an INLINE pragma.
In fact, such a call will not be INLINED since at compile time we do not know
the "program" this module is being compiled for. You are only specifying that
the implementation of an INTERFACE (the MODULE that EXPORTS the INTERFACE)
will INLINE the procedure.

--

                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


======================================================================== 74 ===
Date:    28 Dec 91 18:24:09 GMT
From:    johnh@wheaton.EDU (John Doc Hayward)
Subject: When will 2.0 be available

Earlier I had seen a hint that we would be receiving a Christmas gift of
version 2.0.

When will it be available?  When will the report describing it be available?
I have used Modula-3 in my last two Data Structures courses and am going to
be using it this next term as well.  I would like to get things installed and
up and running in advance of the start of the term (Jan 13th).

Thanks in advance.
johnh...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=
UUCP: johnh@wheaton.uucp           telephone: (708) 752-5871 (office)
Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187
       Act justly, love mercy and walk humbly with your God. Micah 6:8b


======================================================================== 75 ===
Date:    30 Dec 91 15:25:18 GMT
From:    hudson@cs.umass.edu (Rick Hudson)
Subject: Re: Using the INLINE pragma

In article <1991Dec24.115234.12112@src.dec.com> mjordan@src.dec.com (Mick Jorda
n) writes:
   In article <1991Dec24.161948.18048@bert.pinecreek.com>, harbison@bert.pinecr
eek.com (Sam Harbison) writes:
   > Sam ("One note") Harbison

   > I have in the past taken issue with the "easy" way out of the
   > following inlining situation, so I'll do so again:
   > 
   > 	INTERFACE Int;
   > 	  INLINE PROCEDURE Easy();
   > 	END Int.
   >
   > 	MODULE Client;
   > 	  IMPORT Int;
   > 	BEGIN
   > 	  Int.Easy();	(* Should/will this be in-lined? *)
   > 	END Client.
   > Mick Jordan (I think) makes no claims about this case. (That's OK.)
   > Rick Hudson suggests inlining *never happens*. I hope Modula-3

Actually I didn't mean to suggest it didn't happen, all I meant was that
adding INLINE to an interface wasn't enough, as you indicate.

   > implementors try to be sophisticated in this case, or else:
   >  - the C mavens will forever be harping about macros,
   >  - the C++ folk will be trying to get us to put bodies in interfaces, and
   > - the Ada poeple will think that Modula-3 is a toy 

I suspect INLINE is needed more in M3 than Ada since methods might tend to be
short and imported.

   Mick Jordan -
   The Olivetti M3 implementation was designed to behave essentially as the ADA
 world,
...
   My proposal does indeed require implementors to be sophisticated because it 
does not permit
   knowledge of a particular implementation's inline characteristics to propaga
te into 
   the interface. This seems correct if not, perhaps, pragmatic. But it is near
ly 1992 and,
   as the Ada community has demonstrated, it is possible.


The real issue being raised here is what the concept of a "program" and
"compilation" means. A "program" is defined on pg 42 of Nelson's book. The
book however doesn't define, nor should it, what compilation is and the
relationship between compilation and a program. A good argument could be made
that one needs the program prior to "final" code generation and optimization.
We haven't decided how to handle it with the UMass compiler (yet) but do
recognize the need to do INLINE. 


--

                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


