======================================================================= 1 === Date: Tue, 1 Sep 1992 14:37:11 GMT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Modula3 for Windows > ... is that something impossible > > I am a BIG fan of modula2. I have not fallen for modula3 yet since > ... > But the last year I have mostly been programming under MS-Windows and > therefore been forced to change language. > So, does anyone know something? is a Windows version on its way... or it is > just a hopeful dream? Right now nothing is available but this is certainly not impossible. You need the compiler to work under MS-windows or, more likely, Windows NT. With the linear address space offered by Windows NT it should be easier to port DEC SRC Modula 3 or the upcoming GNU Modula 3. Then you also need Trestle to support Windows NT. The X code in Trestle is well separated since it has already been ported from the Firefly/Topaz experimental workstation. The people at DEC SRC even mentioned the possibility of doing the port when Windows NT comes out (Windows NT should be supported on DEC's Alpha architecture). -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 2 === Date: 1 Sep 92 14:46:35 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Modula3 for Windows Well, assuming we get GNU Modula-3 done (gm3), that the djgpp port of gcc can be used as the basis of a Windows gcc, and that someone undertakes to port gm3 using djgpp's machine description and run-time as a starting point, it could all be done. But don't hold your breath. Alternatively, perhaps someone has already done or is working on a port of SRC M3 to windows ..... -- J. Eliot B. Moss, Associate Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================= 3 === Date: 2 Sep 1992 00:28:59 GMT From: lim@soda.berkeley.edu (Lincoln Myers) Subject: What is the current status of GNU Modula 3? Is someone working right now on gm3? Is there a way to find out more about what it is, when it will be, beta testing, all that? Lincoln (modula 3 groupie) ======================================================================= 4 === Date: Wed, 2 Sep 1992 15:15:19 GMT From: hudson@cs.umass.edu (Rick Hudson) Subject: Re: What is the current status of GNU Modula 3? >>>>> On 2 Sep 1992 00:28:59 GMT, lim@soda.berkeley.edu (Lincoln Myers) said: Lincoln> Is someone working right now on gm3? Is there a way to find out more about Lincoln> what it is, when it will be, beta testing, all that? Yes, the gm3 project is alive and well. Right now it consists of the following University of Massachusetts related people: Eliot Moss, Rick Hudson, Amer Diwan, Tony Hosking and Norman Walsh I will only make estimated of when external alpha testing will begin a month after it has begun. Ask me again at the first of the year. The compiler will be a native code compiler utilizing a lot of the gcc backend. One technical paper concerning Modula-3 garbage collection support is easily available @InProceedings{DMH91, author = "Amer Diwan and J. Eliot B. Moss and Richard L. Hudson", title = "Compiler Support for Garbage Collection in a Statically Typed Language", pages = "273--282", booktitle = "Conference on Programming Language Design and Implementation", year = 1992, organization = "SIGPLAN", publisher = "ACM Press", address = "San Francisco, California", month = "June" } Hope this helps. -- Richard L. Hudson, Research Associate University Computing Services Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-1220; Hudson@cs.umass.edu ======================================================================= 5 === Date: 2 Sep 92 22:22:19 GMT From: rhyspj@occs.cs.oberlin.edu (Rhys Price Jones) Subject: Soliciting names for ACM/SIGCSE panelists I am looking for participants in a panel discussion for next year's SIGCSE to discuss issues affecting choice of language in CS1 - the introductory CS course. Please e-mail me suggested names for advocates of your particular favorite introductory language. Anybody know any advocates for oberon? Thanks -- Rhys Price Jones Cyd-athro Cyfrifiaduriaeth ____ Associate Professor Computer Science / / / Oberlin College / / / King 223C /___/ /__ __ Oberlin OH 44074 - USA - UDA / \ / / / / ( (216) 775 8697 / \_/ /_/_/ __) __/_/ ======================================================================= 6 === Date: 3 Sep 92 02:35:34 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: What is the current status of GNU Modula 3? I can expand on Rick Hudson's comments a bit. We have substantial parts of the language compiling the VAX code using the gcc back end. The front end is gcc changed to accept Modula-3 syntax, and considerably enhanced to do two passes to resolve names (as required by Modula-3) and to implement/enforce Modula-3 semantics. Much of the data structure and some of the algorithms are retained from gcc. The back end has been enhanced only to support things not present in C, such as exceptions and garabge collection. Those hard things are all working. It's the raft of little things, such as complete floating point and string support, all the built in functions, etc., etc., that we're mostly into now. With two of us moving to CMU for the year (sabbatical) and a new person being trained up, there's been some disruption, but things are still getting done and I think you might see something without threads by the end of the calendar year. We had hoped for September, but vacations and things had more effect than we anticipated. The garbage collector is indeed running, though, which is more than we could say in June. -- J. Eliot B. Moss, Associate Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================= 7 === Date: Thu, 3 Sep 92 02:27:04 GMT From: muller@bismol.pa.dec.com (Eric Muller) Subject: Modula-3 Frequently Asked Questions (FAQ) Modula-3 Frequently Asked Questions =================================== What is Modula-3 ? The goal of Modula-3 is to be as simple and safe as it can be while meeting the needs of modern systems programmers. Instead of exploring new features, we studied the features of the Modula family of languages that have proven themselves in practice and tried to simplify them into a harmonious language. We found that most of the successful features were aimed at one of two main goals: greater robustness, and a simpler, more systematic type system. Modula-3 descends from Mesa, Modula-2, Cedar, and Modula-2+. It also resembles its cousins Object Pascal, Oberon, and Euclid. Modula-3 retains one of Modula-2's most successful features, the provision for explicit interfaces between modules. It adds objects and classes, exception handling, garbage collection, lightweight processes (or threads), and the isolation of unsafe features. Is Modula-3 a superset of Modula-2 ? No; valid Modula-2 programs are not valid Modula-3 programs. 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 book about Modula3: Modula-3 Samuel P. Harbison Prentice Hall, 1992 ISBN 0-13-596396-6 as well as an overview article, "Modula-3", in Byte, Vol. 15, Number 12, October 1990, p 385. Where can I get information on Modula-3 ? There is a Usenet newsgroup, comp.lang.modula3. The archives of that group are available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/comp.lang.modula3. 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. Where can I get an implementation ? There is only one implementation available today. It has been built by SRC and is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/release. Contributed software can be found in pub/DEC/Modula-3/contrib. The current version, 2.07, 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 IBMR2 IBM R6000 running AIX 3.1, IBMRT IBM RT running IBM/4.3, NEXT NeXT running ? SPARC SPARCstation running SunOS 4.1.x SUN3 SUN3 running SunOS 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. What if I don't have ftp access ? Unfortunately, we cannot deliver Modula-3 other than by anonymous ftp. Your best bet is to post a message to comp.lang.modula3, in the hope that somebody with ftp access can make a tape or floppy for you. 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. -- Eric. -- Eric. ======================================================================= 8 === Date: Thu, 3 Sep 1992 16:04:03 -0400 From: "Vinay K. Chaudhri" Subject: Re: Modula-3 Frequently Asked Questions (FAQ) Would you have any information about the modula2 compiler for SUN SPARC stations? thanks, vinay. ======================================================================= 9 === Date: 3 Sep 92 17:23:04 GMT From: do12+@andrew.cmu.edu (Dick Orgass) Subject: RISC 6000 Binaries for SRC M3 v 2.06 I know that this is somewhat late, but the result may be useful to a few people. A set of binaries (and the public interface sources) for the SRC compiler and all libraries is available for anonymous ftp from emsworth.andrew.cmu.edu in directory m3. The compressed tar file is the only file in the directory so mget * will work just fine. The system is built on the assumption that it is installed in /u/decsrc. If you put it someplace else, just install a symbolic link from /u/decsrc to the actual location. Hope these are a bit useful to a few people. Dick ======================================================================= 10 === Date: Wed, 9 Sep 92 16:42:31 EDT From: Geoff.Wyant@East.Sun.COM (Geoffrey Wyant - Sun BOS SunLabs) Subject: OpenWindows patches for Trestle ? It seems that Trestle causes the OpenWindows X server to crash. While this is undoubtably a bug in OpenWindows, does anyone have any patches to Trestle to work around this ? thanks, geoff Geoff Wyant Sun Laboratories, Inc. wyant@suneast.east.sun.com ======================================================================= 11 === Date: Wed, 9 Sep 1992 20:23:55 GMT From: ryan@ponder.csci.unt.edu (Ryan Stansifer) Subject: Syntax of WITH and TRY After programming some in Modula-3 I have come to think that the WITH and TRY statements are wordy, especially in conjunction with other blocks. In thinking about the language syntax it occurred to me that some simplification may be possible. So, for the sake of argument I offer the following 2 suggestions for expanding the block statement to encompass both the WITH and the TRY statements. Instead of WITH x = e DO S END add a new kind declaration, say, WITH. Now we write: WITH x = e BEGIN S END Now we can mix VAR, CONST, WITH declarations and use only one BEGIN/END block. I think the WITH declarations should be separated by semicolons like other declarations. (There is another, perhaps more important, issue. WITH declarations seem to be used in two distinct ways. One, as READONLY constant r-values. Two, as aliases. Adding READONLY constants is unproblematic, but I would hate to add a new "alias" declaration when they are really READONLY constants of type reference, reference in the C++ sense.) Instead of TRY S EXCEPTION Handler END we could follow the example of Ada and tack on an exception part to the block. Now we write BEGIN S EXCEPTION Handler END This permits declarations can be added to the block without extra BEGIN/END pairs. I do not wish to touch off another language-changing war. I'm just curious about the advantages and disadvantages of different approaches. ======================================================================= 12 === Date: 10 Sep 92 11:14:21 GMT From: joachim@nada.kth.se (Joachim Hollman) Subject: Standard interfaces in M3 - no I/O? After reading Nelson's ``Systems Prpgramming with Modula-3'' I have the impression that the standard intefaces in M3 are 1. Text 2. Thread 3. Word 4. Floating-point while the RECOMMENDED intefaces are 1. Fmt (Textual formatting) 2. Pkl (``pickles'' - binary files, depends on Wr and Rd, see below) 3. Table (Generic hash tables). SRC Modula-3 also provides interfaces for input and output (Wr, Rd, Stdio, FileStream and WrClass), but these are not part of the standard. So the question is: *** Why are the interfaces for input and output not part of the standard? *** ------------------------------------------------------------------------------- Joachim Hollman Royal Institute of Technology Tel. +46 8- 790 7188 Dept of Numerical Analysis and Computing Science Theoretical CS S-100 44 Stockholm Sweden joachim@nada.kth.se -- ------------------------------------------------------------------------------- Joachim Hollman Royal Institute of Technology Tel. +46 8- 790 7188 Dept of Numerical Analysis and Computing Science Theoretical CS - Symbolic Computation Group S-100 44 Stockholm ======================================================================= 13 === Date: Thu, 10 Sep 1992 15:56:11 GMT From: shri@sol.acs.unt.edu (Shrinand Desai) Subject: Re: Modula3 for Windows MBLOMQVIST@finabo.abo.fi (Mikael Blomqvist INF) writes: >... is that something impossible >I am a BIG fan of modula2. I have not fallen for modula3 yet since I have been >using jensen&partner's TopSpeed M2 which includes LONGCARD and such useable >data types. > But the last year I have mostly been programming under MS-Windows and >therefore been forced to change language. > So, does anyone know something? is a Windows version on its way... or it is >just a hopeful dream? >Micke Hello, I am in process(in very initial stages) of porting a subset of M3 on IBM-PC (386 and above using MS_DOS) with the help of DJGPP 32-bit c compiler (which does not support windows 3.1) but does support deskview. But I thought,even a subset of M3 would be very good for PC-world(no threads). Dr. Moss is writing a native compiler for modula-3 using gcc which would be easier to port then DEC M3(IMO). But it is fun anyway. --shri ======================================================================= 14 === Date: 14 Sep 92 06:17:27 GMT From: andru@concerto.lcs.mit.edu (Andrew Myers) Subject: Constructors in Modula-3 I am very fond of Modula-3, but it has one lack that periodically annoys me: it doesn't have constructors. A constructor, in C++ parlance, is a special initializer associated with a class. Objects of that class cannot be created except by using one of the constructors of the class. This restriction allows a class designer to ensure that objects of the class will always be properly initialized. By contrast, if I see the Modula-3 declaration TYPE T <: U; I can write the statement VAR x := NEW(T); and obtain an object that has not been initialized. Maybe it's a valid object of that type; maybe not. Modula-3 programmers, in my experience, handle this problem through the use of conventions and careful documentation. Any interface that describes a Modula-3 type should clearly state what is needed to obtain a valid object of the type. The most obvious and common convention is a "New" procedure. To create an object of type Interface$T, we say VAR x := Interface$New(...) where the "..." represents the arguments that are needed to initialize an object. The approach works until you try to subclass, since the "New" procedure of type "S" with S<:T cannot use T's New to initialize the T part of S. Another standard convention I've seen used is an "init" method. This method is used in the following way: VAR x := NEW(T).init(...) The "init" method is seldom overridden, and doing so is never useful. Consider that "NEW(T).init(...)" is identical to "T.init(NEW(T), ...)" if T reveals that it overrides the "init" method. The fact that "init" is made a method is a matter of convenient notation. Though less efficient, "NEW(T).init()" is easier to type and read than "Interface_T$Init(NEW(T))". Both of these variants avoid the limitations of "New", since the subtype's "Init" procedure can be written as PROCEDURE Init(x: S, S_args...) = BEGIN Interface_T$Init(x, T_args...) (* or Interface_T.T.init(x, T_args...) *) (* Rest of S initialization here *) END Init; All of these solutions require careful programming, since an initialization method must be sure to properly initialize all of the fields of an object, and to properly initialize the supertype. Since Modula-3 guarantees that each field of an object is initialized by the NEW operator to some value of its declared type, all of these solutions also overwrite existing values in the fields. This reinitialization is only a potential inefficiency, since any old garbage is considered to be a valid value of any type. If future implementations choose a more intermediate point on the debuggability/performance curve, the inefficiency will become real. More importantly, ensuring that variables and values are properly initialized is a major source of programming errors, and it is unfortunate that Modula-3 doesn't help the programmer out more. Here is a proposal for constructors in Modula-3, just as food for thought: In any module that fully reveals (i.e., contains "REVEAL T = ... ") an object type T, a "constructor" may be declared. A constructor looks much like a procedure, but it may only be used in the place of the NEW operator, or within another constructor's body . Thus, to create a new object of the type T with a constructor named "Make", we could say VAR x := Make(...) Let T have a supertype named U with a constructor named Make_U and a method named "index", fields named "a" and "b" of types "A" and "B", and a field "i" of type "INTEGER". The constructor implementation syntax looks like: CONSTRUCTOR T Make(a_: A) = VAR tmp := Make_B(); ( Make_U(a_, ....), a := a_, b := tmp, i := tmp.index() ) A constructor body contains a list of comma-separated items. At most one item may be a constructor invocation for some supertype of T. Call this supertype "U". All of the subtypes of U must be fully revealed in the scope of the constructor, implying that a supertype constructor must be used on a subtype of T's closest opaque supertype, if any. Each of the remaining items is an assignment to a field belonging to T, or to a local variable of the constructor. Every field of T that is not contained in U and does not have a default value must be assigned to within the constructor body. Because the object being constructed cannot be named, this approach avoids the problem of defining the semantics of method invocations on a partially constructed object, and the consequent inefficiency that C++ creates during object construction. A constructor can be declared in an interface, and the syntax is similar to procedure-declaration syntax, e.g.: CONSTRUCTOR T Make(a_: A); A call to NEW is just like a constructor body: in addition to the usual override assignments, one of the arguments to NEW(T, ...) may be a constructor invocation. NEW may only be called on an opaque type if a constructor is used. A call to NEW is required to initialize all of T, just as a constructor body is. Thus, x := Make(...) is really just shorthand for x := NEW(T, Make(...)) if "Make" is a constructor for "T". Andrew ======================================================================= 15 === Date: Mon, 14 Sep 92 17:29 MSK From: "MICHAEL I. TROFIMOV" Subject: OOP VS NON-OOP? "INTER-BRIDGE TO OBJECT WORLD." (Preliminary project) In relation to Object Oriented Technologies, the current situation in computing may be characterized by the following. 1) Wide distribution of different Object Oriented approaches. 2) Combining efforts in development of Object Orientation. 3) Many people do not use any Object Oriented technology yet. 4) There is a lot of existent and developed non Object Oriented software. Under these conditions the following attitudes are possible. 1) "agressive": OOP vs (other) programming; 2) "indifferent": non-OO directions are ignored like wrong; 3) "interactive": competition and/or consolidation (integration). The second (indifferent) looks like the least optimal and the third like the most optimal for Object Oriented progress. Support of different interactions between different objects produced from different sources is significant achievement of Object Oriented computing. The possibility to make a bridge between objects is provided by standards and specifications. Special standard and specifications would be necessary to make a bridge between Object Oriented and Procedure Oriented paradigms. The bridge would be useful for adaptation of old applications in modern Object Oriented environment as well as to redesign old sources into Object Oriented design (i.e. to support of continuous processes of software evolution: from Procedure Oriented to Object Oriented paradigm). The very attractive base for the future projects is investigation of common limitations of OOP and of practical troubles, defined with the theoretical restrictions, because just those very cases are the most interesting for comparative analysis of different methodologies to concentrate efforts on non-trivial problems of reality. The enumeration of the typical cases would be interesting also as challenge for Object Oriented industry to promote its progress. There is a theoretical challenge, too. What types of portability between Object Oriented environment and non-OO applications are possible and which of them can support a good OO style? For example, there are well-known hybrid computer languages and tools (Oberon, Turbo Pascal v.6.0, Modula-3 etc.) to support both paradigms. However, it seems as first step only, but not as sufficient decision. Also, it should be pointed out that some important unsolved problems of computer education are closely connected with the subject. MICHAEL I. TROFIMOV, LABORATORY OF COMPUTER CHEMISTRY, N.D.ZELINSKY INSTITUTE OF ORGANIC CHEMISTRY, ACADEMY OF SCI., LENINSKY PROSPECT, 47, 117913, MOSCOW, RUSSIA. FAX: (095) 135-5328 E-MAIL: L447@SUEARN2.BITNET ================= =============== ================= =================================================================== ======================================================================= 16 === Date: Mon, 14 Sep 1992 18:33:41 GMT From: mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) Subject: Re: Constructors in Modula-3 I proposed what I think is a simple solution to this problem a couple months ago, but got no response. My solution was to add a pragma, say <*NO NEW*>, that can be affixed to type declarations in an interface. E.g., INTEFACE foo <*NO NEW*> TYPE T <: U; PROCEDURE New(x: INTEGER): T; END foo. In the presence of this type declaration, NEW cannot be used to create objects of type T. This forces the user of the interface to use whatever constructor procedures are supplied in the interface; in this case "New". (Of course, NEW could still be used inside a module that implements foo.) What I would really like to see is a keywork, say PRIVATE, that does what <*NO NEW*> does. I think it is a mistake in the language design that Modula-3 tries to guess whether NEW should be allowed based on how much is known about a type. Whether NEW is allowed is really orthogonal to whether a type is completely opaque, partly revealed, or fully revealed. -mike ======================================================================= 17 === Date: Mon, 14 Sep 92 15:00:57 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Constructors in Modula-3 An obvious solution (though not very elegant) to the constructor problem is to have an "initialized" flag in the object. This can be set to FALSE by the default initialization. Every method should check this flag and either raise an exception if the flag is unset, or it can dynamically init the object at the first use. Especially the last solution makes NEW act like a constructor, since the actual init method is not exported. Now, if you don't like this, I think we should handle the problem in a more general way. Your suggestion might work for constructors, but at the cost of introducing pretty much new syntax. This overhead could be reduced dramatically if we think of constructors as class methods, i.e. methods which can be applied to non-existing objects. This might look something like TYPE A = OBJECT CLASS METHODS OVERRIDES END; Maybe the distinction between class and object methods could be dropped altogether; I'm not sure if I'd like this. In this case, NEW would loose it's status as standard operator and would become a default for a class constructor. Any new class declaration could override this NEW method by doing a NEW on the superclass and then perform initializations on the object fields. Peter --- Peter Klein E-Mail: pk@rwthi3.informatik.rwth-aachen.de Lehrstuhl fuer Informatik III Tel.: +49/241/80-21320 Ahornstrasse 55 Fax.: +49/241/80-21329 RWTH Aachen D-5100 Aachen Germany ======================================================================= 18 === Date: 15 Sep 92 12:22:37 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Constructors in Modula-3 In article 92Sep14133341@tolstoy.uwaterloo.ca, mhcoffin@tolstoy.uwaterloo.ca (M ichael Coffin) writes: > >I proposed what I think is a simple solution to this problem a couple >months ago, but got no response. My solution was to add a pragma, say ><*NO NEW*>, that can be affixed to type declarations in an interface. >E.g., > > INTEFACE foo > <*NO NEW*> TYPE T <: U; > PROCEDURE New(x: INTEGER): T; > END foo. > >In the presence of this type declaration, NEW cannot be used to create >objects of type T. This forces the user of the interface to use >whatever constructor procedures are supplied in the interface; in this >case "New". (Of course, NEW could still be used inside a module that >implements foo.) > No, *please* no more pragmas. If you want to have a feature in the language standard, then introduce a new keyword. Everything else leads to portability problems. I see a certain use for pragmas if they don't change the semantics of a program, like <* OBSOLETE *> or <* INLINE *>. (What about INLINE anyway? Will it ever be supported?) But what you suggest definetely changes the semantics, and should therefore be a keyword (just like <* EXTERNAL *>, which is actually no pragma either). >What I would really like to see is a keywork, say PRIVATE, that does >what <*NO NEW*> does. I think it is a mistake in the language design >that Modula-3 tries to guess whether NEW should be allowed based on >how much is known about a type. Whether NEW is allowed is really >orthogonal to whether a type is completely opaque, partly revealed, or >fully revealed. > Yes. For constructors, this would be an acceptable solution. Peter --- Peter Klein E-Mail: pk@rwthi3.informatik.rwth-aachen.de Lehrstuhl fuer Informatik III Tel.: +49/241/80-21320 Ahornstrasse 55 Fax.: +49/241/80-21329 RWTH Aachen D-5100 Aachen Germany ======================================================================= 19 === Date: Mon, 14 Sep 1992 05:45:41 GMT From: yost@adobe.com (David Yost) Subject: Re: What is the current status of GNU Modula 3? In article moss@cs.umass.edu writes: >It's the raft of little things, such as complete floating point and string >support, all the built in functions, etc., etc., that we're mostly into now >... I think you might see something without threads by the end of the >calendar year. Hmmm, sounds like you've decided to do floating point before threads. Here's a vote that says you should get something running and out there first, then add threads, then floating point. --dave yost ======================================================================= 20 === Date: Wed, 16 Sep 1992 07:29:43 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: Re: Constructors in Modula-3 Peter Klein writes: > An obvious solution (though not very elegant) to the constructor problem is > to have an "initialized" flag in the object. [... rest of paragraph deleted] This is the automagic init. The user does not have to know whether initializati on is required, and never notices it. I don't think I'ld like to have to put check s in all methods. Also, what if I call a method in an object which doesn't use any methods defined by its ancestors. Then I cannot initialize, unless I can force propagation of the initialization upwards. i.e. I _must_ be able to call the init() method of my ancestors. This can become bothersome if I do not know the full hierarchy, as can happen with partial revelations. > Now, if you don't like this, I think we should handle the problem in a more > general way. Your suggestion might work for constructors, but at the cost > of introducing pretty much new syntax. This overhead could be reduced > dramatically if we think of constructors as class methods, i.e. methods > which can be applied to non-existing objects. > [...] > Maybe the distinction between class and object methods could be dropped > altogether; I'm not sure if I'd like this. In POOL there were METHODs and ROUTINEs. The former were called as object.metho d(), the latter as classname.subr(). The Modula-3 approach is to put Class-methods, or subroutines in the interface exporting the type. Together with the conventio n of calling that type `T', while letting the interface have the descriptive name , the net effect is the same. > In this case, NEW would loose it's status as standard operator and would > become a default for a class constructor. Any new class declaration could > override this NEW method by doing a NEW on the superclass and then perform > initializations on the object fields. I think the difference to having a function procedure called New in the interfa ce is minimal. Greetings, Bert -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null ======================================================================= 21 === Date: Wed, 16 Sep 92 14:14:58 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Constructors in Modula-3 In article 92Sep15145854@tolstoy.uwaterloo.ca, mhcoffin@tolstoy.uwaterloo.ca (M ichael Coffin) writes: >In article <1992Sep15.122237.271@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.in formatik.rwth-aachen.de (Peter Klein) writes: >> ... >> No, *please* no more pragmas. If you want to have a feature in the >> language standard, then introduce a new keyword. Everything else leads >> to portability problems. I see a certain use for pragmas if they don't >> change the semantics of a program, like <* OBSOLETE *> or <* INLINE *>. >> (What about INLINE anyway? Will it ever be supported?) But what you suggest >> definetely changes the semantics, and should therefore be a keyword (just >> like <* EXTERNAL *>, which is actually no pragma either). > >I, too, like a new keyword, but that would involve changing the >standard, which is pretty difficult. Adding a pragma can be done by >merely changing a single implementation. Furthermore, if successfully >implemented and tested, it would add ammunition for introducing a new >keyword in the next version of the standard (if there is one). > I've contributed quite enough about my opinion concerning language changes. Unfortunately, the language designers seem so content about the current state of Modula-3 that I never received an authoritative response to that thread. >And, as pragmas go, <*NO NEW*> is fairly benign. It doesn't introduce >any portability problems that I can see. If you write a program using >a compiler that supports <*NO NEW*>, you can compile it on another >compiler that ignores <*NO NEW*> and everything will work just fine. >On the other hand, if you develop a program using a compiler that >doesn't support <*NO NEW*>, it will certainly work on one that does. > Well, the portability problem that I see is just what you said above: it can be done by changing an implementation instead of changing the standard. >The point is that <*NO NEW*> restricts the language, which merely >makes some otherwise-legal programs illegal. In contrast, ><*EXTERNAL*>, makes some otherwise-illegal programs legal, which is >far more serious and *does* cause portability problems. > Right. EXTERNAL is even worse. Peter --- Peter Klein E-Mail: pk@rwthi3.informatik.rwth-aachen.de Lehrstuhl fuer Informatik III Tel.: +49/241/80-21320 Ahornstrasse 55 Fax.: +49/241/80-21329 RWTH Aachen D-5100 Aachen Germany ======================================================================= 22 === Date: Tue, 15 Sep 1992 19:58:54 GMT From: mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) Subject: Re: Constructors in Modula-3 In article <1992Sep15.122237.271@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.inf ormatik.rwth-aachen.de (Peter Klein) writes: > ... > No, *please* no more pragmas. If you want to have a feature in the > language standard, then introduce a new keyword. Everything else leads > to portability problems. I see a certain use for pragmas if they don't > change the semantics of a program, like <* OBSOLETE *> or <* INLINE *>. > (What about INLINE anyway? Will it ever be supported?) But what you suggest > definetely changes the semantics, and should therefore be a keyword (just > like <* EXTERNAL *>, which is actually no pragma either). I, too, like a new keyword, but that would involve changing the standard, which is pretty difficult. Adding a pragma can be done by merely changing a single implementation. Furthermore, if successfully implemented and tested, it would add ammunition for introducing a new keyword in the next version of the standard (if there is one). And, as pragmas go, <*NO NEW*> is fairly benign. It doesn't introduce any portability problems that I can see. If you write a program using a compiler that supports <*NO NEW*>, you can compile it on another compiler that ignores <*NO NEW*> and everything will work just fine. On the other hand, if you develop a program using a compiler that doesn't support <*NO NEW*>, it will certainly work on one that does. The point is that <*NO NEW*> restricts the language, which merely makes some otherwise-legal programs illegal. In contrast, <*EXTERNAL*>, makes some otherwise-illegal programs legal, which is far more serious and *does* cause portability problems. -mike ======================================================================= 23 === Date: 16 Sep 92 19:24:22 GMT From: andru@concerto.lcs.mit.edu (Andrew Myers) Subject: Constructors in Modula-3 Michael Coffin defines <* NO NEW *>: ... > In the presence of this type declaration, NEW cannot be used to create > objects of type T. ... Presumably this isn't what you actually mean. If you can't call NEW, you can't create objects of type T. Perhaps you wanted to allow NEW within the module implementing the interface in which the <* NO NEW *> pragma occurred? Or within any module in which the type T is revealed? In any case, this pragma doesn't help much. Once you subtype from type T, you are faced with the problem of initializing the "T" part of the subtype. Having a "New" procedure is useless for this task. Andrew ======================================================================= 24 === Date: 17 Sep 92 15:26:40 GMT From: jml@visus.com (Jim Large) Subject: Re: Constructors in Modula-3 In article andru@concerto.lcs.mit.edu (Andrew Myers) writes: > > I am very fond of Modula-3, but it has one lack that periodically > annoys me: it doesn't have constructors. > [...] > Modula-3 programmers, in my experience, handle this problem through the > use of conventions and careful documentation. > [...] > [A] standard convention I've seen used is an "init" method. This > method is used in the following way: > > VAR x := NEW(T).init(...) > > [This approach requires] careful programming, since an > initialization method must be sure to properly initialize all of the > fields of an object, and to properly initialize the supertype. > > [reasons why M3 should have C++-like "constructors" deleted] The "init method" technique is used throughout the NeXTStep (Objective-C) programming environment. It is a WELL established convention. No experienced programmer would ever think of allocating an object without calling one of it's "initializer"s on the same line. Nor would (s)he ever write an initializer that fails to call the super-class's "designated initializer". The init method technique adds *NOTHING* to the language. Compare with C++'s "constructors" which add a pile of semantic baggage, and provide less power in return. ----------------+------------------+------------------------------------ |\ /| | Jim Large | Visual Understanding Systems, Inc. | V | | jml@visus.com | 2100 Wharton St. \_| |__ | (412)488-3600 | Pittsburgh, PA 15203 ======================================================================= 25 === Date: 22 Sep 92 19:12:23 GMT From: frederic@parc.xerox.com (Ron Frederick) Subject: Re: Another installation problem (long) elliottm@beach.csulb.edu (Mike Elliott) writes: >Although I feel I've gotten closer, now I get the message > >*** >*** runtime error: >*** ASSERT failed >*** file "OS.m3", line 109 > >followed by a stack dump of the exception handler. Well, what do I do >now, boss? This problem indicates that the compiler isn't finding one of the programs it runs for intermediate processing. Check your "config" file where you define the various PASS0, PASS1, etc. variables for each of these steps. In particular, note the use of "@" as the separator. This means you can't use "@" in your pathnames, such as "@sys" in AFS. If you need to put in something like @sys, change the separator character to something else. Also, you might want to try running m3 with the -? option to see what all of these things are presently defined as. Hope this helps... -- Ron Frederick frederick@parc.xerox.com ======================================================================= 26 === Date: 23 Sep 92 03:34:57 GMT From: mdixon@parc.xerox.com (Mike Dixon) Subject: yet another installation problem (seg violation compiling RT0.i3) ok, i've managed to get the driver and compiler running on my NeXT machine, but i'm losing when i try to make libm3. here's the (tail of the) output from m3make with -debug: ------------------------------------------------------------ ... new source -> compile ../C/src/generic/M3toC.i3 /m3/lib/m3/m3compiler -F.m3path -w1 -oM3toC_i.c -xM3toC.ix ../C/src/generic/M3t oC.i3 /bin/cc -g -O -I../Csupport/src/generic -I../Csupport/src/NEXT -I/m3/lib/m3 -c M3toC_i.c mv M3toC_i.o M3toC.io rm M3toC_i.c reading final link info for ../C/src/generic/M3toC.i3 reading "M3toC.ix": 0 seconds merging final link info for ../C/src/generic/M3toC.i3 searching library: merging: 0 seconds adding object: M3toC.io new source -> compile ../runtime/src/generic/RT0.i3 /m3/lib/m3/m3compiler -F.m3path -w1 -oRT0_i.c -xRT0.ix ../runtime/src/generic/R T0.i3 /bin/cc -g -O -I../Csupport/src/generic -I../Csupport/src/NEXT -I/m3/lib/m3 -c RT0_i.c mv RT0_i.o RT0.io rm RT0_i.c reading final link info for ../runtime/src/generic/RT0.i3 *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x601 *** *** Quit Stop. ------------------------------------------------------------ any suggestions? thanks... -- .mike. ======================================================================= 27 === Date: 23 Sep 92 03:28:28 GMT From: mdixon@parc.xerox.com (Mike Dixon) Subject: Re: Another installation problem (long) well, i just tried installing m3 on my NeXT machine, and ran into exactly this problem (assert failed on line 109 of OS.m3). in my case i figured out that the problem was that the installation of m3compiler had been interrupted, and it had been left with the wrong mode (for some reason the makefile installs it with mode 644, and then changes it to 755 in a separate operation). since it didn't have the execute bit set, the execvp was failing, which in turn caused the assert failure. .mike. -- .mike. ======================================================================= 28 === Date: 23 Sep 92 13:42:46 GMT From: andersen@reality (Robert Andersen) Subject: Re: Another installation problem (long) In article mdixon@parc.xerox.com (Mike Dixon) writes: > well, i just tried installing m3 on my NeXT machine, and ran into Hey Mike, Where did you get that copy of Modual-3. Don't try to send this to me directly as my mail system is F$$$$$. Robert John Andersen (919) 380-6523 (v,w) andersen%reality@glv.com - NeXT mail! Outside of a dog, a book is man's best friend. Inside of a dog it's to dark to read. ======================================================================= 29 === Date: Thu, 24 Sep 1992 23:31:00 GMT From: cosc18g7@elroy.uh.edu (92F06820) Subject: size of modula3 compiler and source ======================================================================= 30 === Date: Fri, 25 Sep 1992 13:33:37 GMT From: andersen@reality (Robert Andersen) Subject: Re: verifying correct installation In article werts@piggy.cecs.csulb.edu (Michael Werts) writes: > I appear to have finally gotten Modula-3 installed for our DECsystem > 5000/200 at school. Where did you get it from? -- Robert John Andersen (919) 380-6523 (v,w) andersen%reality@glv.com - NeXT mail! Outside of a dog, a book is man's best friend. Inside of a dog it's too dark to read. ======================================================================= 31 === Date: 25 Sep 92 20:14:56 GMT From: rro@CS.ColoState.EDU (Rod Oldehoeft) Subject: Data structures text using M3? We intend to use Modula-3 in the second CS course (data structures) here beginning in the Spring, 1993 semester. It would be fine if there were an appropriate text that also uses M3, but we're having trouble finding such a thing. Perhaps it's too early in the life of M3 to expect this. If you know of one, please let me know. If you know of a manuscript for a book that could benefit from our test-driving it, we'd like to have a discussion about that. ======================================================================= 32 === Date: 25 Sep 92 17:57:06 GMT From: werts@piggy.cecs.csulb.edu (Michael Werts) Subject: Re: verifying correct installation In article <1992Sep25.133337.186@glv.uucp> writes: > In article werts@piggy.cecs.csulb.edu (Michael > Werts) writes: > > I appear to have finally gotten Modula-3 installed for our DECsystem > > 5000/200 at school. > > Where did you get it from? > > -- > Robert John Andersen > (919) 380-6523 (v,w) > andersen%reality@glv.com - NeXT mail! > anonymous ftp from gatekeeper.dec.com. Look in DEC/Modula-3 I think. Check the FAQ for this group. Mike ======================================================================= 33 === Date: Sat, 26 Sep 92 05:03:26 GMT From: muller@src.dec.com (Eric Muller) Subject: Re: yet another installation problem (seg violation compiling RT0.i3) In article , mdixon@parc.xerox.com (Mike Dixon) wri tes: |> ok, i've managed to get the driver and compiler running on my NeXT machine, |> but i'm losing when i try to make libm3. [...] |> any suggestions? thanks... Unfortunately, we do not have access to NeXT machines to see what is going on. You may want to contact Gary Frederick or Drew Dean , who have worked on the NeXT port. -- Eric. ======================================================================= 34 === Date: Sat, 26 Sep 92 12:31:08 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: verifying correct installation In article A7s@beach.csulb.edu, werts@piggy.cecs.csulb.edu (Michael Werts) writ es: >I appear to have finally gotten Modula-3 installed for our DECsystem >5000/200 at school. The "Hello World" example program described in >"How to Use the System" compiled and ran. > >Unfortunately, it also appeared to give an error message during the >compile. > > > cheetah.cecs.csulb.edu> m3 -make -why -o hello Main.m3 A.m3 A.i3 > new source -> compile A.i3 > new source -> compile Main.m3 > new source -> compile A.m3 > program missing -> link hello > > >Is the last line of this message anything to be concerned about? > No, not at all. Due to the -why option you passed to the driver, it explains to you what it is doing and why. And the reason for linking the program hello is simply that the the program didn't exist (just like the reason for compiling the sources was that they were new). So this is no error message, just an explanation. Peter --- Peter Klein E-Mail: pk@rwthi3.informatik.rwth-aachen.de Lehrstuhl fuer Informatik III Tel.: +49/241/80-21320 Ahornstrasse 55 Fax.: +49/241/80-21329 RWTH Aachen D-5100 Aachen Germany ======================================================================= 35 === Date: Thu, 24 Sep 1992 20:43:55 GMT From: werts@piggy.cecs.csulb.edu (Michael Werts) Subject: verifying correct installation I appear to have finally gotten Modula-3 installed for our DECsystem 5000/200 at school. The "Hello World" example program described in "How to Use the System" compiled and ran. Unfortunately, it also appeared to give an error message during the compile. cheetah.cecs.csulb.edu> m3 -make -why -o hello Main.m3 A.m3 A.i3 new source -> compile A.i3 new source -> compile Main.m3 new source -> compile A.m3 program missing -> link hello Is the last line of this message anything to be concerned about? Thanks in advance. Mike (werts@csulb.edu) ======================================================================= 36 === Date: 28 Sep 92 11:06:05 GMT From: rh@ecs.soton.ac.uk (Rachel Harrison) Subject: Re: verifying correct installation In article <1992Sep26.123108.16975@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.i nformatik.rwth-aachen.de writes: >In article A7s@beach.csulb.edu, werts@piggy.cecs.csulb.edu (Michael Werts) wri tes: >>I appear to have finally gotten Modula-3 installed for our DECsystem >>5000/200 at school. The "Hello World" example program described in >>"How to Use the System" compiled and ran. >>......... >>Is the last line of this message anything to be concerned about? > >No, not at all. Due to the -why option you passed to the driver, it explains I've compiler and run this program as well. The only problem is the size of the object file generated, which is nearly 1Mb ! (for "hello world" !) Can anyone tell me how to reduce this ? Rachel Harrison email: rh@ecs.soton.ac.uk Dept. of Electronics and Computer Science, 307 Mountbatten Building, University of Southampton Southampton, SO9 5NH, UK Tel: +44 703 593249 Messages: +44 703 593649 Fax: +44 703 593045 ======================================================================= 37 === Date: Mon, 28 Sep 92 12:43:06 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: large M3 executables (was: verifying correct installation) In article 12942@ecs.soton.ac.uk, rh@ecs.soton.ac.uk (Rachel Harrison) writes: >I've compiler and run this program as well. The only problem is the size >of the object file generated, which is nearly 1Mb ! (for "hello world" !) >Can anyone tell me how to reduce this ? > The problem is the pretty large part of the M3 standard library which is linked into *every* executable, even the "hello world" one: garbage collector, thread scheduler, etc. Although the code size for small examples seems unreasonable, remember that this overhead won't grow with the size of your application. Well, to reduce the size, there are a few possibilities: - compile libm3 with optimization. With gcc, this reduces the code size almost to a half. - strip your executable. - the most elegant way to solve the problem once and for all is to use shared libraries. In this case, libm3 is not linked statically into the executable, so the size of the executable is proportional to the sum of your object file sizes. Unfortunately, not all operating systems can handle shared libraries, but I don't know which. To use shared libraries, you can either extend the m3make templates as suggested some weeks ago in this group. This will give you a shared_library target in the m3makefiles. Personally, I use the following little script for converting the static library into a shared one: #! /usr/public/bin/zsh /bin/ld -o $1:r.so.$2 $(/bin/nm -pg $1 | awk '/^[0-9a-f]* D/{printf " -u " $3 } ') $1 rm $1 touch $1 This works on SunOS, I don't know about others. The script takes two parameters: the name of the static library to be converted and the revision number for the shared library. Note that the static library is reduced to 0 bytes. Peter --- Peter Klein E-Mail: pk@rwthi3.informatik.rwth-aachen.de Lehrstuhl fuer Informatik III Tel.: +49/241/80-21320 Ahornstrasse 55 Fax.: +49/241/80-21329 RWTH Aachen D-5100 Aachen Germany ======================================================================= 38 === Date: Tue, 29 Sep 92 21:41:02 -0700 From: Subject: Re: Data structures text using M3? On 9/25, rro@CS.ColoState.EDU (Rod Oldehoeft) posted the following: We intend to use Modula-3 in the second CS course (data structures) here beginning in the Spring, 1993 semester. It would be fine if there were an appropriate text that also uses M3, but we're having trouble finding such a thing. Perhaps it's too early in the life of M3 to expect this. If you know of one, please let me know. If you know of a manuscript for a book that could benefit from our test-driving it, we'd like to have a discussion about that. There are two books in the works: - Bob Sedgewick at Princeton is doing "Algorithms in M3". It will be similar to the Pascal, C, and C++ version of his text, with the snippits of code in M3. - Joe Bergin at Pace is writing a test for course in Data Abstraction in Modula-3. The latter is probably more what you are after. I don't know the status of the project. Joe's email is BERGINF%PACEVM.bitnet@CUNYVM.CUNY.EDU