======================================================================== 1 === Date: Wed, 2 Oct 91 14:15:31 PDT From: antoy@cs.pdx.edu (Sergio Antoy) Subject: Modula 3 on the Sequent Is there an official or unofficial port of Modula 3 on a Sequent? If yes, is it either for PTX or Dynix? Thanks. Sergio Antoy Portland State University P.O.Box 751 Portland, OR 97207 voice +1 (503) 725-3009 fax +1 (503) 725-3221 internet antoy@cs.pdx.edu ======================================================================== 2 === Date: 2 Oct 91 21:13:52 GMT From: antoy@antares.cs.pdx.edu (Sergio Antoy) Subject: Modula 3 on the Sequent Is there an official or unofficial port of Modula 3 on a Sequent? If yes is either for PTX or Dynix? Thanks. Sergio Antoy Portland State University P.O.Box 751 Portland, OR 97207 voice +1 (503) 725-3009 fax +1 (503) 725-3221 internet antoy@cs.pdx.edu ======================================================================== 3 === Date: 3 Oct 91 23:06:32 GMT From: lins@Apple.COM (Chuck Lins ) Subject: Productivity of Type-Safe Languages (First some background info) I recently spent a week in a series of classes on programming for System 7.0 (Apple's fancy new OS for the Mac). You had your choice of programming language for the various exercises: Pascal or C. There were maybe 12 people in this class. Two of us used Pascal. Then others used C. In all the exercises, never once did my programs drop into the debugger. It seemed however that this happened often with the C programmers. Not real scientific, but perhaps this is representative of the current state in programming. (Now for the real part) At the recent Modula2 conference there was one paper titled something like "Modula-2 is 3 times better than C". It took a look at the kinds of errors made by various programmers in each language. The result was that the Modula compiler found more errors at compile-time than the C compiler. Thus, the C programmers found their errors at run-time (at least a larger percentage of the total number of errors). Of course, we all know this. (Now for the imaginary part) The members of these newsgroups all know the refrain "type-safe is better". And I'm certain there are many other advantages to both Modula-3 and Oberon/Oberon- 2. The problem is how to convinve the rest (or at least a significant number) of the programming community that this is so AND they are willing to use them in everyday work. The major omission of the aforementioned paper is that it wasn't able to measure the impact of language on the development cycle and schedule. And it seems to me that neither Modula-3 nor Oberon-2 will amount to anything more than a footnote in the pages of programming language history unless there is some _measureable_ benefit. The marketing "hype" of type-safe is better won't sell to a programming development manager [maybe to a few, but not many]. What's needed is a good study that says "modula-3 saved us $$$ in the development of our great product. and it's also why it's so reliable." Sonething like that will sell these languages in the minds of managers and programmers (well lots of libraries will keep the latter happy :-) So here's a plea to the research community to demonstrate to everyone else that these languages really are better than C (and everyone's favorite C++). Don't let M3 and O2 go down the dead-end where M2 ended up. Let me close with: "Build a better programming language and the world will _not_ beat a path to yo ur door." Chuck Lins -- Chuck Lins | "Shut up! Be happy!" -- Jello Biafra Apple Computer, Inc. | Looking for RISC Oberon compiler job. 20525 Mariani Avenue | Resume available on request. Mail Stop 58-C | Internet: lins@apple.com Cupertino, CA 95014 | ======================================================================== 4 === Date: Fri, 4 Oct 91 11:35:09 PDT From: muller@src.dec.com (Eric Muller) Subject: Modula-3 FAQ MODULA-3 FAQ ============ What is Modula-3 ? The goal of Modula-3 is to be as simple and safe as it can be while meeting the needs of modern systems programmers. Instead of exploring new features, we studied the features of the Modula family of languages that have proven themselves in practice and tried to simplify them into a harmonious language. We found that most of the successful features were aimed at one of two main goals: greater robustness, and a simpler, more systematic type system. Modula-3 descends from Mesa, Modula-2, Cedar, and Modula-2+. It also resembles its cousins Object Pascal, Oberon, and Euclid. Modula-3 retains one of Modula-2's most successful features, the provision for explicit interfaces between modules. It adds objects and classes, exception handling, garbage collection, lightweight processes (or threads), and the isolation of unsafe features. There is an overview article "Modula-3", by Sam Harbison, in Byte, Vol. 15, Number 12, October 1990, p 385. Is Modula-3 a superset of Modula-2 ? No; valid Modula-2 programs are not valid Modula-3 programs. Where can I get a definition of Modula-3 ? The definition of Modula-3 is contained in: System Programming with Modula-3 Edited by Greg Nelson Prentice Hall Series in Innovative Technology ISBN 0-13-590464-1 L.C. QA76.66.S87 1991 Previous definitions were published as SRC Reports # 31 and 52 and can be obtained on paper from SRC by sending a message to src-report@src.dec.com. Report # 52 is also available in PostScript format via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/report. Where can I get information on Modula-3 ? There is a Usenet newsgroup, comp.lang.modula3. The archives of that group are available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/comp.lang.modula3. The messages sent to comp.lang.modula3 are relayed to a mailing list; send a message to m3-request@src.dec.com to be added to it. Also, Pine Creek Software publishes a free newsletter and various announcements about Modula-3 products and activities. To be added to their mailing list, send email or US mail to: Pine Creek Software Suite 300 305 South Craig Street Pittsburgh, PA 15213 Phone & Fax: [1] (412) 681 9811 Email: modula3@bert.pinecreek.com Where can I get an implementation ? There is only one implementation available today. It has been built by SRC and is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/m3-1.6. The current version, 1.6, implements the language defined in the SRC report # 52. Version 2.0 is in the works and will implement the latest definition. Version 1.6 runs on: Acorn R260 running RISC iX 1.21 Apollo DN4500 running Domain/OS, DECstation 3100 and 5000 running Ultrix 4.0 and 4.2 Encore Multimax running UMAX 4.3 (R4.1.1) HP 9000/300 running HP-UX 8.0 IBM PC running AIX/PS2, IBM RT running IBM/4.3, IBM R6000 running AIX 3.1, VAX running Ultrix 3.1 SPARCstation running SunOS 4.1.x SUN3 running SunOS SRC Modula-3 includes a user manual, compiler, runtime library, core library, pretty-printer, and a few other goodies. The libraries include interfaces for X11R4, I/O streams, string functions, access to command line arguments, random numbers, and operating system access. The compiler generates C as an intermediate language and should be fairly easy to port. Except for the very lowest levels of the thread implementation, the entire system is written in Modula-3. What if I don't have ftp access ? You can contact Pine Creek Software (see the address above). ---- Eric. ======================================================================== 5 === Date: 4 Oct 91 14:47:36 GMT From: schoebel@bs5.informatik.uni-stuttgart.de (Thomas Schoebel) Subject: Re: Productivity of Type-Safe Languages In article <58163@apple.Apple.COM> lins@Apple.COM (Chuck Lins ) writes: > So here's a plea to the research community to demonstrate to everyone else > that these languages really are better than C (and everyone's favorite C++) . > Don't let M3 and O2 go down the dead-end where M2 ended up. Agreeing that some demonstration of the better productivity of MODULA is necessary to convince more laymen, I don't believe M2 is at a dead end now. However, there is a risk to be beaten out by the C/C++ promoters. What to do? Some ideas: Compatibility and other demands forces you often to use C. But who says that you have to code all in C directly? If we had good M2 to C translators, such could be used as a "preprocessor", using C as intermediate language, reflecting its usefulness as a portable assembly language (and usefulness only for that!). Example: You are asked to do some programming in C. You write it in M2 (or Oberon, M3) instead, and your "preprocessor" outputs what your employer wants. While you take advantage from M2, the employer does not see anything from this (ideally). Currently, the problem is that no such (portable) preprocessor is available. For example, the mtc from GMD has some disadvantages: a) It does no full type checking, the main point of M2 b) Comments are lost c) translations between different M2 dialects and different C dialects (16bit vs. 32bit architectures) are not possible. d) It is not public domain. If there were a translator satisfying the above points, there should be no need to any more use C, as far as a programmer is willing to learn M2. Comments on the net ? Is there someone trying to improve mtc? -- Thomas ======================================================================== 6 === Date: 4 Oct 91 15:07:32 GMT From: toma@sail.LABS.TEK.COM (Tom Almy) Subject: Re: Productivity of Type-Safe Languages In article <58163@apple.Apple.COM> lins@Apple.COM (Chuck Lins ) writes: >The members of these newsgroups all know the refrain "type-safe is better". An d >I'm certain there are many other advantages to both Modula-3 and Oberon/Oberon -2. >The problem is how to convinve the rest (or at least a significant number) of >the programming community that this is so AND they are willing to use them >in everyday work. If I may speak some heresy here (:-) I have been teaching a C class at a local college for the past year and a half in a class equiped with PCs and Turbo C (old version). ANSI C allows for a great deal of "type safe" compilation; in the first class I tell everyone to enable all warning messages (ok, so in C these are warnings and not *errors*) and make it clear that programs that generate any warnings are not acceptable. With one exception, once the programs compile successfully the students programs only have logic errors. The one exception is the G*dawful scanf/printf for which there is no error checking. Of course if the class were C++ we would be using streams and even this problem would go away. Anyway, with an ANSI C compiler and *discipline* good results can be achieved. Don't get me wrong -- I enjoy Modula-2, but the rest of the world, in particular the "C Majority" isn't standing still -- the old K&R C High-Level Assembler is becoming a thing of the past. -- Tom Almy toma@sail.labs.tek.com Standard Disclaimers Apply ======================================================================== 7 === Date: 4 Oct 91 17:19:43 GMT From: sdl@mitre.org (Steven D. Litvintchouk) Subject: Re: Productivity of Type-Safe Languages In article <58163@apple.Apple.COM> lins@Apple.COM (Chuck Lins ) writes: > The major omission of the aforementioned paper is that it wasn't able to > measure the impact of language on the development cycle and schedule. And it > seems to me that neither Modula-3 nor Oberon-2 will amount to anything more > than a footnote in the pages of programming language history unless there is > some _measureable_ benefit. The marketing "hype" of type-safe is better won't > sell to a programming development manager [maybe to a few, but not many]. > What's needed is a good study that says "modula-3 saved us $$$ in the > development of our great product. and it's also why it's so reliable." > > Sonething like that will sell these languages in the minds of managers and > programmers (well lots of libraries will keep the latter happy :-) I must disagree with this assessment. Before I got interested in Modula-3, I used to program in Ada, and saw that the Ada community was likewise trying (and often failing) to sell type-safety (and other Ada features) to managers and bean-counters. My observations: 1. The programmers who appreciate type-safe languages have a different style of development, and even a different life-cycle model. That is, they are used to spending more time on ensuring the consistency of their design, prior to trying to debug it dynamically. With a type-safe language, you spend a lot of extra time trying to push your design through the compiler successfully, and less time debugging it dynamically. 2. Prior advances in programming, notably structured programming, did not become widely used by selling the professional bean-counters on their "cost-effectiveness." Rather, they simply became part of the accepted practices of programmers. And as those programmers rose up through the ranks to become project leaders and managers, those techniques became standardized within the organization. So what I often saw in industry, were managers who enforced structured programming standards and guidelines, despite having no empirical evidence on their cost-effectiveness. At the same time, these managers would oppose Ada and its features such as type-safety, on the grounds that there was no evidence on their cost-effectiveness! -- Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 Fone: (617)271-7753 ARPA: sdl@mitre.org UUCP: ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl "Where does he get those wonderful toys?" ======================================================================== 8 === Date: Fri, 4 Oct 1991 23:13:16 PDT From: David Goldberg Subject: arrays with empty index type Can arrays have empty index type? In particular, are the following valid? 1. the statement: refArr := NEW(REF ARRAY OF INTEGER, 0) 2. the declaration: arr: ARRAY[1..0] OF INTEGER what about 3. refArr := NEW(REF ARRAY OF INTEGER, -1)? The reference manual seems to imply that both 1 and 2 should be valid, although the 1.6 m3 compiler rejects 2. David Goldberg goldberg@parc.xerox.com ======================================================================== 9 === Date: Sun, 6 Oct 91 17:51:30 PDT From: Subject: Re: arrays with empty index type The expression NEW(REF ARRAY OF INTEGER, 0) and the declaration VAR arr: ARRAY [1..0] OF INTEGER are both legal, as the reference manual implies. The 1.6 compiler should not be regjecting the declaration. The expression NEW(REF ARRAY OF INTEGER, -1) is illegal. Greg ======================================================================== 10 === Date: 7 Oct 91 14:38:34 GMT From: davis@passy.ilog.fr (Harley Davis) Subject: Re: Productivity of Type-Safe Languages In article <58163@apple.Apple.COM> lins@Apple.COM (Chuck Lins ) writes: "Modula-2 is 3 times better than C". It took a look at the kinds of errors made by various programmers in each language. The result was that the Modula compiler found more errors at compile-time than the C compiler. Thus, the C programmers found their errors at run-time (at least a larger percentage of the total number of errors). Of course, we all know this. The major omission of the aforementioned paper is that it wasn't able to measure the impact of language on the development cycle and schedule. And it seems to me that neither Modula-3 nor Oberon-2 will amount to anything more than a footnote in the pages of programming language history unless there is some _measureable_ benefit. The marketing "hype" of type-safe is better won't sell to a programming development manager [maybe to a few, but not many]. What's needed is a good study that says "modula-3 saved us $$$ in the development of our great product. and it's also why it's so reliable." The success or failure of programming languages has absolutely nothing to do with any inherent value of the language. It has to do with the number, value, and openness of the applications written in the language. As long as nobody is writing useful programs written in a language, and distributing the sources, the language will not succeed on a large scale. Another potential factor in a language's success is a mandate from above to use the language. Ada is an example of such a language. However, this alone will not guarantee success. PL/I, for example, was a flop. -- Harley Davis -- ------------------------------------------------------------------------------ nom: Harley Davis ILOG S.A. net: davis@ilog.fr 2 Avenue Gallie'ni, BP 85 tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France ======================================================================== 11 === Date: 5 Oct 91 20:54:00 GMT From: ccoleman@gmuvax2.gmu.edu (Chuck Coleman) Subject: Oberon-2 ( was Re: Productivity of Type-Safe Languages ) Pardon my ignorance, but when did Oberon-2 come out, and where is it available? I haven't even had a chance to play with my MS-DOS Oberon compiler! Chuck Coleman "Sorry, no concluding witticism" School: Work: Center for Study of Public Choice NPA Data Services, Inc. George Mason University 1424 16th St. N.W. Suite 700 4400 University Drive Washington, DC 20036 Fairfax, VA 22030 (202) 265-7685 BITNET: ccoleman@GMUVAX Internet: ccoleman@gmuvax2.gmu.edu ======================================================================== 12 === Date: 8 Oct 91 23:57:24 GMT From: mgallo@zeus.calpoly.edu (M. Gallo) Subject: Re: Oberon-2 This was originally a letter, but I decided to post due to recurring inquiries. >Rumor is there that there is something like Oberon-2. I know Oberon >but what is Oberon-2? Does anybody have some information about it? It's not just a rumor. Oberon-2 is an extension of Oberon by Hans-Peter Mossenbock at ETH, Zuerich. It is an attempt to enhance Oberon with new OO and other features while remaining true to the "spirit" of Oberon. As far as I know, it has only been implemented for SPARCstations at this point, but people are writing implementations for other platforms. I'm sure that they'll be announced in comp.lang.modula2 when they're available. You can find the SPARC implementation and documentation by ftp at neptune.inf.ethz.ch, among other places. Also of interest, perhaps, is Oberon-2's predecessor, Object Oberon. Although abandoned in favor of Oberon-2, you can find a description of it in _Structured Programming_ (1989) v10 n4, pp. 199-207. I hope this is useful. -- _ /| Miguel \'o.O' mgallo@ares.calpoly.edu =(___)= "C is its own virus." U ======================================================================== 13 === Date: 10 Oct 91 18:01:56 GMT From: jimad@microsoft.UUCP (Jim ADCOCK) Subject: Re: Productivity of Type-Safe Languages In article schoebel@bs5 .informatik.uni-stuttgart.de (Thomas Schoebel) writes: |I don't believe M2 is at a |dead end now. However, there is a risk to be beaten out by the C/C++ |promoters. No risk at all, because Modula-3 [and other OOPS] *have* been beaten *out* of the market by C/C++. So, that's not the issue. Rather, the issue is, what if anything, can other OOPLs do to beat their way back *into* the market. Here's some numbers backing up my claims. From the Computer Select database: Number of magazine articles and abstracts referring to a particular programming language in the last year [out of a total of about 70000 magazine articles and abstracts covering the vast majority of common computer magazines] C 3823 C++ 918 Modula-2 104 Modula-3 6 In summary, C and C++ really have taken over the market. Supporters of other languages thus need to formulate a strategy for getting their favorite languages back into the market. Given that C and C++ really are quite a kludge, one would have to believe that *some day* *some language* will come along and knock them out of their present dominating positions. But, as of today, its hard to see what and when. At the very least, a language that would take over from C/C++ better address the issue of C/C++ compatibility closely, because all the people writing tons of software under C/C++ compilers are going to be loath to throw it all away. I don't believe its necessary that a language take the approach of Objective-C or C++ where they try to *be* the previous language. Still, you'd better think *seriously* about how you want to address the back[ass]wardly compatibility issues, if you want your favorite language to be a success. ======================================================================== 14 === Date: Thu, 10 Oct 1991 21:08:06 PDT From: Mark_Weiser.PARC@xerox.com Subject: Re: Productivity of Type-Safe Languages Counting magazine articles is hardly a way to measure wins. For instance, if I counted the number of articles on cold vs. hot fusion in 1990, I would have figured cold fusion had won by your measure. Less facetiously, take OS/2. Counting OS/2 vs. Windows articles in 1988-1989 would have predicted Windows as dead and OS/2 the winner. But look what happened. And my favorite example: PL/I, the language that was going to take over the world, the language with all the latest features, etc. etc., just like C++, and just like C++ a large bag of ugly tricks. It had its day, and then died as people got disgusted with its complexity and returned to simpler languages. -mark ======================================================================== 15 === Date: 11 Oct 91 15:06:36 GMT From: dduggan@plg.waterloo.edu (Dominic Duggan) Subject: Experiences etc using Modula-3 for teaching I'm interested in hearing people's experiences/advice/opinions on using Modula-3 in a third-year undergrad computer systems course. The material for the course is basically IPC and file systems, some intro to distributed systems. The text is Silberschatz, Peterson & Galvin, which they will have used in the prereq course. I'd like to use M3 primarily because of its module system, possibly doing some Choices stuff later with the object system. I have some worries, primarily the stability of the compiler (the course will probably work on Microvax-II's or Sun-3's). I'm also hoping students can pick up the basic M3 stuff quickly from previous exposure to Pascal and Ada. I'd also be _very_ grateful if someone had an implementation for a stable transport layer that could sit atop BSD sockets... Please reply to me directly, I'll summarize to the net if there's interest. ======================================================================== 16 === Date: Sat, 12 Oct 1991 06:09:56 GMT From: schwartz@roke.cs.psu.edu (Scott Schwartz) Subject: Re: Productivity of Type-Safe Languages Mark_Weiser.PARC@xerox.com writes: And my favorite example: PL/I, the language that was going to take over the world, the language with all the latest features, etc. etc., just like C++, and just like C++ a large bag of ugly tricks. It had its day, and then died as people got disgusted with its complexity and returned to simpler languages. While I agree with this in principle, I wonder if it will work out that easily in practice. One thing that did PL/I in was that there were ``lean and mean'' alternatives, both in terms of simplicity of conception and of implementation. (Look at all the miniscule Pascal compilers in the world!) Today, while I think there are all sorts of languages better conceived than C++, I worry about implementation. How big is the runtime system (or even just ``hello world'') of your favorite Modula-3 compiler? Your favorite Scheme compiler? Or (just for Mark) your favorite Ceder compiler? If all the better languages in the world are percieved as bloated, we may be stuck with C+n for a long time to come. ======================================================================== 17 === Date: Mon, 14 Oct 91 02:24:00 mdt From: Dave Barrett Subject: Modula III on HPUX I am attempting to install modula III version 1.6 onto HP-UX (HP300 config) The installation package does not work as written because the link-compiler target in system/complier/Imakefile tries to execute a command with too many arguments. The HP-UX kernal refuses to exec command lines more than about 5000 characters. Is there an easy fix for this? Dave Barrett barrett@boulder.Colorado.EDU ======================================================================== 18 === Date: 13 Oct 91 20:52:25 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: OOPSLA '91 debriefing I just returned from OOPSLA '91. Here's a quick summary of Modula-3 activities: Interest: The Modula-3 tutorial had about 35 attendees, which I'm informed is good for a "specialized" topic. There was a total attendance at the conference of about 2,000. About 60 people signed up for the Modula-3 mailing list at the Pine Creek booth; probably 30 others took literature. I can't estimate the overlap between the booth visitors and the tutorial attendees, although I think it was low since the tutorial people already had all the M3 literature I had at the booth. Competition: I talked with many C++ programmers; few expressed any affection for the language. I listened to a long recital about C++ faults (post version 1.2) from the C++ product manager of a major tools company that was exhibiting at the conference. The presenter of a tutorial on C++ class design said that every C++ application he'd seen had storage problems (leaks or bugs caused by dangling pointers); he spent about 30 minutes describing all the ways you can get in trouble. Conclusions: I had hoped for more Modula-3 interest, but in retrospect I think the response is OK at this point. More people are saying that they have at least heard of Modula-3. No one said, "I don't like Modula-3 because " (for any ), although some people said they had to use C++ as a matter of company policy. The availability of SRC Modula-3 and the Modula-3 books are important advantages. A PC compiler is still needed. In my opinion, the academic community is ripe for a good teaching language like Modula-3. Sam Harbison Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. ======================================================================== 19 === Date: 10 Oct 91 21:42:39 GMT From: sdy@ssc-bee.boeing.com (Ugly Bag of Mostly Water) Subject: Need Help Installing SRCModula3 (Apollo) I've been trying to install SRCModula3 on an Apollo (DN4500/DN3000) and have been having some problems. I have the latest 1.6 distribution direct from the DECWRL archives and would like to talk to (email) someone who has successfully installed this on an Apollo (running SR10.3) -- the release notes claim it can be done but I've encountered the need for numerous adjustments to the makefile and have now been totally stalled. steven yee sdy@ssc-bee.boeing.com -- Steven D. Yee >>> my employer does not share my opinions <<< sdy@ssc-bee.boeing.com >>> that's because I'm always right! ;b <<< You couldn't pay me enough, but go ahead and try. ======================================================================== 20 === Date: 14 Oct 91 19:19:58 GMT From: raginis@cs.albany.edu (Ragini Shamsunder) Subject: beginner wanting to know about opaque types Hi, I just started working on Modula3 very recently and am having trouble figuring out opaque types. I tried defining a stack in a separate module without disclosing the data structure. Here is the INTERFACE: INTERFACE stks; TYPE stack <: T; PROCEDURE push(item : INTEGER; VAR s : stack); PROCEDURE pop(VAR item : INTEGER; VAR s : stack); PROCEDURE empty(s : stack) : BOOLEAN; END stks. and here is PART of the Module itself: MODULE stks; TYPE REVEAL stack = T; T = BRANDED REF RECORD store : ARRAY [1..MYMAX] OF INTEGER; top, mark : INTEGER; END; The error given by thecompiler is that T is undefined in the .i3 file. I am not quite sure how to deal with this problem. I am trying to avoid using objects. Could someone provide me with some useful suggestions? I would appreciate it and thanks in advance. Ragini ======================================================================== 21 === Date: Mon, 14 Oct 91 14:42:03 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: beginner wanting to know about opaque types In article , raginis@cs.albany.edu (Ragi ni Shamsunder) writes: > I just started working on Modula3 very recently and am having > trouble figuring out opaque types. I tried defining a stack in a separate > module without disclosing the data structure. Here is the INTERFACE: > > INTERFACE stks; > TYPE stack <: T; > > PROCEDURE push(item : INTEGER; VAR s : stack); > PROCEDURE pop(VAR item : INTEGER; VAR s : stack); > PROCEDURE empty(s : stack) : BOOLEAN; > > END stks. > > and here is PART of the Module itself: > > MODULE stks; > > TYPE > REVEAL stack = T; > T = BRANDED REF RECORD > store : ARRAY [1..MYMAX] OF INTEGER; > top, mark : INTEGER; > END; > > The error given by thecompiler is that T is undefined in the .i3 file. > I am not quite sure how to deal with this problem. I am trying to avoid > using objects. > Could someone provide me with some useful suggestions? I would > appreciate it and thanks in advance. Here is a version that should work: INTERFACE Stks; TYPE T <: REFANY; PROCEDURE Push (item: INTEGER; s: T); ... END Stks. MODULE Stks; REVEAL T = BRANDED REF RECORD store: ARRAY [1..MYMAX] OF INTEGER; top := 0; mark:= 0; END; ... END Stks. Note that a client of the stks interface can invoke NEW (Stks.T) (at least in the latest version of the language). If you can use the initializers in the RECORD declaration, that's good enough. You still have to be careful to say what should happens in push and the other procedures when s is NIL: - you can say that it is the responsability of the caller to ensure that s is non-NIL and not test for that case (unchecked runtime error). - you can say that the implementation checks for s to be non-NIL and generates a runtime error (by calling RTMisc.FatalError) if it is not the case (checked runtime error). - you can check and raise an exception. - you can check and allocate the stack (in which case, you need the argument to be VAR). - you can provide a "new" procedure in the interface (see below). Sometime, initialization through the type is not enough, and you need to execute some code. In those cases, you can add to the interface: PROCEDURE New (): T; (* allocate a new, empty stack. You must call this procedure to get a valid stks.T *) and to the implementation: PROCEDURE New (): T = VAR t: T; BEGIN t := NEW (T); (* whatever you need to do *) RETURN t; END New; Clients just need to call "Stks.New ()" to get a valid stack. If you want to use objects, here is a way I do it: INTERFACE Stks; TYPE Public = OBJECT METHODS new (): T; (* allocate (self = NIL) or initialize (self # NIL) a T. This method must be called before the other methods *) push (item: INTEGER); ... END; T <: Public; ... MODULE Stks; REVEAL T = Public BRANDED OBJECT store : ARRAY [1..MYMAX] OF INTEGER; top, mark : INTEGER; OVERRIDES new := new; push := push; ... END; PROCEDURE new (self: T): T = BEGIN IF self = NIL THEN self := NEW (T); END; self.top := ... self.mark := ... RETURN self; END new; Clients of that interface can say: t := Stks.T.new (NIL); to allocate a new stack. Or a subclass of Stks.T can say: TYPE Subclass = Stks.T OBJECT ... METHODS ... OVERRIDES new := new; .... END; PROCEDURE new (self: Subclass): Subclass = BEGIN IF self = NIL THEN self := NEW (Subclass); END; EVAL Stks.T.new (self); (* other initialization specific to Subclass *) RETURN self; END new; Note that the type Public is there is only to avoid retyping the public part of the type in the module. Also, note that I used the SRC conventions for names (interface, module, procedure and type names start with an uppercase; method names start with a lower case; procedures that implement methods start with a lower case -- this last bit is actually my own convention). Finally, the way of doing it with objects depends on the latest version of the language (where you can call .); this not the language implemented by SRC Modula-3 1.6, but release 2.0 (to be available soon in a ftp directory near you) will do that. In the mean time, the module Stks can export the interface StksDotT (in addition to Stks), with the procedure new in it: INTERFACE StksDotT; FROM Stks IMPORT T; PROCEDURE new (self: T): T; END StksDotT. MODULE Stks EXPORTS Stks, StksDotT; ... END Stks. and clients of Stks can import it: ... IMPORT Stks, StksDotT; ... t := StksDotT.new (); ... When 2.0 is available, you just need to change "StksDotT" to "Stks.T" and to remove the StksDotT interface. Don't hesitate to post more questions if that is not clear. -- Eric. ======================================================================== 22 === Date: 15 Oct 91 06:21:12 GMT From: yeung@reed.edu (Woodrow Yeung) Subject: MPW Modula-3 Has anyone done a port of Modula-3 to generate code for MPW C? Thanks. Woodrow Yeung yeung@reed.edu -- Woodrow Yeung tektronix!reed!yeung or tektronix!reed!lclark!yeung or tektronix!psu-cs!yeung ======================================================================== 23 === Date: 15 Oct 91 06:35:41 GMT From: mgallo@zeus.calpoly.edu (M. Gallo) Subject: Re: OOPSLA '91 debriefing In article <1991Oct13.205225.18497@bert.pinecreek.com> harbison@bert.pinecreek. com (Sam Harbison) writes: >Modula-3 and the Modula-3 books are important advantages. A PC >compiler is still needed. In my opinion, the academic community is >ripe for a good teaching language like Modula-3. What other implementations for Modula-3 are underway? A PC version would be great, but so would native code compilers. -- _ /| Miguel \'o.O' mgallo@ares.calpoly.edu =(___)= "C is its own virus." U ======================================================================== 24 === Date: 15 Oct 91 12:49:29 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: OOPSLA '91 debriefing As has been mentioned here a number of times, my research group is developing GNU Modula-3, which will provide optimized native code with the same retargetability as the GNU C compiler (since a lot of the code between the two compilers is shared). When finished, this will be released through the Free Software Foundation under the usual GNU terms. If you're interested in seeing it released sooner, get somebody to give us more money :-) .... -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================== 25 === Date: 15 Oct 91 15:12:06 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Other Modula-3 compilers (was Re: OOPSLA '91 debriefing) I have been in touch with organizations interested in doing Modula-3 compilers for PC's and other non-UNIX systems. Things are moving, but you should not assume anything is close. Don't be discouraged from doing a Modula-3 compiler yourself, whether for fun or profit. There are now several people with Modula-3 compiler expertise. These people are willing to help experienced compiler builders deal with the peculiarities of the Modula-3 language and run-time system, including garbage collection. With such help, a Modula-3 compiler and run-time library should not be difficult to produce. As is the case for other languages, an outstanding Modula-3 product will also require good engineering and an effective set of well-integrated tools. People who have succeeded in producing good environments for other languages will succeed at Modula-3 also. Sam Harbison Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. ======================================================================== 26 === Date: 15 Oct 91 20:17:20 GMT From: tsai@Veritas.COM (Cary Tsai) Subject: Any unix public domain Modula3 compiler ? Hi: I am new in this group. I would like to have a modula3 compiler on my SYSV machine (i386). Is any public domain modula3 compiler available on the i386 SYSV system ? DO any manuals or books talk about this language ? ======================================================================== 27 === Date: Tue, 15 Oct 91 14:21:48 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: beginner wanting to know about opaque types A few more words on the subject: With a declaration such as: TYPE T <: ROOT; U <: REFANY; both types T and U are known to be traced references. T is known to be an object type, U may be an object type, may be not. In both cases, it is legal for a client of an interface that has those declarations to invoke NEW on theses types. The function of NEW, which is to allocate storage in the traced heap, does not really differ when allocating a REF or an OBJECT (of course, different things have to be done). My example used the OVERRIDES keyword in object types. You may have SRC Report # 52: "Modula-3 Report (revised)", November 1, 1989. This is the language implemented by SRC Modula-3 1.6 (modulo bugs). In that language, the syntax does not make the distinction between: TYPE foo = bar OBJECT METHODS n () := N; m := M; END; and TYPE foo = bar OBJECT METHODS n () := N; m () := M; END; very apparent. The first syntax means that the default value for method 'm' for objects of type foo is M. The second syntax means that the type foo introduces a new method, 'm', that takes precedence over any method 'm' that may have been declared for the type bar. Pages 13 and 14 of the report describes this difference. Since that report, 'twelve changes' have been made to the definition of the language. One of them is to have a syntax that makes theses cases more apparent: TYPE foo = bar OBJECT METHODS n () := N; OVERRIDES m := M; END; and TYPE foo = bar OBJECT METHODS n () := N; m () := M; END; The 'twelve changes' have been described in a message sent to comp.lang.modula3 by Greg Nelson. They also have been integrated in the definition of the language, as it appears in: Systems Programming with Modula-3 Greg Nelson, Ed. Prentice Hall ISBN 0-13-590464-1 We are working on SRC Modula-3 2.0 that will implement this new definition of the language. The main mechanism for input/output is implemented by the Rd and Wr interfaces. Roughly, a Rd.T is a thing you can get characters from, and a Wr.T is a thing you can send characters to. There are various kinds of readers and writers; some of them are connected to files (see the Filestream and Stdio interfaces), some are connected to texts (see the TextRd and TextWr interfaces). Also, the Fmt and Scan interfaces are used to transform numbers into texts and back. -- Eric. ======================================================================== 28 === Date: Tue, 15 Oct 91 16:02:56 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Re: beginner wanting to know about opaque types In article <1991Oct15.142148.15303@src.dec.com>, muller@src.dec.com (Eric Mulle r) writes: > A few more words on the subject: > > With a declaration such as: > > TYPE T <: ROOT; U <: REFANY; > > both types T and U are known to be traced references. T is known to > be an object type, U may be an object type, may be not. In both > cases, it is legal for a client of an interface that has those > declarations to invoke NEW on theses types. The function of NEW, > which is to allocate storage in the traced heap, does not really > differ when allocating a REF or an OBJECT (of course, different things > have to be done). > > This is not quite right. As its says on p53 of Systems Programming in Modula-3, "If T is declared to an opaque type, NEW(T) is legal only in scopes where T's concrete type is known completely or is known to be an object type." So, with the above declarations, a client can NEW(T), but not NEW(U). I.e. "U <: REFANY" is a pure abstract data type. Only clients that "know" either the complete revelation (REVEAL U = ...) or a partial revelation that shows U to be an object type (e.g. REVEAL U <: ROOT) can effect a NEW(U). Mick Jordan ======================================================================== 29 === Date: 15 Oct 91 12:46:56 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: beginner wanting to know about opaque types In article raginis@cs.albany.edu (Ragin i Shamsunder) writes: Hi, I just started working on Modula3 very recently and am having trouble figuring out opaque types. I tried defining a stack in a separate module without disclosing the data structure. Here is the INTERFACE: ... bunch of code omitted ... I am trying to avoid using objects. Why avoid using objects? Are you afraid they'll cost too much or something? I doubt you'll notice any performance difference in a significant program .... -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================== 30 === Date: Thu, 17 Oct 91 10:39:35 BST From: Simon Hood (Maths) Am currently running Modula-3 on a Sun SPARC station. I have successfully linked to the C suncore graphics routines, however this does not appear to contain printer support. We have Uniras which does, unfortunately its all written in Fortran(?!) and so to use its printer support routines would mean either linking M3 or C to Fortran. Can anyone help with this, or offer any other suggestions? Simon. ======================================================================== 31 === Date: 17 Oct 91 10:46:06 GMT From: liam@dcs.qmw.ac.uk (William Roberts) Subject: Re: Experiences etc using Modula-3 for teaching In <1991Oct11.150636.17852@watmath.waterloo.edu> dduggan@plg.waterloo.edu (Dominic Duggan) writes: >I'm interested in hearing people's experiences/advice/opinions on using >Modula-3 in a third-year undergrad computer systems course. We have just started using Modula-3 (1.6) as a first programming language for undergraduate computer science. Actually , we teach two parallel first programming courses: "Imperative Programming" which uses Modula-3, and "Functional Programming" which uses Miranda. Both of these are being run on Mac IIcx workstations running A/UX (I did get M3 more or less working). The attraction of Modula-3 is that it will hold up across our entire course: it can be used for the Software Engineering course in the second year, and students wishing to use it for project work can still get at all of the system calls, X libraries etc that they might want. My main criticism so far is that the m3 compiler does very little to help you if you do something wrong which isn't detected within a single compilation unit. Worse still, it exposes all its gory implementation innards by letting other programs try to report the problem. Here is a recent example: ----------------- >I seem to be experiencing a problem with the Modula 3 compiler, eg: > >> m3 List.i3 >ld: Symbol M3_LINKPROC_IList in >/import/exampleexec/exec/lib/m3/core/libm3core.a > is multiply defined. First defined in 00152000_i.o >ld fatal: Error(s). No output written to a.out >linking The Modula3 compiler isn't very clever about a number of things, including picking up libraries automatically and resolving module name clashes. The important line in the above message is: >ld: Symbol M3_LINKPROC_IList in The "M3_LINKPROC_I" prefix is just part of how M3 gets the normal UNIX linker to stick all the bits together, and the bit that interests you is the rest of the symbol, namely List. You have defined a module called List and imported it, but this in turn imports various other things which import the M3 system's own implementation of List. The compiler would have told you earlier and more intelligibly if it recursively examined all the .i3 files involved, but it doesn't and so things only go wrong at the linking stage. ----------------- I might also add that the m2imc tool doesn't notice the PASS3 stuff about nm in the config file when you build it, so that doesn't work under A/UX at all. Reflecting briefly on the use of two different Modula-2 systems in previous years, the strengths of those systems relative to the M3 implementation we are using are as follows: 1) Ana Systems Modula-2 This had awful bugs in it and almost no access to C libraries, but it had its own linker which collected automatically all the modules implied by the main module, scanning a traditional sort of search path to find them and doing the validity checks on timestamps embedded in the files. The strength of this was that students get sensible messages about the kinds of conflicts illustrated above, messages which are meaningful in terms of the Modula-2 language. 2) Cambridge Modula-2 This had much better interfaces to C libraries etc, but generated native ns32000 code and nobody here felt like retargeting it to 680x0. The best feature of this system was a utility called m2make which generated Makefiles for you. I believe it did significant consistency checking as well, but it was a few years ago now so I can't remember for certain. Thinking about m3 1.6, I can't currently see the value of m3ar. It produces nice little readable files called libthing.ma, but there is no evidence of anything else in the system actually looking at those. The m3 program itself certainly doesn't change the list of -l directives at all: it puts in a fixed list defined when it was compiled, whether you need them or not. In summary: m3 1.6 is not expected to be fun to support as a first teaching language, because its overall module consistency checking is a side-effect of standard linking rather than an explicit part of the system and hence generates deeply unhelpful error messages. m3 requires its own checking stage at link time (possibly earlier as well), which should also remove the need to call every top-level module Main and to specify all of the .io and .mo files to be linked. -- % William Roberts Internet: liam@dcs.qmw.ac.uk % Queen Mary & Westfield College UUCP: liam@qmw-dcs.UUCP % Mile End Road Telephone: +44 71 975 5234 % LONDON, E1 4NS, UK Fax: +44 81-980 6533 ======================================================================== 32 === Date: Thu, 17 Oct 91 13:15:56 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Re: Experiences etc using Modula-3 for teaching In article <3883@redstar.dcs.qmw.ac.uk>, liam@dcs.qmw.ac.uk (William Roberts) w rites: > In <1991Oct11.150636.17852@watmath.waterloo.edu> dduggan@plg.waterloo.edu > (Dominic Duggan) writes: > My main criticism so far is that the m3 compiler does very little to help you > if you do something wrong which isn't detected within a single compilation > unit. Worse still, it exposes all its gory implementation innards by letting > other programs try to report the problem. Bill or Eric will undoubtedly comment individually on your message, but to do what you ask requires a pre-linker, which the 2.0 implementation has. As an aside, in the now-defunct Olivetti implementation, we had a pre-linker that used compiler generated ASTs as input. It could and did give very detailed messages on version mismatches and missing procedures etc. [In fact for the latter it generated a stub procedure that raised an exception if called at run-time]. > 2) Cambridge Modula-2 > > This had much better interfaces to C libraries etc, but generated native > ns32000 code and nobody here felt like retargeting it to 680x0. The best > feature of this system was a utility called m2make which generated Makefiles > for you. I believe it did significant consistency checking as well, but it wa s > a few years ago now so I can't remember for certain. > The remnants of the Olivetti implementation, which includes the Modula-3 versio n of the "m2make", is available from SRC as part of the Modula-3 toolkit. Its called "m3tk" and lives on gatekeeper.dec.com in the Modula-3 directory. It does include checking part of the pre-linker tool but, owing to its memory needs, probably isnt suitable in a teaching environment. If you liked the Cambridge Modula-2 libraries, which I wrote a large part of, you might like to check out the libraries that come with the toolkit, since the y are based more on the Cambridge model. They essentially evolved out of the Modula-2 versions. Mick Jordan ======================================================================== 33 === Date: 21 Oct 91 15:47:34 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Getting Nelson's book From time to time I get mail from people in the USA and abroad looking for Nelson's "Systems Programming with Modula-3." Although the book should now be available in most US bookstores, a few people are still having trouble finding it. I have been taking orders, but selling books is not my line of business, so... By special arrangement, Total Information, Inc. of Rochester, NY has agreed to keep Nelson's book in stock and to provide 24-hour turnaround on book orders. To order, call 1-800-876-4636 or FAX (716) 254-0153. They ship books world-wide and handle a full range of science and technology books. I can't yet personally vouch for their service, so I'd appreciate receiving reports from people who order from them. Sam Harbison Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. ======================================================================== 34 === Date: 23 Oct 91 17:15:10 GMT From: kirschne@Informatik.TU-Muenchen.DE (Kirschner) Subject: Nelson's book's Trestle Window System, where is it ? Dear Netfellows, please help me with this problem: I lack much experience with Modula-3 programming, but I just managed to get a copy of Greg Nelson's "System Programming with Modula-3" (Prentice Hall, ISBN 0-13-590464-1). So far, so good. I have the SRC Modula-3 distribution Version 1.6, which is the latest available, as far as I know. It installed perfectly on my DEC 5000/200 and all the demos run just fine. I use Ultrix 4.2 with X11R4. Now I wanted to start programming with M3, and to get catchy results I chose (X)Windows as an interesting playground. I didn't read through to whole book yet, but I figured that Nelson covers the subject in his Chapter 7 "Trestle Window System Tutorial". On page 171 he says: "... To use Trestle, you need a copy of SRC Modula-3 and an X server for your system.[...] They {i.e., the example programs} are in the trestletutorial directory of the Modula-3 distribution." Well, I searched through my whole distribution, but I cannot find anything named Trestle or trestletutorial. All the X11R4-stuff I can see is stored in dist-1.6/demos/X11R4. But it's all a port of the MIT XConsortium's demos, done by Chris D. Peterson using the SRC Xt Interface. The long explained question is: Where can I find this Trestle Window System ? I think the rest of the Interfaces like Text, Thread, etc. described in Nelson's book are as provided with my copy of the distribution, but I haven't checked that yet, either. ( Is there any literature describing the Interfaces to X in this SRC M3 distrib., i.e. Xt, Xaw ? I guess there just a 1:1 port of their equivalences in C. ) Can anybody help me ? I'd be very glad, and thank you in advance, too. Torsten ======================================================================== 35 === Date: Wed, 23 Oct 91 13:23:03 PDT From: Subject: Re: Nelson's book's Trestle Window System, where is it ? Torsten Kirschne asks where Trestle is. You can copy Trestle from /archive/pub/DEC/Modula-3/trestle.tar.Z which is on gatekeeper. What you find will differ slightly from the version in the book (in particular, it is compatible with version 1.6 of the compiler, while the book version is compatible with version 2.0 of the compiler). You can do all the exercises in the book except Mouse Hockey. Greg Nelson ======================================================================== 36 === Date: Thu, 24 Oct 91 09:10:03 PDT From: msm@src.dec.com (Mark S. Manasse) Subject: Re: Nelson's book's Trestle Window System, where is it ? If you try to experiment much with Trestle beyond what's in the tutorial in the book, you'll soon discover that there are lots of problems; we're working on a new release that should fix most of them. In particular, there are some quite trivial errors that make fonts and pixmaps hard to use. Mark ======================================================================== 37 === Date: 25 Oct 91 09:16:54 GMT From: collberg@dna.lth.se (Christian S. Collberg) Subject: Three questions 1) When is the SRC version 2.0 compiler expected to be released? 2) There was talk earlier that the 2.0 release would include a pre-linker. Can someone give a brief description of its functionality? 3) Why doesn't the Pickle interface include procedures "ToBytes" and "FromBytes", i.e. procedures to pickle an object into a bytestring and to unpickle a bytestring into an object? That would be handy when doing remote procedure calls, for example. Christian -- Christian.Collberg@dna.lth.se Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden ======================================================================== 38 === Date: 26 Oct 91 19:16:05 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Why I like Modula3 (C++ libraries) Well, it came to pass that I was cruising some of the OOP libraries for C++, looking for some good ideas for Modula-3 libraries. What I found was that many of these libraries devote a lot of effort to providing what Modula-3 gives you right out of the box: bounds-checked arrays, run-time type checking, generics, exceptions, threads, etc. (Since exceptions and generics aren't yet standard in C++, the libraries that are out now involved roll-your-own versions.) These fundamentals turn out to be very complex and underly all the higher-level libraries, making those yet more obscure. (For example, a list package is pretty straightforward--until you see that it's built on top of the run-time type class and the generic class.) To get a productivity improvement, you have to build all your own classes on top of these underpinnings, too. Thus, not only is the language C++ more complicated than M3, but your own classes get more complicated. So, after stripping away all the things I don't need in Modula-3, it turns out there wasn't much else. I guess I'll check back in a year or so... Sam Harbison Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. ======================================================================== 39 === Date: 27 Oct 91 16:22:42 GMT From: bytor@ctt.bellcore.com (Ross Huitt) Subject: Re: Why I like Modula3 (C++ libraries) In article <1991Oct26.191605.1257@bert.pinecreek.com> harbison@bert.pinecreek.c om (Sam Harbison) writes: ... >What I found was that many of these libraries devote a lot of effort >to providing what Modula-3 gives you right out of the box: >bounds-checked arrays, run-time type checking, generics, exceptions, >threads, etc. (Since exceptions and generics aren't yet standard in >C++, the libraries that are out now involved roll-your-own versions.) IMNSHO, the biggie is garbage collection. C++ is the only OO language I've used without GC and it has caused me more heart-aches and more wasted hours than the lack of generics or exceptions. > >These fundamentals turn out to be very complex and underly all the >higher-level libraries, making those yet more obscure. (For example, >a list package is pretty straightforward--until you see that it's >built on top of the run-time type class and the generic class.) To >get a productivity improvement, you have to build all your own classes >on top of these underpinnings, too. Thus, not only is the language C++ >more complicated than M3, but your own classes get more complicated. One thing I find myself doing over and over and over again is creating a slew of infrastructure classes for each implementation class to provide support for run-time typeinfo, typesafe callbacks, implementation-specification separation, etc... (Of course I do have some hand-dandy macros to simplify the process.) If you take the time to read comp.lang.c++ you will constantly see exchanges like: Q: How do I implement [some useful mechanism that could easily be accomplished in 1 line of Smalltalk]? A: Well, first you have to create another class.... ... > >Sam Harbison >Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; >USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. Ross Huitt bytor@ctt.bellcore.com (908) 699-2973 ======================================================================== 40 === Date: Sun, 27 Oct 1991 15:31:04 GMT From: eric@tfs.com (Eric Smith) Subject: Re: Why I like Modula3 (C++ libraries) In article <1991Oct26.191605.1257@bert.pinecreek.com> harbison@bert.pinecreek.c om (Sam Harbison) writes: >Well, it came to pass that I was cruising some of the OOP libraries >for C++, looking for some good ideas for Modula-3 libraries. > >What I found was that many of these libraries devote a lot of effort >to providing what Modula-3 gives you right out of the box: >bounds-checked arrays, run-time type checking, generics, exceptions, >threads, etc. (Since exceptions and generics aren't yet standard in >C++, the libraries that are out now involved roll-your-own versions.) > >These fundamentals turn out to be very complex and underly all the >higher-level libraries, making those yet more obscure. (For example, >a list package is pretty straightforward--until you see that it's >built on top of the run-time type class and the generic class.) To >get a productivity improvement, you have to build all your own classes >on top of these underpinnings, too. Thus, not only is the language C++ >more complicated than M3, but your own classes get more complicated. > >So, after stripping away all the things I don't need in Modula-3, it turns >out there wasn't much else. I guess I'll check back in a year or so... > >Sam Harbison >Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; >USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. Modula 3 sounds good, but will it work on my computer? One big advantage of C++ is that it is ubiquitously available. With Zortech C++ Version 3, I can use a cheap but very powerful computer based on a 486/33. This computer will accept 64 megabytes of low cost high speed SIMM memory modules. The total cost of the whole system is low enough that most programmers can buy it out of their salary, and use it at home in their spare time. That is the kind of thing that builds grass roots support for a programming language. Besides, the complexity of the classes is not really a problem. The whole purpose of object oriented programming is to make complexity trivial. Programmers can ignore the complexities and just access the public interface of each class they use. However, if there is some easy way to get Modula 3 to work on this computer, I am willing to give it a try. Just like I'm willing to give Eiffel a try. I also tried Smalltalk, but I was put off by the fact that I couldn't use more than 16 megabytes of memory with the version I tried. So far, I haven't found anything that beats C++ in the ways that are important to me. ======================================================================== 41 === Date: Mon, 28 Oct 91 09:06:42 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Nelson's book's Trestle Window System, where is it ? > You can copy Trestle from > > /archive/pub/DEC/Modula-3/trestle.tar.Z > > which is on gatekeeper. That is, you can use anonymous ftp and look in gatekeeper.dec.com:pub/DEC/Modula-3 -- Eric. ======================================================================== 42 === Date: 29 Oct 91 03:25:14 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Modula-3 on PCs (was: Re: Why I like Modula3 (C++ libraries)) In article <1991Oct27.153104.705@tfs.com> eric@tfs.com (Eric Smith) writes: > >Modula 3 sounds good, but will it work on my computer? ... >... Indeed, the absence of a good Modula-3 on PC's is a problem. Many of us are trying hard to correct that problem. SRC Modula-3 2.0 may be more easily portable to PC's, and there are other Modula-3 implementations under way and anticipated. Stay tuned... Sam ======================================================================== 43 === Date: 29 Oct 91 22:03:28 GMT From: phillip@cs.uow.edu.au (Phillip McKerrow) Subject: Re: Modula-3 on PCs (was: Re: Why I like Modula3 (C++ libraries)) Is there a Modula 3 available for the Macintosh yet? Phillip McKerrow University of Wollongong Australia ======================================================================== 44 === Date: 30 Oct 91 04:49:33 GMT From: warwick@cs.uq.oz.au (Warwick Allison) Subject: Re: Modula-3 on PCs (was: Re: Why I like Modula3 (C++ libraries)) phillip@cs.uow.edu.au (Phillip McKerrow) writes: >Is there a Modula 3 available for the Macintosh yet? From what I've seen of the code, it is TRIVIAL to port it - once you can find the space to build one of the base implementations. >Phillip McKerrow >University of Wollongong >Australia Cool - my birthplace! Ciao, Warwick. -- _-_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.-._/ University of Queensland, v Brisbane, AUSTRALIA. ======================================================================== 45 === Date: 28 Oct 91 20:10:00 GMT From: matt@emtek.UUCP (Matt Meola) Subject: Re: Three questions Is Modula-3 available to the public in source-form? If so, then how can one who doesn't have FTP access get it? I would VERY much like to investigate modula-3; I currently program in C++, and I love it. If Modula-3 looks better, I'll switch! collberg@dna.lth.se (Christian S. Collberg) writes: : 1) When is the SRC version 2.0 compiler expected to be released? : : 2) There was talk earlier that the 2.0 release would include a : pre-linker. Can someone give a brief description of its : functionality? : : 3) Why doesn't the Pickle interface include procedures : "ToBytes" and "FromBytes", i.e. procedures to : pickle an object into a bytestring and to unpickle : a bytestring into an object? That would be handy : when doing remote procedure calls, for example. : : Christian : : : : -- : : Christian.Collberg@dna.lth.se : Department of Computer Science, Lund University, : BOX 118, S-221 00 LUND, Sweden ------------------------------------------------------------------ Matt Meola UUCP: uunet!emtek!matt Emtek Health Care Systems, Inc. Phone: (602) 431-9071 x3057 2929 South Fair Lane Fax: (602) 431-9074 Tempe, Arizona 85282 ======================================================================== 46 === Date: Wed, 30 Oct 91 08:09:53 PST From: Subject: Re: Three questions > 1) When is the SRC version 2.0 compiler expected to be released? Most of the groups here at SRC have already switched to using 2.0. We'll make it available for FTP as soon as we can. > 2) There was talk earlier that the 2.0 release would include a > pre-linker. Can someone give a brief description of its > functionality? Yes, 2.0 includes a pre-linker, 1.6 does too. The 2.0 prelinker checks inter-module consistency, determines the module initialization order and allocates some data structure for the runtime type system. The 1.6 system does all of these things as well, but in a much slower and more fragile way. > 3) Why doesn't the Pickle interface include procedures > "ToBytes" and "FromBytes", i.e. procedures to > pickle an object into a bytestring and to unpickle > a bytestring into an object? That would be handy > when doing remote procedure calls, for example. Use the TextWr and TextRd modules to get memory buffered I/O streams. Pickle doesn't care what type of stream you hand it. - Bill Kalsow ======================================================================== 47 === Date: 30 Oct 91 17:05:50 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Modula-3 source for non-FTP sites (was Re: Three questions) In article <228@emtek.UUCP> matt@emtek.UUCP (Matt Meola) writes: > >Is Modula-3 available to the public in source-form? If so, then how >can one who doesn't have FTP access get it? > ... Yes, source is provided in the standard distribution from ftp site gatekeeper.dec.com in pub/DEC/Modula-3/... If you have a computer to which Modula-3 has been ported, but not FTP access, I can provide the SRC distribution on seven 3.25", 1.4meg PC-compatible floppy disks. The software includes Trestle, m3tk, SRC Modula-3, and the Modula-3 report. These disks contain the original, unmodified SRC software distributions. The binary .Z files are split into pieces (if necessary) and encoded with uuencode. Unpacking instructions are included. There is a $50 charge for the disks, plus a shipping and handling fee ($6.00 in the US). European customers: We expect that this software will be available through Real Time Associates in the UK soon. Details will be posted as soon as they are available. Sam Harbison Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. ======================================================================== 48 === Date: Wed, 30 Oct 91 15:43:51 PST From: harrison@gossamer.pa.dec.com (Stephen Harrison) Subject: Re: Three questions In article <9110301610.AA17597@jumbo.pa.dec.com>, kalsow (Bill Kalsow) writes: >> 3) Why doesn't the Pickle interface include procedures >> "ToBytes" and "FromBytes", i.e. procedures to >> pickle an object into a bytestring and to unpickle >> a bytestring into an object? That would be handy >> when doing remote procedure calls, for example. > >Use the TextWr and TextRd modules to get memory buffered >I/O streams. Pickle doesn't care what type of stream you >hand it. Yes it does, unfortunately. The stream passed to Pkl.Write has to be seekable. TextWr's are not. Cheers, /Stephen ======================================================================== 49 === Date: 30 Oct 91 21:59:23 From: vixie@decwrl.dec.com (Paul A Vixie) Subject: SRC M3 GC question I'm thinking of writing a real-time application in SRC Modula-3 and I'm concerned about the garbage collection. What I'm worried about is that my program will periodically stop collecting/forwarding data while it runs through the traced heap throwing out the trash. I know that the SRC M3 GC is based on Joel Bartlett's incremental "mostly copying" GC, but what I don't know is how often the generated code in 1.6 will call the GC. I am willing to do a little bit of housekeeping to remove the nastier trash by hand, but I don't see a RELEASE() anywhere. I'm also willing to run the GC at times which are convenient for me (that is, when I expect my data source to be quiescent for a few milliseconds), but I don't know where the hook is to run the GC and I don't want to go looking for it lest I end up calling something that disappears in 2.0. Help? -- Paul Vixie, DEC Network Systems Lab Palo Alto, California, USA "Be neither a conformist or a rebel, decwrl!vixie for they are really the same thing. vixie!paul Find your own path, and stay on it." (me) ======================================================================== 50 === Date: 31 Oct 91 07:28:21 GMT From: n8243274@henson.cc.wwu.edu (steven l. odegard) Subject: M3 for 8088 I am investigating the possibility of organizing an enterage to complete a native-code M3 compiler for the 8088 PC. I have decided to write this in Modula-3 (of course) and plan to begin springtime or when M3 2.0 is publicly available. I now request opinions for some major design decisions. The goal will be efficiency of implementation, speed of compilation, and security of the final product. Is there on-line documentation available for writing for the Microsoft Linker, or would I be better off designing my own linker system? 'Shared' run-time libraries are a must. It will be intolerable to produce Megabytes of code to output short messages. Furthermore, it will be necessary to support parameter passing to the operating system and routines written in other PC languages. Is there on-line documentation of calling conventions? I will first be designing my own assembler to 8088 code written as a Modula-3 library (bottom up), and a Modula-3 parser to an internal structure (top down). Would it be an advantage to use one of the RISC architectures as an internal code representation? Furthermore, I would like to incorperate into the design formal verification techniques and an extended pragma set for rapid evolutionary development, a software development technique and paradigm I am now formulating. May I request anyone interested in discussing any of these issues to email me here at n8243274@henson.cc.wwu.edu. What I have outlined is exactly the state of the development now. S Lee ODEGARD n8243274@henson.cc.wwu.edu ======================================================================== 51 === Date: Thu, 31 Oct 91 09:42:57 PST From: Subject: Re: SRC M3 GC question SRC Modula-3 only invokes the garbage collector as a side-effect of NEW. If your real-time critical loops don't do a NEW, they won't trigger a collection. Alternatively you can call RTHeap.DisableCollection and RTHeap.EnbleCollection to temporarily suspend collections. You can force a garbage collection by calling RTHeapRep.CollectNow. The RTHeap and RTHeapRep interfaces are essentially unchanged between version 1.6 and 2.0. - Bill Kalsow ======================================================================== 52 === Date: Thu, 31 Oct 91 15:04:59 PST From: muller@src.dec.com (Eric Muller) Subject: Re: M3 for 8088 In article <1991Oct31.072821.16552@henson.cc.wwu.edu>, steven l. odegard writes: > May I request anyone interested in discussing any of these issues to > email me here at n8243274@henson.cc.wwu.edu. What I have outlined is > exactly the state of the development now. Given the interest that has been manifested in the past about PC implementations of Modula-3, you may want to have the discussion in comp.lang.modula3. eric. ======================================================================== 53 === Date: Thu, 31 Oct 91 21:03:19 -0800 From: Paul A Vixie Subject: strange Wr bug (was Re: SRC M3 GC question ) Thanks for your help. Knowing that RTHeap is not going to change much in 2.0 pretty much tells me what I need to know. I got several other answers but I would rather not use DISPOSE() if it means I have to use untraced refs. Anyway, I have a new quandry. I'm co-authoring a Datagram interface to make UDP sockets available to M3 applications. I found RTScheduler.IOSelect and followed the suggestions in its .i3 file; everything seems to work with send() but when I got around to recv() I was never waking up out of IOSelect(). I eventually got around to adding a Wr.PutText(Stdio.stdio, mumble) just before the IOSelect(), but I forgot that stdout is buffered so I got no output before the program hung in IOSelect() as it had been doing. So I added a Wr.Flush() between Wr.PutText and RTScheduler.IOSelect(), and not only did I get my debugging output, the program stopped hanging and I got my recv() data! So I took out the Wr.PutText() and left in the Wr.Flush(Stdio.stdout), and it still works fine -- even though there is never anything to flush. Have I tickled a bug, or is there something I should be doing to make IOSelect work as its .i3 advertises? I'm willing to call more things, but Wr.Flush() seems like the wrong way to unwedge my socket select. Here's the code: PROCEDURE Receive(self: T; data: REFANY; size: INTEGER): INTEGER = VAR cc: INTEGER; fds: CoreOS.FDSet; BEGIN LOCK self DO LOOP cc := Usocket.recv(self.socket, LOOPHOLE(data, ADDRESS), size, 0); IF cc < 0 AND Cerrno.errno # CoreOS.EWOULDBLOCK THEN Net.Error(); ELSIF cc >= 0 THEN RETURN cc; END; fds := CoreOS.FDSet{self.socket}; (* XXX SHOULD NOT be nec'y but otherwise we block in select *) Wr.Flush(Stdio.stdout); (* XXX *) EVAL RTScheduler.IOSelect(self.socket+1, ADR(fds), NIL, NIL); END; END; END Receive; I'm using the M3 from /proj/cra. Thanks, Paul Vixie DEC NSL