======================================================================= 1 === Date: 1 Oct 1993 19:04:07 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. ======================================================================= 2 === Date: 2 Oct 1993 22:21:19 GMT From: steveq@umiacs.umd.edu (Stephen Quirolgico) Subject: Modula* compilers Hi, Does anyone know if there is a Modula* compiler for a SIMD (CM-1), SAMD (CM-5) or Cray T3D? Also, does anyone have any information on the Triton project from the University of Karlsruhe in Germany? -Stephen Quirolgico ======================================================================= 3 === Date: Sun, 3 Oct 1993 23:02:19 GMT From: jmkomine@napier.uwaterloo.ca (John Kominek) Subject: Re: Is there an OS/2 2.x Port for Modula3? In article <1993Sep28.222906.26419@sifon.cc.mcgill.ca>, whitney@oberon.Meakins. McGill.CA () writes: > Craig Kingston (ckingsto@descartes.uwaterloo.ca) wrote: > : Does Anyone know of a port - or a plan to port Modula-3 > to OS/2 2.x. > > It is not M3, but might be helpful as interim solution. > Extacy by RTA makes a very good Modula-2 to C translator. > The same translator also supports Oberon-2 and the languages > can be mixed. ( I use it as Oberon-2 on OS/2 ). > They may or may not have done some work on Modula-3. > > Here is their address. > > Real Time Associates Ltd, Tel : (+44)(0)81 656 7333/4/5 > Canning House, 59 Canning Road, Fax : (+44)(0)81 655 0401 > Croydon,Surrey,CR0 6QF Email : ian@rtal.demon.co.uk > UK Compuserve : 71333,2456 > > > Whitney Do they supply the C compiler or is that for you to do? John Kominek ======================================================================= 4 === Date: 4 Oct 1993 15:08:17 GMT From: mead@bucknell.edu (Jerry Mead) Subject: Modula-3 based CS1 texts??? I posted this question early in the summer and got no replies. So here goes again. Do any of you know of plans for a CS1 text based on Modula-3. Seems that the existence of such a text would end at least some of the C++ vs Modula-2 in CS1/2 wars. Thanks - if anything interesting comes up I will post a summary. jerry --------------------- Jerry Mead Dept of Computer Science Bucknell University Lewisburg, PA 17837 mead@bucknell.edu ======================================================================= 5 === Date: 7 Oct 1993 08:47:02 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: Re: Why structural equivalence? Michael Werts writes: > Subject line says it all. Structural equivalence > strikes me as UNOBJECT-ORIENTED. What is the ^^^^^^^^^^^^^^^^^ Interesting term. Please explain. Perhaps this would require an explanation of what you see as Object-Oriented. PS Objects a-la OBJ also use what can be termed as structural equivalence, be it that not only the data structure, but also the algebraic specification of operators/functions is included. Greetings, Bert -- ------------------------------------------------------------------ Bert Laverman, Dept. of Computing Science, Groningen University Email: laverman@cs.rug.nl Phone: +31-50-633948 Home: bert@rakis.iaf.nl Fax: +31-50-633800 ======================================================================= 6 === Date: 7 Oct 1993 04:02:43 GMT From: werts@beach.csulb.edu (Michael Werts) Subject: Why structural equivalence? Subject line says it all. Structural equivalence strikes me as UNOBJECT-ORIENTED. What is the rationale for structural equivalence in Modula-3? Thanks. -- MICHAEL WERTS -- werts@csulb.edu Computer Engineering Computer Science California State University Long Beach ======================================================================= 7 === Date: 7 Oct 1993 13:37:33 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Why structural equivalence? werts@beach.csulb.edu (Michael Werts) writes: >Subject line says it all. Structural equivalence >strikes me as UNOBJECT-ORIENTED. What is the >rationale for structural equivalence in Modula-3? > Citation from Harbison's Modula-3 book: Modula-3's structural equivalence is considered by some to be one of the language's weaknesses. These people prefer "name equivalence", in which types that are given different names are treated as distinct and cannot accidentally be mixed just because their structure happens to be the same. Under the name equivalence rules used by C, Pascal, and Modula-2, new types come into being when special type constructors are used, such as RECORD ... END, union {}, SET OF ..., etc. However, a simple "renaming" declaration does not create a new type. Consider these declarations: TYPE Apple = RECORD size: REAL END; (* Pascal, Modula-2 *) Orange = RECORD size: REAL END; Lemon = Orange; In Modula-3, Apple, Lemon, and Orange are all the same type. In Pascal, Modula-2, and C, Apple and Orange would be different types, but you could still mix Lemons and Oranges: they're the same type even though they have different names. Furthermore, you can never create "new" integers or floating-point types. So, name equivalence has its own loopholes. Ada takes name equivalence further; you can create "new" integer types by writing TYPE InventoryCode = NEW INTEGER; InventoryCode is not the same as INTEGER. However, since the new type is still an "integers" in some sense, there is a complicated set of rules that allows InventoryCode to inherit many of the INTEGER operations, so that you can assign integer literals to InventoryCode variables, etc. Structural equivalence is easy to explain and is adequately safe in most cases. It is superior to name equivalence when programming distributed systems, in which seperate programs must communicate typed data. There are some important situations in which you want to "disable" structural equivalence to prevent a hidden type from being "guessed"; this is handled in Modula-3 by "branded" types, which are discussed in Chapters 10 and 11. My personal opinion: - Structural equivalence makes life easier in many standard situations. - It does not interfere with information hiding, since opaque types *have* to be branded and are therefore incompatible to all other types. 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 ======================================================================= 8 === Date: Thu, 07 Oct 93 12:56:57 GMT From: will@marvin.or.uni-bonn.de (Hans-Martin Will) Subject: SRC Modula-3 for IBMR2 / RS6000 Does anybody know about an adaption of SRC-Modula-3 to the IBMR2 with all stub modules replaced by "real" working code? Thanks in advance, Martin Will will@marvin.or.uni-bonn.DE ======================================================================= 9 === Date: Thu, 7 Oct 93 13:45:43 EDT From: wewang@rodan.syr.edu (Wen-shyan Wang) Subject: only test Sorry, this is for test. ======================================================================= 10 === Date: 9 Oct 1993 00:09:27 GMT From: mbk%anl433.uucp@Germany.EU.net (Matt Kennel) Subject: Re: Why structural equivalence? Peter Klein (pk@rwthi3.informatik.rwth-aachen.de) wrote: : Structural equivalence is easy to explain and is adequately safe in : most cases. Is a complex number always the same as a two-dimensional vector? No. You can't divide vectors. Structural equivalence also seems to focus too much on data "attributes", and ignores the other half of the object---the methods. Witness the above example. And finally, two things that happen to be structurally equivalent in one implementation may not remain so with subtypes thereof. (Not sure here) It also goes against the "spirit" of the concept of a named type. (You gave it a name for a reason). If you have a langauge that allows one to put new abstract types "over" already existing concrete ones (e.g. Sather), then it seems superfluous, and potentially confusing. : Peter : --- -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego -*** AD: Archive for nonlinear dynamics papers & programs: FTP to -*** lyapunov.ucsd.edu, username "anonymous". ======================================================================= 11 === Date: 9 Oct 1993 01:17:56 GMT From: agulbra@nvg.unit.no (Arnt Gulbrandsen) Subject: Re: Why structural equivalence? In article <294vfnINNr96@network.ucsd.edu>, Matt Kennel wrote: >Structural equivalence also seems to focus too much on data "attributes", >and ignores the other half of the object---the methods. No. Two otherwise equal types with a different set of methods aren't structurally equivalent, merely storage-wise. If both types have a method INTEGER (FLOAT, FLOAT) which does completely different things, they might be structurally equivalent. >It also goes against the "spirit" of the concept of a named type. (You >gave it a name for a reason). If you have a reason to make a type special, you brand it. -- Arnt Gulbrandsen, agulbra@nvg.unit.no This is what's known as a double entendre. -- Arnt Gulbrandsen, agulbra@nvg.unit.no This is what's known as a double entendre. ======================================================================= 12 === Date: 11 Oct 1993 08:55:34 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: Re: Why structural equivalence? Matt Kennel writes: > Is a complex number always the same as a two-dimensional vector? Please! Structural equivalence does not necessarily mean 'ignoring field labels'. Only when you have two record types with equal field names can you start to consider equality, which is what Modula-3 does. > Structural equivalence also seems to focus too much on data "attributes", > and ignores the other half of the object---the methods. Witness the > above example. Please elaborate. What kind of structural equivalence are you attacking here? Methods form a part of an object's structure, at least with M-3. > And finally, two things that happen to be structurally equivalent > in one implementation may not remain so with subtypes thereof. > (Not sure here) Quite. I suppose you mean to say that if A and B are equal (according to struct. eq.) and A' <: A, then the implied A' <: B may not be wanted? If so, then the original A = B was already unwanted, in which case you probably should have branded A and B to make them distinct. > It also goes against the "spirit" of the concept of a named type. (You > gave it a name for a reason). When the choice between named and structural goes to structural, indeed the principles of named will be violated. > If you have a langauge that allows one to put new abstract types "over" > already existing concrete ones (e.g. Sather), then it seems superfluous, > and potentially confusing. I don't know sather, but please keep your comments relevant to the language under discussion. For M-3 structural equivalence works fine. That it may not do so for other languages is irrelevant. Bert ------------------------------------------------------------------ Bert Laverman, Dept. of Computing Science, Groningen University Email: laverman@cs.rug.nl Phone: +31-50-633948 Home: bert@rakis.iaf.nl Fax: +31-50-633800 ======================================================================= 13 === Date: 11 Oct 1993 17:13:26 GMT From: dat93jpe@ludat.lth.se (Jan Persson) Subject: Is there any M3 port to Linux? Just as the headerline says. Is there any port of M3 to Linux? Or is there someone who is working on it? Regards /Janne ======================================================================= 14 === Date: Tue, 12 Oct 1993 15:23:32 GMT From: dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Is there any M3 port to Linux? The upcoming DEC SRC Modula-3 3.0 release is in alpha test right now and supports LINUX directly. The last i heard the Linux port was a bit ahead of the Sparc port :-). It should not be very long. I will announce the availability of binaries on comp.os.linux.announce. -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 15 === Date: 12 Oct 1993 18:06:08 GMT From: madon@disuns2.epfl.ch (Dominik Madon) Subject: M3 for NEXSTEP intel Is there a SRC M3 version (2.x or 3.0) for NEXSTEP intel ? Thanks for answers. Dominik Madon ----------------------------------------------------------------- madon@di.epfl.ch Ecole Polytechnique Federale de Lausanne CH ----------------------------------------------------------------- ======================================================================= 16 === Date: Wed, 13 Oct 1993 07:05:15 GMT From: skj@oasis.icl.co.uk (Simon Johnston) Subject: Re: Is there any M3 port to Linux? Michel Dagenais (dagenais@gutrune.vlsi.polymtl.ca) wrote: : The upcoming DEC SRC Modula-3 3.0 release is in alpha test right now : and supports LINUX directly. The last i heard the Linux port was : a bit ahead of the Sparc port :-). It should not be very long. : I will announce the availability of binaries on comp.os.linux.announce. Please can we have access to ALPHA/BETA code for evaluation / testing. I really want to get my hands on the Linux code to see what sort of performance the compiler / runtime gives. MODULE Sig; FROM ICL IMPORT StdDisclaimer; 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 : 7621 6320 OP Mail: S.K.Johnston@BRA0801|RG12 8TJ | `------------------------------------------------------------------------ *) END Sig. ======================================================================= 17 === Date: Wed, 13 Oct 1993 04:01:35 GMT From: Bob Hathaway Subject: Comp.Object FAQ Version 1.0.3 (10-12) Announcement This announces the October version 1.0.3 of the Comp.Object FAQ! It has many updates and corrections and has several very up-to-date appendices on object- oriented methodologies and systems. It may very well comprise the latest and most up-to-date collection of object-oriented systems and terminology in the world today! New noteworthy additions are the OO methodologies and OOA/OOD sections and ever expanding appendices. Future FAQs will contain a diff file. The FAQ is updated and posted monthly. Comments, suggestions, additions, updates, and new systems and site entries should be sent to rjh@geodesic.com. The FAQ is posted to the comp.object, comp.answers and news.answers newsgroups and is available via anonymous ftp from zaphod.uchicago.edu and rtfm.mit.edu, although new versions may be temporarily found in zaphod's /uploads directory. A hypertext version is also available, see the FAQ for details. Thank you to the many people who have contributed their time and effort into helping this document spread the word about object-oriented technology and available systems! It is hoped it will be most useful in that endeavor. Best Regards! bob ======================================================================= 18 === Date: Wed, 13 Oct 1993 14:12:05 GMT From: george@bcstec.ca.boeing.com (Harry G. George) Subject: M3 in a C/C++ world Thank you to those who responded to my query re running trestle on SUN. The fixes worked. Thank you to those who designed and built trestle, vbt, et al. Looks like a clean, robust approach. OTOH, we live in a C/C++/Motif world. I might be able to sell folks on Modula3 as a replacement for C++, or as a code generator for C. But I can't ignore the growing reuse libraries of Motif-based widgets. (Betamax may have been better than VHS, but VHS won.) Therefore: Does anyone have a set of Motif .i3 files (e.g., following the pattern of the X and Xt interfaces in the M3 release)? If not , is anyone interested in helping prepare a PD version of same? We really need a general C-to-Modula3 translator, which converts .h files to .i3 files. It needs to understand the preprocessor commands, e.g. #include "Abc.h" --> IMPORT Abc; #define abc --> CONST abc = TRUE; #define def 2.345 --> CONST def = 2.345; #define ghi "Hello" --> [in .i3] VAR ghi := CharStar; [in .m3] ghi := TtoS("Hello"); #define jkl (x) (x*3)--> <*INLINE*> PROCEDURE jkl(x:INTEGER):INTEGER = BEGIN RETURN x*3; END jkl; Of course, there is likely to be some hand-tweaking, but a good translator would keep us in the game as more and more C libraries arrive in the market. I built a Perl script which does part of the job. I've been thinking of trying to use TXL or PCCTS to do a more robust job. Sure would like to hear that someone else has already solved it. [Reply to address below] --------------------------------------------------------- Disclaimer: Any opinions expressed herein are my own and not those of The Boeing Company. Contact: Harry George, BCAG Automated Software Analysis Phone: (206) 237-6915 Org: 6-6541 M-S: 6A-UA E-mail: george@garden.ca.boeing.com IP address: 137.137.45.51 ======================================================================= 19 === Date: Wed, 13 Oct 1993 14:24:06 GMT From: dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Is there any M3 port to Linux? Please can we have access to ALPHA/BETA code for evaluation / testing. I really want to get my hands on the Linux code to see what sort of performance the compiler / runtime gives. Well, you do. I dont have any special access to alpha/beta code. I just keep looking around on gatekeeper.dec.com. There is a directory named pub/DEC/Modula-3/alpha-3.0 which i downloaded and somehow managed to modify and compile but could not get to run. While the compiler has been used at DEC SRC for some months, the ports and packaging are, as they are called, "alpha" (documentation missing, ports incomplete...). Personally, i will wait for the next alpha/beta release and as soon as i get something usable i will keep you posted. -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 20 === Date: Thu, 14 Oct 1993 15:44:49 +0000 From: steve@rtal.demon.co.uk (Steve Callins) Subject: Doctor Dobbs Article I dont know how many of you have seen a copy of the October edition of Dr Dobbs. I was excited by their theme, but disappointed by the contents. Please see my following letter to the DDJ editor in chief. Unless I am far wrong, with the exception of Eiffel, none of the alternative to C++ languages reviewed have any global popularity. Ironically, when DDJ hit my desk, I was attending a major International Conference hosted by our Open University here in the UK. This was a workshop on the choice of programming languages. This was attended by over 100 people with speakers drawn from throughout the world. This conference best part mirrored the 'Beyond C++' DDJ thrust, but exemplifying an entirely different set of alternative languages that already have marketplace acceptance. Amongst others, languages covered at this conference were: C++ Modula-2 (pending ISO Standard) Ada Modula-3 (why did not Dobbs cover this?) Extended Pascal (ISO Standard) Oberon (see my letter) Turing (from Canada) Eiffel Smalltalk Lisp Omega (from Austria) CooL (from a huge pan european cooperative effort, backed by Siemens in Germany) Fortran 90 (ISO Standard) All are basically OOP languages - why did not DDJ cover these too? Why do the editorial staff of DDJ not publish an accessible EMAIL address? Any comments that you have about the above and enclosed would we welcome. Steve Collins, RTA London. ----------------Enclosed Letter to Doctor Dobbs------------------------- Jonathan Erickson Editor in Chief Dr. Dobb's Journal 411 Borel Ave San Mateo CA 94022-3522 USA 13th October 1993 Dear Jonathan, Re: DDJ October 1993 issue - please consider the following for letter publication It was good to see that DDJ has finally realised that there are other programming languages in the world than C (and its derivatives), and so your OOP language comparison feature was a welcome change. However, this was xenophobic to the extreme - why just concentrate upon obscure 'made in the USA' languages - and ignore world mainstream, commercial language developments? After all, you must be aware that DDJ is now read Internationally, and so it is a pity that you do not even bother to investigate - let alone report - on what is happening outside of California. As an example, why not report on Oberon-2 language developments? It is a fine, small and application versatile OOP language. It also has the Niklaus Wirth / ETH language and commercial acceptance heritage - Algol, Pascal, Modula-2, and now Oberon-2. Did you know that NASA use Oberon-2? If you would like a well balanced article, on OOP developments then I will happily contribute. With best regards, Steve Collins (Managing Director) ---------------------------------------------------------------------------- -- ---------------------------------------------------------- Steve Collins steve@rtal.demon.co.uk Managing Director 71333.2346@compuserve.com Real Time Associates Ltd CompuServe: 71333,2346 Canning House, 59 Canning Road Tel: (+44) (0)81 656 7333 Croydon, Surrey, CRO 6QF, UK Fax: (+44) (0)81 655 0401 ---------------------------------------------------------- ======================================================================= 21 === Date: 14 Oct 1993 18:17:26 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Doctor Dobbs Article >Amongst others, languages covered at this conference were: > >C++ >Modula-2 (pending ISO Standard) >Ada >Modula-3 (why did not Dobbs cover this?) >Extended Pascal (ISO Standard) >Oberon (see my letter) >Turing (from Canada) >Eiffel >Smalltalk >Lisp >Omega (from Austria) >CooL (from a huge pan european cooperative effort, backed by Siemens > in Germany) >Fortran 90 (ISO Standard) > >All are basically OOP languages - why did not DDJ cover these too? You're wrong. I don't know about Turing, Omega, and CooL, but Modula-2, Ada-83, Extended Pascal, and Lisp are *not* OOP languages. They are at most OOB languages - and Lisp isn't even that. Although there is no real consensus about the term `object oriented', there are some generally accepted definitions. One of the best known ones ist that of [CW85]: "... a language is object-oriented if and only if it satisfies the following requirements: - It supports objects that are data abstractions with an interface of named operations and a hidden local state. - Objects have an associated type. - Types may inherit attributes from supertypes." Another point: why are so many people who use `lesser known programming languages' (which includes me, too) so zealous about propagating their language? Why don't we just do what we're having fun in and look what becomes of the others? Peter [CW85] L. Cardelli and P. Wegner. On Understanding Types, Data Abstraction, and Polymorphism. ACM Computing Surveys vol. 17 (4), pp. 471-520 (1985} --- 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 ======================================================================= 22 === Date: Thu, 14 Oct 1993 15:57:34 -0400 From: Dick Orgass Subject: Re: SRC Modula-3 for IBMR2 / RS6000 I did the original port of SRC Modula-3 to a RISC/6000 when I was still with IBM. The last version that I had fully running was 2.05 and it seemed to work just fine, including Trestle and all the other "friends". Several people at IBM Research continued working on Modula-3 and I hope the will provide you with additional information. Dick ======================================================================= 23 === Date: 14 Oct 1993 21:37:28 GMT From: mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz) Subject: Re: Doctor Dobbs Article Peter Klein (pk@rwthi3.informatik.rwth-aachen.de) wrote: : Ada-83, Extended Pascal, and Lisp are *not* OOP languages. : They are at most OOB languages - and Lisp isn't even that. Oh, CLOS (Common Lisp Object System) is not object oriented? : - It supports objects that are data abstractions with an interface of : named operations and a hidden local state. Supported by CLOS; encapsulation is done with packages. [You could break it by use of low-level functionality, but I consider that similar to taking storage addresses in other languages - useful for a few cases in systems programming, but to avoided elsewhere.] : - Objects have an associated type. Supported by CLOS. : - Types may inherit attributes from supertypes." Supported by CLOS. Btw, CLOS is part of the (draft) ANSI standard for Lisp. In addition, there are many other Lisp variants with different ways supporting oop (according to the above definitions). ------------------------------------------------------------------------------ * wonder everyday * nothing in particular * all is special * Marc Wachowitz ======================================================================= 24 === Date: 15 Oct 1993 11:58:20 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Doctor Dobbs Article >Peter Klein (pk@rwthi3.informatik.rwth-aachen.de) wrote: >: Ada-83, Extended Pascal, and Lisp are *not* OOP languages. >: They are at most OOB languages - and Lisp isn't even that. > >Oh, CLOS (Common Lisp Object System) is not object oriented? > Of course, CLOS is OO. But the intention of my posting was to put terminology right. If we are talking about Lisp, we generally don't mean CLOS. If we are talking about Modula-2, we don't mean any draft of some proposal which might include OO features in the future. If we are talking about object oriented, we don't mean object based. That's all. 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 ======================================================================= 25 === Date: 15 Oct 1993 14:23:52 GMT From: info@xinotech.com (Brian Hanson) Subject: Re: Doctor Dobbs Article > You're wrong. I don't know about Turing, Omega, and CooL, but Modula-2, > Ada-83, Extended Pascal, and Lisp are *not* OOP languages. They are at > most OOB languages - and Lisp isn't even that. There is now Ada 9X which is as much object oriented as c++. You can even get an ada 9x compiler (gnu ada or gnat) for sun sparc and os2 via ftp. ======================================================================= 26 === Date: Fri, 15 Oct 1993 20:57:33 GMT From: papresco@undergrad.math.uwaterloo.ca (Paul Prescod) Subject: Re: Doctor Dobbs Article In article <29k53m$78t@urmel.informatik.rwth-aachen.de>, >Another point: why are so many people who use `lesser known programming >languages' (which includes me, too) so zealous about propagating their >language? Why don't we just do what we're having fun in and look what >becomes of the others? > >Peter 1.If they are popular our bosses will let us use them. 2.They will have optimizing compilers. 3.They will be on more platforms so our code is more portable. 4.There will be more cool tools released for them. 5.We won't have to work with "existing code" in other languages. 6.We won't have to use interfaces to C-geared OS and tool features. 7.A market gives rise to competition. Competition gives rise to better products. 8.We won't have to work with rotten apps that seg fault because of pointer violations. 9.We wouldn't want the product to get cancelled due to lack of interest (this has happened to many languages) 10.We feel sorry for the poor fools who don't know any better. Paul Prescod ======================================================================= 27 === Date: Fri, 15 Oct 1993 15:06:39 GMT From: george@bcstec.ca.boeing.com (Harry G. George) Subject: DDJ article (short) Here is how M3 would look for the DDJ example. See "DDJ article (long)" for the supporting modules. MODULE tstlist EXPORTS Main; (* Public Domain, No Rights Reserved. Abstract: Singly linked list, to demonstrate M3 code Per Dr. Dobbs Journal, 18(11):118-125, Oct 1993 9/8/93 H. George Initial version *) IMPORT Wr,Stdio,MyList,Geometry; VAR list1:=NEW(MyList.T).init(); list2:=NEW(MyList.T).init(); n1:=NEW(Geometry.Number).init(10); n2:=NEW(Geometry.Number).init(20); p1:=NEW(Geometry.Point).init(2,3); p2:=NEW(Geometry.Point).init(4,5); BEGIN (*build the lists*) list1.AddToList(n1); list1.AddToList(n2); list1.AddToList(p1); list2.AddToList(n2); (*an object can be in more than one list*) list2.AddToList(p1); (*at the same time*) list2.AddToList(p2); list2.AddToList(list1); (*we can even put a list into another list*) (*print the lists*) Wr.PutText(Stdio.stdout,"\nlist1:\n"); list1.print(); Wr.PutText(Stdio.stdout,"\nlist2:\n"); list2.print(); (*Note that garbage collector cleans up -- no deletes needed*) (*even if we weren't exiting the whole program at this point*) END tstlist. --------------------------------------------------------- Disclaimer: Any opinions expressed herein are my own and not those of The Boeing Company. Contact: Harry George, BCAG Automated Software Analysis Phone: (206) 237-6915 Org: 6-6541 M-S: 6A-UA E-mail: george@garden.ca.boeing.com IP address: 137.137.45.51 ======================================================================= 28 === Date: Fri, 15 Oct 1993 14:59:31 GMT From: george@bcstec.ca.boeing.com (Harry G. George) Subject: DDJ article (long) The day I saw the DDJ article, I wrote up a Modula-3 treatment. But I didn't want to send it, because I didn't know if this was the best/most appropriate idiom. Obviously, it is more verbose than some of the examples in the article - of course we think of that as self-documenting :-). Maybe someone who know the language better than I could rework this and submit it. In particular, it probably ought to make use of exceptions. ========================================== INTERFACE Geometry; (* Public Domain, No Rights Reserved. Abstract: Geometry for singly linked list, to demonstrate M3 code Per Dr. Dobbs Journal, 18(11):118-125, Oct 1993. 9/8/93 H. George Initial version. *) IMPORT MyList; TYPE Number <: PublicNumber; PublicNumber = MyList.Data BRANDED OBJECT METHODS init(initialValue:INTEGER:=0):Number; END; (*-------------------*) Point <: PublicPoint; PublicPoint= MyList.Data BRANDED OBJECT METHODS init(initialX,initialY:INTEGER:=0):Point; END; END Geometry. =========================================== MODULE Geometry; (* Public Domain, No Rights Reserved. Abstract: Geometry for singly linked list, to demonstrate M3 code Per Dr. Dobbs Journal, 18(11):118-125, Oct 1993. 9/8/93 H. George Initial version. *) IMPORT Wr,Stdio,Fmt,MyList; REVEAL Number = PublicNumber BRANDED OBJECT value:INTEGER; METHODS OVERRIDES init:=InitNumber; print:=PrintNumber; END; Point = PublicPoint BRANDED OBJECT x,y:INTEGER; METHODS OVERRIDES init:=InitPoint; print:=PrintPoint; END; (*-----------------*) PROCEDURE InitNumber(self :Number; initialValue:INTEGER:=0 ):Number = BEGIN self.value:=initialValue; RETURN self; END InitNumber; (*-----------------*) PROCEDURE PrintNumber(self:Number) = BEGIN Wr.PutText(Stdio.stdout,"Number: "&Fmt.Int(self.value)&"\n"); END PrintNumber; (*-----------------*) PROCEDURE InitPoint(self :Point; initialX,initialY:INTEGER:=0 ):Point = BEGIN self.x:=initialX; self.y:=initialY; RETURN self; END InitPoint; (*-----------------*) PROCEDURE PrintPoint(self:Point) = BEGIN Wr.PutText(Stdio.stdout,"Point: " & Fmt.Int(self.x) & "," & Fmt.Int(self.y) & "\n"); END PrintPoint; (*================*) BEGIN END Geometry. =============================================== INTERFACE MyList; (* Public Domain, No Rights Reserved. Abstract: Singly linked list, to demonstrate M3 code Per Dr. Dobbs Journal, 18(11):118-125, Oct 1993. 9/8/93 H. George Initial version. *) TYPE (*In each case, the C++ "public" stuff is visible in **the PublicXyz object, while the "private" stuff is **hidden in its opaque subtyp. Clients use the subtypes. *) (*-------------------*) Data <: PublicData; PublicData = OBJECT METHODS print(); END; (*-------------------*) Element <: PublicElement; PublicElement = OBJECT METHODS init(initialData:Data:=NIL; next:Element:=NIL ):Element; END; (*-------------------*) T <: PublicT; PublicT = Data BRANDED OBJECT METHODS init():T; AddToList(data:Data); END; END MyList. ================================================ MODULE MyList; (* Public Domain, No Rights Reserved. Abstract: Singly linked list, to demonstrate M3 code Per Dr. Dobbs Journal, 18(11):118-125, Oct 1993. 9/8/93 H. George Initial version. *) IMPORT Wr,Stdio,Fmt; REVEAL Data = PublicData BRANDED OBJECT OVERRIDES print:=PrintData; END; Element = PublicElement BRANDED OBJECT data: Data:=NIL; next: Element:=NIL; OVERRIDES init:=InitElement; END; T = PublicT BRANDED OBJECT head,tail:Element:=NIL; OVERRIDES init:=InitT; AddToList:=AddToListT; print:=PrintT; END; (*-----------------*) PROCEDURE PrintData(self:Data) = BEGIN Wr.PutText(Stdio.stdout,"No print method!\n"); END PrintData; (*-----------------*) PROCEDURE InitElement(self :Element; initialData:Data:=NIL; next :Element:=NIL ):Element = BEGIN self.data:=initialData; self.next:=next; RETURN self; END InitElement; (*-----------------*) PROCEDURE InitT(self:T):T = BEGIN self.head:=NIL; self.tail:=NIL; RETURN self; END InitT; (*-----------------*) PROCEDURE AddToListT(self:T; data:Data) = VAR newElement:Element:=NEW(Element).init(data); BEGIN IF (self.head = NIL) OR (self.tail=NIL) THEN self.head:=newElement; self.tail:=newElement; ELSE self.tail.next:=newElement; self.tail:=newElement; END; END AddToListT; (*-------------------*) PROCEDURE PrintT(self:T) = VAR element:Element; BEGIN element:=self.head; WHILE element # NIL DO IF (element.data#NIL) THEN element.data.print(); ELSE Wr.PutText(Stdio.stdout,"NIL list member\n"); END; element:=element.next; END; END PrintT; (*================*) BEGIN END MyList. ============================================= [output] # tstlist list1: Number: 10 Number: 20 Point: 2,3 list2: Number: 20 Point: 2,3 Point: 4,5 Number: 10 Number: 20 Point: 2,3 --------------------------------------------------------- Disclaimer: Any opinions expressed herein are my own and not those of The Boeing Company. Contact: Harry George, BCAG Automated Software Analysis Phone: (206) 237-6915 Org: 6-6541 M-S: 6A-UA E-mail: george@garden.ca.boeing.com IP address: 137.137.45.51 ======================================================================= 29 === Date: 16 Oct 1993 14:16:14 GMT From: kubla@bianca.zdv.Uni-Mainz.DE (Dominik Kubla) Subject: Re: Doctor Dobbs Article : >Peter Klein (pk@rwthi3.informatik.rwth-aachen.de) wrote: : >: Ada-83, Extended Pascal, and Lisp are *not* OOP languages. : >: They are at most OOB languages - and Lisp isn't even that. : > : >Oh, CLOS (Common Lisp Object System) is not object oriented? : > But ADA was part of the DDJ comparison! So if they look at ADA, then there is no argument against checking Modula-2 or Oberon. Since they did not even mentioned those languages, the initial remarks of being a bit narrowminded still holds. BTW Oberon-2 is definitely OO. -- Cheers, Dominik +---------------------------------------------------------------------------+ | eMail: kubla@goofy.zdv.Uni-Mainz.DE | | sMail: Dominik Kubla, Steinsberg 34, 56355 Nast\"atten, F. R. Germany | +---------------------------------------------------------------------------+ | | | "Linux: The choice of a GNU generation" --S. Frampton | | | +---------------------------------------------------------------------------+ DISCLAIMER: Everything written above are the expressed thoughts of the author and in no way connected to 'Johannes Gutenberg Universit\"at', Mainz (Germany). This way, they do not have to care about what I say ... ======================================================================= 30 === Date: 16 Oct 1993 16:47:59 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Doctor Dobbs Article kubla@bianca.zdv.Uni-Mainz.DE (Dominik Kubla) writes: >But ADA was part of the DDJ comparison! So if they look at ADA, then >there is no argument against checking Modula-2 or Oberon. Since they did >not even mentioned those languages, the initial remarks of being a bit >narrowminded still holds. BTW Oberon-2 is definitely OO. > The Doctor Dobbs article was about object-oriented programming languages. Why should they mention Modula-2 there? They didn't mention Oberon, which is European. But they also didn't mention Modula-3, which is American. And how about Smalltalk, Fortran-90, and CLOS? We should keep in mind that the usage of *all* object-oriented languages is pretty negligible compared to Fortran, Cobol, and C. And amongst the OOPLs, C++ has definitely the greatest popularity. Personally, I think this is regrettable, but it's true. 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 ======================================================================= 31 === Date: 16 Oct 1993 21:13:24 GMT From: mbk%anl433.uucp@Germany.EU.net (Matt Kennel) Subject: Re: Doctor Dobbs Article Peter Klein (pk@rwthi3.informatik.rwth-aachen.de) wrote: : kubla@bianca.zdv.Uni-Mainz.DE (Dominik Kubla) writes: : >But ADA was part of the DDJ comparison! So if they look at ADA, then : >there is no argument against checking Modula-2 or Oberon. Since they did : >not even mentioned those languages, the initial remarks of being a bit : >narrowminded still holds. BTW Oberon-2 is definitely OO. : > : The Doctor Dobbs article was about object-oriented programming languages. : Why should they mention Modula-2 there? They didn't mention Oberon, which : is European. But they also didn't mention Modula-3, which is American. : And how about Smalltalk, Fortran-90, and CLOS? Remember; the articles were written by different people, one for each language. I.e. they probably couldn't get somebody to write articles for other languages in time. Smalltalk? People know about it already. F-90? No. CLOS? Too slow. Modula-3 and Oberon are the big omissions. I would have preferred less emphasis on some of those Windows/PC-centric/C-oid/non-garbage-collecting things which seem like a dumb idea. I'm personally rooting for Sather, followed by Eiffel and then M3. : Peter -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego -*** AD: Archive for nonlinear dynamics papers & programs: FTP to -*** lyapunov.ucsd.edu, username "anonymous". ======================================================================= 32 === Date: 17 Oct 93 00:10:44 GMT From: peju@alice.att.com (Peter Juhl) Subject: Re: Doctor Dobbs Article Just one small fact, Dr Dobbs allready ran an article on Modula3, less than a year ago. So if you subscribe then you allready know about Modula3 (or a least you should) The Modula3 article was written by Sam Harbison. --- peter (peju@research.att.com) ======================================================================= 33 === Date: Sun, 17 Oct 1993 12:38:51 GMT From: pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma) Subject: M3 vs Oberon capabilities Can someone tell me what the basic differences are between Modula-3 and Oberon and especially concerning OOP. I've done a lot of programming in C,C++ mainly because I wanted to write graphical simulation programs and the acces to the libraries (X11, Xview, Sunview etc) was up to date when using C and C++. Meanwhile C++ is becoming way to big for me. Just look at the comp.lang.c++, it's like they were born on a different planet. Most of my programs are in C++ and are based on OOP and X11R4-Xview. How easy is it to convert things. Do Modula-3 and/or Oberon support operator-overloading etcetera. How good is there graphical capability. I read about Trestle for M3 but is it worth it? What are the graphical interfaces for Oberon?? Thanks in advance for all the information. (personal e-mail is ok) Paul -- ___ (o o) -----------------------------ooO-(_)-Ooo----------------------------- Paul Sjoerdsma, Godwin Laboratory, Free School Lane, Cambridge CB2 3RS England fax: (44) (0)223-334871, email: pgs1002@cus.cam.ac.uk --------------------------------------------------------------------- ======================================================================= 34 === Date: Sun, 17 Oct 1993 22:31:45 GMT From: kirschnt@informatik.uni-muenchen.de (Torsten R. Kirschner) Subject: Q: M3 alpha-3.0 on axposf.pa.de.com Hello, is there a chance that M3 alpha-3.0 gets installed on axposf.ps.de.com? [For those who don't know: axposf is a publicly accessible DEC Alpha.] I tried to install the compiler, but while I can compile it without any problems, I cannot get it installed. [The install scripts claim that some chgrp doesn't work. Well, I don't want to chgrp to anything at all in the first place...] However, that's more than I achieved on other platforms, even DS3100. I would be happy to get a look at a snapshot of 3.0 on DEC Alpha OSF/1. Couldn't someone at SRC who's working at it put a copy of it on axposf, please? Thanks in advance for any comments, Torsten -- Torsten R. Kirschner Torsten.R.Kirschner@informatik.tu-muenchen.de ======================================================================= 35 === Date: Mon, 18 Oct 1993 10:59:08 GMT From: ross@mama.minmet.uq.oz.au (Ross Cottrell) Subject: Re: Doctor Dobbs Article kubla@bianca.zdv.Uni-Mainz.DE (Dominik Kubla) writes: >But ADA was part of the DDJ comparison! So if they look at ADA, then >there is no argument against checking Modula-2 ... You must be joking. Compared to ADA, Modula-2's support for data data abstraction is pitiful. You don't have OO without data abstraction! Regards, Ross. ======================================================================= 36 === Date: Mon, 18 Oct 1993 03:23:54 GMT From: whitney@oberon.Meakins.McGill.CA () Subject: Re: Doctor Dobbs Article Peter Moylan (peter@laplace.newcastle.edu.au) wrote: : I've been wondering whether we'll gain much by the addition : of OO features to Modula-2. I use a compiler (TopSpeed) which : supports some OO extensions, and so far I've failed to find : anything useful to do with those extensions. I've looked at : the possibility of re-designing some of my modules using an : OO approach, but every time I'm stopped by a nasty problem: : I can't do it without making public some things that I think : ought to be kept private. This is a problem with export control not extensibility. In fact you can have extensibility without exporting fields of an object. The mechanics of extensibility is acheived by passing the required information such as the size of records, the offset of exported fields through symbol files. Eg. Pseudo Modula-2 IMPLEMENTATION MODULE M0; PUBLIC TYPE (* export Object, ObjectRecord *) Object = POINTER TO ObjectRecord; ObjectRecord = RECORD PRIVATE x,y : INTEGER; PUBLIC z : INTEGER; END; TYPE PrivateRecord = RECORD x : INTEGER; END; PUBLIC PROCEDURE Do( obj : Object ); BEGIN END Do; END MODULE M0. Note: This would require that symbol files be generated from a mixture of definition and implementation modules rather than just definition modules as is the case for Modula-2. There is not enough information in the definiton modules to determine the offsets of fields, record sizes, etc as required by OOP. BTW, Other languages such as Oberon ( a successor to Modula-2 ) have a single source which used to generate *.Sym and *.Obj files. Definition modules are also generated. They are not written by the programmer. They are not used for documentation but serve as on-line references for the programmer familiar with the design of the module. Here is the "generated" definition module for the module above. DEFINITION MODULE M0; TYPE Object = POINTER TO ObjRecord; ObjectRecord = RECORD z : INTEGER; END; PROCEDURE Do( obj : Object ); END M0. ======================================================================= 37 === Date: 18 Oct 1993 07:04:41 GMT From: mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz) Subject: Re: Doctor Dobbs Article Peter Moylan (peter@laplace.newcastle.edu.au) wrote: : whitney@oberon.Meakins.McGill.CA wrote: : >BTW, Other languages such as Oberon ( a successor to Modula-2 ) : >have a single source which used to generate *.Sym and *.Obj files. : >Definition modules are also generated. They are not written : >by the programmer. They are not used for documentation but : >serve as on-line references for the programmer familiar : >with the design of the module. : : That's a step backwards, in my opinion. The automatic generators : strip out the comments. What good is a definition module : without comments? I think the problem here is not that the merge of definition and implementation were a bad thing, but the lack of a sufficiently clever documentation tool. What I'd like to see is a convention how to attach public comments to declared entities (including the whole module), which would then be extracted by the browser. There would probably have to be some restrictions on comment formatting, but e.g. choosing between either one-line comments or block comments on lines of their own would be ok. This way you could also embed some other information for automatic cross referencing, like the 'index' entries in Eiffel. ------------------------------------------------------------------------------ * wonder everyday * nothing in particular * all is special * Marc Wachowitz ======================================================================= 38 === Date: Mon, 18 Oct 1993 01:11:43 GMT From: peter@laplace.newcastle.edu.au (Peter Moylan) Subject: Re: Doctor Dobbs Article Peter Klein (pk@rwthi3.informatik.rwth-aachen.de) wrote: >We should keep in mind that the usage of *all* object-oriented languages >is pretty negligible compared to Fortran, Cobol, and C. And amongst the >OOPLs, C++ has definitely the greatest popularity. Personally, I think >this is regrettable, but it's true. And among the C++ users, very few do any OO programming. They use C++ because it's the latest version of C, not for any other reason. I've been wondering whether we'll gain much by the addition of OO features to Modula-2. I use a compiler (TopSpeed) which supports some OO extensions, and so far I've failed to find anything useful to do with those extensions. I've looked at the possibility of re-designing some of my modules using an OO approach, but every time I'm stopped by a nasty problem: I can't do it without making public some things that I think ought to be kept private. -- Peter Moylan peter@tesla.newcastle.edu.au ======================================================================= 39 === Date: Mon, 18 Oct 1993 05:59:12 GMT From: peter@laplace.newcastle.edu.au (Peter Moylan) Subject: Re: Doctor Dobbs Article whitney@oberon.Meakins.McGill.CA wrote: >Peter Moylan (peter@laplace.newcastle.edu.au) wrote: >: I've been wondering whether we'll gain much by the addition >: of OO features to Modula-2. I use a compiler (TopSpeed) which >: supports some OO extensions, and so far I've failed to find >: anything useful to do with those extensions. I've looked at >: the possibility of re-designing some of my modules using an >: OO approach, but every time I'm stopped by a nasty problem: >: I can't do it without making public some things that I think >: ought to be kept private. >This is a problem with export control not extensibility. >In fact you can have extensibility without exporting >fields of an object. The mechanics of extensibility is >acheived by passing the required information such as the >size of records, the offset of exported fields through >symbol files. I agree - but the sort of ideas I've seen thrown around for OO extensions for M2 don't seem to be headed that way. Everyone seems to think that you can't have inheritance unless the parent class is fully elaborated in the definition module. Of course you could start using keywords like PUBLIC and PRIVATE in the definition module, but I don't think that's an adequate solution. The visibility rules could easily turn into the sort of baroque mess you have in C++, especially if the concept of "static members" is included. I much prefer what you're suggesting [example deleted], though I think it ought to be carried a little further: put the visible members in the definition module, and the hidden ones in the implementation module. >Note: This would require that symbol files be generated from a mixture >of definition and implementation modules rather than just definition >modules as is the case for Modula-2. There is not enough >information in the definiton modules to determine the offsets >of fields, record sizes, etc as required by OOP. Oh, if only the standard would allow that! Not so much because I want OOP, but because it would at last remove the stupid rule about opaque types having to be pointers. There's a catch, though: to make this work, you might have to ban circular dependencies among modules. (Not just circularities in the definition modules - these are already banned - but circularities involving the implementation modules.) That wouldn't bother me, since I believe that a circularity in imports is a priori evidence of a design error, but apparently it would bother some people. The new M2 standard takes care to define the order of execution of initialisation parts, and that's a detail that it shouldn't be necessary to specify _unless_ you write programs with circular dependencies. Furthermore, the new standard I/O library modules are specified in such a way that, as far as I can tell, they are fundamentally impossible to implement unless you allow a circular dependency. >BTW, Other languages such as Oberon ( a successor to Modula-2 ) >have a single source which used to generate *.Sym and *.Obj files. >Definition modules are also generated. They are not written >by the programmer. They are not used for documentation but >serve as on-line references for the programmer familiar >with the design of the module. That's a step backwards, in my opinion. The automatic generators strip out the comments. What good is a definition module without comments? On the other hand, Oberon does teach us one valuable lesson: with type extensibility, you can get the advantages of OOP without actually having to go down the OOP path. -- Peter Moylan peter@tesla.newcastle.edu.au ======================================================================= 40 === Date: Mon, 18 Oct 1993 12:37:53 +0000 From: ian@rtal.demon.co.uk (Ian Marshall) Subject: Re: Doctor Dobbs Article In article <1993Oct18.055912.5789@seagoon.newcastle.edu.au> peter@tesla.newcast le.edu.au writes: >That's a step backwards, in my opinion. The automatic generators >strip out the comments. What good is a definition module >without comments? This is completely implementation dependant. For example, our Extacy Oberon-2 implementation (latest release) will now keep selected comments in the pseudo-definition module. You also have a certain degree of control of ordering. For example, in other browsers I have seen (including earlier versions of our own) the order of the pseudo-def was alphabetic (mostly because the symbol file is arranged this way). I always found this irritating as I grouped definitions according to relation of use. >On the other hand, Oberon does teach us one valuable lesson: >with type extensibility, you can get the advantages of >OOP without actually having to go down the OOP path. I don't see what you mean. Oberon (or at least Oberon-2) is definitely object-oriented. Only the 'standard' jargon has been removed. Replace 'type extension' with 'inheritance' (as it is the same thing) and you have 'object-oriented' jargon and functionality. -- ------------------------------------------------------------------------- Ian Marshall, Real Time Associates Ltd, Tel : (+44)(0)81 656 7333/4/5 Canning House, 59 Canning Road, Fax : (+44)(0)81 655 0401 Croydon,Surrey,CR0 6QF Email : ian@rtal.demon.co.uk UK Compuserve : 71333,2456 ------------------------------------------------------------------------- ======================================================================= 41 === Date: 18 Oct 1993 12:52:08 GMT From: dat93rli@ludat.lth.se (Rune Lindman) Subject: Modula 3 for Macintosh Is there a Modula 3 compiler for the Macintosh series? ======================================================================= 42 === Date: Mon, 18 Oct 1993 11:33:41 +0000 From: ian@rtal.demon.co.uk (Ian Marshall) Subject: Re: Doctor Dobbs Article In article <29po5kINNlqi@network.ucsd.edu> mbk%anl433.uucp@Germany.EU.net write s: >Remember; the articles were written by different people, one for >each language. I.e. they probably couldn't get somebody to write articles >for other languages in time. I doubt this very much. This edition was definitely not a one month project. > >Smalltalk? People know about it already. > But introducing new languages wasn't necessarily the aim of the articles. >I would have preferred less emphasis on some of those >Windows/PC-centric/C-oid/non-garbage-collecting things which seem like a >dumb idea. I agree, but unfortunately they're very much the 'in thing'. Unlike skateboards, however, I think they'll take a while to die. -- ------------------------------------------------------------------------- Ian Marshall, Real Time Associates Ltd, Tel : (+44)(0)81 656 7333/4/5 Canning House, 59 Canning Road, Fax : (+44)(0)81 655 0401 Croydon,Surrey,CR0 6QF Email : ian@rtal.demon.co.uk UK Compuserve : 71333,2456 ------------------------------------------------------------------------- ======================================================================= 43 === Date: Mon, 18 Oct 1993 12:23:28 +0000 From: ian@rtal.demon.co.uk (Ian Marshall) Subject: Re: Doctor Dobbs Article In article <1993Oct18.011143.2328@seagoon.newcastle.edu.au> peter@tesla.newcast le.edu.au writes: >And among the C++ users, very few do any OO programming. They >use C++ because it's the latest version of C, not for any >other reason. Not quite. I agree with the fact that they do little OO stuff, basically because to so many C->C++ converts, encapsulation and generally correct abstraction is something that only happens to everybody else. I think that OO programming is often too 'academic' to people who have not been using C properly. These people do, however, use the additional features of C++ such as function overloading and much of the other aspects of (non-inheritance) polymorphism. It odd to see such a powerful tool wasted in the hands of so many. Please, however, never make the mistake of generalising C++ programmers in this way. Many (probably most, now) do use the language properly and to its full extent. > I use a compiler (TopSpeed) which >supports some OO extensions, and so far I've failed to find >anything useful to do with those extensions. I've looked at >the possibility of re-designing some of my modules using an >OO approach, but every time I'm stopped by a nasty problem: >I can't do it without making public some things that I think >ought to be kept private. Oddly enough, to a certain extent the OO features of TopSpeed are pulled from the general ideas of C++'s OO features. They are almost as useful as the C++ approach. The difficulties you are having are probably related to TopSpeeds 2 levels of protection against C++'s 3 levels, and also the difficulties of having separate header and body for classes. -- ------------------------------------------------------------------------- Ian Marshall, Real Time Associates Ltd, Tel : (+44)(0)81 656 7333/4/5 Canning House, 59 Canning Road, Fax : (+44)(0)81 655 0401 Croydon,Surrey,CR0 6QF Email : ian@rtal.demon.co.uk UK Compuserve : 71333,2456 ------------------------------------------------------------------------- ======================================================================= 44 === Date: Mon, 18 Oct 1993 16:37:03 GMT From: hendrik@vedge.com (Hendrik Boom) Subject: Re: Why structural equivalence? mbk%anl433.uucp@Germany.EU.net (Matt Kennel) writes: : : It also goes against the "spirit" of the concept of a named type. (You : gave it a name for a reason). When I talk about real numbers, I often use names like x and y, without implying either that x = y or that x /= y. If I need distinct numbers, I make sure they are different by other means than using different names. If use of different names implied distinctness of value, I would find all kinds of theorems like, given real x and y, x - y /= 0. This would greatly complicate mathematics. I do not see why the situation should be different for types. When reasoning about programs, performing program transformations, etc., one frequently copies code, renames bound variables, etc. This can be dome with types, too, just like variables in algebra. I am pleased that, unlike Pascal and many other languages, modula 3 distinguishes between branding and naming. If I need them distinct, modula 3 provides convenient means of ensuring that they are so. -- ------------------------------------------------------- Try one or more of the following addresses to reply. at work: hendrik@vedge.com, iros1!vedge!hendrik at home: uunet!ozrout!topoi!hendrik ======================================================================= 45 === Date: 19 Oct 93 01:43:48 GMT From: blaak@csri.toronto.edu (Raymond Blaak) Subject: Re: Why structural equivalence? hendrik@vedge.com (Hendrik Boom) writes: >mbk%anl433.uucp@Germany.EU.net (Matt Kennel) writes: >: >: It also goes against the "spirit" of the concept of a named type. (You >: gave it a name for a reason). >...If use of different names implied distinctness of value, >I would find all kinds of theorems like, given real x and y, x - y /= 0. >This would greatly complicate mathematics. >I do not see why the situation should be different for types. >When reasoning about programs, performing program transformations, etc., >one frequently copies code, renames bound variables, etc. This can >be dome with types, too, just like variables in algebra. My problem with structural equivalence is the hidden surprises. If I have two records with fields of identical types, but with different semantic meanings, then by default I prefer to have them treated as distinct unless explicitly stated otherwise. I feel safer when the only operations on a type are those explicitly stated, for then the compiler will catch by default any silly mistakes I make (e.g. passing the wrong type of parameter to a procedure). If I want do describe an algorithm in a type independent way I should build as such explicitly (e.g. via templates or generics, or providing a set of common overloaded operators for a group of types as in algebra, or inheriting from a common parent, etc.). The point is that the only things allowed are those specifically stated. If it is not said, it doesn't happen. In my opinion, this leads to less bugs because of less unexpected surprises. As for reasoning about programs, the programs being reasoned about then become the data, and appropriate types and their operators should be defined to properly state what can and cannot be done when doing such reasoning. Given my preference, if I am to program in Modula-3 I would brand everything unless I specifically needed structural equivalence. Please note I am not particularly knocking Modula-3 here, but rather responding to the structural equivalence thread. Cheers, Ray blaak@csri.toronto.edu ======================================================================= 46 === Date: 18 Oct 1993 21:35:11 GMT From: crawford@boole.mitre.org (Randy Crawford) Subject: Re: M3 vs Oberon capabilities In article , pgs1002@cus.cam.ac.uk (D r P.G. Sjoerdsma) writes: > Can someone tell me what the basic differences are between Modula-3 > and Oberon and especially concerning OOP. Oberon is a version of Modula2 without several of the data types and operators that Wirth thought were largely uneeded by most programmers (and sometimes hard to implement). Oberon is a subset of Modula2, and if M2 is not an OOPL (which it's not) then neither is Oberon. Modula3 adds single inheritance and simple polymorphism. I believe that operator overloading is not supported (which is fine by me). I've heard tell that some sort of extended variant of Oberon exists which *is* an OOPL, but good luck to you finding a compiler. Better to stick with M3 if you feel Modulish. IMHO, Oberon's heyday is past. > I've done a lot of > programming in C,C++ mainly because I wanted to write graphical > simulation programs and the acces to the libraries (X11, Xview, > Sunview etc) was up to date when using C and C++. Meanwhile C++ > is becoming way to big for me. Ditto. A PL is just a tool, not a lifestyle. > Most of my programs are in C++ and are > based on OOP and X11R4-Xview. How easy is it to convert things. Until someone (maybe GNU?) completes a decent PD (public domain) M3 compiler, I'd say it's impossible. DEC's PD M3 is much too large to be taken seriously. I know that several of the design decisions Wirth made with M2 were intended to support C-like efficiency, especially for systems programming. It's highly probable that even a barely-adequate M3 compiler would sport an operational C foreign-function interface. > Do Modula-3 and/or Oberon support operator-overloading etcetera. How good > is there graphical capability. I suspect few graphics libraries will be built expressly for M3 compilers. It's much easier to have the user call directly to C libraries or build their own M3 wrappers around external C functions. > I read about Trestle for M3 but is it > worth it? What are the graphical interfaces for Oberon?? ??? -- | Randy Crawford crawford@mitre.org The MITRE Corporation | 7525 Colshire Dr., MS Z421 | N=1 -> P=NP 703 883-7940 McLean, VA 22102 ======================================================================= 47 === Date: 19 Oct 1993 13:19:15 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: M3 vs Oberon capabilities Puh, it's been quite a time since I saw such an incompetent posting in this group. You have obviously never worked with either of the two languages or even read the FAQs. Why are you posting then? crawford@boole.mitre.org (Randy Crawford) writes: >Oberon is a version of Modula2 without several of the data types and >operators that Wirth thought were largely uneeded by most programmers >(and sometimes hard to implement). Oberon is a subset of Modula2, >and if M2 is not an OOPL (which it's not) then neither is Oberon. >Modula3 adds single inheritance and simple polymorphism. I believe >that operator overloading is not supported (which is fine by me). > Wrong. Oberon features extendible records and thus polymorphism. What Oberon misses is a predefined notion of methods, which one has to implement with procedure variables. Also included in Oberon are garbage collection and multidimensional open arrays. Oberon is definitely not a Modula-2 subset. Dropped from Modula-2 are variant records, enumeration types, FOR loops, and subranges. >I've heard tell that some sort of extended variant of Oberon exists >which *is* an OOPL, but good luck to you finding a compiler. Better >to stick with M3 if you feel Modulish. IMHO, Oberon's heyday is past. > You probably refer to Oberon-2, a successor to Object Oberon. This is a superset of Oberon with some features reintroduced which were dropped in Oberon, like the FOR statement. Also introduced are type-bound procedures, an equivalent to methods. Oberon-2 is freely available from neptune.inf.ethz.ch. >Until someone (maybe GNU?) completes a decent PD (public domain) M3 >compiler, I'd say it's impossible. DEC's PD M3 is much too large to >be taken seriously. > The basic Modula-3 compiler is about 3MB. This is quite the same size as that of gcc. Of course, there is a great bunch of additional libraries, which can be installed optionally. >I suspect few graphics libraries will be built expressly for M3 compilers. >It's much easier to have the user call directly to C libraries or build >their own M3 wrappers around external C functions. > There is an extensive graphic library for Modula-3. On the lowest level there is a simple interface to X11R4. Upon that, there is a basic graphic layer called Trestle, which can be compared to the Athena Widget Set. On the next level, we have VBTKit, a tool collection for Trestle. And for high level graphics, there is FormsVBT, comparable to interviews. I like it, but everbody should evaluate that for himself. I can't say anything about the effort to rewrite existing applications in Modula-3/FormsVBT, since I don't know much about interviews. But it's definitely worth a look. You can find the complete documentation for VBTKit and FormsVBT as well as the Modula-3 compiler on gatekeeper.dec.com. If you want to get a quick overview over Oberon-2 and Modula-3, you might want to look at a paper called "A Comparison of Object-Oriented Programming in Four Modern Languages" by Robert Henderson and Benjamin Zorn from UCB. It's available from their ftp server (ftp.cs.colorado.edu). For more details, take a look at Oberon(-2): Oberon-2 language report, same ftp server as above Niklaus Wirth: From Modula to Oberon, Software - Practice and Experience, 18(7), July 1988 Hanspeter Mossenbock and Niklaus Wirth: The programming language Oberon-2, Structured Programming, 12, 1991 Modula-3: Modula-3 language report (revised), DEC TR 52, 1989 (ftp'able postscript is around, but I've forgotten where) Sam Harbison: Modula-3, Prentice Hall, 1992 Greg Nelson (ed.): Systems Programming with Modula-3, Prentice Hall, 1991 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 ======================================================================= 48 === Date: Tue, 19 Oct 1993 16:26:50 GMT From: whitney@oberon.Meakins.McGill.CA () Subject: Re: M3 in a C/C++ world Bob Strzelinski (strzelin@sscdaq.phy.bnl.gov) wrote: : In article , george@bcstec.ca.boeing.com (Ha rry G. George) writes: : |> We really need a general C-to-Modula3 translator, which converts .h files : |> to .i3 files. It needs to understand the preprocessor commands, e.g. : |> #include "Abc.h" --> IMPORT Abc; : |> #define abc --> CONST abc = TRUE; : |> #define def 2.345 --> CONST def = 2.345; : |> #define ghi "Hello" --> [in .i3] VAR ghi := CharStar; : |> [in .m3] ghi := TtoS("Hello"); : |> #define jkl (x) (x*3)--> <*INLINE*> : |> PROCEDURE jkl(x:INTEGER):INTEGER = : |> BEGIN : |> RETURN x*3; : |> END jkl; : |> : |> Of course, there is likely to be some hand-tweaking, but a good translator : |> would keep us in the game as more and more C libraries arrive in the : |> market. A header file translator might be useful for code that is no going to be rewritten. As for sources themselves, it is often more cost effective to rewrite the code from scratch than use C sources. : This is the most significant roadblock to using m3 in my environment. I do : a lot of GUI work and everyone wants Motif-compliance. Even if they're not : sure what it means. An simple Motif interface library would be sufficient : (if I had the time...) but what would really be nice is something like the : public domain motif++ library which encapsulates all the Motif widgets as : C++ classes. I've found this approach very useful (it's even easier to : learn Motif this way) and it seems a natural approach for an m3 toolkit also. Alternatively, one could design window decorations to make Trestle look like Motif. This would keep end-users happy. There is little advantage in using Motif from a programmers point of view. The system is relatively hard to work with. Whitney ======================================================================= 49 === Date: Tue, 19 Oct 93 16:05:13 GMT From: buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409) Subject: Why structural equivalence? My main reasons to have structural equivalence instead of name equivalence are a) Names If you have structural equivalence you usually have one name for a record. for example TYPE Triple = RECORD x, y, z : LONGREAL; END; You don't create extra names for pointers to this type, but write something like VAR p : REF Triple; VAR pp : REF REF Triple; If instead you have name equivalence, you will have to give explicit names to all these types saying: TYPE Triple = RECORD x, y, z : LONGREAL; TYPE RefTriple = REF Triple; TYPE RefRefTriple = REF RefTriple; ... If you are going to share code, all these definitions have to go into the Interface / Definition Module shared by everyone. And if you later find out you need one more REF, you better have it in your Interface / Definition Module. If not, you either add it there, so everything has to recompile (which is a pain if you are developing distributed), or you add it to one of your private files, whichs gives you problems if someone else needs this type also. b) Access Say someone wrote a type like TYPE Quadruple = REF RECORD a, b, c, d : REAL; END; and you want to store this thing in a list, or a bigger structure. What you want is a type = RECORD a, b, c, d : REAL; END; so you can add it to your own structure TYPE QList = RECORD REF QList next; q; END This really isn't possible with name equivalence. Once someone forgot to name some intermediate type, you are lost. Don't tell me, it doesn't happen, I have seen it more than once. Even in Interfaces distributed with professional Moula2 Compilers / Libraries. And you can't edit them, cause you don't have the source to the libraries. Of cause, I am biased. I leaned programming using Algol68 (at university). Three years later I teached programming to other students using Modula2. Tschuess Andreas -- #include /|) Andreas Buschmann /-|) SEL Stuttgart US/END buschman@us-es.sel.de ======================================================================= 50 === Date: Tue, 19 Oct 1993 00:31:01 GMT From: ihandler@metatron.win.net (Ivan Handler) Subject: Re: Doctor Dobbs Article In article <750947873snz@rtal.demon.co.uk>, Ian Marshall (ian@rtal.demon.co.uk) writes: >In article <1993Oct18.055912.5789@seagoon.newcastle.edu.au> peter@tesla.newcas tle.edu.au writes: > >>That's a step backwards, in my opinion. The automatic generators >>strip out the comments. What good is a definition module >>without comments? > >This is completely implementation dependant. For example, our Extacy >Oberon-2 implementation (latest release) will now keep selected comments >in the pseudo-definition module. You also have a certain degree of control >of ordering. For example, in other browsers I have seen (including earlier >versions of our own) the order of the pseudo-def was alphabetic (mostly >because the symbol file is arranged this way). I always found this >irritating as I grouped definitions according to relation of use. > Tell us more about Extacy, which platforms does it run on? >>On the other hand, Oberon does teach us one valuable lesson: >>with type extensibility, you can get the advantages of >>OOP without actually having to go down the OOP path. > >I don't see what you mean. Oberon (or at least Oberon-2) is definitely >object-oriented. Only the 'standard' jargon has been removed. Replace >'type extension' with 'inheritance' (as it is the same thing) and you >have 'object-oriented' jargon and functionality. > I believe that part of the problem with OOP & Modula is that Modula is a pre-OOP language and a very good one at that. I tend to use data-abstraction via functional parameters in lieu of inheritance. I think this is a perfectly valid way of proceeding that is not in use because of the OOP's popularity (fad??). If you really want to go OOP then Oberon or Eiffel or Ada 9X are languages that were designed around OOP concepts. None of them are as loose or messy as C++. For myself I find Modula to be very powerful and useful in many circumstances and I continue to use it as is. -- Ivan Handler Internet: ihandler@metatron.win.net 2513 N. Central Park CI$: 70705,232 Chicago, IL 60647 Fax: (312) 342-4518 ======================================================================= 51 === Date: Tue, 19 Oct 1993 12:28:23 +0000 From: ian@rtal.demon.co.uk (Ian Marshall) Subject: Re: M3 vs Oberon capabilities In article <29v26f$8k1@newsflash.mitre.org> crawford@boole.mitre.org writes: >I've heard tell that some sort of extended variant of Oberon exists >which *is* an OOPL, but good luck to you finding a compiler. 'Some sort of extended variant of Oberon' is Oberon-2, has been around for some time now, and has many implementations. We supply for just about every platform. Another point to note is that in news and the like the name Oberon is often used to represent the language Oberon-2 (in the same way as many people call Modula-2 Modula, on the basis that the real Modula is no longer really represented and every body knows what you're talking about anyway). The problem is that, as mentioned in an earlier posting, Oberon itself is actually an OS and environment, not just a language - and there is no specific 'Oberon-2' environment. There are of course many implementations of the Oberon and Oberon-2 languages which are freestanding. > Better >to stick with M3 if you feel Modulish. IMHO, Oberon's heyday is past. Which considering your comment about 'some sort of extended variant of Oberon' is not a particularly informed opinion. Oberons 'heyday' hasn't come yet. A de-facto uninformal definition from a conference in September is about to be released (the views of about 40 compiler manufacturers, including ETH, are represented within). Oberon-2 is just catching on and is getting an accelerating following (see comp.lang.oberon if you don't believe me). It appears to me that you have taken the unfortunate path of the C and C++ fanatics who believe that they are using the one and only correct language in the world, and can thereby pass judgement on languages which they clearly know nothing about. -- ------------------------------------------------------------------------- Ian Marshall, Real Time Associates Ltd, Tel : (+44)(0)81 656 7333/4/5 Canning House, 59 Canning Road, Fax : (+44)(0)81 655 0401 Croydon,Surrey,CR0 6QF Email : ian@rtal.demon.co.uk UK Compuserve : 71333,2456 ------------------------------------------------------------------------- ======================================================================= 52 === Date: Tue, 19 Oct 1993 14:47:44 GMT From: strzelin@sscdaq.phy.bnl.gov (Bob Strzelinski) Subject: Re: M3 in a C/C++ world In article , george@bcstec.ca.boeing.com (Harr y G. George) writes: |> Thank you to those who responded to my query re running |> trestle on SUN. The fixes worked. Thank you to those who designed |> and built trestle, vbt, et al. Looks like a clean, robust approach. |> |> OTOH, we live in a C/C++/Motif world. I might be able to |> sell folks on Modula3 as a replacement for C++, or as a code generator |> for C. But I can't ignore the growing reuse libraries of Motif-based |> widgets. (Betamax may have been better than VHS, but VHS won.) Therefore: |> |> Does anyone have a set of Motif .i3 files (e.g., following the pattern |> of the X and Xt interfaces in the M3 release)? If not , is anyone |> interested in helping prepare a PD version of same? |> |> We really need a general C-to-Modula3 translator, which converts .h files |> to .i3 files. It needs to understand the preprocessor commands, e.g. |> #include "Abc.h" --> IMPORT Abc; |> #define abc --> CONST abc = TRUE; |> #define def 2.345 --> CONST def = 2.345; |> #define ghi "Hello" --> [in .i3] VAR ghi := CharStar; |> [in .m3] ghi := TtoS("Hello"); |> #define jkl (x) (x*3)--> <*INLINE*> |> PROCEDURE jkl(x:INTEGER):INTEGER = |> BEGIN |> RETURN x*3; |> END jkl; |> |> Of course, there is likely to be some hand-tweaking, but a good translator |> would keep us in the game as more and more C libraries arrive in the |> market. |> |> I built a Perl script which does part of the job. I've been thinking of |> trying to use TXL or PCCTS to do a more robust job. Sure would like |> to hear that someone else has already solved it. |> |> [Reply to address below] |> --------------------------------------------------------- |> Disclaimer: Any opinions expressed herein are my own and |> not those of The Boeing Company. |> Contact: Harry George, BCAG Automated Software Analysis |> Phone: (206) 237-6915 Org: 6-6541 M-S: 6A-UA |> E-mail: george@garden.ca.boeing.com |> IP address: 137.137.45.51 |> This is the most significant roadblock to using m3 in my environment. I do a lot of GUI work and everyone wants Motif-compliance. Even if they're not sure what it means. An simple Motif interface library would be sufficient (if I had the time...) but what would really be nice is something like the public domain motif++ library which encapsulates all the Motif widgets as C++ classes. I've found this approach very useful (it's even easier to learn Motif this way) and it seems a natural approach for an m3 toolkit also. /////////////////////////////////////////////////////////////////////////////// // Robert J Strzelinski // Brookhaven National Laboratory // // strzelin@sscdaq.phy.bnl.gov // Upton, NY 11973-5000 // /////////////////////////////////////////////////////////////////////////////// ======================================================================= 53 === Date: 19 Oct 93 19:56:15 GMT From: blaak@csri.toronto.edu (Raymond Blaak) Subject: Re: Why structural equivalence? buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409) writes: > If you are going to share code, all these definitions have to go > into the Interface / Definition Module shared by everyone. And if > you later find out you need one more REF, you better have it in > your Interface / Definition Module. If not, you either add it > there, so everything has to recompile (which is a pain if you are > developing distributed), or you add it to one of your private > files, whichs gives you problems if someone else needs this type > also. Presumably if shared code needs one more REF, it also needs operators using that one more REF, and so the interface module needs to be changed anyway. If the use of the shared code doesn't require the extra REF, then having local type definitions of the extra REF won't impact on the use of the shared code. If someone else needs this type they should be able to declare their own local reference type too. > Say someone wrote a type like > TYPE Quadruple = REF RECORD a, b, c, d : REAL; END; > and you want to store this thing in a list, or a bigger structure. > What you want is a type > = RECORD a, b, c, d : REAL; END; > so you can add it to your own structure > TYPE QList = RECORD > REF QList next; > q; > END > This really isn't possible with name equivalence. Once someone > forgot to name some intermediate type, you are lost. In languages with strict name equivalence, it shouldn't be possible to write unnamed intermediate types. Thus there would always be a named record type for one to use. Cheers, Ray blaak@csri.toronto.edu ======================================================================= 54 === Date: Tue, 19 Oct 93 07:44:10 CEST From: g_dotzel@obula.nbg.sub.org (Guenter Dotzel) Subject: Re: Doctor Dobbs Article > This is completely implementation dependant. For example, our Extacy > Oberon-2 implementation (latest release) will now keep selected comments Ian, it's not your Oberon-2 implementation! Extacy may be a trademark of RTA, but RTA did not write the compiler. Guenter ======================================================================= 55 === Date: 20 Oct 1993 09:52:24 GMT From: laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI) Subject: Re: M3 vs Oberon capabilities You might read the paper A Comparison of Modula-3 and Oberon-2 in Structured Programming (1993) 14: 15-22 by L. Boszormenyi The comparison is not exhaustive, concentrates on the most essentila features. 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 ======================================================================= 56 === Date: Mon, 18 Oct 1993 14:30:12 MST From: "D. C. Sessions" Subject: Going in circles In <1993Oct18.055912.5789@seagoon.newcastle.edu.au>, peter@laplace.newcastle.ed u.au (Peter Moylan) wrote: # # whitney@oberon.Meakins.McGill.CA wrote: # >Peter Moylan (peter@laplace.newcastle.edu.au) wrote: # >Note: This would require that symbol files be generated from a mixture # >of definition and implementation modules rather than just definition # >modules as is the case for Modula-2. There is not enough # >information in the definiton modules to determine the offsets # >of fields, record sizes, etc as required by OOP. # # Oh, if only the standard would allow that! Not so much because # I want OOP, but because it would at last remove the stupid # rule about opaque types having to be pointers. # # There's a catch, though: to make this work, you might have to # ban circular dependencies among modules. (Not just circularities # in the definition modules - these are already banned - but # circularities involving the implementation modules.) That # wouldn't bother me, since I believe that a circularity in # imports is a priori evidence of a design error, but apparently # it would bother some people. This seems to be a good launch-point for a thread with some actual content. I seem to recall an example from some while back of modules which pretty well HAD to be circular, but now forget the details. Let's debate the point, "Resolved: circular dependency between implementatuion modules always reflects bad design." --- D. C. Sessions Speaking for myself --- --- Note new network address: dcs@witsend.stat.com --- --- Author (and everything else!) of TMail (DOS mail/news shell) --- ======================================================================= 57 === Date: 20 Oct 1993 13:51:30 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Why structural equivalence? buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409) writes: >With the REF operator / function I mean one keeping the base type. > > F (lvalue : TYPE T) -> rvalue : TYPE TRACED REF T > traced > > F (lvalue : TYPE T) -> rvalue : TYPE UNTRACED REF T > untraced Hmm, if I'm not missing something, there are three possibilities: 1. lvalue is on the stack (variable) and should stay there. Then, rvalue cannot be some REF, since REF points into the heap. The only chance to reference lvalue would be to use the ADR operator, which returns type ADDRESS. 2. lvalue is on the stack and should be put on the heap. Then, rvalue := NEW((UNTRACED) REF T); rvalue^ := lvalue; should do. 3. lvalue is on the heap. Then, you already have a pointer to it. 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 ======================================================================= 58 === Date: Wed, 20 Oct 1993 14:55:37 GMT From: dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Modula 3 for Macintosh Is there a Modula 3 compiler for the Macintosh series? Currently none but the upcoming 3.0 release, in alpha test currently, should be easier to port. -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 59 === Date: Wed, 20 Oct 93 12:48:27 GMT From: buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409) Subject: Re: Why structural equivalence? blaak@csri.toronto.edu (Raymond Blaak) : me : : > If you are going to share code, all these definitions have to go : > into the Interface / Definition Module shared by everyone. And if : > you later find out you need one more REF, you better have it in : > your Interface / Definition Module. If not, you either add it : > there, so everything has to recompile (which is a pain if you are : > developing distributed), or you add it to one of your private : > files, whichs gives you problems if someone else needs this type : > also. : Presumably if shared code needs one more REF, it also needs operators : using that one more REF, and so the interface module needs to be : changed anyway. : If the use of the shared code doesn't require the extra REF, then : having local type definitions of the extra REF won't impact on the use : of the shared code. If someone else needs this type they should be : able to declare their own local reference type too. I usually don't require extra operators or functions, if I am just shuffeling stuff around. What I need is the address operator in C, ADDRESS in Modula2 (which doesn't keep the base type), a missing REF operator or function in Modula3, and just leaving the dereferenciation out in Algol68. With the REF operator / function I mean one keeping the base type. F (lvalue : TYPE T) -> rvalue : TYPE TRACED REF T traced F (lvalue : TYPE T) -> rvalue : TYPE UNTRACED REF T untraced Tschuess Andreas -- #include /|) Andreas Buschmann /-|) SEL Stuttgart US/END buschman@us-es.sel.de ======================================================================= 60 === Date: 21 Oct 93 05:58:57 GMT From: khaw@parcplace.com Subject: Re: Doctor Dobbs Article In <59@metatron.win.net> ihandler@metatron.win.net (Ivan Handler) writes: ... ->inheritance. I think this is a perfectly valid way of proceeding ->that is not in use because of the OOP's popularity (fad??). If ^^^ about as much as Unix is a fad, since they are about the same vintage (roughly). ->you really want to go OOP then Oberon or Eiffel or Ada 9X are ->languages that were designed around OOP concepts. None of them and Smalltalk is chopped liver? -- Michael Khaw khaw@parcplace.com (or khaw%parcplace.com@netcom.com) ParcPlace Systems, Sunnyvale, CA PRODUCT INFO: info@parcplace.com ======================================================================= 61 === Date: Thu, 21 Oct 93 08:41:50 GMT From: buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409) Subject: Re: Why structural equivalence? pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) : me : >With the REF operator / function I mean one keeping the base type. : > : > F (lvalue : TYPE T) -> rvalue : TYPE TRACED REF T : > traced : > : > F (lvalue : TYPE T) -> rvalue : TYPE UNTRACED REF T : > untraced : : Hmm, if I'm not missing something, there are three possibilities: : : 1. lvalue is on the stack (variable) and should stay there. Then, rvalue : cannot be some REF, since REF points into the heap. The only chance : to reference lvalue would be to use the ADR operator, which returns : type ADDRESS. You assume here a traced REF like in the current Implementation of Modula3, which usually points only to the heap. The more generic REF (like in Algol68) may point anywhere. This can be handy sometimes. There are some nice algorithms for linked lists, which require a pointer to the root pointer of the linked list, and then step through, pointing to the next fields. You can of cause run into problems with the lifetime of memory objects. : 3. lvalue is on the heap. Then, you already have a pointer to it. No, I have not necessarily. Lets assume TYPE REC = RECORD x, y, z : INT; END; VAR rec : REF REC := NEW (REC); VAR pin : REF INT := F (rec^.z); Now pin points to the heap, but into the middle of a memory object, not to the beginning of it. You could name this No.4. 4. lvalue is on the heap, but not allocated by new. It is part of something allocated by new. 5. lvalue is in static memory; it either is a (modul) global variable or part of a global variable. (No problems with lifetime here.) But this is really getting away from structural equivalence into the memory concept of languages and memory allocation. Tschuess Andreas -- #include /|) Andreas Buschmann /-|) SEL Stuttgart US/END buschman@us-es.sel.de ======================================================================= 62 === Date: 21 Oct 1993 12:02:02 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Address Operators (was: Why structural equivalence?) buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409) writes: >pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) >: me >: >With the REF operator / function I mean one keeping the base type. >: > >: > F (lvalue : TYPE T) -> rvalue : TYPE TRACED REF T >: > traced >: > >: > F (lvalue : TYPE T) -> rvalue : TYPE UNTRACED REF T >: > untraced >: >: Hmm, if I'm not missing something, there are three possibilities: >: >: 1. lvalue is on the stack (variable) and should stay there. Then, rvalue >: cannot be some REF, since REF points into the heap. The only chance >: to reference lvalue would be to use the ADR operator, which returns >: type ADDRESS. > >You assume here a traced REF like in the current Implementation of >Modula3, which usually points only to the heap. The more generic REF >(like in Algol68) may point anywhere. > Yes, but REF'ed objects being on the heap is not just a SRC m3 implementation detail, it's necessary for the semantics of the language. Let's see what NEW should do: obviously, it cannot allocate something on the stack. The stack's size cannot be expanded arbitrarily at run time. And what should DISPOSE do on the stack? What should the garbage collector do on the stack? I would say he couldn't do anything, since, for stack objects, the property of being garbage or in use has nothing to do with the existence of any pointers to it. >This can be handy sometimes. There are some nice algorithms for linked >lists, which require a pointer to the root pointer of the linked list, >and then step through, pointing to the next fields. > Why do you require a *pointer* to the root pointer? If I walk through a linked list, I initialize the current pointer to the root pointer and advance through the list using the "next" links. >You can of cause run into problems with the lifetime of memory >objects. > Indeed, that's the problem. One important feature which distinguishes stack from heap objects is that stack object lifetimes are determined by their scope, whereas heap object lifetimes are controlled by the dynamic execution path of the program. I don't see a reason to give up this concept. >: 3. lvalue is on the heap. Then, you already have a pointer to it. > >No, I have not necessarily. Lets assume > > TYPE REC = RECORD x, y, z : INT; END; > VAR rec : REF REC := NEW (REC); > VAR pin : REF INT := F (rec^.z); > >Now pin points to the heap, but into the middle of a memory object, not >to the beginning of it. > >You could name this No.4. > >4. lvalue is on the heap, but not allocated by new. It is part of > something allocated by new. > Two points here: - Same thing as above: What if I dispose something right out of the middle of another object? - If it is *intended* to have a pointer to a component of another object, then why not write exactly this? For your example: TYPE REC = RECORD x, y, z := NEW(REF INT); END; VAR rec := NEW(REF REC); VAR pin := rec.z; >5. lvalue is in static memory; it either is a (modul) global variable > or part of a global variable. (No problems with lifetime here.) > Same as above: if you want a pointer, why not use one? 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 ======================================================================= 63 === Date: 21 Oct 1993 08:35:39 -0400 From: thutt@access.digex.net (Taylor Hutt) Subject: Re: Doctor Dobbs Article In article , wrote: >In <59@metatron.win.net> ihandler@metatron.win.net (Ivan Handler) writes: >... >->inheritance. I think this is a perfectly valid way of proceeding >->that is not in use because of the OOP's popularity (fad??). If > ^^^ >about as much as Unix is a fad, since they are about the same >vintage (roughly). > >->you really want to go OOP then Oberon or Eiffel or Ada 9X are >->languages that were designed around OOP concepts. None of them > >and Smalltalk is chopped liver? No, smalltalk is what you do at a party when you see someone of the opposite sex that attracts you. Oh yeah, it was also a computer language of minor importance in the mid 80s. >Michael Khaw khaw@parcplace.com (or khaw%parcplace.com@netcom.com) >ParcPlace Systems, Sunnyvale, CA PRODUCT INFO: info@parcplace.com ^^^^^^^^^^^^^ Yes, I saw where you were from. This is a joke, if you are humor impaired. Taylor "Inappropriate Behavior" Hutt Girls like to dance, guys don't. Guys like sex. Guys dance. -- R. Bessara ======================================================================= 64 === Date: 21 Oct 1993 16:45:20 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: M3 alpha-3.0 on Linux In article , skj@oasis.icl.co.uk (Simon Johnston) w rites: > Having ftp-ed the alpha linux compiler from gatekeeper I am having a number o f > build problems. Yes, it's a known problem. The alpha-3.0 release was intended for a few brave pioneers and the curious browsers. It won't build and install correctly on most platforms. The next release should be much better. I'll announce it when it's released. > Firstly I had problems getting quake to compile, now fixed, > but most important I get an undefined symbol __setjmp, this has meant that > I cannot link any of the code. I am using gcc 2.4.5 and libc 4.4.2, could > someone let me know if this is a known problem ? The problem is that libm3/runtime/src/LINUX/{RTThread.i3,RTThreadC.c} use "_setjmp" instead of "__setjmp". You can get over this problem by replacing "__setjmp" by "___setjmp" in your .ms and .c files. - Bill Kalsow ======================================================================= 65 === Date: Thu, 21 Oct 1993 12:28:39 GMT From: skj@oasis.icl.co.uk (Simon Johnston) Subject: M3 alpha-3.0 on Linux Having ftp-ed the alpha linux compiler from gatekeeper I am having a number of build problems. Firstly I had problems getting quake to compile, now fixed, but most important I get an undefined symbol __setjmp, this has meant that I cannot link any of the code. I am using gcc 2.4.5 and libc 4.4.2, could someone let me know if this is a known problem ? MODULE Sig; FROM ICL IMPORT StdDisclaimer; 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 : 7621 6320 OP Mail: S.K.Johnston@BRA0801|RG12 8TJ | `------------------------------------------------------------------------ *) END Sig. ======================================================================= 66 === Date: 21 Oct 1993 15:42:39 GMT From: heinze@i41s5.ira.uka.de (Ernst A. Heinz) Subject: Modula-2* Environment paper (updated version) available by anonymous f tp For all interested folks we have now made the final version of our MPPM'93 paper publicly available by anonymous ftp. The title of the paper reads as follows: "The Modula-2* Environment for Parallel Programming" (by S.U. Haenssgen, E.A. Heinz, P. Lukowicz, M. Philippsen, and W.F. Tichy). To retrieve PostScript or compressed Postscript versions of the paper please connect to i41s10.ira.uka.de [129.13.13.110] by anonymous ftp. There, the directory pub/m2s contains the corresponding files named mppm93.ps and mppm93.ps.Z. -rw-r----- 1 ftp ftp 557329 Oct 21 15:27 mppm93.ps -rw-r----- 1 ftp ftp 135382 Oct 21 15:27 mppm93.ps.Z Don't forget to use binary mode when retrieving the compressed PostScript versions! Please send us a short email containing your full name and address plus affiliation if you retrieve any of the above. For your information we include the abstract of our MPPM'93 paper below. ------------------------------------------------------------------------------- - THE MODULA-2* ENVIRONMENT FOR PARALLEL PROGRAMMING This paper presents a portable parallel programming environment for Modula-2*, an explicitly parallel machine-independent extension of Modula-2. Modula-2* offers synchronous and asynchronous parallelism, a global single address space, and automatic data and process distribution. The Modula-2* system consists of a compiler, a debugger, a cross-architecture make, graphical X Windows control panel, runtime systems for different machines, and sets of scalable parallel libraries. The existing implementation targets the MasPar MP series of massive ly parallel processors (SIMD), the KSR-1 parallel computer (MIMD), heterogeneous LANs of workstations (MIMD), and single workstations (SISD). The paper describes the important components of the Modula-2* environment and discusses selected implementation issues. We focus on how we achieve a high degree of portability for our system, while at the same time ensuring efficienc y. ------------------------------------------------------------------------------- - In case of any questions or problems, please don't hesitate to contact us directly. Cheers. =Ernst= +--------------------------------------------------------+-------------------+ | Ernst A. Heinz (email: heinze@ira.uka.de) | | | Institut fuer Programmstrukturen und Datenorganisation | Make it as simple | | Fakultaet fuer Informatik, Universitaet Karlsruhe | as possible, but | | Postfach 6980, D-76128 Karlsruhe, F.R. Germany | not simpler. | | (Voice: ++49/(0)721/6084386, FAX: ++49/(0)721/694092) | | +--------------------------------------------------------+-------------------+ ======================================================================= 67 === Date: 21 Oct 1993 12:21:11 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: Re: Why structural equivalence? Andreas Buschmann writes: > Peter Klein: > : 1. ... > You assume here a traced REF like in the current Implementation of > Modula3, which usually points only to the heap. The more generic REF > (like in Algol68) may point anywhere. This is not a 'more generic ref', it is the UNTRACED REF. > This can be handy sometimes. There are some nice algorithms for linked > lists, which require a pointer to the root pointer of the linked list, > and then step through, pointing to the next fields. The usual reason for wanting to do that is that: - you don't have VAR parameters, or (more likely) - you don't have something like objects, and want to simulate a supertype which is known to have a 'next' field as its first member. > You can of cause run into problems with the lifetime of memory > objects. Which is why taking the ADR() of something may only be done in UNSAFE MODULEs in Modula-3. Same for LOOPHOLEing and pointer arithmatic. > : 3. ... > No, I have not necessarily. Lets assume > > TYPE REC = RECORD x, y, z : INT; END; > VAR rec : REF REC := NEW (REC); > VAR pin : REF INT := F (rec^.z); > Now pin points to the heap, but into the middle of a memory object, not > to the beginning of it. So: TYPE REC = RECORD x, y, z : INTEGER; END; VAR rec : UNTRACED REF REC; VAR pin : UNTRACED REF INTEGER; ... rec := NEW(UNTRACED REF REC); pin := ADR(rec^.z); This is valid (though UNSAFE) Modula-3. See '2.7 Unsafe operations', page 59 in SPwM3. > You could name this No.4. > 4. lvalue is on the heap, but not allocated by new. It is part of > something allocated by new. > 5. lvalue is in static memory; it either is a (modul) global variable > or part of a global variable. (No problems with lifetime here.) These are both coverd by the ADR() function. Greetings, Bert -- ------------------------------------------------------------------ Bert Laverman, Dept. of Computing Science, Groningen University Email: laverman@cs.rug.nl Phone: +31-50-633948 Home: bert@rakis.iaf.nl Fax: +31-50-633800 ======================================================================= 68 === Date: Thu, 21 Oct 1993 18:07:43 +0000 From: catalogue@rtal.demon.co.uk (Electronic Sales Dept) Subject: Catalogue Available ------------------------------------------------------------------------ Modula-2, Oberon-2, Fortran-90, C++ catalogues available by Email ------------------------------------------------------------------------ Autumn 1993 RTA Catalogue Catalogues are in ascii text form, of conveniently email-able size, consisting of brief product descriptions, prices, details of how to obtain more full product descriptions and email order information. Send your request to: catalogue@rtal.demon.co.uk Stating clearly : Programming language you are interested in - M2, O2, F90, C++ Platforms you are interested in - DOS, OS/2, Unix (all), Windows/NT, VMS, Macintosh, Amiga, Archimedes, Cross/Embedded Your Email address State whether academic or commercial organisation (optional) Your actual address,telephone, fax Catalogues will be distributed from Monday 25th October 1993 ------------------------------------------------------------------------ ======================================================================= 69 === Date: 22 Oct 93 11:29:14 From: hosking@cs.umass.edu (Tony Hosking) Subject: Alpha 3.0 installation Has anyone had any success in building and installing the SRC Modula-3 Alpha 3.0 release on a DECstation? Everything built OK (with a few minor tweaks), but the driver seems to be misconfigured---"m3 -\?" produces the following output: pass 0 := *UNDEFINED*pass 1 := *UNDEFINED*pass 2 := *UNDEFINED*pass 2 base := pass 3 := *UNDEFINED*pass 4 := *UNDEFINE D*pass 6 := def path := lib path := include := server limit := 0 megabytesmake mode := FALSEbootstrap := FALSEstd libs := TRUE ke ep files := FALSEcoverage := FALSE resolve libs := FALSE-O => - g => which certainly doesn't look right. I checked the template file I am using and it certainly appears to have the right configuration information for the driver. I'd really appreciate any tips folks might have. -- Tony Hosking Papernet: Dept. of Computer Science University of Massachusetts _--_|\ Amherst, MA 01003 / \ Voicenet: (413) 545-0256 \_.--._/ ) Faxnet: (413) 545-1249 v / Internet: hosking@cs.umass.edu ======================================================================= 70 === Date: 23 Oct 1993 11:11:11 GMT From: heinze@i41s5.ira.uka.de (Ernst A. Heinz) Subject: Availability of Modula-2* Programming Environment After putting the updated version of our MPPM'93 paper on ftp I received several mails asking for the availability of our Modula-2* Programming Environment. Because this might be of public interest I now post an answer to the net. "The Modula-2* people (email: msc@ira.uka.de) at the University of Karlsruhe, F.R.G., are currently preparing a new version of their Modula-2* programming environment to be publicly released at the end of November. The upcoming release will consist of binaries for DECStations and SparcStations. Target architectures include the MasPar MP series, the KSR-1, and several sequential Unix workstations." We will announce the availability of the new version on the net as soon as it is ready for public release. So please stay tuned! Cheers. =Ernst= +--------------------------------------------------------+-------------------+ | Ernst A. Heinz (email: heinze@ira.uka.de) | | | Institut fuer Programmstrukturen und Datenorganisation | Make it as simple | | Fakultaet fuer Informatik, Universitaet Karlsruhe | as possible, but | | Postfach 6980, D-76128 Karlsruhe, F.R. Germany | not simpler. | | (Voice: ++49/(0)721/6084386, FAX: ++49/(0)721/694092) | | +--------------------------------------------------------+-------------------+ ======================================================================= 71 === Date: Sun, 24 Oct 1993 16:20:07 GMT From: pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma) Subject: getting SRC-reports Can anyone tell me how to get a SRC report, in this case about Trestle and FormsVBT. I mailed them at: src-report@src.dec.com twice now but no reply. Thanks in advance. -- ___ (o o) -----------------------------ooO-(_)-Ooo----------------------------- Paul Sjoerdsma, Godwin Laboratory, Free School Lane, Cambridge CB2 3RS England fax: (44) (0)223-334871, email: pgs1002@cus.cam.ac.uk --------------------------------------------------------------------- ======================================================================= 72 === Date: Sun, 24 Oct 1993 23:12:01 GMT From: kirschnt@informatik.uni-muenchen.de (Torsten R. Kirschner) Subject: Re: getting SRC-reports pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma) writes: >Can anyone tell me how to get a SRC report, in this case about Trestle >and FormsVBT. I mailed them at: >src-report@src.dec.com >twice now but no reply. Another way to retrieve them in electronic form is this ftp server, gatekeeper.dec.com:/pub/DEC/SRC/research-reports This directory holds a lot of the DEC SRC reports (and also an index to them). Torsten -- Torsten R. Kirschner Torsten.R.Kirschner@informatik.tu-muenchen.de ======================================================================= 73 === Date: Thu, 21 Oct 1993 15:12:51 GMT From: grp@dmu.ac.uk (Graham Perkins) Subject: Re: Doctor Dobbs Article > Message-ID: <29tf69$2qi@darum.uni-mannheim.de> -Peter Moylan (peter@laplace.newcastle.edu.au) wrote: -: whitney@oberon.Meakins.McGill.CA wrote: -: >BTW, Other languages such as Oberon ( a successor to Modula-2 ) -: >have a single source which used to generate *.Sym and *.Obj files. -: >Definition modules are also generated. They are not written -: >by the programmer. They are not used for documentation but -: >serve as on-line references for the programmer familiar -: >with the design of the module. -: -: That's a step backwards, in my opinion. The automatic generators -: strip out the comments. What good is a definition module -: without comments? - -I think the problem here is not that the merge of definition and -implementation were a bad thing, but the lack of a sufficiently clever -documentation tool. What I'd like to see is a convention how to attach -public comments to declared entities (including the whole module), which -would then be extracted by the browser. There would probably have to be -some restrictions on comment formatting, but e.g. choosing between either -one-line comments or block comments on lines of their own would be ok. -This way you could also embed some other information for automatic cross -referencing, like the 'index' entries in Eiffel. Yup, I think the documentation tool is the key issue here. The point is that interface and implementation are two different views of the same object: a proc/fn/type collection. Our Eiffel (2.3) gives two views: interface (via "short") and full implementation (via "cat", "vi", or any other dumb viewing tools). There is only one underlying object corresponding to the single proc/fn collection. Modula-2 designers assumed you would have no tools other than editors and file-systems, so you have to do all the work yourself. By the way, the "short" view of Eiffel includes exported names and signatures first comment from each proc/fn pre & post condition of each proc/fn class invariant of each class (module/type) index clause Perhaps we should expect even more sophisticated view. For example, maybe our viewer should offer separate control over each of the above kinds of information. Also, ability to define different visibility to different clients could be incorporated into viewer, i.e., viewer becomes a client. My own preference is for everything to be done via views, with viewing tool generating the source code when you hit the compile button. But then it might look like Smalltalk, and non-Smalltalkers (Bigtalkers?) would complain! Surely syntax errors should be one such view. And what about static analysis info? Or maybe even dynamic profiling? We should demand tools in which all this kind of info is integrated and available through the same interface. I built my own crude tools years back for doing modular programming with Pascal and no units/environments/modules or nothing, except INCLUDE directives. So my make tool took source code of supplier module, found type/fn/proc defs and comments and put them in a "def" file with "extern" for every proc/fn. I had much fun trying to work out clever rules for outputting definitions or ignoring them. In the end, I went back to my first and simplest idea: "export" anything starting at start-of-line, and leave the rest hidden. No key words embedded in special constants, no special flags on command line, no module description language to invent.. ======================================================================= 74 === Date: Mon, 25 Oct 93 14:55:25 GMT From: buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409) Subject: Re: Address Operators (was: Why structural equivalence?) I (Andreas Buschmann) wrote: : 1. ab> You assume here a traced REF like in the current Implementation of ab> Modula3, which usually points only to the heap. The more generic REF ab> (like in Algol68) may point anywhere. Bert Laverman wrote: bl> This is not a 'more generic ref', it is the UNTRACED REF. nope, in Algol68 you have garbage collection. You can not have heap memory objects which are not garbage collected in Algol68. Peter Klein wrote: pk> Yes, but REF'ed objects being on the heap is not just a SRC m3 pk> implementation detail, it's necessary for the semantics of the pk> language. why? I didn't find anything in the report which required that any traced reference is on the heap. pk> Why do you require a *pointer* to the root pointer? If I walk through pk> a linked list, I initialize the current pointer to the root pointer pk> and advance through the list using the "next" links. To be able tho change the root pointer. (while inserting and deleting) ab> You could name this No.4. ab> 4. lvalue is on the heap, but not allocated by new. It is part of ab> something allocated by new. ab> 5. lvalue is in static memory; it either is a (modul) global variable ab> or part of a global variable. (No problems with lifetime here.) bl> These are both coverd by the ADR() function. no, ADR() is unsafe and doesn't keep the underlying type. pk> If it is *intended* to have a pointer to a component of another pk> object, then why not write exactly this? For your example: pk> TYPE REC = RECORD x, y, z := NEW(REF INT); END; pk> VAR rec := NEW(REF REC); pk> VAR pin := rec.z; This gives you four memory elements instead of one. This is might be ok for big elements x, y, z. This is not that a good idea if your model says that the lifetime of all four memory elements is the same. For having lvalue in static memory this wouldn't work any more. x, y and z would be on the heap then. Tschuess Andreas -- #include /|) Andreas Buschmann /-|) SEL Stuttgart US/END buschman@us-es.sel.de ======================================================================= 75 === Date: 25 Oct 1993 13:41:19 GMT From: gwyant@cloyd.east.sun.com (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: Re: Address Operators (was: Why structural equivalence?) >From Andreas Buschmann: Peter Klein wrote: pk> Yes, but REF'ed objects being on the heap is not just a SRC m3 pk> implementation detail, it's necessary for the semantics of the pk> language. why? I didn't find anything in the report which required that any traced reference is on the heap. Well strictly speak, the word 'heap' is not used in the description of traced references. However, it state: When all traced references to a piece of storage are gone, the implementation reclaims the storage. While this does not logically entail that traced references cannot point to stack allocated entities, I imagine it would be safe reading. By the same token, I think there is the implication (though not entailment) that traced references cannot point to static entities. --geoff -- Geoff Wyant Geoff.Wyant@east.sun.com Sun Microsystems Laboratories, Inc. 2 Elizabeth Drive Chelmsford, Ma. 01824 ======================================================================= 76 === Date: Mon, 25 Oct 93 07:39:09 -0700 From: mhb@src.dec.com ("Marc H. Brown") Subject: Re: getting SRC-reports You can get SRC Research Reports via ftp from gatekeeper.dec.com, in the directory /pub/DEC/SRC/research-reports. This information is also available via the World Wide Web. Some reports are videotapes or contain color images; for those, you should send email to src-report@src.dec.com, or write to "Report Distribution, Digital Systems Research Center, 130 Lytton Ave., Palo Alto, CA 94301." You can also get (electronic) notification of SRC Reseach Reports; send email to src-report@src.dec.com. Trestle is documented in SRC Research Report #68, and there's a tutorial in #69. FormsVBT doc isn't a SRC Report yet; you can get it from the Modula-3 distribution on gatekeeper in /pub/DEC/Modula-3/release/formsvbt.*.ps.Z ======================================================================= 77 === Date: 26 Oct 93 10:36:58 From: mday@note.lcs.mit.edu (Mark Day) Subject: Separate interface (was Re: Doctor Dobbs Article) grp@dmu.ac.uk (Graham Perkins) writes: Yup, I think the documentation tool is the key issue here. The point is that interface and implementation are two different views of the same object: a proc/fn/type collection. Our Eiffel (2.3) gives two views: interface (via "short") and full implementation (via "cat", "vi", or any other dumb viewing tools). There is only one underlying object corresponding to the single proc/fn collection. Modula-2 designers assumed you would have no tools other than editors and file-systems, so you have to do all the work yourself. I've worked for a number of years in CLU: its associated methodology makes a distinction between interface and implementation, but in typical practice a single file is used for both. When working in Modula-3 I've found that the need to write an interface distinct from the implementation has helped me in creating good modular designs. It's also been useful to have a distinct interface in situations where I've had multiple implementations of a type, typically because I was testing the performance of different implementation strategies. These benefits surprised me; my initial reaction to Modula-3 was to criticize the separate interface as just annoying busywork. I don't claim that everyone will have this experience; I suspect it's dependent on the programmer's personality and style. But I don't believe that separating the interface out is due only to assumptions about tool availability. --Mark Day mday@lcs.mit.edu ======================================================================= 78 === Date: Tue, 26 Oct 1993 17:32:15 GMT From: whitney@oberon.Meakins.McGill.CA () Subject: Re: Separate interface (was Re: Doctor Dobbs Article) Mark Day (mday@note.lcs.mit.edu) wrote: : grp@dmu.ac.uk (Graham Perkins) writes: : I've worked for a number of years in CLU: its associated methodology : makes a distinction between interface and implementation, but in : typical practice a single file is used for both. : When working in Modula-3 I've found that the need to write an : interface distinct from the implementation has helped me in creating : good modular designs. It's also been useful to have a distinct : interface in situations where I've had multiple implementations of a : type, typically because I was testing the performance of different : implementation strategies. It is just as easy to prototype designs using languages based on single source file ( such as Oberon ) by implementing the specification using a module with empty procedures. : These benefits surprised me; my initial reaction to Modula-3 was to : criticize the separate interface as just annoying busywork. Having switched from Modula-2 to Oberon, I find that using seperate interfaces to be tedious and dangerous. ( It is possible to change the definition of a module without changing its implementation ). I dislike the dependence on system utilities ( make files, project builders ) to enforce the agreement of module interfaces and implementations. Oddly, enough I have fewer compliants ( the personality thing ) when using similar tools to check the compilation order of modules. Whitney ======================================================================= 79 === Date: Wed, 27 Oct 1993 00:02:11 GMT From: William Burrow Subject: Re: Separate interface (was Re: Doctor Dobbs Article) In article <1993Oct26.173215.4573@sifon.cc.mcgill.ca> whitney@oberon.Meakins.Mc Gill.CA () writes: >: These benefits surprised me; my initial reaction to Modula-3 was to >: criticize the separate interface as just annoying busywork. > >Having switched from Modula-2 to Oberon, I find that using >seperate interfaces to be tedious and dangerous. ( It is possible to >change the definition of a module without changing its implementation ). Well, I'd be second-guessing N. Wirth by noting that seperate interfaces permit a top-down design approach. Haven't quite figured out Oberon's hints yet :) so don't know if that technique is affected. (Not that I use that technique.) Will. ------------------------------ William Burrow Internet: t0fg@unb.ca | If a USENET could net will@p1.f100.n255.z1.fidonet.org | ewes, how many ewes Fidonet: 1:255/100.1 | could a USENET net? ======================================================================= 80 === Date: Thu, 28 Oct 1993 12:25:34 GMT From: bwbecker@watdragon.uwaterloo.ca (Byron Weber Becker) Subject: GenList.mg bug The procedures Find and FindIf in the library file GenList.mg have a bug. When GenList is instantiated with a non-reference type (eg: INTEGER) the compiler (rightly) refuses to compile val : Elt.T := NIL; There doesn't seem to be a work-around without changing the interface since NIL is used to signal failure. With non-reference types there is no sure-fire value to return as a failure. Byron Weber Becker -- ----------------------------------------------------------------------------- Byron Weber Becker bwbecker@watdragon.uwaterloo.ca ----------------------------------------------------------------------------- ======================================================================= 81 === Date: Thu, 28 Oct 1993 13:42:30 GMT From: huw@dcs.gla.ac.uk (Huw Evans) Subject: Modula-3 books Can you direct me to some good modula3 books. I am also interested in books th at deal with the object oriented design and analysis of problems as a separate top ic from modula3 although books that deal with them together are OK. Also, do you know of any books that describe how to management an object oriented project ? Please mail me directly Thanks ======================================================================= 82 === Date: 29 Oct 93 13:12:51 GMT From: fn00@gte.com (Farshad Nayeri) Subject: Re: M3 alpha-3.0 on Linux tIn article <2a6eb0$h01@src-news.pa.dec.com> kalsow@src.dec.com (Bill Kalsow) w rites: Yes, it's a known problem. The alpha-3.0 release was intended for a few brave pioneers and the curious browsers. It won't build and install correctly on most platforms. Any brave pioneers want to share their experience with the SPARC 3.0 distribution on the net? I am anxious to get it up and running here; unfortunately, I am too busy that I can't spend time on it right now. Thanks, --farshad -- Ensuring a working environment is everyone's responsibility. ======================================================================= 83 === Date: Sat, 30 Oct 1993 19:41:21 GMT From: pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma) Subject: formsvbt Display problem I have a problem with running formsedit etc.; when I try to run the program my screen blanks and the following message appears: 'XIO fatal IO error 32 on X server ":0.0" -- stuff deleted the conection was probably broken by a server shutdown or KillClient. /usr/openwin/bin/xinit: connection to X serever lost. XIO: fatal IO error 32 on X server ":0.0" after 869 requests (869 known processed) with 0 events remaining. -- stuff deleted' What has happened???? System: sun SPARCclassic OS : SunOs4.1.3C gcc 2.5.0 olwm window manager Modifications: I included -static -lXmu to go around a well known library bug. This was added in 'toplevel.tmpl' as -X2@-static@. This seems to work ok. Can someone tell me what gas gone wrong, or am I just ignorant or overlooked the obvious? Please mail directly since I installed M3 at my new machine which won't be on the net until december, so I won't have much time to use GNUS. Anyway I'll repost the answers. Thanks Paul -- ___ (o o) -----------------------------ooO-(_)-Ooo----------------------------- Paul Sjoerdsma, Godwin Laboratory, Free School Lane, Cambridge CB2 3RS England fax: (44) (0)223-334871, email: pgs1002@cus.cam.ac.uk --------------------------------------------------------------------- ======================================================================= 84 === Date: Sun, 31 Oct 1993 15:14:43 GMT From: pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma) Subject: mgkit compile-time error Thanks to some friendly folks out here, I got trestle working. Unfortunately I got another error: Compiling mgkit: MGRd.ir error: 'as: "/usr/tmp/cca13282.s", line 8: error: location counter not on word boundary' 'as.. same for line 14' I use gcc-2.5. I tried some things: I adapted the /usr/lang/lib/m3/config file: -- removed optimize flagse (-O) -- changed CC=gcc to CC=cc Nothing works Answers are appreciated!! Thanks, Paul -- ___ (o o) -----------------------------ooO-(_)-Ooo----------------------------- Paul Sjoerdsma, Godwin Laboratory, Free School Lane, Cambridge CB2 3RS England fax: (44) (0)223-334871, email: pgs1002@cus.cam.ac.uk --------------------------------------------------------------------- ======================================================================= 85 === Date: 31 Oct 1993 10:22 PST From: skulski@csa5.lbl.gov (Wojtek Skulski, LBL phone: (510) 486 7791) Subject: Re: M3 vs Oberon capabilities In article <29v26f$8k1@newsflash.mitre.org>, crawford@boole.mitre.org (Randy Crawford) writes... > >I've heard tell that some sort of extended variant of Oberon exists >which *is* an OOPL, but good luck to you finding a compiler. Better >to stick with M3 if you feel Modulish. IMHO, Oberon's heyday is past. To find a good Oberon compiler would be easy. Just look into neptune.inf.ethz.ch, directory Oberon. There are freeware implementations there for MS-DOS, Windows, Mac, Sun, IBM-6000, Silicon Graphics, HP, Amiga, .... And the list is growing. There are also several commercial implementations available for different platforms. Look at the README file in the same directory for vendor info. As for the free ETH implementations, they all are incarnations of the same complete operating environment containing a powerful multifont wordprocessor integrated with a graphics/drawing program, which enables figures to be embedded into text documents. This is pretty impressive by itself, especially because these figures are live and freely editable "on spot". Not only figures, but live elements of different kinds, like pop-up menus, animated clocks, hypertext links and so on. Did you ever compile a program containing a ticking clock as a part of a comment ? Not only fun, but it also opens interesting new horizons as for the way applications are designed and put together. And what's equally amazing: each of these Oberon implementations is packed into about 1 MB. In this amount of disk space there is a complete graphic environment, wordprocessor, graphic package, compiler, linker and lots of documentation. In view of all this Randy's comment is both ill-informed and unwarranted. > >| Randy Crawford crawford@mitre.org The MITRE Corporation >| 7525 Colshire Dr., MS Z421 >| N=1 -> P=NP 703 883-7940 McLean, VA 22102 Wojtek Wojtek Skulski, Lawrence Berkeley Laboratory, 1 Cyclotron Rd, MS 71-259 Berkeley, CA 94720. SKULSKI@LBL.bitnet (Disclaimer: my opinions are my own.) ======================================================================= 86 === Date: Sat, 30 Oct 93 21:11:45 GMT From: gjarvis@timfcbk.isis.org (Greg Jarvis) Subject: Re: Separate interface (was Re: Doctor Dobbs Article) mday@note.lcs.mit.edu writes in article : > > grp@dmu.ac.uk (Graham Perkins) writes: > > Yup, I think the documentation tool is the key issue here. The point > is that interface and implementation are two different views of the > same object: a proc/fn/type collection. Our Eiffel (2.3) gives two > views: interface (via "short") and full implementation (via "cat", "vi", > or any other dumb viewing tools). There is only one underlying object > corresponding to the single proc/fn collection. Modula-2 designers > assumed you would have no tools other than editors and file-systems, > so you have to do all the work yourself. The most important reason for separate files is the software engineer can restrict a programmer from changing an interface to suite his owns needs by simply giving read only access to the interface file. > When working in Modula-3 I've found that the need to write an > interface distinct from the implementation has helped me in creating > good modular designs. It's also been useful to have a distinct > interface in situations where I've had multiple implementations of a > type, typically because I was testing the performance of different > implementation strategies. This second reason results in good modular design resulting in code that usually can be reused.