======================================================================== 1 === Date: Mon, 2 Dec 91 16:02:17 -0500 From: Norman Ramsey 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 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: 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: 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 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 '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 Newsgroups: comp.lang.modula3 Subject: Word of caution using sockets in m3 Summary: References: <95205@brunix.UUCP> 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: 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 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 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 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 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 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 , 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 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, || Mark Craig Carroll: ||"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, 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 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: 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 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@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 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 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@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 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("")' 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: 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@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