======================================================================= 1 === Date: 2 Jan 1994 08:01:37 GMT From: Eric Muller Subject: Re: Quest for Quest |> Does anyone know whether there exists an implementation |> of the Quest language described in this research report: Anonymous ftp to gatekeeper.dec.com:pub/DEC/Quest. -- Eric. ======================================================================= 2 === Date: Sun, 2 Jan 1994 07:44:50 GMT From: aet@munta.cs.mu.OZ.AU (Bert THOMPSON) Subject: Quest for Quest Hi! Does anyone know whether there exists an implementation of the Quest language described in this research report: `Typeful Programming', Luca Cardelli Is Quest similar to Modula3? (I know little about Modula3.) Cheers, Bert. ----------------------------------------------------------------------- bert thompson aet@cs.mu.oz.au. department of computer science university of melbourne ----------------------------------------------------------------------- ======================================================================= 3 === Date: 2 Jan 1994 01:51:52 GMT From: Eric Muller Subject: Modula-3 Frequently Asked Questions (FAQ) Archive-name: Modula-3-faq Last-modified: Sep 9 1993 Modula-3 Frequently Asked Questions =================================== 1. The language 1.1 What is Modula-3? 1.2 Is Modula-3 a superset of Modula-2? 2. The documentation 2.1 Where can I get a description of Modula-3? 2.2 Where can I get other information on Modula-3? 3. The implementations 3.1 Where can I get an implementation? 3.2 What is SRC Modula-3? 3.3 What is m3pc? 3.4 What is GNU Modula-3? 4. Some specific questions 4.1 Why is "Hello World" so large? 4.2 Why objects and interfaces? 4.3 What is the story with Trestle and OpenWindows? 4.4 When is the next release of SRC Modula-3 ? 5. FTP 5.1 What if I don't have ftp access? 6. Contributing 6.1 Can I contribute Modula-3 software? 1.1. What is Modula-3? Modula-3 is a systems programming language that descends from Mesa, Modula-2, Cedar, and Modula-2+. It also resembles its cousins Object Pascal, Oberon, and Euclid. 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 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. 1.2. Is Modula-3 a superset of Modula-2? No; valid Modula-2 programs are not valid Modula-3 programs. However, there is a tool to help convert Modula-2 programs to Modula-3. 2.1. Where can I get a description of Modula-3? The definition of Modula-3 is contained in: System Programming with Modula-3 Edited by Greg Nelson Prentice Hall Series in Innovative Technology ISBN 0-13-590464-1 L.C. QA76.66.S87 1991 also known as SPwM3. Here is the table of contents: 1. Introduction 2. Language Definition 3. Standard Interfaces 4. An Introduction to Programming with Threads 5. Thread Synchronization: A Formal Specification 6. I/O Streams: Abstract Types, Real Programs 7. Trestle Window System Tutorial 8. How the Language Got its Spots Chapters 2 and 3 have been reprinted in Sigplan Notices, Volume 27, Number 8, August 1992, pp 15-42. Sam Harbison has written a more tutorial book about Modula3: Modula-3 Samuel P. Harbison Prentice Hall, 1992 ISBN 0-13-596396-6 The errata sheet is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/errata. 2.2. Where can I get other information on Modula-3? There is a Usenet newsgroup, comp.lang.modula3. The archives of that group are available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/comp.lang.modula3. If you do not have access to Usenet, there is a relay mailing list; send a message to m3-request@src.dec.com to be added to it. There are a couple high-level overview articles available: "Modula-3", Sam Harbison, Byte, Vol. 15, No. 12, November 1990, pp 385+. "Safe Programming with Modula-3", Sam Harbison, Dr. Dobb's Journal, Vol. 17, No. 10, October 1992, pp 88+. A description of the Modula-3 type system is in "The Modula-3 Type System", Luca Cardelli, Jim Donahue, Mick Jordan, Bill Kalsow, Greg Nelson, Conference Record of the Sixteenth Annual ACM Symposium on Principles of Programming Languages (POPL), Austin Texas, January 11-13 1989, pp 202-212. The Trestle window system toolkit, higher-level FormsVBT toolkit, and Zeus animation system available with Modula-3, are documented in the following reports: "Trestle Reference Manual", Mark S. Manasse and Greg Nelson, SRC Research Report 68, December 1991. "Trestle Tutorial", Mark S. Manasse and Greg Nelson, SRC Research Report 69, May 1, 1992. "VBTkit Reference Manual: A toolkit for Trestle", edited by Marc H. Brown and James R. Meehan. (soon to be a SRC Research Report) A draft version is available via anonymous FTP from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/vbtkit.25Mar93.ps.Z. "The FormsVBT Reference Manual", Marc H. Brown and James R. Meehan, (soon to be a SRC Research Report). A draft version is available via anonymous FTP from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/formsvbt.25Mar93.ps.Z and pub/DEC/Modula-3/contrib/formsvbt.AppC.26Mar93.ps.Z. "Zeus: A System for Algorithm Animation and Multi-View Editing", Marc H. Brown, SRC Research Report 75, February 28, 1992. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-075*.ps.Z. "Color and Sound in Algorithm Animation", Marc H. Brown and John Hershberger, SRC Research Report 76a, August 30, 1991. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-076a*.ps.Z. "The 1992 SRC Algorithm Animation Festival", Marc H. Brown, SRC Research Report 98, March 27, 1993. Available via anonymous ftp from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-098*.ps.Z. Hardcopy versions of these reports can be ordered by e-mail; send your request including a postal mail address to src-reports@src.dec.com. 3.1. Where can I get an implementation? Two implementations are available, SRC Modula-3 and a PC version of it (m3pc). Work is also progressing on GNU Modula-3. As far as we know, implementations are not available for VMS, Macintosh, or Alpha AXP/OSF. 3.2. What is SRC Modula-3? SRC Modula-3 was built by the DEC Systems Reseach Center and is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/release. The current version, 2.11, implements the language defined in SPwM3. There are versions for the following machines: AIX386 IBM PC running AIX/PS2, AP3000 Apollo DN4500 running Domain/OS ARM Acorn R260 running RISC iX 1.21 DS3100 DECstation 3100 and 5000 running Ultrix 4.0 and 4.2 HP300 HP 9000/300 running HP-UX 8.0 HPPA HP 700/800 running HP-UX 8.0 IBMR2 IBM R6000 running AIX 3.1, IBMRT IBM RT running IBM/4.3, NEXT NeXT running ?? OKI Okidata 7300 (i860) running AT&T SVR4.0 SPARC SPARCstation running SunOS 4.1.x SUN3 SUN3 running SunOS SUN386 Sun 386i running SunOS 4.0.1 UMAX Encore Multimax running UMAX 4.3 (R4.1.1) VAX VAX running Ultrix 3.1 SRC Modula-3 includes a user manual, compiler, runtime library, some libraries and a few other goodies (see below). The compiler generates C as an intermediate language and should be fairly easy to port. Except for the very lowest levels of the thread implementation, the entire system is written in Modula-3. 3.3. What is m3pc? m3pc is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/m3pc. From: laszlo@post.ifi.uni-klu.ac.at (Prof.Dr.Laszlo BOESZOERMENYI) Subject: M3 pn PC Date: 8 Mar 1993 13:13:52 GMT The Modula-3 system ported by us on the PC and available on the gatekeeper, runs with MSDOS, gnu c compiler and djgpp memory manager (detailed description in the read me file). You may compile, link and run Modula-3 programs, without threads. From the library modules only those are tested which are used by the compiler. In the course of a student project a "student-friendly" environment is in development. It will be available at end of June (hopefully). 3.4. What is GNU Modula-3? From: moss@cs.cmu.edu (Eliot Moss) Subject: GNU Modula-3 alpha release status Date: 25 Mar 93 17:53:12 GMT We said we'd try to get the initial (alpha) release of GNU Modula-3 out some time this month (March), and we're in the process of figuring out what to release and how to package it up. We expect to have something in roughly two weeks (watch this space for a notice). What would this be? First, it is a compiler for the VAX (only) under Ultrix (only), definitely without threads, and probably still failing a small number of the tests in the SRC test suite (which implies that not all of libm3 is likely to work either). The actual release information will detail more about what's working and what's not at that time. We DO currently pass all the compiler tests that the SRC compiler did when it was first released (i.e., the ones we fail are more obscure things that users uncovered over time). Second, the release itself will be a compressed tar file including sources and executables. The executables will probably work only if you put libraries, etc., in the expected places (otherwise, you'll need to rebuild from sources).The compiler is written in C and should be compiled with a recent version of gcc (so you'll need gcc installed). The system also uses gld (the GNU linker). This release should be most useful to people undertaking ports to other machines and operating systems, since it will give them a head start on understanding the compiler and getting the full system ready. It may be of some use for ordinary programming, but it really depends on whether you tend to use features that tickle the remaining bugs. We are indeed interested in alpha test reports, but only if they tell us something new (i.e., we'll provide a list of known deficiencies). When the release is made, we'll also start email discussions with the various parties who have indicated they might undertake ports, to help sort out who will do what. Regards, and thanks for your continued interest and encouragement -- EM From: moss@cs.cmu.edu (Eliot Moss) Subject: GNU Modula-3 pre-release Date: Wed, 5 May 1993 23:49:33 GMT At long last, the GNU Modula-3 project has a pre-release ready, for the VAX/Ultrix platform ONLY. Various folks had notified us of their interest in doing ports or alpha testing, and they have already been sent email with particulars on how to obtain the tar file, etc. There are a number of known bugs; I'll see about making a list available by ftp or something, for interested parties. It is our opinion that the prerelease is not mature enough for general use, but we wished to give a head start to those folks attempting ports, and we will make periodic patches available. If you want to use this compiler for serious program development or need something solid with debugging support for classroom use, you should wait until we've fixed more of the problems. (But to give a sense of what we HAVE accomplished, as I recall, all but 3 of the SRC compiler tests compile (there are 137 of them).) We hope to do a more general release, and support more platforms, in the summer. If you're interested in helping and have not previously contacted us, please send email to me and/or Rick Hudson (hudson@cs.umass.edu). Thanks to Digital and SRC for supporting us, and to Rick Hudson, Amer Diwan, and Norm Walsh, the guys who do all the hard work! 4.1. Why is "Hello World" so large? Modula-3 programs are larger than C programs for the following reasons: 1) The fixed runtime is substantially larger. It contains a garbage collector, a thread runtime, and exception support. Note that "Hello World" is virtually all runtime. For larger programs the runtime is not an issue. 2) The generated code includes runtime checks for out-of-bound array references and NIL pointer. Many of these checks could be removed by a better compiler. The current compiler is only a research prototype. 3) The compiler generates C code as its intermediate language consequently the final machine code suffers. For example, the compiler is constantly storing single-precision floating point values into memory to get around C's predisposition for double precision. 4.2. Why objects and interfaces? Allan Heydon on comp.lang.modula3, May 4th 1993: Modula-3 provides two separate mechanisms for data-hiding: one for hiding details about how interfaces are implemented, and the other for hiding details about how objects are implemented. The first data-hiding mechanism is realized by the distinction between interfaces and modules. Clients can only import interfaces, so the names declared in the modules implementing those interfaces are hidden from clients. Note that this mechanism has only two levels; a name is either declared in an interface, or it isn't. If a name is only declared in a module, it can't be used by a client. The second data-hiding mechanism is realized by opaque types and revelations. A Modula-3 interface may declare an object type to be opaque, in which case only a subset of the fields and methods of that object are revealed to clients importing the interface. Furthermore, the Modula-3 revelation mechanism allows a designer to reveal successively more fields and methods of an object in a series of interfaces. The fields and methods visible to a client then depends on which interfaces the client imports. The latter mechanism is quite flexible. As opposed to the interface/module data-hiding mechanism, opaque types allow you to define an arbitrary number of levels at which more and more information about the implementation of your object is revealed. See Sections 2.2.10, 2.4.6, and 2.4.7 of "Systems Programming with Modula-3" for more information about opaque types and about partial and complete revelations. 4.3. What is the story with Trestle and OpenWindows? Mark Manasse says: I think that the OpenWindows release should be enough (no need to get the MIT X release], although there are a few things in Trestle that trigger devastating bugs in OpenWindows. But the only library we depend on is Xlib, R4 or later. The main thing I know that crashes OW 2.0 is the code where we call GrabKey specifying AnyKey. You can either loop over all of the keys, or you can just comment out the call; programs won't run exactly the same, but you probably won't notice the difference. 4.4 When is the next release of SRC Modula-3 ? The next release will be 3.0. Here are some of the new things you will find in it: 1. the compiler has a new internal interface between the front-end and the back-end, M3CG. This interface is supposed to be easy to implement. 2. the front-end can compute in the target arithmetic system; in particular it is possible to cross-compile to machines with larger integers than the host. 3. one back-end has been implemented on top of gcc. The implementation of M3CG interface generates the tree representation used internally in gcc. From the gcc point of view, this back-end looks like a new front-end. Using this back-end, we have cross-compiled solitaire for mips, alpha and 386 processors; there is no reason to believe that there would be a problem for the other architectures supported by gcc. 4. Dave Hanson wrote another implementation of the M3CG that is self-contained. He is currently working on the 386 code generation (he has done the mips code generation already). 5. gdb has been modified to understand Modula-3 debugging information produced by the back-ends. gdb can now parse Modula-3 expressions, print Modula-3 values and evaluate some of the Modula-3 built-in operations. There is also a little bit of support for multi-threaded programs (you can look at the stacks of other threads). 6. there is a replacement for m3make, m3build, that does not rely on cpp/awk/sed/make and what not, and removes some of the limitations of m3make. m3makefiles are very similar. 7. libm3 has been significantly changed by the Interface Police, mostly in the area of OS interfaces and data structures. 8. for the OS interfaces, we still have the U* interfaces, but applications are not supposed to use those. Instead they should use a new set of interfaces that are os-independent; for example, there is a Pathname interface that manipulates file names; there is a Process interface that manipulate child processes. These interfaces enabled a prototype port of the C based version to Windows NT machines. 9. for the data structures, generics have been introduced and the various data structures are more consistent. 10. because of 6 and 8, we can think about going to different os than Unix. In particular a Windows NT port will be available at some point (may not be in 3.0). 11. the runtime has been improved quite a bit. 12. new platforms: Alpha running OSF/1, 386 running Linux. We will pay more attention to the porting instructions and support. 13. I am not sure about all the changes in the libraries other than libm3. I suspect that there will be few changes in trestle, but that mentor changed quite a bit. 14. The Windows NT port uses native threads. This should be a good model for other implementations of Thread using native threads. The current status is: . the front-end is very stable . the gcc-based back-end has been stable for 4 months . the gdb extensions are brand new and need some test . the interface police work is very stable . we are working on bringing the system up on the machines we have in the building, and building the export machinery. We don't have a date for the 3.0 release. Given the amount of changes introduced by 3.0, I suspect that the first few releases will not work out of the box for any machine but the ones for which we can test (decstations [mips and alpha], linux). Consequently, I expect a high rate of releases for a while. We will try to post accurate information about the status of each machine, but we can only rely what you tell us. At this point, I would not encourage anybody to start a new port. If you have a new port, or are close to complete one, you can send us your bits, we will try to put them in 3.0. 5.1. What if I don't have ftp access? Unfortunately, we cannot deliver Modula-3 other than by anonymous ftp. Fortunately, Prime Time Freeware (PTF) includes Modula-3. PTF is a set of two ISO-9660 CDroms filled with 3GB of freeware, issued semi-annually. The latest issue, Volume 1, Number 2, July 1992, contains SRC Modula-3 2.07. PTF is distributed via bookstores and mail. You can reach PTF using: Email: ptf@cfcl.com Fax: [1] (408) 738 2050 Voice: [1] (408) 738 4832 Mail: Prime Time Freeware 415-112 N. Mary Ave., Suite 50 Sunnyvale, CA 94086 USA 6.1. Can I contribute Modula-3 software? Certainly. Send us what you are willing to share, be it programs, libraries or other things. We'll put them in the distribution. Right now, the pub/DEC/Modula-3/contrib directory contains: m3rpc an rpc system from Xerox Parc M2toM3 a translator from Modula-2 to Modula-3 m3pc an implementation of Modula-3 for PCs. ---- Eric. -- Eric. ======================================================================= 4 === Date: Tue, 04 Jan 1994 10:42:01 +0100 From: vfrank@vnet3.vub.ac.be (Franklin L. Vermeulen) Subject: Mac Implementation? Hi, I read in the FAQ that there currently is no such thing as a Mac implementation of M3. But is *anybody* have plans in that direction? Thanks -- Franklin L. Vermeulen, Ph.D. Vesalius College, Vrije Universiteit Brussel Pleinlaan 2, B-1050 Brussel (Belgium) Ph: +32 2 641-3493; Fax: +32 2 641-3495; Room 10F735 ======================================================================= 5 === Date: 13 Jan 1994 23:26:57 GMT From: kendall@pot.East.Sun.COM (Sam Kendall - Sun Microsystems Labs BOS) Subject: Re: Beginners Guide to M3 There are only two books on M3 that I know of. One is _Modula-3_ by Sam Harbison, and the other is _Systems Programming with Modula-3_, ed. by Greg Nelson. The first one seems to be the one for beginners, although I haven't looked at it. The second has the language reference manual and other articles. SIGPLAN Notices from August '92 has a copy of the reference manual. Good luck! ---- Sam Kendall Sun Microsystems Labs BOS ======================================================================= 6 === Date: 13 Jan 1994 23:22:29 GMT From: kendall@pot.East.Sun.COM (Sam Kendall - Sun Microsystems Labs BOS) Subject: Why can I not qualify an identifier within its own interface? Eg: INTERFACE I; TYPE T = ...; PROCEDURE F(): I.T; (* must delete `I.' to get this to compile *) END I. Why this restriction? (I guess the same restriction exists for modules, though I haven't tried.) ---- Sam Kendall Sun Microsystems Labs BOS ======================================================================= 7 === Date: Thu, 13 Jan 94 15:49:32 -0800 From: mhb@src.dec.com ("Marc H. Brown") Subject: Books on Modula-3 [was: Re: Beginners Guide to M3] There's a third book on Modula-3: Algorithms in Modula-3 Robert Sedgewick Addison-Wesley, 1993. ISBN number is 0-201-53351-0 From the back of the book: "This latest version of Robert Sedgewick's popular book exhibits his comprehensive collection of algorithms in a modular, object-oriented programming environment with implementations in the Modula-3 language. These algorithms cover a broad range of fundamental and more advanced methods: sorting, searching, string-processing, geometric, graph, and mathematical algorithms." Some of the algorithm animations on the DEC SRC Modula-3 release on gatekeeper are closely tied to the diagrams for this book. The focus of the book is on algorithms and data structures, not on programming language constructs. But it does make good use of M3 objects and interfaces. I highly recommend it! Marc ======================================================================= 8 === Date: Thu, 13 Jan 1994 06:48:17 GMT From: rundle@possum.jrc.flinders.edu.au (Richard Rundle) Subject: Beginners Guide to M3 Can anyone recommend some easy to get hold of introductory articles on modula 3 programming? By easy to get hold of I mean, available electronically, or in journals or books which libraries have a tendency to hold. Thanks Richard ======================================================================= 9 === Date: 14 Jan 1994 13:03:29 GMT From: ucaa2385@iris3.csv.ica.uni-stuttgart.de (Peter Hermann) Subject: Re: CFP: Joint Modular Languages Conference (JMLC) In article <2h5u2g$i0m@wega.rz.uni-ulm.de> borchert@thales.mathematik.uni-ulm.d e (Andreas Borchert) writes: >more recent developments. We cordially invite Pascal, Modula-2, Oberon >programmers and programming communities from other traditions to join ... and reject Ada people? ;-) -- Peter Hermann Tel: 0711-685-3611 Institut fuer Computeranwendungen Fax: -3758 or -3669 Pfaffenwaldring 27 ICA2 e-mail: ph@csv.ica.uni-stuttgart.de 70569 Stuttgart Universitaet or ph@ica.uni-stuttgart.d400.de ======================================================================= 10 === Date: 14 Jan 1994 11:01:36 GMT From: borchert@thales.mathematik.uni-ulm.de (Andreas Borchert) Subject: CFP: Joint Modular Languages Conference (JMLC) ------------------------------------------------------------------------------- # # # # ##### University of Ulm, # ## ## # # # in cooperation with Germany # # # # # # # # # # # # # GI, SIG and BCS # # # # # # 28th-30th September # # # # # # # 1994 ##### # # ####### ##### Joint Modular Languages Conference Formerly the European & International Modula-2 Conference Modula-2, Oberon and Friends Keynote Speaker: Niklaus Wirth ------------------------------------------------------------------------------- CALL FOR PAPERS AND FIRST ANNOUNCEMENT ------------------------------------------------------------------------------- IN CO-OPERATION WITH: Gesellschaft fuer Informatik e.V., Fachgruppe 2.1.3, 2.1.4 Schweizer Informatiker Gesellschaft, Fachgruppe Oberon British Computer Society, Modular Languages SIG THEME The time has come for all to take a wider perspective of programming languages. Designers, programmers and teachers interested in modular languages will have the opportunity to become aware of alternative and more recent developments. We cordially invite Pascal, Modula-2, Oberon programmers and programming communities from other traditions to join the conference and share our and their experiences. The scope of the conference is broad but centered around modular high-level languages and their effective use. Papers on recent work in the following areas are invited: * Approaches to modularisation & class design * Module and class libraries & families * Modularity, concurrency & persistence * Safety of programming languages * Comparison of programming languages * Mechanisms for type extension & delegation * Implementation of run-time environments * Safety critical & real-time applications * Programming environments & tool boxes * Life cycle & engineering of program systems * Light-weight systems * Teaching systems & schemes Accepted papers will be published in the conference proceedings. Intending authors should submit three copies of an extended abstract before 15th April 1994 to: Peter Schulthess Verteilte Systeme, Informatik Universitaet Ulm, o-27 D-89069 Ulm, Germany Telefax: +49 731 502 4142 E-Mail: schulthe@informatik.uni-ulm.de PROGRAMME COMMITTEE Peter Schulthess (Chairman, University of Ulm) Marwan M. Al-Akaidi (De Montfort University, UK) Andreas Borchert (University of Ulm, Germany) Randy Bush (PSG, USA) Steven Collins (Real Time Associates, UK) James Cooling (Univ. of Loughborough, UK) Antonio Corradi (University of Bologna, Italy) Guenther Dotzel (ModulaWare, Germany) Jacques Farre (Universite de Nice, France) John Gough (QUT, Australia) Juerg Gutknecht (ETHZ, Switzerland) Brian Kirk (Robinson Associates, UK) Herbert Klaeren (University of Tuebingen, Germany) Wolfram Lippe (Universitaet Muenster, Germany) Hans-Peter Moessenboeck (ETHZ, Switzerland) Libero Nigro (Universita della Calabria, Italy) Gustav Pomberger (University of Linz, Austria) Franz Schweiggert (Unversity of Ulm, Germany) Marjan Spegel (Stefan Institute, Slovenia) Juergen Uhl (IBM, Germany) ORGANISING COMMITEE Alfred Lupper (OC Director, University of Ulm) Marwan Al-Akaidi (De Montfort University, UK) Andreas Borchert (University of Ulm) James Cooling (University of Loughborough, UK) Peter Schulthess (University of Ulm) Franz Schweiggert (University of Ulm) In co-operation with IBM Deutschland, Development GmbH Daimler Benz Research Institute, Ulm NC-Gesellschaft, Ulm FAW, Ulm EXHIBITORS The conference will provide an opportunity for delegates to discuss and view Modula-2, Oberon, C++ and other language compilers and environments. Organisations interested in exhibiting compilers and related products are invited to contact the organising committee. KEY DATES 15. April 94 Submission of abstracts 10. June 94 Notify acceptance to authors 1. Sept. 94 Submission of final papers 26.-27. Sept. 94 Tutorials 28.-30. Sept. 94 Conference VENUE The conference will be held at the University of Ulm on campus, which is situated in the east of Baden-Wuerttemberg, Germany. Ulm and its University are easily reached by ICE-trains and motorways. Direct transfers to Stuttgart airport will be organised. The working language of the conference is English. This will be used for all presentations and printed material. SUPPLEMENTARY EVENT AND BANQUET Particular attention will be given to the organisation of a programme for accompanying persons: Tour of the Ulmer Muenster Visit to Reisensburg Castle Excursion to the Blautopf springs Open air sculpture collection on campus Banquet ... REPLY FORM PLEASE COMPLETE IN BLOCK CAPITALS To: JMLC Conference Secretary Verteilte Systeme, Informatik Universitaet Ulm Oberer Eselsberg o-27 D-89069 Ulm, Germany Phone#: +49 731 502 4140 Telefax: +49 731 502 4142 vsoffice@informatik.uni-ulm.de [ ] I am interested in the conference and require copies of the programme and registration form: Name _______________________________________ Organisation _______________________________________ Address _______________________________________ Telephone, Fax _______________________________________ E-Mail _______________________________________ [ ] I intend to submit a paper provisionally entitled: Title _______________________________________ _______________________________________ [ ] If you know of any other colleague who may be interested, please give details below. Name _______________________________________ Organisation _______________________________________ Address _______________________________________ E-Mail _______________________________________ CONFERENCE INFORMATION General enquiries and requests for detailed information should be addressed to the JMLC Conference Secretary (address given above). For technical information, please contact any member of the organising committee or Prof. Peter Schulthess by one of the following means: Phone#: +49 731 502 4140 Telefax: +49 731 502 4142 E-mail: schulthe@informatik.uni-ulm.de A full conference programme and registration form will be published early in June 1994 and sent to those who complete and return the attached form. The conference fee is budgeted to approximately DM 350. Discounts will be available for GI, SI and BCS SIG members and for students. -- _______________________________________________________________________________ Andreas Borchert, University of Ulm, SAI, D-89069 Ulm, Germany Internet: borchert@mathematik.uni-ulm.de ======================================================================= 11 === Date: 17 Jan 94 16:58:07 GMT From: cbnorman@undergrad.math.uwaterloo.ca (Chris 'Strunoph' Norman) Subject: Odd Comment Question Any idea why the following produces an EOF in comment error? (*) Comment (*) -- /| (Reverend) Christopher Bruce Norman \`o.@' Ack! Ack! Thbbbpppt! cbnorman@descartes.uwaterloo.ca =(___)= CS246 Tutor (MC 1014) U "Strip mining prevents forest fires" -- Smokey the Bear ======================================================================= 12 === Date: 17 Jan 1994 18:14:27 GMT From: mako@FNALA.FNAL.GOV Subject: Re: Odd Comment Question > Any idea why the following produces an EOF in comment error? > > (*) Comment (*) In Moulda-3, comments can nest; the second "(*" is interpreted as the beginning of the next level of comment line, with no corresponding end marks! mako ======================================================================= 13 === Date: Mon, 17 Jan 1994 18:45:42 GMT From: whitney@galileo.Meakins.McGill.CA () Subject: Re: Odd Comment Question Chris 'Strunoph' Norman (cbnorman@undergrad.math.uwaterloo.ca) wrote: : Any idea why the following produces an EOF in comment error? : (*) Comment (*) The EOF is reached before the nested comments are closed. The problem is easy to see if you add some spaces and/or change ) for ]. (* ] Comment (* ] whitney ======================================================================= 14 === Date: 17 Jan 94 20:38:38 GMT From: cbnorman@undergrad.math.uwaterloo.ca (Chris 'Strunoph' Norman) Subject: Re: Odd Comment Question In article <2heki3$dr6@fnnews.fnal.gov>, wrote: >> Any idea why the following produces an EOF in comment error? >> >> (*) Comment (*) > >In Moulda-3, comments can nest; the second "(*" is interpreted as the >beginning of the next level of comment line, with no corresponding end >marks! > mako (smacks self in head) Of course. Thanks. -- /| (Reverend) Christopher Bruce Norman \`o.@' Ack! Ack! Thbbbpppt! cbnorman@descartes.uwaterloo.ca =(___)= CS246 Tutor (MC 1014) U "Strip mining prevents forest fires" -- Smokey the Bear ======================================================================= 15 === Date: 17 Jan 1994 19:07:08 -0500 From: clarence@orion.cc.andrews.edu (Clarence L. Thomas IV) Subject: Global Alert For All: Jesus is Coming Soon The earthquake in Los Angeles, California, the flood in Europe, the seemingly unstoppable war in the former Yugoslavia, the devastating fires in Australia, the flood in the Midwest of the United States of America, the devastating fires near Los Angeles, California, the rapid and appalling increase in violence in cities, towns, villages all over the world, the famines, the diseases, the rapi d decline of the family unit, and the destructive earthquake in India (in 1993) are signs that this world's history is coming to a climax. The human race has trampled on God's Constitution, as given in Exodus 20:1-17 (King James Version Bible), and Jesus is coming to set things right. These rapidly accelerating signs are an indication that Jesus is coming soon (Matthew 24). God's Holy Spirit is gradually withdrawing its protection from the earth and the devastating events you see are demonstrations of Satan's power. All those who are not guarded by God are in danger of forever losing eternal life. If you want to know what's about to happen, please study the books of Daniel and Revelation which are located in God's Word, the Bible. They are not sealed or closed books. They can and must be understood by all. Every word in the Bible from Genesis to Revelation is true. The Bible and the Bible only must be your guide. When God's Law (the Constitution for the Universe) is consistently ignored, disregarded, changed, and questioned, He permits certain events to occur to wake us up. I would urge all, wherever you are and regardless of the circumstances, to directly call on Jesus and ask Him to intervene in your life. Jesus who created this planet and every living creature in it and on it, died on the cross, was raised from the dead by God the Father, and is now in Heaven interceding for you. Jesus is the only One who can rescue us from the slavery, misery, and death Satan is causing us. For reference I'm including God's Constitution as given in the King James Version Bible. Please note that when God says the seventh day, he means Sabbath (the 7th day of the week) not Sunday (1st day of the week). Commandment #1: Exodus 20:1-3 (KJV) And God spake all these words, saying, I am the LORD thy God, which have brought thee out of the land of Egypt, out of the house of bondage. Thou shalt have no other gods before me. Commandment #2: Exodus 20:4-6 (KJV) Thou shalt not make unto thee any graven image, or any likeness of any thing that is in heaven above, or that is in the earth beneath, or that is in the water under the earth. And shewing mercy unto thousands of them that love me, and keep my commandments. Commandment #3: Exodus 20:7 (KJV) Thou shalt not take the name of the LORD thy God in vain; for the LORD will not hold him guiltless that taketh his name in vain. Commandment #4: Exodus 20:8-11 (KJV) Remember the sabbath day, to keep it holy. Six days shalt thou labour, and do all thy work: But the seventh day is the sabbath of the LORD thy God: in it thou shalt not do any work, thou, nor thy son, nor thy daughter, thy manservant, nor thy maidservant, nor thy cattle, nor thy stranger that is within thy gates: For in six days the LORD made heaven and earth, the sea, and all that in them is, and rested the seventh day: wherefore the LORD blessed the sabbath day, and hallowed it. Commandment #5: Exodus 20:12 (KJV) Honour thy father and thy mother: that thy days may be long upon the land which the LORD thy God giveth thee. Commandment #6: Exodus 20:13 (KJV) Thou shalt not kill. Commandment #7: Exodus 20:14 (KJV) Thou shalt not commit adultery. Commandment #8: Exodus 20:15 (KJV) Thou shalt not steal. Commandment #9: Exodus 20:16 (KJV) Thou shalt not bear false witness against thy neighbour. Commandment #10: Exodus 20:17 (KJV) Thou shalt not covet thy neighbour's house, thou shalt not covet thy neighbour's wife, nor his manservant, nor his maidservant, nor his ox, nor his ass, nor any thing that is thy neighbour's. I also recommend that the following books be obtained and closely studied: The Great Controversy By Ellen G. White Review and Herald Publishing Association Hagerstown, MD 21740 The Desire of the Ages By Ellen G. White Review and Herald Publishing Association Hagerstown, MD 21740 Patriarchs and Prophets By Ellen G. White Review and Hearld Publishing Association Hagerstown, MD 21740 Daniel and the Revelation By Uriah Smith Review and Herald Publishing Association Hagerstown, MD 21740 ------- Clarence L. Thomas IV Phone: 616-471-6116 E-mail: thomas@redwood.cc.andrews.edu ======================================================================= 16 === Date: 18 Jan 94 23:07:40 -0500 From: Joe.Klemmer@f370.n109.z1.fidonet.org (Joe Klemmer) Subject: DOS M3 'compiler' I grabbed what perports to be a DOS version of a Modula-3 compiler off of ftp.luth.se in pub/pc/msdos/languages/modula3. The files are in DOS 'Backup' format. I 'Restored' them to their original format and found that there was supposed to be an INSTALL.BAT file with them that was not there. I believe I can fake this (the files are just TAR's of the M3 & DJGPP trees). What I'd like is if anyone has played with this version at all? Any info that anyone might have on this would be appriciated. Later, Joe ======================================================================= 17 === Date: 18 Jan 1994 07:13:30 GMT From: laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI) Subject: Re: Beginners Guide to M3 We are working on a book with the title: "Programming with Style - Introduction into programming with Modula-3" The book is intended first of all for university students. It will come out first in German, this autumn, the English translation will follow as fast as possible. (I hope at the begining of the next year.) It will be published at the Springer Verlag. Best regards Laszlo Boszormenyi ********************************* * Prof. Laszlo Boeszoermenyi * * Institut fuer Informatik * * * * Universitaet Klagenfurt * * Universitaetsstr. 65-67 * * A-9022 Klagenfurt / Austria * * * * e-mail: * * laszlo@ifi.uni-klu.ac.at * * Tel.: * * 00-43-463-2700-509 * * 00-43-463-2700-506 (secr.) * * Fax.: * * 00-43-463-2700-505 * ********************************* ======================================================================= 18 === Date: 20 Jan 94 02:22:03 GMT From: kmc2lee@undergrad.math.uwaterloo.ca (Kennis) Subject: Re: DOS M3 'compiler' In article <330_9401182357@blkcat.fidonet.org>, Joe.Klemmer@f370.n109.z1.fidone t.org (Joe Klemmer) writes: > I grabbed what perports to be a DOS version of a Modula-3 compiler off of > ftp.luth.se in pub/pc/msdos/languages/modula3. The files are in DOS 'Backup' > format. I 'Restored' them to their original format and found that there was > supposed to be an INSTALL.BAT file with them that was not there. I believe I > can fake this (the files are just TAR's of the M3 & DJGPP trees). > > What I'd like is if anyone has played with this version at all? Any info > that anyone might have on this would be appriciated. > > Later, > Joe Sorry, I'm not going to answer your question and I don't the answer either. I just have some other questions. How large is the full system after restored? Is it fully compatible with the SRC Modula3? Thanks. -Kennis kmc2lee@descartes.uwaterloo.ca ======================================================================= 19 === Date: 20 Jan 94 10:56:49 EET From: kolu@tnclus.tele.nokia.fi Subject: Exception handling in Modula-3? Hello! I'm trying to do a comparison on exception handling methods in different programming languages. I'm now looking for information on exception handling in Modula-3. Is there anybody who could help me? Thank you! Minja ======================================================================= 20 === Date: Thu, 20 Jan 1994 11:39:54 GMT From: dns11@cus.cam.ac.uk (D.N. Sann) Subject: TextPorts, VTexts and MTexts. I am implementing an Editor and I would like the ability to split the screen to edit two parts of the same document simultaneously. Currently I have a single textEdit as the editing window. The underlying TextPort does not allow for splitting the window. I can see that a VText has the capability to split but I am not supposed to change the VText in a textport. I thought that having a second textport with the Vtext set to point to the original Textport's VText might work. However since the VText holds info about where it is displayed I think it will not work. As a second Idea I thought that having the VTexts from the two textports point to the same MText. This is Plausable but The internals of the Vtext such as Selections and Markers would be different.(and also it's probably illeg al) Is there any way to do this without having to rewrite the textport? (Which I probably couldn't do anyway!!) Cheers Dave. ======================================================================= 21 === Date: Thu, 20 Jan 1994 13:14:53 GMT From: whitney@galileo.Meakins.McGill.CA () Subject: Re: Exception handling in Modula-3? kolu@tnclus.tele.nokia.fi wrote: : Hello! : I'm trying to do a comparison on exception handling methods in : different programming languages. I'm now looking for information : on exception handling in Modula-3. Is there anybody who could help me? Exception handling in computer languages was covered in Andrew Black's Phd thesis. It is an old thesis ( 1982 ) but it is still worth a read. Exception Handling: The Case Against Andrew P. Black Department of Computer Science University of Washington Seattle, WA 98195 USA Whitney ======================================================================= 22 === Date: Thu, 20 Jan 94 12:01:18 -0800 From: mhb@src.dec.com ("Marc H. Brown") Subject: Re: TextPorts, VTexts and MTexts. You can use a JoinedVBT to allow a VBT to be installed in more than one place. To see how this work, check out the implementation of ViewportVBT: it allows a user to see multiple views of its child by option-clicking in the scrollbar. You are correct to notice that there is *a lot* more functionality in VText (and MText) than is currently used by the layers above it. These libraries were written in the mid-80's in Modula-2, and translated mostly mechnically into Modula-3. They are in dire need of redesign (and reimplementation). ======================================================================= 23 === Date: 20 Jan 94 08:03:21 -0500 From: Joe.Klemmer@f370.n109.z1.fidonet.org (Joe Klemmer) Subject: DOS M3 'compiler' Kennis wrote in a message to All: > I grabbed what perports to be a DOS version of a Modula-3 compiler off of > ftp.luth.se in pub/pc/msdos/languages/modula3. The files are in DOS 'Backup' > format. I 'Restored' them to their original format and found that there was > supposed to be an INSTALL.BAT file with them that was not there. I believe I > can fake this (the files are just TAR's of the M3 & DJGPP trees). > > What I'd like is if anyone has played with this version at all? Any info > that anyone might have on this would be appriciated. K> Sorry, I'm not going to answer your question and I don't the K> answer either. I just have some other questions. How large K> is the full system after restored? Is it fully compatible K> with the SRC Modula3? That's cool, I understand. As to your questions, after instellation it's about 80MB (or so it clames). And as to SRC compatability... I have no idea, haven't untar'd the files yet to see what the read me says. I'll keep anyone posted of my progress if anyone cares. Later, Joe ======================================================================= 24 === Date: 21 Jan 1994 14:51:55 -0000 From: aps@ecs.soton.ac.uk (Adrian Smith) Subject: Are "network objects" available yet? Hi, I've been using M3 threads to build simple models of parallel/ distributed systems. I'd like to try my hand with some new mechanisms :-) Notes with the M3 compiler from DEC imply that "network objects" are/will be available. Can anyone give me the current status of development of these abstractions? Thanks in anticipation, Adrian -- * Adrian Smith (aps@ecs.soton.ac.uk) * * Electronics and Computer Science * * Southampton University * * SOUTHAMPTON SO5 NH * ======================================================================= 25 === Date: 22 Jan 94 07:26:20 GMT From: khaw@parcplace.com Subject: ParcPlace job opening ParcPlace is looking for experienced software developers who seek a change of pace and would be interested in technical support. For details, please see the posting in ba.jobs.offered Apologies to those seeing this posting outside the San Francisco Bay Area. There seems to be some problem with our news transport system handling Distribution: headers correctly. -- Michael Khaw khaw@parcplace.com (or khaw%parcplace.com@netcom.com) ParcPlace Systems, Sunnyvale, CA PRODUCT INFO: info@parcplace.com ======================================================================= 26 === Date: Sat, 22 Jan 1994 15:05:42 GMT From: robsch@robkaos.GUN.de (Robert Schien) Subject: M3 for 386BSD/NetBSD/FreeBSD Is there a version of M3 for 386BSD/NetBSD/FreeBSD? Perhaps even a native 386 compiler? But a M3-to-C converter would be already nice. Thanks in advance. Robert ======================================================================= 27 === Date: Sun, 23 Jan 1994 23:29:32 GMT From: ftcvb@aurora.alaska.edu Subject: Re: DOS M3 'compiler' In article <330_9401182357@blkcat.fidonet.org>, Joe.Klemmer@f370.n109.z1.fidone t.org (Joe Klemmer) writes: > I grabbed what perports to be a DOS version of a Modula-3 compiler off of > ftp.luth.se in pub/pc/msdos/languages/modula3. The files are in DOS 'Backup' > format. I 'Restored' them to their original format and found that there was > supposed to be an INSTALL.BAT file with them that was not there. I believe I > can fake this (the files are just TAR's of the M3 & DJGPP trees). > > What I'd like is if anyone has played with this version at all? Any info > that anyone might have on this would be appriciated. > > Later, > Joe This sounds very much like a repackaged version of m3pc, available from gatekeeper.dec.com, and mentioned in the FAQ. I tried this out briefly. I'm not sure I had it set up right. It took about 5 minutes to compile the "hello" sample program into a 300K+ executable file. I lost interest. Perhaps someone who is familiar with this could tell me whether the 300k files are normal or what I had set up wrong. --Chase Brady FTCVB@AURORA.ALASKA.EDU ======================================================================= 28 === Date: 24 Jan 1994 09:16:16 GMT From: carsten@post.ifi.uni-klu.ac.at (Carsten WEICH) Subject: Re: DOS M3 'compiler' Modula-3 on PC: Modula-3/PC is a fully SRC-compatible compiler. It is based on the version 2.09 of the SRC-compiler and does not support threads. The PC-compiler depends on the djgpp - (gnu)-C-compiler. You will need a strong PC with about 8 MByte of RAM and 20 MB yte free on your disk. 300 KByte hello-world is normal. This is because of the huge Modula-3 library l inked to every program. 5 min translation time for hello-world means that you have not granted enough m emory to the C-compiler. Giving 6-10 MByte to SMARTDRV (the standard PC disk-cache, I think it is part of WINDOWS) speeds up things significantly. You should end w ith turn-around time of less than a minute for the compilation and linking of a sin gle module. We have built a new version of the PC-compiler which is ready but not yet insta lled at the gatekeeper. It is better documented and will only require 20 MByte of yo ur disk-space. But you need a mathematic-coprocessor or a 80486. I hope this made thinks clearer. Carsten Weich -------------------------------------- carsten@ifi.uni-klu.ac.at Carsten Weich Universitdt Klagenfurt Austria ======================================================================= 29 === Date: Mon, 24 Jan 1994 08:37:03 GMT From: skj@oasis.icl.co.uk (Simon Johnston) Subject: Linux Modula-3 Hi all I did pick up and start with the alpha-3.0 Linux port, however I found lots of problems, I have now built it but when I run m3 I get a message along the lines of 'possible segmentation violation' and a core file which grows until it takes all available disk space, and the process is taking all the mill. Can anyone help me, please ! MODULE Sig; FROM ICL IMPORT StdDisclaimer; FROM Interests IMPORT Modula2, Modula3, Linux, OS2; BEGIN (* ------------------------------------------------------------------------. |Simon K. Johnston - Development Engineer |ICL Retail Systems | |------------------------------------------------------|3/4 Willoughby Road| |Unix Mail : S.K.Johnston.bra0801@oasis.icl.co.uk |Bracknell, Berks | |Telephone : +44 (0)344 476320 Fax: +44 (0)344 476084|United Kingdom | |Internal : 7261 6320 OP Mail: S.K.Johnston@BRA0801|RG12 8TJ | `------------------------------------------------------------------------ *) END Sig. ======================================================================= 30 === Date: 24 Jan 1994 17:42:59 +0100 From: agulbra@nvg.unit.no (Arnt Gulbrandsen) Subject: Re: Inheritance and Exceptions In article <2i0nds$e6@urmel.informatik.rwth-aachen.de>, Peter Klein wrote: >Generally, this is quite sensible, because in a statically typed language, >the client of an object has to be able to determine the exceptions which >can result from a method call by the static type of the object, which >may be a supertype of the actual (dynamic) object's type. On the other >hand, it is very common that the implementation of a subtype is more >"complex" than that of the supertype; often, the redefined method calls >the supertype's method and does "something more". So, the implementation >of the subtype's method commonly requires _more_ exceptions in the >raises set, not less. You have to differentiate between implementation on one hand and interfaces on the other hand. The M3 solution "forces" you to regard a subtype as a specialisation of its supertypes. The supertype must be more generic than any of its subtypes. Expressed like that, it sounds very acceptable to me. Of course, it means that the raises set of an abstract class must be rather large, since it ideally should encompass all implementations of a specialisation of the interface. >The only solutions to this problem I can think of are the following: > >- All exceptions which may occur in any specialization of a method > are already in the raises set of the base class. Problem: The base > class has to be changed if a new subtype wants to raise a new exception. True, but that's a fairly major design change. It could change the interfaces of many classes/modules, and is something you should attempt to avoid when you first write the raises set. Design is hard, programming is hard, and there is no magic wand to make it easy. > Furthermore, a method implementation in the "middle" of the inheritance > hierarchy still doesn't see which exceptions might be raised by the > method of the superclass. Well, could it anyway? It only knows the interface, not the implementation, of its superclass, and hardly even that about any super-super-super-classes it might have. All this is IMAO, of course, and I'm nobody in particular. --Arnt ======================================================================= 31 === Date: 24 Jan 1994 14:53:48 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Inheritance and Exceptions Hello world! The following problem now bothers me for some time. I'll use the terminology of Modula-3 in the following, though the problem is language-independent. In Modula-3, the exceptions which may be raised during the execution of a method is called the _raises set_ of the method and is part of the method's signature. As exceptions are somehow an "output" of the method, they are subject to the covariance rules, i.e. the raises set of a redefined method in a subtype must be a subset of the raises set of the method in the supertype. Generally, this is quite sensible, because in a statically typed language, the client of an object has to be able to determine the exceptions which can result from a method call by the static type of the object, which may be a supertype of the actual (dynamic) object's type. On the other hand, it is very common that the implementation of a subtype is more "complex" than that of the supertype; often, the redefined method calls the supertype's method and does "something more". So, the implementation of the subtype's method commonly requires _more_ exceptions in the raises set, not less. The only solutions to this problem I can think of are the following: - All exceptions which may occur in any specialization of a method are already in the raises set of the base class. Problem: The base class has to be changed if a new subtype wants to raise a new exception. Furthermore, a method implementation in the "middle" of the inheritance hierarchy still doesn't see which exceptions might be raised by the method of the superclass. - All methods have the "infinite" raises set ANY. Problem: Nobody knows which exceptions can be raised by calling a method (or you figure it out manually). Both are quite unsatisfactory. Is there anybody out there with a better idea? Peter --- Peter Klein E-Mail: pk@i3.informatik.rwth-aachen.de Lehrstuhl fuer Informatik III Tel.: +49/241/80-21311 Ahornstrasse 55 Fax.: +49/241/80-21329 RWTH Aachen 52074 Aachen Germany ======================================================================= 32 === Date: Mon, 24 Jan 1994 21:18:33 GMT From: jmeehan@mendoza.adobe.com (Jim Meehan) Subject: Re: Inheritance and Exceptions Modula-3 exceptions aren't objects (for better or worse), but their arguments can be. I've written lots of code that used this, and while not perfect, it's quite reasonable. For example, subtypes of the exception-argument type typically override a "print" method to get more (or less) detailed error messages. Jim ======================================================================= 33 === Date: Mon, 24 Jan 94 16:35:40 -0800 From: heydon@src.dec.com Subject: Re: Are "network objects" available yet? > Notes with the M3 compiler from DEC imply that "network objects" > are/will be available. Can anyone give me the current status of > development of these abstractions? To the best of my knowledge, the network object design and implementation are complete. I don't believe they are currently available; the plan is to include them as part of the SRC Modula-3 3.0 release. The best reference on network objects is the following SOSP paper: Andrew Birrell, Greg Nelson, Susan Owicki, and Edward Wobber. "Network Objects." In 14th ACM Symposium on Operating Systems Principles, pages 217-230, December, 1993. - Allan ------------------------------------------------------------------------------- Allan Heydon heydon@src.dec.com DEC Systems Research Center (415) 853-2142 130 Lytton Ave. (415) 853-2104 (FAX) Palo Alto, CA 94301 ------------------------------------------------------------------------------- ======================================================================= 34 === Date: 24 Jan 1994 20:28:58 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Inheritance and Exceptions >>- All exceptions which may occur in any specialization of a method >> are already in the raises set of the base class. Problem: The base >> class has to be changed if a new subtype wants to raise a new exception. > >True, but that's a fairly major design change. It could change the >interfaces of many classes/modules, and is something you should >attempt to avoid when you first write the raises set. Of course, it may change many interfaces, but it's definitely not a major design change. > Design is >hard, programming is hard, and there is no magic wand to make it >easy. > Thanks for the hint, I almost forgot :) >> Furthermore, a method implementation in the "middle" of the inheritance >> hierarchy still doesn't see which exceptions might be raised by the >> method of the superclass. > >Well, could it anyway? It only knows the interface, not the >implementation, of its superclass, and hardly even that about any >super-super-super-classes it might have. > This is not completely true. Thanks to the covariance rule, the compiler can (and does) warn you about unhandled exceptions. So, if an exception can be raised by a method and it is not in the raises set of the method's declaration, you'll get a warning. If the modules of the inheritance hierarchy compile without warning, the raises set visible in the interface is indeed a superset of the exceptions which may result from the method call. Peter --- Peter Klein E-Mail: pk@i3.informatik.rwth-aachen.de Lehrstuhl fuer Informatik III Tel.: +49/241/80-21311 Ahornstrasse 55 Fax.: +49/241/80-21329 RWTH Aachen 52074 Aachen Germany ======================================================================= 35 === Date: Mon, 24 Jan 1994 18:29:53 GMT From: hughes@twostep.cs.uiuc.edu (Eric Hughes) Subject: Re: Inheritance and Exceptions It seems to me that, although subclass methods will test for _more_ exceptions, the question is whether the exceptions tested will be derived from exceptions that can be raised by the superclass method. In other words, if the subclass method raises exception type A and the superclass raises exception type B, is A a subtype of B? This viewpoint may be an artifact of the (proposed) implementations I've seen. Regards, [][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][] Eric Hughes 2231 DCL 1304 W. Springfield Urbana, IL 61801 USA voice: +1 (217) 244-7117 fax: +1 (217) 333-3501 email: hughes@cs.uiuc.edu ======================================================================= 36 === Date: Tue, 25 Jan 1994 01:00:08 GMT From: whitney@galileo.Meakins.McGill.CA () Subject: Re: Inheritance and Exceptions From the thesis Insight ETHOS: On Object-Orientation in Operating Systems. by Clemens A. Szyperski ISBN 3 7281 1948 2. ".. exception handling of some kind is crucial for extensible systems. The point was that the correctness of an extension called from the within a base service cannot be guaranteed. Hence, the calling service will need to handle exceptions occuring during of the extension, if it has to guarantee invariants. The main problem with exception handling are: How to handle the complicated flow of control that results if an exception occuring at one place is caught at another, and how exceptions interact with a strong typing scheme. In principle one may introduced a language feature to handle exceptions, eg. similar to Modula-3: TRY Si EXCEPT e0 => T0 | e1 => T1 | .. en-1 => Tn-1 END; Sk Here Si is a statement that may raise an exception. If it terminates normally, execution proceeds with statement Sk. However, if one of the exception, say ej is raised, the respective handling statement Tj is executed before continuing with Sk. If an exception occurs which is not listed, or if a handler raises an exception, or if a handler raises an exception, the TRY statement itself raises the exception. A problem is: How can a programmer of the TRY statement know which kind of exceptions can occur. If Si invokes a late-bound procedure, the possible exceptions that can be raised need be declared together with the signature of the procedure, and occurrence of other exceptions would have to be prevented by the conpiler. In conjunction with extensions, declaration of possible extensions becomes problematic. For example, a procedure P bound to type T may be declared to raise exceptions out a set Ep. Then, for a subtype T' of T , an overiding procedure P' is forced to raise exceptions of a set Ep', where Ep' <= Ep must hold. This exhibts a conflict: On the one hand, the procedure refined operations and may meaningfully raise new exceptions. On the other hand, the base type type may be the only one known to the client, and guarantees that only exceptions out Ep will be raised. Since the exception set may be considered the type of an out-parameter of an exception raising procedure, the described conflict is just a special case of the covariance problem." : > Design is : >hard, programming is hard, and there is no magic wand to make it : >easy. ETHOS is an operating system implemented in Oberon-2. Exception handling is not introduced at the language level but rather is offered by the system. Whitney ======================================================================= 37 === Date: Tue, 25 Jan 1994 15:13:28 GMT From: k1xe@unb.ca (ZINCK T) Subject: Modula-2 test code... Hello ! I am in the process of writting a M2 static analysis toolkit for an undergradut e report. I am writting, basically, the front end on a M2 compiler. I have several pieces of code to use for testing, but I was wondering if any co mplete test code is available, shareware of course. Please email any information. Thanx, Tom Zinck ------------------------------------------------------------------------------- ---- k1xe@unb.ca University of New Brunswick Faculty of Computer Science ======================================================================= 38 === Date: Thu, 27 Jan 1994 01:09:25 GMT From: norman@flaubert.bellcore.com (Norman Ramsey) Subject: Generic and exceptions I have written an interpreter for an extension language, and clients can add procedures to the extension language. The problem is with the type of those procedures. At the moment the signature is PROCEDURE (interpreter:T) RAISES {E} but that's inconvenient if there are other exceptions a procedure raises. I would like to make it generic, e.g. GENERIC INTERFACE Interp(Errors); TYPE T = OBJECT ... EXCEPTION E (...); ... PROCEDURE (interpreter:T) RAISES {E, Errors.E} ... END Interp. but this isn't much better, because I'm trying to adapt existing code which could raise any of several exceptions. I could adopt a scheme by which my code raises only the One True Exception, using the argument to distinguish different causes. I've heard this scheme advocated here, but the scheme in the SRC library is quite different---interface designers seem to feel free each to export one or more exceptions. What all this suggests to me is that the language is weak in this spot. Designers of the Next Twelve Changes take note! If I could create such a thing as a CONST Exns = ``list of exceptions'', and if I could use it in a RAISES clause, then that would help a lot, and it shouldn't cause any problems with the language. There's no way to say that a procedure raises only the exceptions raised by some procedure argument, e.g. for List.Map PROCEDURE Map( l: T; p: MapProc; arg: REFANY := NIL ): T RAISES {OF p}; which I realize equates to ANY in the general case, but often one can do better, e.g., because at most call sites p is a constant. Maybe there shouldn't be a distinction between exceptions and object types? (I'm a rank amateur prepared to believe there may be type-theoretic reasons not to do this, but it would be nice to have the issue explained by the pros.) Comments are welcome. -- Norman Ramsey norman@bellcore.com ======================================================================= 39 === Date: Fri, 28 Jan 1994 16:19:15 GMT From: fn00@gte.com (Farshad Nayeri) Subject: GIF to Image.Raw format Does anyone out there have some code that can read a stream of GIF data from an "Rd.T" in Modula-3? (I am trying to convert GIF data coming over a network stream into an "Image.Raw" to display.) I know that the "Image" interface reads ppm format, and there are UNIX filters for gif to ppm conversion, but doing it by using UNIX pipes and/or "system" call seems a bit ugly. Thanks! --farshad -- /// | {@,@} | "He's so unhip that when you (...) Farshad Nayeri | say Dylan, he thinks you're " " nayeri@gte.com | talking about Dylan Thomas." ======================================================================= 40 === Date: 28 Jan 1994 13:25:28 GMT From: carsten@post.ifi.uni-klu.ac.at (Carsten WEICH) Subject: New version of Modula-3/PC NEW VERSION OF M3-PC -------------------- We are happy to announce that Carsten Weich, University of Klagenfurt, has completed an adavanced version of PC-Modula-3. The new version is smaller, faster and more comfortable. It is available on the gatekeeper! Please find necessary information appended. (Further approvements are still in progress - do hope!) Laszlo Boszormenyi ------------------------------------------------------------- We have built a new version of Modula-3 running on a PC. You will need a PC: * 80486 or 80386 with floatingpoint-coprocessor, * at least 4 but preferable 8 MByte of RAM, * 20 MByte discspace free at least. You can run a modified Modula-3 version 2.09 without thread- support. Our version features: * support for Unix-like long filenames * automatic compilation (to substitute the lack of m3make) * library to access DOS-files and directories. We have built a little shell which translates the long filenames you type in into DOS-filenames. It has a unix-lookalike "ls"-command. There are commands to teach the system new long filenames. You can savely move such files around through DOS-directories (which was not possible with the first version). This version accesses DOS-files significantly faster than the first version. Especially linking large Modula-3 programs is much faster now. On a 50 MHz 80486 with 16 MByte of RAM we measured a turn-around time of 2 minutes for a 5 module, 500 lines program. If you want to compile only one module you will have to wait about one minute. The necessary files are available at "gatekeeper.dec.com" in /pub/DEC/Modula-3/contrib/m3pc: Install.txt please read this first! djgpp.tar the DJGPP-gnu-C-compiler m3.tar compiler binaries m3src.tar sources of the compiler (optional) tar.exe program to unpack these files ======================================================================= 41 === Date: 29 Jan 94 20:05:01 GMT From: toref@dcs.glasgow.ac.uk (Tor Erlend Fagri) Subject: Calling object methods by reference I would like to know the readers opinion on the following problem: Given two objects A and B, maybe of different classes, and given that each of these two objects have access to a reference (the address) of a third object C. How can I make calls in C from both A and B? Or, is it possible? As far as I can read out of the Modula-3 report, the only way to call a method in a object is by direct reference, i.e. .. I my case, objects A and B would be active (threads), wanting to call methods in a passive object C. Thanks for any help. -- Tor E. Faegri (e-mail: toref@dcs.gla.ac.uk) ======================================================================= 42 === Date: Fri, 28 Jan 1994 03:32:05 GMT From: anders@cs.su.oz.au (Anders Lindstrom) Subject: M3 for Solaris Does anyone know if SRC plans to port Modula-3 to the new SPARCserver 1000's running Solaris 3.2? We are looking at using it for undergraduate teaching next year (1995). Thanks in advance, Anders. -- Anders Lindstrom Phone: +61 2 692 4174 Basser Department of Computer Science Fax: +61 2 692 3838 Madsen Building F09 University of Sydney NSW 2006 Australia -- Anders Lindstrom Phone: +61 2 692 4174 Basser Department of Computer Science Fax: +61 2 692 3838 Madsen Building F09 ======================================================================= 43 === Date: Mon, 31 Jan 1994 20:21:56 GMT From: jvichere@undergrad.math.uwaterloo.ca (Jan Vicherek) Subject: Modula3 -> C/++ (for Linux) Hello. Does anybody know anything about a Modula3 -> C/++ translator, eventually it's Linux port ? Thanx, Jan ======================================================================= 44 === Date: 31 Jan 1994 21:26:45 GMT From: schilit@parc.xerox.com (Bill Schilit) Subject: Re: Regular expressions pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma) writes: >Is there regular expression matching implemented for M3?? I looked at >Lex.i3 but couldn't find anything. >Any pointers are appreciated beta.xerox.com:/pub/schilit/m3regex.tar.Z - Bill --