Date: Sun, 02 Jun 91 12:56:03 PDT From: harbison@bert.pinecreek.com Subject: RAISES in Fmt.F Under certain circumstances the Fmt.F routine raises the exception FFailed, but since Fmt.F includes a "RAISES {}" clause, a run-time error ensues. Sam Harbison Pine Creek Software; 305 S. Craig St., Suite 300; Pittsburgh, PA 15213 +1 412 681 9811; harbison@bert.pinecreek.com ------------------------------------------------------------------------------ Date: Wed, 5 Jun 91 10:32:15 EDT From: wyant@saber.com Subject: garbage collection and fast allocation/deallocation This may have been discussed before, so pardon me for raising it again if it has been. It has been observed that allowing the user to write specialized allocators and deallocators for classes of objects that share similiar lifetimes can improve performance. Mesa and Cedar supported this with the notion of 'zones'. Lisp environments have something similiar; and C++ allows on e to overloadthe 'new' and 'free' operators to provide type-specific allocator s/deallocators. I don't see such support in Modula-3. I guess my question to the Modula-3 designers would be: is the trend to move away from such mechanisms and have mor e intelligent garbage collectors (generational or temporal). Has anyone found this to be a problem in developing Modula-3 applications. Not having seen Trestle, how has garbage collection interacted with the need to create lightweight UI objects fairly rapidly ? Any studies on this ? Ever curious (in more then one sense :-)) Geoff Wyant wyant@saber.com ------------------------------------------------------------------------------ Date: Wed, 5 Jun 91 10:45:18 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: garbage collection and fast allocation/deallocation In article <9106051432.AA22607@riposte>, wyant@saber.com ask about specialized allocators and deallocators. The Modula-3 language does not offer direct support for that. However, in SRC Modula-3, the runtime is written in Modula-3 and we give the source. In particular, the interfaces RTHeap and RTHeapRep, and the module RTHeap that implements them, are concerned with traced heap management. There is nothing that prevents a program from using an alternative implementation of RTHeap. This implementation could treat the allocation requests differently based on the typecode of the referent to allocate. It could also receive hints from the program, also based on typecodes. It is also conceivable to use the current system for some typecodes, and another one for other typecodes. The current collector would not support very well 'free' methods, as detecting the deallocated objects would imply a sweep of the heap. -- Eric. ------------------------------------------------------------------------------ Date: 5 Jun 91 17:02:21 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: garbage collection and fast allocation/deallocation Well, we're working on a pretty flexible (and we trust fast) generational collector for our Modula-3 system, and making good progress. Allowing user defined allocators would be complex, and I'm not sure it would be all that much help (with the obvious exception of user written routines for managing the UNTRACED area(s)). We may extend our collector to support finalization, but that would be a ways down the road. Eliot -- J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ------------------------------------------------------------------------------ Date: Mon, 10 Jun 91 22:04:48 -0400 From: Dave Hanson Subject: STextTable bug? is the outcome below a bug in STextTable? it appears to me that STable compares keys with NIL and that TexT.Compare no longer accepts NIL arguments (did it ever?). or perhaps i've made some (obvious) error in using STexTTable? elan 344 cat Main.m3 MODULE Main; IMPORT STextTable; VAR tab := STextTable.New(); count: REF INTEGER; BEGIN count := NEW(REF INTEGER); count^ := 1; EVAL STextTable.Put(tab, "foo", count) END Main. elan 345 m3 Main.m3 -lm3data elan 346 a.out M3 runtime error: Text.Compare: NIL argument Quit (core dumped) elan 347 ------------------------------------------------------------------------------ Date: Tue, 11 Jun 91 08:22:44 PDT From: Subject: Re: STextTable bug? Yes, it's a bug in STextTable. It calls Text.Compare with NIL arguments. The language report specifies that passing NIL to any procedure in the Text interface is a checked runtime error. Early releases of SRC Modula-3 didn't adhere to this piece of the specification. Version 1.6 does. We'll fix STextTable for the next release. Thanks for the bug report. - Bill Kalsow ------------------------------------------------------------------------------ Date: Tue, 11 Jun 1991 17:41:06 PDT From: David Goldberg Subject: Re: STextTable bug? This bug has been addressed earlier: Date: Mon, 1 Apr 1991 18:00:12 PST From: muller@src.dec.com (Eric Muller) Subject: SRC-M3 1.6: bug in STextTable. To: modula3.parc@xerox.com Norman Ramsey and David Golberg reported that STextTable sometime fails with a runtime error in Text.Compare. The Text module now implements its interface properly, i.e. it complains when a NIL Text.T is passed to one of the Text routines. Unfortunately I failed to modify all the clients of Text so that they do not call Text.xxx with a NIL Text.T. Here is a version of STextTable.Compare that will do the right thing: PROCEDURE Compare (arg: REFANY; key1, key2: STable.Key): INTEGER = BEGIN IF key1 = NIL THEN key1 := ""; END; IF key2 = NIL THEN key2 := ""; END; RETURN Text.Compare (key1, key2) END Compare; Thanks to Norman and David for reporting this bug. -- Eric. ------------------------------------------------------------------------------ Date: Thu, 13 Jun 91 13:50:45 EDT From: wyant@saber.com Subject: M3 Mode for emacs ? Does anyone have a good M3 mode for emacs ? If not I suppose I could adapt exisiting M2 mode. -- Geoff Wyant wyant@saber.com ------------------------------------------------------------------------------ Date: Thu, 13 Jun 91 12:07:45 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: M3 Mode for emacs ? In article <9106131750.AA14797@riposte>, wyant@saber.com writes: > Does anyone have a good M3 mode for emacs ? > If not I suppose I could adapt exisiting M2 mode. Here is archie's answer: Host iamsun.unibe.ch (130.92.64.10) Last updated 05:06 7 May 1991 Location: /emacs FILE rw-r--r-- 31947 May 30 1990 modula3.el Eric. ------------------------------------------------------------------------------ Date: Fri, 14 Jun 91 12:11:39 PDT From: muller@src.dec.com (Eric Muller) Subject: New organization of SRC Modula-3 This article is my proposal for the organization of future releases of SRC Modula-3. Please read it and post your comments so that we can achieve a satisfactory release mechanism. There are three main goals for the new organization. The first goal is to break the distribution in smaller pieces. The current release is monolithic, and this limits the rate of evolution. In the new scheme, we would like to have library components (and program components) that can be released independantly. This will become very useful as some libraries and programs are now stable, while others will evolve much faster. The second goal is to make as few assumptions as possible about the underlying operating system. For example, the current release makes heavy use of symbolic links and the distribution itself has some; also we have not been very careful about file name length and such things. The third goal is to make the imake machinery available to all Modula-3 users. Imake provides a simple and portable mechanism to write descriptions of software systems, leaving out most (if not all) the details that depends on the architecture and the site configuration. The motivation here is to have Imakefile that are portable, so as to facilitate the exchange of Modula-3 software. SOURCE GROUPS A source group is small collection of related interfaces and modules. For example, the rd group contains the Rd, UnsafeRd and RdClass interfaces and the RdRep module. Another example is the Cstd group that contains the Modula-3 translations of the ANSI-C standard include files. Source code that differs for different architectures, will go in separate groups. For example, the Csetjmp interface (the counterpart of the setjmp.h ANSI-C standard include file) depends on the architecture. In this case, we would have one group for each kind of architecture, with the appropriate version of Csetjmp in each. The group Cstd.generic would contain Cstdlib.i3 (which is architecture-independant), and the groups Cstd.{VAX,DS3100,SPARC,...} would each contain the appropriate version of Csetjmp.i3. Another case to consider is when "architecture" is too fine grained. For example, the implementation of Random.Real depends on the representation of floating point numbers and we have two versions today: for VAX-like machines and for IEEE machines. To minimize the maintenance headache, we would like to have only two groups instead of one for each architecture. So we would have the group random.generic with the interface Random and the module Random that implements all of Random but the function Real; random.IEEE with the module RandomIEEE that implements just Random.Real, for IEEE machines; and random.VAX with the module RandomVAX that implements just Random.Real, for VAX-like machines. Each source group has an Imakefile, which describes the contents of the group; for example: rd/Imakefile: public_interface (Rd) public_interface (UnsafeRd) public_interface (RdClass) implementation (RdRep) Cstd.VAX/Imakefile: public_interface (Csetjmp) Cstd.DS3100/Imakefile: public_interface (Csetjmp) Here is an initial set of possible entries in these Imakefiles: interface (i) # Modula-3 interface in i.i3 implementation (m) # Modula-3 module in m.m3 module (m) # = interface (m) + implementation (m) public_interface (i) # = interface (i) + make it available in /proj/m3./pub public_module (m) # = public_interface (m) + implementation (m) C_object (c) # C source file in c.c S_object (s) # assembly source file in s.s lib_export (f) # make f available in /proj/m3./lib man_page (p,s) # man page f.man in section s These Imakefiles can also contain values for the Modula-3 and C compilation flags: M3FLAGS = CFLAGS = Whenever source files in this group are compiled, are passed to the m3 driver. Similarly for C files with . LIBRARY AND PROGRAM GROUPS To build a program or a library, one collects the source files from a bunch of source groups, compiles and combines them. Each program or library has its own source group with at least an Imakefile which mentions the source groups it should be built from. For example, the Imakefile for the libm3 group (the equivalent of the today's libm3core library) is: group (fmt) group (scan) group (coreos.ARCHITECTURE) group (float) group (main) group (runtime) group (text) group (thread) group (time) group (word) group (Cstd.generic) group (Cstd.ARCHITECTURE) group (Csupport) group (Csupport.ARCHITECTURE) #if defined (IBMRT) || defined (AIX386) || defined (UMAX) group (Csupport.strtod) #endif group (convert.generic) #if defined (ARM) || defined (HP300) || defined (AIX386) || defined (IBMR2) group (convert.int) #else group (convert.address) #endif library (libm3) 'group (foo)' means that the objects obtained from the compilation of the sources in the source group 'foo' are to be part of the library. 'library (libm3)' means put the collected objects in libm3.a. A few symbols are defined by the templates so that it is easy to conditionalize selection of a group by architecture: VAX, IBMRT, ... defined if the current architecture is Vax, IBM-RT, ... ARCHITECTURE the architecture name (e.g. VAX, IBMRT) UNIX the name of the Unix interface library (e.g. ultrix-3-1) HAVE_X11R4 defined if X11R4 is installed on the system LIBXAW, LIBXMU the names of the corresponding X libraries LIBXEXT LIBXT LIBX11 This list of symbols is not exhaustive. New names will be added as the need occurs. The Imakefile for a program is very similar to that of a library; the main difference is that the last line reads 'program (pgm, )'. There is the relatively common case of simple programs for which it would be overkill to have separate source and program groups. For example, the tetris program is made of only one module. In that case, there would be one group with the following Imakefile: tetris/Imakefile: LIBS = -lm3misc \ -lm3Xaw -lm3Xt -lm3X11 \ # Modula-3 binding libraries to X LIBXAW LIBXMU LIBXEXT LIBXT LIBX11 # actual X libraries implementation (tetris) program (tetris, $(LIBS)) The groups we have described so far are all sources only. Note that the organization is very simple: a group just contains a bunch of files, no subdirectories. The collection of groups is not organized in any particular way. This should make the mapping of groups to file system easy on any machine. DERIVED GROUPS For each library or program group, there will be a derived group for each configuration (that is, those that are available at the site). These derived groups contain an automatically-generated makefile, the intermediate objects that result from the compilation of the source files, and the resulting library or program. "Configuration" in the first sentence means "architecture with compilation switches". For example, one could have the libraries compiled with debugging info for DS3100, compiled with optimization for DS3100, compiled with debugging info for VAX. The makefile in derived groups allows to build the library or program, as well as the man pages and other derived files, to install them using the site template to determine where to install. EXAMPLE Let's see what are the groups and their contents for the current libm3io library: source: autoflushwr Imakefile AutoFlushWr.i3 AutoFlushWr.m3 pickles Imakefile Pkl.i3 Pkl.m3 libm3io ; or m3io or io ? Imakefile derived: libm3io.DS3100.g ; compiled for debug makefile AutoFlushWr.io AutoFlushWr.mo Pkl.io Pkl.mo libm3io.a libm3io.ma lim3io.DS3100.O2 ; compiled optimized ... SRC MODULA-3 We have now reached the limits of the current release scheme; in particular, adding say 5 new architectures will make the whole thing just too complex to be reliable. The release will be broken in the following pieces: - bootstrap: imake + templates + example site templates, compiler and driver for bootstrap. One piece for each architecture. Contains the compiler and the driver in C (intermediate files). These pieces are intended for bootstrap only and therefore can be extremely simple, thus make boostrap very easy. Probably one directory for each program with all the necessary C files, so that compilation can be as simple as "cc -o m3compiler *.c". - for each library and program (including the compiler): source groups for that library or program. -- Eric. ------------------------------------------------------------------------------ Date: 18 Jun 91 15:26:47 GMT From: liam@dcs.qmw.ac.uk (William Roberts;) Subject: M3 using gcc, anyone? I'm trying to build version 1.6 of Modula-3 with the following configuration: Sun 3, SunOS 4.1.1b, gcc 1.39. It built fine with the native Sun C compiler, but won't build with gcc - the m3compiler crashes. I haven't had much luck with the debuggers either. Has anyone ported 1.6 to use gcc on any architecture? Any suggestions about an architecture-specific thing that is so subtle it could differ between different compilers on the same machine? My goal, incidentally, is to bring up Modula-3 under Apple's version of UNIX (A/UX) on our Mac II and IIcx machines. -- % William Roberts Internet: liam@dcs.qmw.ac.uk % Queen Mary & Westfield College UUCP: liam@qmw-dcs.UUCP % Mile End Road Telephone: +44 71 975 5234 % LONDON, E1 4NS, UK Fax: +44 81-980 6533 ------------------------------------------------------------------------------ Date: 19 Jun 91 04:05:47 GMT From: lambert@unix.cis.pitt.edu (Michael H Lambert) Subject: Re: M3 using gcc, anyone? In article <3383@redstar.dcs.qmw.ac.uk> liam@dcs.qmw.ac.uk (William Roberts;) w rites: > >I'm trying to build version 1.6 of Modula-3 with the following configuration: >Sun 3, SunOS 4.1.1b, gcc 1.39. > >It built fine with the native Sun C compiler, but won't build with gcc - the >m3compiler crashes. I haven't had much luck with the debuggers either. > >Has anyone ported 1.6 to use gcc on any architecture? Any suggestions about an >architecture-specific thing that is so subtle it could differ between >different compilers on the same machine? > > ... I was able to build version 1.6 of Modula-3 on a DECstation 3100 (RISC) using gcc. The OS was Ultrix 3.1. I used gcc with the patches from the Open Software Foundation. At the moment, I don't recall whether I used version 1.37.1 or version 1.39. I do know that I did not use OSF version 1.39.9, the latest, as the compilation of Point.m3 leads to an internal compiler error. I haven't tried debugging M3 code, either with gdb or dbx. One additional point: it seemed necessray to configure the M3 build to use the standard C preprocessor (/lib/cpp) rather than the GNU preprocessor. The GNU version occasionally exhibits strange behavior (at least I don't understand it) when fed something other than C input. Michael H. Lambert +1 412 268-7037 Pittsburgh Supercomputing Center lambert@psc.edu ------------------------------------------------------------------------------ Date: 19 Jun 91 17:21:03 GMT From: sinner@csd4.csd.uwm.edu (Ken E Sinner) Subject: Where are SRC sources? Where can I get the SRC sources by anonymous ftp? I would need the domain address and the directory? Thanx. ken ------------------------------------------------------------------------------ Date: 20 Jun 91 03:59:34 GMT From: n8243274@gonzo.cc.wwu.edu (steven l. odegard) Subject: Modula3 compiler to 8088 native code I am researching the feasibility of generating a modula-3 compiler for 8088 nat ive code. The main reason for this is to gain programming control over my own personal XT turbo. This wi ll be a summer project which I would release for a nominal fee on the Shareware concept. However, on researching the feasibility of this, I came across the book describ ing program verification as a development methodology. (Sorry I don't have the title to the book yet). Essentially, the specification is machine-checked for inconsistencies, and the code is deveolope d to the specification and mechanically verified to prove consistency. Realizing this technique, I have t emporairly abandoned the original project to explore the possibilities of incorperating these techniques in the specification to modula-3 that I will employ. I love the pragma syntax! I believe extended pragmas will work nicely to imple ment a version of the stanford verifier. I am also interested in incorporating all of this into a CA SE (Computer Assisted Software Engineering) implementation. I believe that a well-developed machine- assisted programming methodology can be implemented without a graphical user interface, and result i n a four to eightfold productivity increase. (My personal experience was a threefold increase of pro ductivity after learning and regularly employing the module interfacing technique of Modula-2.) If anyone wishes to provide suggestions or direct me to current research on the se issues, I would be most greatful. Please post mail to n8243274@henson.cc.wwu.edu. --Steven Lee Od egard PS Is there an effort to post the march91, april91, and may91 news summaries t o comp.lang.modula3 in gatekeeper.dec.com? ------------------------------------------------------------------------------ Date: Thu, 20 Jun 91 14:00:59 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: Where are SRC sources? > Where can I get the SRC sources by anonymous ftp? > I would need the domain address and the directory? Below is the annoucement for SRC Modula-3 1.6. Please note that this version implements the language described in the SRC Report #52. Since that report, the language has been slightly modified (by the so-called "Twelve Changes"). The book "System Programming with Modula-3" describes the modified language. We are working on a new release that implements those changes. SRC Modula-3 ------------ A new release, version 1.6, of the SRC Modula-3 compiler and runtime are available now (March 28, 1991). This is the fourth public release of SRC Modula-3. The system was developed at the DEC Systems Research Center. It is being distributed in source form (mostly Modula-3) and is available for public ftp. You must have a C compiler to build and install the system. NEW IN THIS RELEASE ------------------- The primary changes since version 1.5 are: - many bugs are fixed (in particular, installation bugs) - additional library modules (more U**X bindings, pickles) - it is easier to build shared libraries (by default on IBMR2) - the system was ported to: SUN3 running SunOS Encore Multimax running UMAX 4.3 (R4.1.1) Acorn R260 running RISC iX 1.21 in addition to the previous ports: Apollo DN4500 running Domain/OS, IBM PC running AIX/PS2, IBM RT running IBM/4.3, IBM R6000 running AIX 3.1, HP 9000/300 running HP-UX 8.0 VAX running Ultrix 3.1 DECstation 3100 and 5100 running Ultrix 3.1 SPARCstation running SunOS 4.0.3 DISTRIBUTION ------------ The system is available: - via anonymous ftp from 'gatekeeper.dec.com' [16.1.0.2], - via uucp from decwrl - via Easynet from DECWRL The SRC Modula-3 files are in '/pub/DEC/Modula-3'. Those files include: % ls -R README m3-1.6 report comp.lang.modula3 comp.lang.modula3: README aug90.Z dec90.Z feb91.Z jan91.Z jun90.Z may90.Z oct90.Z apr90.Z dec89.Z feb90.Z jan90.Z jul90.Z mar90.Z nov90.Z sep90.Z m3-1.6: README dist-1.6.tar.Z-02 dist-1.6.tar.Z-05 dist-1.6.tar.Z-08 dist-1.6.tar.Z dist-1.6.tar.Z-03 dist-1.6.tar.Z-06 dist-1.6.tar.Z-09 dist-1.6.tar.Z-01 dist-1.6.tar.Z-04 dist-1.6.tar.Z-07 report: README Report.ps.Z Report1.ps.Z Report2.ps.Z Report3.ps.Z The compressed tar file m3-1.6.tar.Z is about 4.6Mbytes. The entire system requires about 35Mbytes of disk space to build and install. The system is also available via semi-anonymous UUCP from the Computer and Information Science Department at Ohio State University, osu-cis (there may be a small delay between the avaibility from the above sources and the avaibility from osu-cis). The files are in the directory '~/m3'. Here is a set L.sys or Systems file lines suitable for contacting osu-cis via UUCP: # # Direct Trailblazer # osu-cis Any ACU 19200 1-614-292-5112 in:--in:--in: Uanon # # Direct V.32 (MNP 4) # dead, dead, dead...sigh. # #osu-cis Any ACU 9600 1-614-292-1153 in:--in:--in: Uanon # # Micom port selector, at 1200, 2400, or 9600 bps. # Replace ##'s below with 12, 24, or 96 (both speed and phone number). # osu-cis Any ACU ##00 1-614-292-31## "" \r\c Name? osu-cis nected \c GO \d\r\d\r \d\r in:--in:--in: Uanon For information about acquiring Modula-3 by other means, please write to Pine Creek Software 305 South Craig St. Suite 300 Pittsburgh, PA 15213 CONDITIONS ---------- SRC Modula-3 is not a Digital Equipment Corporation product. It is a research work which is provided ``as is''. We do not promise to fix bugs, but we will try. SRC Modula-3 is available without signing any license agreements. If you chose to sign the commercial license, you will be able to use SRC Modula-3 commercially. See the documents that are included in the release for more information. WHAT IS SRC MODULA-3 ? ---------------------- 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. KEEPING IN TOUCH ---------------- If you want to communicate with other Modula-3 users, you can post articles to the comp.lang.modula3 Usenet newsgroup. If you do not have access to this newsgroup, you can send a message to m3-request@src.dec.com to be added to the relay mailing list. Messages sent to m3@src.dec.com are forwarded to the newsgroup and to the members of the relay mailing list. If you want to communicate with us, please send your message to m3-request@src.dec.com We may also be reached at: Systems Research Center 130 Lytton Avenue Palo Alto, CA 94301 Enjoy, Bill Kalsow and Eric Muller REFERENCES ---------- [1] The Modula-3 Report (Revised), L. Cardelli, J. Dohnaue, L. Glassman, M. Jordan, B. Kalsow, G. Nelson, DEC Systems Research Center, Palo Alto, CA and Olivetti Research Center, Menlo Park, CA, Nov 89. VAX, DECstation and ULTRIX are registered trademarks of Digital Equipment Corporation. Unix is a registered trademark of AT&T Corporation. SPARC and SunOS are trademarks of Sun MicroSystems. Apollo and Domain/OS are trademarks of Apollo. IBM and AIX are registered trademarks of International Business Machines Corporation. RT and PS/2 are trademarks of International Business Machines Corporation. HP, HP9000 and HP9000/300 are trademarks of Hewlett-Packard Company. HP-UX is Hewlett-Packard's implementation of the Unix operating system. PostScript is a registered trademark of Adobe Systems Incorporated. ------------------------------------------------------------------------------ Date: Fri, 21 Jun 91 10:28:12 PDT From: muller@src.dec.com (Eric Muller) Subject: archive of comp.lang.modula3 for March, April and May available The articles posted to comp.lang.modula3 during the months of March, April and May 91 are availabe via anonymous ftp on gatekeeper.dec.com, in 'pub/DEC/Modula-3/comp.lang.modula3/{mar,apr,may}91.Z'. Previous months are also available there. Eric. PS: Sorry for the delay in updating the archive. I'll try to do a better job in the coming months. ------------------------------------------------------------------------------ Date: Fri, 21 Jun 91 13:51:17 PDT From: muller@src.dec.com (Eric Muller) Subject: why not Wr.T <: MUTEX ? How come that "Every writer is a monitor" is stated in the description of the Wr interface [System Programming with M3, p132], but that we are just told TYPE T <: ROOT and have no access to this monitor from the Wr interface ? Suppose that I have a Wr.T and I want to print the two texts t1 and t2 on it, and be sure that t1 and t2 are one just after the other in the writer. I would like to avoid Wr.PutText (wr, t1 & t2) as this can be expensive. How I am supposed to do that ? It is ok to import WrClass and to WrClass.Lock (wr) ? -- Eric. ------------------------------------------------------------------------------ Date: 24 Jun 91 08:31:58 GMT From: collberg@dna.lth.se (Christian S. Collberg) Subject: Modula-3 Report -- Where? I have the Revised Modula-3 Report (Nov 1989) from Olivetti, but there are a few pages missing (27,30,31,34). This is fairly annoying and I would like to get hold of a complete copy. Is there a newer report available? If so, where from? An ftp location would be ideal. Thanks! Christian -------------------------------------------------------------------- Christian.Collberg@dna.lth.se Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden -- -------------------------------------------------------------------- Christian.Collberg@dna.lth.se Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden ------------------------------------------------------------------------------ Date: 24 Jun 91 12:35:02 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Modula-3 Report -- Where? The latest version of the Report (which is unfortunately not quite up-to-date with the language (you also need the document "Twelve Changes to Modula-3")) is available on gatekeeper.dec.com in pub/DEC/Modula-3/report/Report.ps.Z, a compressed PostScript file. Be sure to retrieve in binary, then uncompress and print on a PostScript printer. If the file is too large for you to handle in one shot, it is also broken into three pieces in that same directory. The 12 Changes document was sent out to the mailing list and newsgroup about six months ago, and should be in the archives. I understand that these changes are reflected in the language as described in the book edited by Greg Nelson, Systems Programming with Modula-3 (I may not have the exact title, but it's close; perhaps Greg or someone could post ordering info for the book again, etc.) -- J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ------------------------------------------------------------------------------ Date: Mon, 24 Jun 1991 18:06:21 GMT From: janssen@parc.xerox.com (Bill Janssen) Subject: Re: New organization of SRC Modula-3 Would you be so kind as to compare and contrast the M3 `imake' with the X Window System `imake'? I seem to be doing a lot of work with the latter (that is, many packages are showing up that use it), and I'd hate to get involved with a different but similar system that used the same name. Bill -- Bill Janssen janssen@parc.xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304 ------------------------------------------------------------------------------ Date: Tue, 25 Jun 91 13:32:57 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: New organization of SRC Modula-3 In article <1991Jun24.180621.19438@parc.xerox.com>, Bill Janssen asks: > Would you be so kind as to compare and contrast the M3 `imake' > with the X Window System `imake'? I seem to be doing a lot of > work with the latter (that is, many packages are showing up that > use it), and I'd hate to get involved with a different but similar > system that used the same name. The 'imake' for M3 is the same as the 'imake' for X11. The big difference is in the templates. The goal is to have Imakefiles that are as descriptive as possible (by opposition to imperative), so that we can avoid the some of the troubles that people have with X Imakefiles. In any case, the executable 'imake' will be hidden in Modula-3 library directories, and the 'public' executable will be 'm3make'. -- Eric. ------------------------------------------------------------------------------ Date: 26 Jun 91 19:50:41 GMT From: janssen@parc.xerox.com (Bill Janssen) Subject: Re: New organization of SRC Modula-3 And the Andrew folks think that they have solved the world's problems, as well, with *their* own set of Imake templates. Can one specify in an Imakefile the "template standard" which it is written to conform to? This reminds me of DTDs in SGML... Bill -- Bill Janssen janssen@parc.xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304 ------------------------------------------------------------------------------ Date: 26 Jun 91 22:07:26 GMT From: schwartz@groucho.cs.psu.edu (Scott Schwartz) Subject: Re: New organization of SRC Modula-3 janssen@parc.xerox.com (Bill Janssen) writes: And the Andrew folks think that they have solved the world's problems, as well, with *their* own set of Imake templates. And the InterViews folks have *their* own set, and so on and so on and so on. Doesn't it seem like Imake is the C++ of configuration tools? ------------------------------------------------------------------------------ Date: Wed, 26 Jun 91 16:07:08 PDT From: kjones@src.dec.com (Kevin Jones) Subject: Report on Larch/Modula-3 interface language available A report describing a Larch/Modula-3 interface language is now available from SRC. Author: Kevin D. Jones Title: LM3: a Larch/Modula-3 interface language Report No: 72 Abstract: This report describes a Larch interface language (LM3) for the Modula-3 programming language. LM3 is a complete example of a Larch interface language and addresses areas previously ignored in interface language definition, such as the specification of non-atomic procedures and object types. We give a complete definition of the syntax and illustrate it with some straightforward examples. We also give translation functions from LM3 specifications to Larch Shared Language traits and show their use for type checking. Finally, we present example specifications of standard Modula-3 interfaces. SRC Reports can be obtained from: Digital Equipment Corp., Systems Research Center, 130 Lytton Avenue, Palo Alto, CA 94301 or by sending mail to src-report@src.dec.com For those unfamiliar with Larch, a potted description: The Larch Project is developing tools and techniques to aid in the productive application of formal specifications. A major component of the project is a family of specification languages. These languages are used to write specifications that describe aspects of software components. They are written primarily to provide precise easy-to-read documentation of interfaces. This documentation facilitates system design, integration, and maintenance, and encourages reuse of components. Each Larch specification has components written in two languages: one designed for a specific programming language and another common to all programming languages. We call the former Larch interface languages, and the latter the Larch Shared Language (LSL). An interface specification describes the interface that a program component provides to clients (implementers of programs that use the component). Each interface specification is built on an auxiliary specification, which provides a notation that allows one to express the interface specification succinctly and precisely. An interface specification is always dependent on the programming language. Auxiliary specifications are not. (Guttag & Horning) ================================================================= = Kevin D. Jones = = = = Digital Equipment Corporation | E-mail: kjones@src.dec.com = = Systems Research Center | Phone: (415) 853 2209 = = 130 Lytton Avenue | = = Palo Alto | = = CA 94301 | = = USA | = ================================================================= ------------------------------------------------------------------------------ Date: Wed, 26 Jun 91 22:32:17 EDT From: lenhart@cs.williams.edu (Bill Lenhart) Subject: Two questions: Generics and code size I have just downloaded and installed version 1.6 of Modula-3 and I have two questions. First, it does not seem to include generics. When will generics be available? Second, I compiled the "Hello World" example from the SRC Modula-3 Version 1.6 document (page 12) WITHOUT the -g option and it's size was 1253376 bytes. After running "strip" it was still 491520 bytes. Isn't this rather large? Pardon the naivete of these questions. -Bill Lenhart Dept. of Computer Science Williams College, Williamstown, Ma, 01267 lenhart@cs.williams.edu ------------------------------------------------------------------------------ Date: Thu, 27 Jun 91 08:28:17 PDT From: Subject: Re: Two questions: Generics and code size The "12 changes" which include generics and were announced last December are not in SRC Modula-3 version 1.6. They will be included in the next release. We're working hard, but it won't be available for at least a month. Yes, "Hello World" is large. It's big for several reasons. The a.out is large because we generate a *large* number of C symbols to make debugging easier and to guarantee consistency between separately compiled modules. The code is large because the C we generate contains "extra" loads and stores that, in principle, an optimizer could remove. We also generate extra procedures to help print objects during debugging. Finally, the fixed runtime is larger than in the C world. Remember, it includes threads, exceptions and a garbage collector. The next release addresses several of these issues. The symbol tables will be smaller. The code will be tighter. And, the runtime will be smaller. We welcome your comparisons and criticisms. Please keep in mind that SRC Modula-3 is not a production quality compiler, it's a research prototype. Hopefully it's useful and will stimulate enough interest in the language to cause second generation, production quality compilers to be produced. Lobby your compiler vendors. > Pardon the naivete of these questions. Today, everyone is a new Modula-3 programmer. No question is naive. - Bill Kalsow ------------------------------------------------------------------------------ Date: Thu, 27 Jun 91 19:49:01 CDT From: psde@crayamid.cray.com (Peter Edwards) Subject: Re: New organization of SRC Modula-3 This looks like the perfect time to ask a couple of dumb questions (-: > And the Andrew folks think that they have solved the world's > problems, as well, with *their* own set of Imake templates. Can anyone recommend some documentation on how to use imake? Not the man page - that doesn't help much in USING an imakefile someone else set up, let alone writing your own. > And the InterViews folks have *their* own set, and so on and so on and What is (are?) InterViews? I've seen mentions before, but never an explanation. Thanks - Hooroo - Peter Cray Research Australia Suite 2.6, 424 St Kilda Rd, Melbourne, Vic 3004 Voice: +61-3-6694389 FAX: +61-3-6694699 (marked c/o SRSU, 4th floor) Internet: psde@cray.com or peter.edwards@cray.com AARNet: psde@burp.ho.bom.gov.au UUCP: ...!uunet!cray!psde Delphi: PSDE ------------------------------------------------------------------------------