======================================================================= 1 === Date: 1 Jul 92 14:26:18 GMT From: markp@dmsperth.dms.oz (Mark Palmer) Subject: maspars We are just about to have shared access to a DECmpp12000, otherwise known as a Maspar, and I was wondering if anyone had attempted to use modula 3 on such a beast. Presumably one would run the 'normal' sequential type code on the front end DECstation, but possibly link it with parallel code that could execute on the back end? D ======================================================================= 2 === Date: Thu, 2 Jul 92 03:50:27 GMT From: muller@src.dec.com (Eric Muller) Subject: Modula-3 FAQ Archive-name: Modula-3-faq Last-modified: Jun 6 1992 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. 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. 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. ======================================================================= 3 === Date: Thu, 2 Jul 92 18:59:21 GMT From: muller@src.dec.com (Eric Muller) Subject: comp.lang.modula-3 archive for june available The messages sent to comp.lang.modula-3 during the month of June 92 are available via anonymous ftp from: gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3/92-06.Z Previous months are availble in the same directory. -- Eric. ======================================================================= 4 === Date: Thu, 2 Jul 1992 19:53:05 GMT From: wewallac@watsol.waterloo.edu (Bill Wallace) Subject: Generics using generic interfaces If one has a generic for a list say, and a tree and one wishes to implement the tree generic in terms of the the list generic, the list generic must be passed as an argument to the tree generic, and an actual modula/interface must be created for the list as well as the tree. It would be nice if this were not so, if one could say in an interface (even if this is restricted entirely to generic interfaces) Generic Interface Tree(Label,List,Elem); Interface Local=List(Elem); END Local; ... END Tree. ======================================================================= 5 === Date: 3 Jul 92 01:24:47 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Generics using generic interfaces Well, you don't really want more than instance of the inerface List(T) for a given T within a program. Hence the need to create such interfaces explicitly, since structural equivalence is not defined on interfaces, but on types. See the discussion in the Systems Programming in Modula-3 book ...... -- 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 ======================================================================= 6 === Date: 6 Jul 92 14:44:53 GMT From: ggf@saifr00.cfsat.honeywell.com (Gary Frederick) Subject: building a cross compiler I am interested in building the NeXT version on a Sun. How do I set things up such that I can use the Sun compiler to build new boots for the NeXT? Please e-mail to ggf@jsoft.com in addition to posting here if you can. I may be loosing access to news )-: Gary ======================================================================= 7 === Date: Sat, 04 Jul 92 22:43:23 GMT From: whedon@netcom.com (Bill Whedon) Subject: Pointer to Professional Programmers Poll POINTER: Please see comp.lang.misc article dated Wed 01 Jul 92 04:38:41 GMT using keywords language, programming, poll, statistics for a poll regarding your use of languages. Thanks for your patience and for not flaming me for not putting your favorite in a box specifically. There are simply too many languages, and the poll would have been too big for posting. Please use the write-in box as much as you need. Thanks in advance for your participation! Cheers, bw -- Bill Whedon whedon@netcom.com (408) 842-9914 "Hey, we're all professionals here, ain't we?" ======================================================================= 8 === Date: Sat, 4 Jul 92 14:51:49 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Modula-3 Users' Group meeting report: part 4 In article 11150@src.dec.com, jdd@src.dec.com (John DeTreville) writes: > [ ... ] > Proposed Language Changes > Norman Ramsey > [ ... ] >Discussion moved from specific topics to the general questions of how >much change we want and what mechanisms there are for making changes. >There was broad consensus in favor of keeping the language stable, >although we didn't explore in detail what ``stability'' meant. >Greg Nelson's view was that another ``12 changes'' in the next 18 >months would be too much change, but that there would be changes >eventually---otherwise the language would be dead. Sam Harbison >suggested that we think about making changes approximately every two >years. > IMHO, the crucial aspect of stability is that a valid M3 program today is still a valid program tomorrow. Adding new features which simply extend the capabilities of the language (like VIRTUAL OBJECT) don't affect stability seriously. Other changes, which might cause that existing programs have to be adapted, should be included carefully. But why discuss this in terms of every n months? If there is a consensus that a certain feature is wanted and needed, why not include it immediately? If someone personally dislikes this, well - nobody is forced to work with an up-to-date version of the language. Just stick with your old compiler until you think it's time to install a new one. Some good concepts are an important basis for a new language. But if the language designers can't react (i.e. at least talk about) promptly to new developments, the language *will* be dead before you know it. This is no vote for being opportunistic, just for being open to new suggestions. >Sam Harbison suggested that no changes at all are better than a few >good changes, and that it is important to be able to point new users >to a single document that describes the language, not make them apply >deltas to the existing documents. Christian Jacobi said that small >improvements are not worth the disruption. He also said that there is >a difficult tightrope walk between promising enough stability and >getting the necessary changes done. He thought that the language >commitee handled the 12 changes quite elegantly in this respect. > Hmm, does this mean that language changes should be made in large chunks?! I don't see any good in this. In fact, I would want changes to come one at a time, especially if I have to modify my sources. Of course, there should be an up-to-date language description at any time. But in what way does this oppose new developments? Just change the language report accordingly and there we are. >Dave Detlefs argued the opposite position, that Modula-3 has a small >user community, so now is a good time to make changes. Modula-3 might >need to change to compete with C++ templates. Eliot Moss pointed out >that the designers might have an inaccurate picture of the potential >impact changes, since they and most users are at SRC where the impact >is high. Eliot also suggested that compilers with experimental >features should offer a conforming mode. > Very right. Even more important than the small user community seems to be the fact that there is only one M3 compiler by now. This takes away all the standarization overhead. >It was suggested that comp.lang.modula3 could be used as a forum for >proposing changes, but there seemed to be agreement posting is too >easy and that the process for proposing changes should be more >arduous. Someone asked how well comp.lang.modula3 is working, and >those present were not too dissatisfied, although there were broad >complaints that there is too much quantity and the signal-to-noise >ratio is low. No-one present volunteered to moderate a Modula-3 >newsgroup. > WHAT?! Ever took a look at comp.lang.Ada, ..., not to talk about comp.lang.C++? The C++ group comes up with 30-60 (!) articles *every day*! If you think signal-to-noise ratio is low in comp.lang.modula3, just look into a few other groups. Now there you'll find really idiotic postings. The modula3 group is one of the most constructive and serious I know of. We surely don't need moderation . And talking about quantity: IMHO, there should be much *more* discussion about conceptual aspects of the language. Most of the time, I have the impression tha t not many people are overly interested in improving M3 - either they like it and use it or they don't (flame on - sometimes this impression extends to the language designers themselves - flame off). Anyway: what alternatives have you considered? Discussion about M3 in the newsgroup is natural - that's what it's good for. So what's the problem? To take a frequent look into the postings if there might be something valuable in there? That shouldn't be too hard. Or do you guys think you will have all good ideas by yourselves (little post-flame here). --- 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 ======================================================================= 9 === Date: Sat, 4 Jul 92 18:48:30 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Optimization on SPARC Part 2 I've just got into installing M3 2.07 with gcc 2.2.2. In addition to the optimization error in compiler/src/types/SubrangeType.m3, there seems to be a new problem in libm3 if compiled with -O. The resulting compiler will crash with segmentation violation. Also, RGBInt__FromRGB won't run through the C compiler, because the function returns a RECORD with packed components. Any help? --- 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 ======================================================================= 10 === Date: Mon, 6 Jul 1992 07:36:23 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: Re: Optimization on SPARC Part 2 Peter Klein wrote: > I've just got into installing M3 2.07 with gcc 2.2.2. In addition to the > optimization error in compiler/src/types/SubrangeType.m3, there seems to > be a new problem in libm3 if compiled with -O. The resulting compiler will > crash with segmentation violation. Also, RGBInt__FromRGB won't run through > the C compiler, because the function returns a RECORD with packed components. I retrieved 2.07 when it was still in the test-release directory, and it compil ed with no problems (boot.SPARC). I use that compiler at the moment without proble ms. Earlyer I tried compiling all the 2.06 stuff using the earlyer installed compil er, but I never managed to pull it off. PS I use the standard SUN cc. PPS Code generation with the current version is MUCH better than previous relea ses! hello worlds is down to 350Kb stripped ;-) Greetings, Bert -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null ======================================================================= 11 === Date: 7 Jul 92 01:33:41 GMT From: freeman@EuroPARC.Xerox.COM (Steve Freeman) Subject: m3text in Andrew EZ editor Does anyone know anything about the m3text mode in the EZ editor in Andrew? In particular, how to get it to work without core-dumping EZ. I suspect it's something simple like setting a path but I haven't anyone to hand who would know. Incidentally, the reason I'm interested in this is that, much as I like the language, I find the combination of M3 and emacs (even with the right modes) pretty bad for the wrists; I think it`s the heavy use of various shift keys. Steve (really Steve.Freeman@computer-lab.cambridge.ac.uk) ======================================================================= 12 === Date: Tue, 7 Jul 92 06:22:18 GMT From: muller@src.dec.com (Eric Muller) Subject: Re: building a cross compiler In article <1992Jul6.144453.29189@saifr00.cfsat.honeywell.com>, ggf@saifr00.cfs at.honeywell.com (Gary Frederick) writes: > I am interested in building the NeXT version on a Sun. How do > I set things up such that I can use the Sun compiler to build > new boots for the NeXT? In the toplevel directory: $ m3make -f m3makefile.compiler cross NEW=NEXT to build a cross compiler running on the current machine, compiling for NEXT $ m3make -f m3makefile.compiler bootstrap_both NEW=NEXT to cross-compile the driver and the compiler $ m3make -f m3makefile.compiler pack NEW=NEXT to create boot_files/boot.NEXT-2.07.tar.Z, similar to the one we distribute If your Sun and you NeXT share the file system, you don't need the last step: go on the NeXT, in the top-level directory and pretend that you have just unpacked the boot archive. -- Eric. ======================================================================= 13 === Date: 7 Jul 92 12:53:22 GMT From: ggf@saifr00.cfsat.honeywell.com (Gary Frederick) Subject: Re: building a cross compiler Thanks for the info on building the cross. Gary ======================================================================= 14 === Date: Tue, 7 Jul 92 11:10:26 EDT From: wyant@centerline.com Subject: re: Proposed langauge changes > [ ... ] > Proposed Language Changes > Norman Ramsey > [ ... ] >Discussion moved from specific topics to the general questions of how >much change we want and what mechanisms there are for making changes. >There was broad consensus in favor of keeping the language stable, >although we didn't explore in detail what ``stability'' meant. >Greg Nelson's view was that another ``12 changes'' in the next 18 >months would be too much change, but that there would be changes >eventually---otherwise the language would be dead. Sam Harbison >suggested that we think about making changes approximately every two >years. > The older I get, the more conservative toward language changes I get. Maybe that's just a consequence of seeing how C++ is evolving. To many of the proposals are of the form, "Language X has this nifty feature, can we force it into C++...?" The principal reasons for suggesting a language change (IMHO) should be: 1) To clarify an ambiguous area of the language definition. 2) To better support an area where the language a) Discovered to be deficient AND b) Discovered to be a widely used area of the language (or was intended to be a widely used area) I think M3 generics fall under (2) above. I would like to see some hard thinking done in the area of a cleaner, simpler definition of generics that preserves abstraction. -- geoff Geoff Wyant wyant@centerline.com Centerline Software, Inc. (Formerly Saber Software, Inc) 10 Fawcett Street Cambridge, Ma. 01238 ======================================================================= 15 === Date: 7 Jul 1992 22:23:51 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: Proposed langauge changes In article <9207071510.AA20139@riposte> wyant@centerline.com writes: >The older I get, the more conservative toward language changes I >get. Maybe that's just a consequence of seeing how C++ is evolving. >To many of the proposals are of the form, "Language X has this >nifty feature, can we force it into C++...?" I think this is correct -- that is, language change is not necessarily a bad thing, but it has been a bad thing for C++. For instance, if someone could figure out what multiple inheritance was supposed to mean, and what the useful idioms are, and how to make it interact cleanly with the rest of the language, then it might be good to add it to Modula-3. I hear good things about mix-ins from NeWS and CLOS programmers. However, if we don't understand it, or cannot caputer the useful idioms, or if it as some vile interaction with any existing good thing, then perhaps we can live without it. David Chase Sun ======================================================================= 16 === Date: Tue, 7 Jul 92 23:39:36 GMT From: msm@src.dec.com (Mark S. Manasse) Subject: Re: question on generics The issue of generics is a bit of a red-herring here; you would have the same problem if you wanted to put the ListOfBar interface in a separate interface even if it weren't generic. The way you get around this is to split up your Foo interface as follows: INTERFACE Foo; TYPE Bar <: PublicBar; PublicBar = OBJECT ... END; END Foo. INTERFACE BarDetails; IMPORT Foo, ListOfFooDotBar; REVEAL Foo.Bar = Foo.PublicBar BRANDED OBJECT enumerate(): ListOfFooDotBar.T END; END BarDetails. Every Bar will then have an enumerate method, and any clients of BarDetails will be able to call it. Alternatively, you could have a Bar interface that reveals only that a Bar.T is a subtype of ROOT, build ListOfBar, and then have Foo reveal that a Bar.T had an enumerate procedure, and all the other stuff you wanted to know about Bars. Mark ======================================================================= 17 === Date: Tue, 7 Jul 92 17:16:06 EDT From: wyant@centerline.com Subject: question on generics I may not be thinking about this in the right way... I have a generic interface, say "List", and a non-generic interface say "Foo". Foo exports an object type, say "Bar". Bar has an operation which wants to return a "List of Bar", using the generic "List" interface. Given that I need to have imported an instantiation of the List interface parameterized by Bar, I don't see any way to do this with the current generics definition. I need to have Bar defined in order to instantiate the "List of Bar" interface, and I need the "List of Bar" interface defined for the interface exporting "Bar". As I said, I may just be thinking of this in the wrong way. -geoff ======================================================================= 18 === Date: Tue, 7 Jul 1992 19:58:48 GMT From: cope@cbnewsb.cb.att.com (james.o.coplien) Subject: OOPSLA/92 Development Process Workshop: Call for Papers Preliminary Call for Participation - 1992 OOPSLA Workshop Proposal "Development Processes for Use of the Object Paradigm" ---------------------------------------------------- In conjunction with the OOPSLA '92 conference being held in Vancouver, British Columbia, Canada, on October 18 - 22 1992, a workshop will be held on the subject of using OO Methods in the commercial environment. I am issuing this preliminary call for papers to allow potential participants extra time to prepare their position papers. PURPOSE AND GOALS FOR WORKSHOP ------------------------------ Most proponents of the object paradigm advocate iterative design methods and prototyping, and claim it helps reduce long-term software evolution costs. Many of these claims relate to use of domain analysis in the front-end process, to broaden design scope in a way that better anticipates, or at least accommodates, long-term change. An iterative development process is key to exploring design alternatives beyond those considered by more strictly structured techniques. These assumptions raise some interesting questions about how long-term maintenance should be managed. Large organizations cannot work effectively in an environment of constantly changing interfaces. How early in the release cycle should interfaces be pronounced stable and put under project control? Other perspectives on this problem have been suggested: - Totally doing away with organizational ownership of interfaces, leaving project interface management to free, global collaboration; - Doing away with the concept of "releases" by defining new releasable products as the inventory of services to support them become stable over time; - Allowing no deletion of existing code, accommodating evolution only through the addition of new classes, largely through derivation from existing classes; - Automating generation of product structure or code directly from product specifications, every time the specification changes; This workshop will explore the following issues, drawing on the experience of its participants, and on ongoing research in this area: - Where objects do and do not work well to address the problem of changing interfaces; - What tools, mechanisms, and management policies should be used to manage object-oriented interface evolution (version, interface, and configuration management); - Whether mixed language technologies (e.g., Smalltalk for evolution, and C++ for deployment) within a single project help or hurt long-term flexibility and cost. In this one day of dialogue, I hope the group can establish a framework of development processes based on product development interval, project size and maturity, and such other ideas as occur during the day. Individual papers will be selected for presentation on the workshop agenda, but all are expected to participate in discussion and are encouraged to bring supporting materials. I would also like to entertain proposals for carrying this dialogue forward in one or more forums beyond OOPSLA '92. PARTICIPANTS AND OBSERVERS -------------------------- Participation is solicited from those actively engaged in research on software methodology, architectural evolution, or software process, as well as spokespersons for project and corporate management strategies for deployment of software products. Requests to participate as observers will be honored as space permits on a first-come, first-served basis. WORKSHOP FORMAT AND LENGTH -------------------------- I hope to keep as much of the agenda as possible free for moderated discussion. Specific papers may be selected for short (20 minute) presentations, depending on the response received. I am open to suggestions for use of other formats. The workshop will be one day long. POSITION PAPERS --------------- All participants must submit short (1-2 page) position papers to the workshop organizer. The paper should briefly describe your project (application, number of people, language used), and address 3-5 issues of interest to you. You may select issues from the list above, or contribute additional issues. Papers must be submitted by August 20, 1992. Participants will be selected and notified by Sept. 15, 1992. Those who wish to be placed on the waiting list for observers should provide us with their name, address, phone number, Email address and Fax number. For more information, please contact me. Jim Coplien IHC 1G341 AT&T Bell Laboratories 1000 East Warrenville Road Naperville, IL 60566 Voice: (708) 713-5384 Fax: (708) 713-4982 Email: cope@research.att.com ======================================================================= 19 === Date: Wed, 8 Jul 1992 04:37:28 GMT From: alanf@cs.monash.edu.au (Alan Grant Finlay) Subject: Re: Changes to Modula-3 pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) writes: >IMHO, the crucial aspect of stability is that a valid M3 program today is >still a valid program tomorrow. Adding new features which simply extend the >capabilities of the language (like VIRTUAL OBJECT) don't affect stability >seriously. Other changes, which might cause that existing programs have to be >adapted, should be included carefully. But why discuss this in terms of >every n months? If there is a consensus that a certain feature is wanted and >needed, why not include it immediately? If someone personally dislikes this, >well - nobody is forced to work with an up-to-date version of the language. >Just stick with your old compiler until you think it's time to install a new >one. One point you seem to have missed is that language users form a community. If I choose to stick to version X of a language definition and everybody else moves to X+1 then I can't use or understand some of the code which is generously donated every now and again. Changing a language definition too often => suicide for the language. As an example, has anybody tried using Icon? Versions of Icon are all upwardly compatible and add new features which only Icon fanatics would bother to learn to use. The basic core of Icon is hard enough to learn as it is. In addition, for users who do not maintain their own computing facilities, it can be hard to convince an overworked systems manager to reinstall a little used (in terms of number of users) language compiler every year. ======================================================================= 20 === Date: Wed, 8 Jul 92 17:58:29 GMT From: muller@src.dec.com (Eric Muller) Subject: Re: Modula 3 2.07 In article , dagenais@vlsi.polymt l.ca (Michel Dagenais) writes: > Version 2.07 switched from test-release to release without fanfare. Perhaps > a short announcement on this newsgroup would prevent unnecessary polling of > gatekeeper.dec.com. I sent a message on Tue, 30 Jun 92 19:35:34 GMT, Message-ID: <1992Jun30.193534.20917@src.dec.com>: SRC Modula-3 2.07 is available in: gatekeeper.dec.com:pub/DEC/Modula-3/release In addition to the usual bug fixes, the main changes are: - the libraries color, sx and pinecreek have been merged into libm3 - three new archives: vbtkit, a set of VBTs formsvbt, a user-interface editor library vbtapps, which include a user-interface editor and demo applications I'll let Marc or Jim (the culprits) comment more on that - the DECstation OSF/1 version has been reactivated. I don't know if it works. It seems that the <*OBSOLETE*> mechanism is now reliable. In the next release, all the things marked <*OBSOLETE*> in 2.07 will be removed; you probably want to start cleaning your code when you have a chance. -- Eric. ======================================================================= 21 === Date: Wed, 8 Jul 92 18:03:02 GMT From: muller@src.dec.com (Eric Muller) Subject: Re: short language tutorial? In article <5960@otc.otca.oz>, johng@otc.otca.oz.au (John Gibbons) writes: > > Is there a short tutorial on modula3 that can be ftped across the net? I woul d > like to get a quick idea of the language. For a very quick idea: 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. For more details: "Modula-3" by Sam Harbison, Byte, Vol. 15, Number 12, October 1990, p 385. For all the details; 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 Sam Harbison has written a book about Modula3: Modula-3 Samuel P. Harbison Prentice Hall, 1992 ISBN 0-13-596396-6 There is nothing available on-line. Of course, if somebody wants to write or recyle a blurb, we can archive it on gatekeeper.dec.com and/or mention it in the FAQ. -- Eric. ======================================================================= 22 === Date: Wed, 8 Jul 1992 14:59:18 GMT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: Modula 3 2.07 Version 2.07 switched from test-release to release without fanfare. Perhaps a short announcement on this newsgroup would prevent unnecessary polling of gatekeeper.dec.com. Moreover, comp.archive would pick up the announcement and give some further exposure to Modula 3. Besides, there is more in this new release than the .01 increment suggests (FormsVBT...). It installed fine on the Sparc here. Does anyone have a packaged "patch" or shell script that can produce shared libraries. I dont really need sharing in core (-pic, .so and .sa files...), i just want to reduce the disk requirements of executables. -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 23 === Date: 8 Jul 92 08:04:28 GMT From: johng@otc.otca.oz.au (John Gibbons) Subject: short language tutorial? Is there a short tutorial on modula3 that can be ftped across the net? I would like to get a quick idea of the language. Thanks in advance ======================================================================= 24 === Date: Wed, 08 Jul 92 17:14:47 -0400 From: Samuel Harbison Subject: Dr. Dobbs article on Modula-3 The October issue of Dr. Dobbs's journal will contain an introductory Modula-3 article, "Safe Programming in Modula-3". Sam Harbison, Director, Commercial Products Division Tartan, Inc.; 300 Oxford Drive, Level 4; Monroeville, PA 15146; USA. Phone: +1 (412) 568-3600; Fax: +1 (412) 568-3636; Email: harbison@tartan.com. ======================================================================= 25 === Date: Wed, 8 Jul 92 03:25:15 PDT From: surak!frode (Frode Odegard) Subject: defaults for VAR parameters Why can't VAR parameters have defaults ? - Frode (frode@odegard.com) ======================================================================= 26 === Date: Wed, 8 Jul 1992 18:22:06 PDT From: David Nichols Subject: m3pp with PostScript support I've made a new version of m3pp with support for PostScript pretty-printing available for anonymous ftp on parcftp. This version uses special fonts for keywords, comments, built-in identifiers, the procedure name in a procedure declaration, etc. Unlike similar programs, this one simultaneously adds fonts and reformats, so it's able to make line break and column alignment decisions based on the actual PostScript font widths. The backend to the formatter package is "generic", so you might be able to use it to make a pretty-printer for something like ATK (hint, hint). It's on parcftp.parc.xerox.com (13.1.64.94) in "pub/m3/m3pp.tar.Z". I'm releasing this myself because the changes to the Formatter package are larger than normal, and to get it out a little quicker. Please let me know how it works for you. Thanks to Bill Schilit for merging my old version of this into the current version of m3pp. David ======================================================================= 27 === Date: Tue, 7 Jul 1992 13:40:29 GMT From: amichail@cayley.waterloo.edu (Amir Michail) Subject: real-time extensions to high level languages I am looking for papers/books on adding real-time extensions to high level languages. In particular, I am most interested in the extensions required to handle interrupts. I understand that there has been much talk about this, particularly in extensions to Ada. However, I have had a hard time locating papers on this. Could someone point me to the definitive sources? Amir ======================================================================= 28 === Date: Thu, 9 Jul 92 10:21:57 EDT From: wyant@centerline.com Subject: M3 Keyword and comment highlighting for Epoch I'd don't know many M3 users use the Epoch version of Emacs, but this seemed relatively short and useful to post. Its a modification of Marc Andreesssen's "lightbrite" highlighting package to support M3. It's pretty much self contained. Before loading it, add the following lines to your .emacs file: (defun make-style-with-font (font) "Make a style with font FONT." (let ((s (epoch::make-style))) (set-style-font s font) s)) (setq red-style (make-style-with-font "*helvetica-medium-r-normal--10*")) (setq green-style (make-style-with-font "*courier-bold-r-normal--12*")) (setq yellow-style (make-style-with-font "*helvetica-bold-r-normal--10*")) (setq magenta-style (make-style-with-font "*helvetica-medium-r-normal--10*")) (setq comment-style (make-style-with-font "*times-medium-i-normal--10*")) (setq yellow-underline-style (make-style-with-font "*helvetica-medium-o-normal--12*")) (setq red-underline-style (make-style-with-font "*helvetica-bold-o-normal--12*")) Below is the "lightbrite" package itself. Let me know what you think. --geoff ------- Cut here ----------- ;; File: --- lightbrite.el --- ;;; Author: Marc Andreessen (marca@ncsa.uiuc.edu) ;;; Copyright (C) National Center for Supercomputing Applications, 1992. ;;; ;;; This program is free software; you can redistribute it and/or modify ;;; it under the terms of the GNU General Public License as published by ;;; the Free Software Foundation; either version 1, or (at your option) ;;; any later version. ;;; ;;; This program is distributed in the hope that it will be useful, ;;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a copy of the GNU General Public License ;;; along with your copy of Epoch; if not, write to the Free Software ;;; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. ;;;*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ;;;* CONTENTS: ;;;* Lightbrite (formerly marc-hilite) v1.0. ;;;* Epoch functions for syntax-directed highlighting of assorted ;;;* types of source, including Lisp, C, LaTeX, plain text, and mail. ;;;* NOTES: ;;;* Code and ideas stolen from Ken Wood, Heinz W. Schmidt, Paul Nakada, ;;;* and Dan LaLiberte. ;;;* FUTURE: ;;;* Dynamic hilighting of regexp's (maybe a bank of ;;;* available regexp's and associated styles). ;;;* HISTORY: ;;;*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (require 'syntax-decode) (provide 'lightbrite) ;; TODO: ;; o Should use zones-in-region primitive. ;; o Comment highlighting doesn't work in instant mode. ;; o Move to regexp-based comment highlighting for all modes. ;; o Maybe add a little padding to paragraph/function extents. ;; o Move to list representation of mode/regexp specification. ;; o Save match-data any time we do highlighting. ;;; ---------------------- brite::make-foreground-style ---------------------- (defun brite::make-foreground-style (fgname) "Convenience function to make a style with given foreground FGNAME." (let ((brite::style (make-style))) (set-style-foreground brite::style fgname) brite::style)) (defun brite::make-underline-style (fgname) "Convenience function to make a style with given underline FGNAME." (let ((brite::style (make-style))) (set-style-underline brite::style fgname) brite::style)) ;;; ------------------------- buffer-local variables ------------------------- ;; Users can setq the *-default variables before loading this file ;; to affect defaults for buffer-local variables. ;; Define the default values. (defvar brite::comment-highlight-on-default t) (defvar brite::touchup-highlight-on-default t) (defvar brite::touchup-check-string-default t) (defvar brite::touchup-check-zone-default t) (defvar brite::highlight-on-write-default nil) ;; Define the buffer-local variables. (defvar brite::comment-highlight-on nil "T if comments should be highlighted in this buffer; NIL otherwise.") (defvar brite::touchup-highlight-on nil "T if syntax-directed touchup should be done in this buffer; NIL otherwise.") (defvar brite::touchup-check-string nil "T if in-string checking should be done in this buffer; NIL otherwise.") (defvar brite::touchup-check-zone nil "T if in-zone checking should be done in this buffer; NIL otherwise.") (defvar brite::highlight-on-write nil "T if this buffer should be re-highlighted on write; NIL otherwise.") ;; Make the buffer-local variables buffer-local. (make-variable-buffer-local 'brite::comment-highlight-on) (make-variable-buffer-local 'brite::touchup-highlight-on) (make-variable-buffer-local 'brite::touchup-check-string) (make-variable-buffer-local 'brite::touchup-zone-string) (make-variable-buffer-local 'brite::highlight-on-write) ;; Set the defaults. (setq-default brite::comment-highlight-on brite::comment-highlight-on-default) (setq-default brite::touchup-highlight-on brite::touchup-highlight-on-default) (setq-default brite::touchup-check-string brite::touchup-check-string-default) (setq-default brite::touchup-check-zone brite::touchup-check-zone-default) (setq-default brite::highlight-on-write brite::highlight-on-write-default) ;;; --------------------------- control variables ---------------------------- ;; Users can setq these before loading this file. (defvar brite::highlight-on-find t "T if we should highlight each new file when it's first loaded.") ;; These should be able to be nil also. (defvar brite::comment-threshold 100000 "Integer for maximum size of file for which comments are highlighted.") (defvar brite::touchup-threshold 30000 "Integer for maximum size of file for which touchup highlighting is done.") ;; Setting this value small (<5) really makes it look good, but gives ;; quite a performance hit. (defvar brite::change-interval 6 "Number of changes between line highlighting, when after-change-function is activated.") ;; 80 makes sure we see the beginning of normal-length lines. (defvar brite::area-extent 80 "Half of the size of a local area, for instant highlighting purposes.") ;;; --------------------------- colors and styles ---------------------------- ;; User can setq either the *-name variables or the *-style variables, ;; at their choice, before loading this file. ;; These colors were chosen for a black background; I don't ;; know how they'd look on a light background. Suggested foreground ;; colors are wheat, grey80-grey90, #ffa07a, #ffaf7f, #ff7f24, ;; and #efafff. If you come up with a nice set of fg/bg/highlight ;; colors, send them to me. (defvar comment-style-color "#7d9ec0") (defvar red-style-color "red") (defvar magenta-style-color "magenta") (defvar green-style-color "green") (defvar yellow-style-color "yellow") (defvar comment-style (brite::make-foreground-style comment-style-color) "Style used to highlight comments.") (defvar red-style (brite::make-foreground-style red-style-color) "Style used to highlight in red.") (defvar magenta-style (brite::make-foreground-style magenta-style-color) "Style used to highlight in magenta.") (defvar green-style (brite::make-foreground-style green-style-color) "Style used to highlight in green.") (defvar yellow-style (brite::make-foreground-style yellow-style-color) "Style used to highlight in yellow.") (defvar yellow-underline-style (brite::make-underline-style yellow-style-color) "Style used to underline in yellow.") (defvar red-underline-style (brite::make-underline-style red-style-color) "Style used to underline in red.") ;;; --------------------------- internal variables --------------------------- ;; Users shouldn't tamper with these. (defvar brite::highlight-done nil "Flag for highlighting done once here.") (make-variable-buffer-local 'brite::highlight-done) (setq-default brite::highlight-done nil) (defvar brite::beginning-point 0 "Starting point for regexp searches.") (defvar brite::ending-point 0 "Ending point for regexp searches.") (defvar brite::change-counter 0 "Internal counter to track number of changes.") (defvar brite::instant-highlight-on nil "Flag for instant highlighting. Call brite::toggle-instant-highlight-on to turn instant highlighting on and off.") (make-variable-buffer-local 'brite::instant-highlight-on) (setq-default brite::instant-highlight-on nil) (defvar brite::diagnostics-on nil "If T, print diagnostics to minibuffer as appropriate.") ;;; ---------------------------- brite::in-zone-p ---------------------------- (defun brite::in-zone-p (point) "T if POINT is in a zone, NIL otherwise." (if (epoch::zone-at point) t nil)) ;;; ----------------------- brite::in-quoted-string-p ------------------------ (defun brite::in-quoted-string-p (point) "Use parse-partial-sexp to check for POINT in quoted string; return T if so, NIL if not." (save-excursion (beginning-of-defun) (if (null (nth 3 (parse-partial-sexp (point) point))) nil t))) ;;; ------------------------- brite::regexp-touchup -------------------------- (defun brite::regexp-touchup (regexp sty &optional everytime) "Highlight all matches of REGEXP in a given style. Second arg STY is a style. Optional third arg EVERYTIME indicates that pattern should always be highlighted, even when in a zone or string." (let (brite::beginning brite::end (case-fold-search nil)) (save-excursion (goto-char brite::beginning-point) ;; Loop through all matches in this buffer. (while (re-search-forward regexp brite::ending-point t) ;; Preserve values of begin/end from search. (setq brite::beginning (match-beginning 0)) (setq brite::end (match-end 0)) ;; If everytime flag not set, and brite::touchup-check-zone ;; not set, check for in-zone-p. (if (or everytime (not brite::touchup-check-zone) (not (brite::in-zone-p brite::beginning))) ;; Either everytime is set, or we're not checking ;; strings, or we're not in a string. (if (or everytime (not brite::touchup-check-string) (not (brite::in-quoted-string-p brite::beginning))) (epoch::add-zone brite::beginning brite::end sty))))))) ;;; --------------------- convenience touchup functions ---------------------- (defun brite::regexp-touchup-red (regexp) "Touchup REGEXP in red." (brite::regexp-touchup regexp red-style)) (defun brite::regexp-touchup-magenta (regexp) "Touchup REGEXP in magenta." (brite::regexp-touchup regexp magenta-style)) (defun brite::regexp-touchup-green (regexp) "Touchup REGEXP in green." (brite::regexp-touchup regexp green-style)) (defun brite::regexp-touchup-yellow (regexp) "Touchup REGEXP in yellow." (brite::regexp-touchup regexp yellow-style)) (defun brite::regexp-touchup-yellow-always (regexp) "Touchup REGEXP in yellow always." (brite::regexp-touchup regexp yellow-style t)) (defun brite::regexp-touchup-yellow-underline (regexp) "Touchup REGEXP in yellow underline." (brite::regexp-touchup regexp yellow-underline-style nil)) (defun brite::regexp-touchup-red-underline (regexp) "Touchup REGEXP in red underline." (brite::regexp-touchup regexp red-underline-style nil)) ;;; ----------------------- brite::highlight-comments ------------------------ ;; This function is stolen almost verbatim from Ken Wood's package. (defun brite::highlight-comments () "Highlight all comments in a buffer if the buffer's size does not exceed brite::comment-threshold." ;; Silently do nothing if there are no regexps to search with ;; or if the buffer is too large to highlight. (if (and syndecode-comment-start-regexp syndecode-comment-end-regexp brite::comment-threshold (< buffer-saved-size brite::comment-threshold)) (let ((starting-point brite::beginning-point) comment-start-begin comment-start-end comment-end-end) (save-excursion (goto-char brite::beginning-point) ;; Algorithm is: search for start of a comment, ;; make sure it really is a comment; then highlight ;; from there to the end of the comment. ;; First, find a comment-start sequence. (while (re-search-forward syndecode-comment-start-regexp brite::ending-point t) (progn (setq comment-start-begin (match-beginning 0)) (setq comment-start-end (match-end 0)) ;; Check that the comment start sequence really does ;; indicate the start of a comment, and that it's not ;; inside a string etc. (if (nth 4 (parse-partial-sexp starting-point comment-start-end)) ;; Yes, this is really the start of a comment (progn (goto-char comment-start-end) ;; Find the end of the comment by searching ;; for a comment terminating sequence. ;; Second arg was changed to brite::ending-point ;; to keep emacs from complaining during per-line ;; highlighting. (re-search-forward syndecode-comment-end-regexp brite::ending-point t) (setq comment-end-end (point)) ;; Highlight the comment (epoch::add-zone comment-start-begin comment-end-end comment-style) ;; Start the next syntax parse at the end of the ;; comment just processed. (setq starting-point comment-end-end))))))))) ;;; ------------------------- brite::true-mode-name -------------------------- ;; Author: Lynn Slater (lrs@indetech.com). (defun brite::true-mode-name () "Returns the name of the mode in such a form that the mode may be re-established by calling the function named by appending '-name' to this string. This differs from the variable called mode-name in that this is guaranteed to work while the values held by the variable may have embedded spaces or other junk." (let ((major-mode-name (symbol-name major-mode))) (substring major-mode-name 0 (or (string-match "-mode" major-mode-name) (length major-mode-name))))) ;;; ------------------------ brite::do-buffer-touchup ------------------------ ;; Datatype must be preceded by whitespace, open paren, or open brace. (setq brite::c-datatype-prefix "[ \n\t({]") ;; Datatype must be followed by whitespace, close paren, or *. (setq brite::c-datatype-suffix "[ \n\t)*]") ;; Keyword must be preceded by whitespace or open brace. (setq brite::c-keyword-prefix "[ \n\t{]") ;; Keyword must be followed by whitespace, semicolon, or open paren. (setq brite::c-keyword-suffix "[ \n\t;(]") (setq brite::c-directives "\\(#endif\\|#else\\|#ifdef\\|#ifndef\\|#if\\)") (setq brite::c-defines "\\(#include\\|#define\\|#undef\\|typedef\\|enum\\)") (setq brite::c-datatypes (concat brite::c-datatype-prefix "\\(int\\|float\\|Float\\|char\\|double\\|short\\|long\\|void\\|struct\\|un ion\\)" brite::c-datatype-suffix)) (setq brite::c-data-attributes "\\(unsigned\\|extern\\|static\\|public\\|private\\)") (setq brite::c-flagged-keywords (concat brite::c-keyword-prefix "\\(return\\|exit\\|assert\\|goto\\)" brite::c-keyword-suffix)) ; ; Modula-3 variables ; (setq brite::m3-flagged-keywords "\\(PROCEDURE\\|TYPE\\|VAR\\|MODULE\\|INTERFACE\\|IMPORT\\|RETURN\\|RAISE \\|FROM\\|RAISES\\)" ) (setq brite::m3-datatypes "\\(INTEGER\\|REAL\\|BOOLEAN\\|CARDINAL\\|CHAR\\|TEXT\\)" ) (setq brite::m3-flagged-block-keywords "\\(BEGIN\\|CASE\\|OF\\|FINALLY\\|TYPECASE\\|END\\|IF\\|THEN\\|ELSE\\|ELS IF\\|WHILE\\|TRY\\|EXCEPT\\|LOOP\\)" ) ;; In the future this will be in table format and facilities ;; will be provided for extending both the modes supported and ;; the regexp's used. (defun brite::do-buffer-touchup () "Based on current mode, do series of calls to brite::regexp-touchup routines to highlight certain regex patterns certain colors, if the buffer's size is less than brite::touchup-threshold." ;; Allow touchup-threshold to be nil also. (if (or (null brite::touchup-threshold) (< buffer-saved-size brite::touchup-threshold)) (cond ;;------------------------------------------------------------------- ((equal mode-name "Text") ;; String between sets of three dashes is a section header. ;; Three equal-signs marks a subsection. ;; '-->' and 'o' are 'item' indicators. ;; String 'Justification:' is always red; ;; at the moment we flag comments (in shell scripts, ;; etc) in red also. ;; UNRESOLVED/FUTURE/CORRECTION/TODO should be flagged. (brite::regexp-touchup-magenta "\\( ===\\|=== \\)") (brite::regexp-touchup-green "\\(-?-->\\|[ \n\t]o[ \t]\\|^o[ \n\t]\\)") (brite::regexp-touchup-red "\\(Justification: \\|#.*\\)") (brite::regexp-touchup-yellow "\\(UNRESOLVED\\|FUTURE\\|CORRECTION\\|T[Oo][ ]?D[Oo]\\|--- .* ---\\) ")) ;;------------------------------------------------------------------- ((equal mode-name "RMAIL") ;; These don't have beginning-of-line rules ("^From" etc) because ;; I like them highlighted in messages included in other messages. (brite::regexp-touchup-yellow "From:.*") (brite::regexp-touchup-magenta "Date:.*") (brite::regexp-touchup-green "Subject:.*")) ;;------------------------------------------------------------------- ((equal (brite::true-mode-name) "rmail-summary") ;; If this is a message we've sent, highlight the receiver. (brite::regexp-touchup-magenta " to: [^ ]*") ;; Highlight the date column. (brite::regexp-touchup-green " [ 0-9][0-9]-[A-Za-z][A-Za-z][A-Za-z] ")) ;;------------------------------------------------------------------- ((equal mode-name "Mail") (brite::regexp-touchup-red "--text follows this line--") (brite::regexp-touchup-green "Subject:.*") (brite::regexp-touchup-magenta "\\(^To:.*\\|^CC:.*\\)")) ;;------------------------------------------------------------------- ((equal mode-name "Texinfo") ;; Code fragments and keystrokes in green. (brite::regexp-touchup-red-underline "\\(@menu\\|@item\\)") (brite::regexp-touchup-yellow-underline "\\(^@chapter.*\\|^@section.*\\ |^@subs.*\\|^@unnumbered\\|^@appendix\\)") (brite::regexp-touchup-green "\\(@code{[^}]*}\\|\@kbd{[^}]*}\\|@file{[^ }]*}\\)") ;; Menu entries and xrefs in magenta. (brite::regexp-touchup-magenta "\\(\*.*::\\|@xref{[^}]*}\\)") (brite::regexp-touchup-yellow "^@node[^,]*") ;; (brite::regexp-touchup-yellow "\\(^@chapter.*\\|^@section.*\\|^@unnu mbered.*\\)") (brite::regexp-touchup-red "\\(@dfn{[^}]*}\\|^@[a-z]index.*\\)") ) ;;------------------------------------------------------------------- ((or (equal mode-name "AUC-LaTeX") (equal mode-name "LaTeX")) (brite::regexp-touchup-yellow "\\([\\]document.*[}]\\|[\\]input.*[}]\\|[\\]include.*[}]\\|includeon ly.*[}]\\)") (brite::regexp-touchup-magenta "\\([\\]begin.*[}]\\|[\\]end.*[}]\\)") ;; String between sets of three dashes is in a comment banner. (brite::regexp-touchup-yellow-always "--- .* ---") ;; For font changes, pick up: ;; o Opening brace, backslash, and keyword. ;; o Any number of characters, except }. ;; o Closing brace. ;; How to pick up entire \verb? ;; How to handle multiline footnote? (brite::regexp-touchup-red "\\([\\]item\\|[{][\\]it[^}]*[}]\\|[{][\\]sc[^}]*[}]\\|[{][\\]em[^}]* [}]\\|[\\]verb\\|[\\]footnote\\|[\\]label.*[}]\\|[\\]ref.*[}]\\)") ;; Assume citation is one long word; always on one line. ;; Also get three dashes in normal text. (brite::regexp-touchup-green "\\([\\]cite[^}]*[}]\\|[ \n]---[ \n]\\|[\\]chapter\\|[\\]section\\|[\ \]subsection\\|[\\]subsubsection\\|[\\]appendix\\|[\\]tableofcontents\\|[\\]new page\\)")) ;;------------------------------------------------------------------- ((or (equal mode-name "C") (equal mode-name "C++")) (brite::regexp-touchup-red-underline "^[_a-zA-Z][^=\n]*(\\(.*;\\|[^{]*\ \)") ;; fn decls (brite::regexp-touchup-red brite::c-directives) (brite::regexp-touchup-red "NULL") ;; These are removed for performance reasons. (brite::regexp-touchup-magenta brite::c-datatypes) (brite::regexp-touchup-magenta "\\([ \t]switch[ (]\\|[ \t]break;\\)") (brite::regexp-touchup-green brite::c-data-attributes) (brite::regexp-touchup-green "[ \t]case.*:") (brite::regexp-touchup-yellow brite::c-defines) (brite::regexp-touchup-yellow brite::c-flagged-keywords) (brite::regexp-touchup-yellow-always "--- .* ---")) ;;------------------------------------------------------------------- ((or (equal mode-name "Modula 3")) (brite::regexp-touchup-yellow brite::m3-flagged-keywords) (brite::regexp-touchup-red brite::m3-flagged-block-keywords) (brite::regexp-touchup-magenta brite::m3-datatypes) (brite::regexp-touchup-yellow-always "--- .* ---")) ;;------------------------------------------------------------------- ((or (equal mode-name "Emacs-Lisp") (equal mode-name "Lisp")) (brite::regexp-touchup-magenta "(interactive[^)\n]*)") (brite::regexp-touchup-green "\\(setq\\|defvar\\|let[ \*]\\|global-set- key\\|define-key\\)") (brite::regexp-touchup-red "\\(nil\\|epoch::[^ \t\n)]*\\)") ;; This gets strings, unless they contain quotes, which ;; throws it out of whack. ;; (brite::regexp-touchup-red "\"[^\"]*\"") (brite::regexp-touchup-yellow "\\(return\\|(require[^)]*)\\|(load[^)]*)\\)") ;; Sadly, this hits (end-of-_defun_) also. (brite::regexp-touchup-red-underline "defun") ;; This doesn't, but it doesn't look real good. ;; (brite::regexp-touchup-yellow-underline "defun [a-zA-Z\-\*:]+") (brite::regexp-touchup-yellow-always "--- .* ---")) ))) ;;; ------------------------ brite::highlight-buffer ------------------------- (defun brite::highlight-buffer () "Highlight current buffer as appropriate." (if brite::comment-highlight-on (brite::highlight-comments)) (if brite::touchup-highlight-on (brite::do-buffer-touchup))) ;;; --------------------- brite::set-search-whole-buffer --------------------- (defun brite::set-search-whole-buffer () "Tell the highlighting code to search the entire buffer." (setq brite::beginning-point (point-min)) (setq brite::ending-point (point-max))) ;;; ---------------------- brite::set-search-this-defun ---------------------- (defun brite::set-search-this-function () "Tell the highlighting code to only search this function." (save-excursion (beginning-of-defun) (setq brite::beginning-point (point)) (end-of-defun) (setq brite::ending-point (point)))) ;;; -------------------- brite::set-search-this-paragraph -------------------- (defun brite::set-search-this-paragraph () "Tell the highlighting code to only search this paragraph." (save-excursion (backward-paragraph) (setq brite::beginning-point (point)) (forward-paragraph) (setq brite::ending-point (point)))) ;;; ---------------------- brite::set-search-this-line ----------------------- (defun brite::set-search-this-line () "Tell the highlighting code to only search this line." (save-excursion (beginning-of-line) (setq brite::beginning-point (point)) (end-of-line) (setq brite::ending-point (point)))) (defun brite::set-search-this-area () "Tell the highlighting code to only search the immediate area." ;; We assume the re-search routines will do range-checking ;; (definitely checking on bound is done). (setq brite::beginning-point (- (point) brite::area-extent)) (setq brite::ending-point (+ (point) brite::area-extent))) ;;; ---------------------- brite::do-highlight-on-find ----------------------- (defun brite::do-highlight-on-find () "Called by find-file-hooks; does highlighting as appropriate." ;; Extract comment details from the current syntax table. (if brite::highlight-on-find (progn (message "Highlighting...") (decode-syntax-table) (brite::set-search-whole-buffer) (brite::highlight-buffer) (message "Highlighting... done.") (if brite::diagnostics-on (message "Made %d zones." (length (epoch::zone-list)))) (setq brite::highlight-done t)))) ;;; ---------------------- brite::do-highlight-on-write ---------------------- (defun brite::do-highlight-on-write () "Called by write-file-hooks; does highlighting as appropriate." ;; Check to see if we highlight this buffer on write. (if brite::highlight-on-write (progn (message "Highlighting...") ;; Check to see if there is any highlighting currently in effect. (if brite::highlight-done ;; If so, remove & redo highlighting. (progn (epoch::clear-zones) (brite::set-search-whole-buffer) (brite::highlight-buffer)) ;; Else, do highlighting for the first time. (progn (decode-syntax-table) (brite::set-search-whole-buffer) (brite::highlight-buffer) (setq brite::highlight-done t))) (message "Highlighting... done."))) ;; Have to return nil or write-file-hooks will get stuffed up. nil) ;;; ---------------------- brite::do-highlight-explicit ---------------------- (defun brite::do-highlight-explicit () "Called interactively; does highlighting as appropriate." (interactive) ;; Check to see if there is any highlighting currently in effect. (if brite::highlight-done ;; If so, remove & redo highlighting. (progn (epoch::clear-zones) (brite::set-search-whole-buffer) (brite::highlight-buffer)) ;; Else, do highlighting for the first time. (progn (decode-syntax-table) (brite::set-search-whole-buffer) (brite::highlight-buffer) (setq brite::highlight-done t)))) ;;; ----------------------- brite::rmail-show-message ------------------------ (defun brite::rmail-show-message () "Called from rmail-show-message hook, and ensures that rmail buffers will always be highlighted." ;; Save current value of touchup max size and temporarily balloon ;; it to nil. This is safe since RMAIL only ;; sets the buffer extents to that part of the file that holds the current ;; message, so (point-min) is not necessarily 0 and (point-max) is ;; not necessarily buffer-saved-size; thus, we can highlight the ;; whole buffer for each message without incurring huge performance ;; penalties. (let ((brite::touchup-threshold-temp brite::touchup-threshold)) (setq brite::touchup-threshold nil) (brite::do-highlight-explicit) (setq brite::touchup-threshold brite::touchup-threshold-temp))) ;;; ---------------------- brite::clear-zones-in-region ---------------------- (defun brite::clear-zones-in-region (start end) "Prune zones lying in region defined by START and END from list of zones in buffer." (catch 'brite::done-clearing-zones (dolist (foo (epoch::zone-list)) (let ((foo-start (epoch::zone-start foo))) ;; We remove zones that start inside this region. (if (and (>= foo-start start) (<= foo-start end)) (epoch::delete-zone foo)) ;; If the zone starts after the end of this region, ;; we're done. (if (> foo-start end) (throw 'brite::done-clearing-zones t)))))) ;;; ---------------------- brite::do-highlight-question ---------------------- (defun brite::do-highlight-function () "Called interactively; highlights current defun only." (interactive) (message "Highlighting function.") ;; Check to see if there is any highlighting currently in effect. (if brite::highlight-done ;; If so, remove & redo highlighting. (progn ;; We have brite::set-search-this-function to set function ;; extents in globals, then clear that region. (brite::set-search-this-function) (brite::clear-zones-in-region brite::beginning-point brite::ending-point) (brite::highlight-buffer)) ;; Else, do highlighting for the first time. (progn (decode-syntax-table) (brite::set-search-this-function) (brite::highlight-buffer) (setq brite::highlight-done t)))) ;;; --------------------- brite::do-highlight-paragraph ---------------------- (defun brite::do-highlight-paragraph () "Called interactively; highlights current paragraph only." (interactive) (message "Highlighting paragraph.") ;; Check to see if there is any highlighting currently in effect. (if brite::highlight-done ;; If so, remove & redo highlighting. (progn ;; We have brite::set-search-this-paragraph to set paragraph ;; extents in globals, then clear that region. (brite::set-search-this-paragraph) (brite::clear-zones-in-region brite::beginning-point brite::ending-point) (brite::highlight-buffer)) ;; Else, do highlighting for the first time. (progn (decode-syntax-table) (brite::set-search-this-paragraph) (brite::highlight-buffer) (setq brite::highlight-done t)))) ;;; ----------------------- brite::highlight-on-change ----------------------- (defun brite::highlight-on-change (pos inspos dellen) "Highlights current line only. Accepts arguments as per after-change-function. Don't do anything if DELLEN nonzero. Assume highlighting has already been done here to speed things up. Only do this every brite::change-interval changes." ;; First make sure this isn't a deletion. (if (= dellen 0) (progn ;; Increment the change counter. (setq brite::change-counter (+ brite::change-counter 1)) ;; Do line highlight if this is a good time. (if (>= brite::change-counter brite::change-interval) ;; Protect everything to keep this from messing up replaces. (save-excursion (let ((data (match-data))) (unwind-protect (progn (setq brite::change-counter 0) ;; To search on the current line, use this. ;; (brite::set-search-this-line) ;; To search in the immediate area, do this. (brite::set-search-this-area) (brite::clear-zones-in-region brite::beginning-point brite::ending-point) (if brite::comment-highlight-on (brite::highlight-comments)) (if brite::touchup-highlight-on (brite::do-buffer-touchup))) (store-match-data data)))))))) ;;; ------------------- INTERACTIVE STATUS CHANGE ROUTINES ------------------- (defun brite::toggle-comment-highlight-on () "Toggle buffer-local comment highlighting." (interactive) (setq brite::comment-highlight-on (not brite::comment-highlight-on)) (message "Setting comment highlighting to %s." brite::comment-highlight-on) (brite::do-highlight-explicit)) (defun brite::toggle-touchup-highlight-on () "Toggle buffer-local touchup highlighting." (interactive) (setq brite::touchup-highlight-on (not brite::touchup-highlight-on)) (message "Setting touchup highlighting to %s." brite::touchup-highlight-on) (brite::do-highlight-explicit) (if brite::diagnostics-on (message "With touchup, %d zones in buffer." (length (epoch::zone-list))))) (defun brite::toggle-touchup-check-string () "Toggle buffer-local in-quoted-string checking." (interactive) (setq brite::touchup-check-string (not brite::touchup-check-string)) (message "Setting touchup string-checking to %s." brite::touchup-check-string) (brite::do-highlight-explicit)) (defun brite::toggle-touchup-check-zone () "Toggle buffer-local in-zone checking." (interactive) (setq brite::touchup-check-zone (not brite::touchup-check-zone)) (message "Setting touchup zone-checking to %s." brite::touchup-check-zone) (brite::do-highlight-explicit)) (defun brite::toggle-highlight-on-write () "Toggle buffer-local highlighting on write." (interactive) (setq brite::highlight-on-write (not brite::highlight-on-write)) (message "Setting highlight on write to %s." brite::highlight-on-write)) (defun brite::balloon-comment-threshold () "Balloon the maximum file size for comment highlighting." (interactive) (setq brite::comment-threshold (+ (buffer-size) 1000)) (message "Ballooning comment highlighting max size to %d." brite::comment-threshold) (brite::do-highlight-explicit)) (defun brite::balloon-touchup-threshold () "Balloon the maximum file size for touchup highlighting." (interactive) (setq brite::touchup-threshold (+ (buffer-size) 1000)) (message "Ballooning touchup highlighting max size to %d." brite::touchup-threshold) (brite::do-highlight-explicit) (if brite::diagnostics-on (message "%d zones in buffer." (length (epoch::zone-list))))) (defun brite::toggle-instant-highlight-on () "Toggle value of brite::instant-highlight-on." (interactive) (if (boundp 'after-change-function) (progn (setq brite::instant-highlight-on (not brite::instant-highlight-on)) (if brite::instant-highlight-on (progn (make-variable-buffer-local 'after-change-function) (setq after-change-function 'brite::highlight-on-change) (message "Instant highlighting is active.")) (progn (setq after-change-function nil) (message "Instant highlighting in inactive.")))))) ;;; -------------------------------------------------------------------------- ;;; ----------------------------- HOOKS AND KEYS ----------------------------- ;;; -------------------------------------------------------------------------- ;; Author: Daniel LaLiberte (liberte@cs.uiuc.edu). (defun brite::postpend-unique-hook (hook-var hook-function) "Postpend HOOK-VAR with HOOK-FUNCTION, if it is not already an element. hook-var's value may be a single function or a list of functions." (if (boundp hook-var) (let ((value (symbol-value hook-var))) (if (and (listp value) (not (eq (car value) 'lambda))) (and (not (memq hook-function value)) (set hook-var (append value (list hook-function )))) (and (not (eq hook-function value)) (set hook-var (append value (list hook-function)))))) (set hook-var (list hook-function)))) ;; Do the hooks. (brite::postpend-unique-hook 'find-file-hooks 'brite::do-highlight-on-find) (brite::postpend-unique-hook 'write-file-hooks 'brite::do-highlight-on-write) (brite::postpend-unique-hook 'rmail-show-message-hook 'brite::rmail-show-message) (brite::postpend-unique-hook 'mail-setup-hook 'brite::do-highlight-explicit) ;; C-z SPC does whole-buffer highlighting. (global-set-key "\C-z " 'brite::do-highlight-explicit) ;; C-c f (C-z f is taken) highlights the current function. ;; C-c p (C-z p is taken) highlights the current paragraph. (global-set-key "\C-cf" 'brite::do-highlight-function) (global-set-key "\C-cp" 'brite::do-highlight-paragraph) ;; C-z c and C-z t toggle comment/touchup highlighting ;; for this buffer. (global-set-key "\C-zc" 'brite::toggle-comment-highlight-on) (global-set-key "\C-zt" 'brite::toggle-touchup-highlight-on) ;; C-z C and C-z T balloon the comment/touchup threshold for ;; all buffers. (global-set-key "\C-zC" 'brite::balloon-comment-threshold) (global-set-key "\C-zT" 'brite::balloon-touchup-threshold) ;; C-z q/z/w toggle misc parameters. (global-set-key "\C-zq" 'brite::toggle-touchup-check-string) (global-set-key "\C-zz" 'brite::toggle-touchup-check-zone) (global-set-key "\C-zw" 'brite::toggle-highlight-on-write) ;; C-z a toggles instant highlighting. (global-set-key "\C-za" 'brite::toggle-instant-highlight-on) ======================================================================= 29 === Date: 9 Jul 92 10:10:17 From: thewalt@canuck.ce.berkeley.edu (C. Thewalt) Subject: Re: Proposed langauge changes While I understand the reserve expressed in making dramatic changes, I don't understand why the same reserve is applied to relatively trivial extensions like complex number support and an exponentiation operator. The latter may require considerable discussion to nail down the semantics, but in terms of language extension both of these seem pretty minor. Chris -- Christopher Robin Thewalt (thewalt@ce.berkeley.edu) Dept. of Civil Engineering These opinions are not necessarily University of California, Berkeley shared by my employer... ======================================================================= 30 === Date: 9 Jul 92 12:56:24 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: defaults for VAR parameters Why can't VAR parameters have defaults ? I think the primary answer is: because it would not be very useful, and might be dangerous. A default for a VAR would have to be a *variable* (lvalue to those familiar with C terminology), since it must be assignable. One cannot simply pass the address of a constant, but would have to do something like have the caller's code sequence allocate an additional anonymous variable and pass its address. I suppose one could give a value in a default clause, which would be the initial value of such a variable. That's how such a thing might be postulated to work. Now I cannot come up with any specific quantitative evidence, but I don't believe I would use this feature very often. More importantly, VAR parameters are there so that a procedure can have an effect on them, and defaults for them may remove all or most of a procedure's effect, so why call it under such circumstances? This is why I think it is probably not widely useful, and also potentially dangerous in the sense that it may lead to user surprise or unintended behavior (or lack of behavior). WHile I cannot speak for the language designers, I suspect the bottom line was that the utility did not outweigh the costs of defining and implementing such a feature. Of course, it could be that it never occurred to them (it would not have occurred to me). Regards --- Eliot -- 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 ======================================================================= 31 === Date: Thu, 9 Jul 92 14:31:06 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: question on generics In article AA20531@riposte, wyant@centerline.com () writes: >I may not be thinking about this in the right way... > >I have a generic interface, say "List", and >a non-generic interface say "Foo". Foo exports >an object type, say "Bar". Bar has an operation >which wants to return a "List of Bar", using the >generic "List" interface. > [ ... ] >As I said, I may just be thinking of this in the >wrong way. IMHO, you are. What you are trying to design here is what we call an entry-collection-subsystem: your objects represent some form of entry, whereas the list is a collection of these entries. I've been taught that the only right way to implement this is to make an abstract data type for the object and another abstract data/object type for the list. The main reason for designing this way is that the implementation of the entry type and the implementation of the collection type should be hidden from each other. This does not only conform to the basic rule that different implementation decisions should be encapsulated in different modules, but it also improves reusability: the entry type can be reused without changes in another collection and vice versa. I admit that my argumentation here is somewhat weakened by the fact that your collection type is generic. But nevertheless I consider it a very important rule not to mix operations on the entry type and on the collection type in the same interface. --- 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 ======================================================================= 32 === Date: Thu, 9 Jul 92 15:47:16 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Proposed langauge changes In article l5k6bnINN1ge@exodus.Eng.Sun.COM, chased@rbbb.Eng.Sun.COM (David Chas e) writes: >In article <9207071510.AA20139@riposte> wyant@centerline.com writes: >>The older I get, the more conservative toward language changes I >>get. Maybe that's just a consequence of seeing how C++ is evolving. >>To many of the proposals are of the form, "Language X has this >>nifty feature, can we force it into C++...?" > >I think this is correct -- that is, language change is not necessarily >a bad thing, but it has been a bad thing for C++. For instance, if >someone could figure out what multiple inheritance was supposed to >mean, and what the useful idioms are, and how to make it interact >cleanly with the rest of the language, then it might be good to add it >to Modula-3. I hear good things about mix-ins from NeWS and CLOS >programmers. However, if we don't understand it, or cannot caputer >the useful idioms, or if it as some vile interaction with any existing >good thing, then perhaps we can live without it. > >David Chase >Sun I don't know if you've read my earlier posting on the language changes discussion, but somehow you are going about exactly the direction at which I flamed a bit. I agree with both of you up to the point that the C++ way of handling changes is just as bad as the rest of the language. Of course, every development step has to be considered carefully. Especially in a language which claims to be ``compact'', interactions between new ideas and existing features should be investigated thoroughly. Now, learning from the C++ mess should not result in taking the opposite direction. My impression of the M3 developers (this includes everyone who feels pointed at, not just the guys at SRC) is, that this thorough investigation just isn't happening. Everyone is just saying something like "Hey, what's the problem? We've got a nice little language here, which could be better, but we don't know in what way, so ..." Since you mentioned the MI thing again: I still don't see any problem with it. If you remember my first article, I didn't say: "Gee, MI is such a fantastic thing, we simply *must* have it", I just wanted to encourage a discussion about the pros and cons of it. But, if anything, the discussion almost convinced me that it actually *is* useful. The pro side provided some IMHO good examples, where MI is a natural way of solving a problem. The con side came up only with "MI is hard to understand" (I still don't believe that, examples?) and "We have MI in C++, but we don't use it" (this also prooves nothing). Even more, if I haven't missed anything in John DeTreville's Users Group Meeting Report, some Users found MI worth discussing, but nothing came from it. Now this isn't exactly what I would call ``thorough investigation''. My personal conclusion from this is that there should be *more* discussion about proposed new language features than in C++. At the moment, it is far less. Don't forget that some people consider some things essential which you might think of as unnecessary or even bad. If you don't give these people at least some reasons *why* it's not in M3, they'll never use it. --- 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 ======================================================================= 33 === Date: Thu, 9 Jul 1992 12:19:31 PDT From: jacobi.PARC@xerox.com Subject: Re: defaults for VAR parameters I agree with Eliot that I consider defaults for VAR parameters would not fit into Modula 3; I do not propose to introduce it. However, in languages where such functionality is available I use it a lot and I don't see why it has to be dangerous. In Mesa, VAR parameters are approximated with taking the adresses and passing it to a pointer parameter; I very frequently use a default of NIL for such pointer parameters. In Modula 3, the EVAL statement implements approximately the concept in question, only slightly less general. Christian ======================================================================= 34 === Date: Thu, 9 Jul 92 20:56:33 PDT From: surak!frode (Frode Odegard) Subject: Re: defaults for VAR parameters I was writing a procedure that would mostly store its result in 'x' but sometimes in a different variable. After getting tired of writing P(x) most of the time I thought that being able to say PROCEDURE P (VAR w: INTEGER : = x) would be "nice". Obviously 'x' would have to be visible in the scope where P is declared. Obviously 'x' would have to be a variable, or rather, an lvalue. Correct me if I'm wrong, but there is nothing inherently dangerous in evaluatin g the lvalue 'x', it should be no more dangerous than evaluating some another lvalue explictly passed to P. As for the argument that a default may lead to surprises, well, that can be said for value parameter defaults, too.. Defaults should be used with care, that's for sure. But I agree with Eliot and Christian that this is not a MUST-HAVE feature, it's just something that struck me. The obvious solution is to write an <*inline*> procedure Pdefault that calls P( x) and let the compiler (or Mick :->) take care of it. It was just a thought, really. :-} - Frode <*reply-to: frode@odegard.com *> ======================================================================= 35 === Date: 10 Jul 92 00:25:59 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: defaults for VAR parameters >>>>> On 9 Jul 92 19:19:31 GMT, jacobi.PARC@xerox.com said: jacobi.PARC> In Mesa, VAR parameters are approximated with taking the jacobi.PARC> adresses and passing it to a pointer parameter; I very frequently jacobi.PARC> use a default of NIL for such pointer parameters. In Modula 3, jacobi.PARC> the EVAL statement implements approximately the concept in jacobi.PARC> question, only slightly less general. With VAR paramters there is no equivalent passing NIL and no way to test for it either. I think this makes the approaches substantially different. In Modula-3, one would have to pass the address of *something* ..... Eliot -- 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 ======================================================================= 36 === Date: Fri, 10 Jul 1992 03:33:13 GMT From: alanf@cs.monash.edu.au (Alan Grant Finlay) Subject: documentation of libraries I have some tutorials for the standard libraries and trestle but many additional libraries have no documentation. I can look in the include directory but there are hundreds of interfaces, listed in alphabetical order. If these interfaces are the documentation then I need at least a list of which interfaces belong to which library and preferably a dependancy tree. I could write a program to read the include directory and contruct a forest of dependencies, has anybody else done this. Am I missing something? Alan ======================================================================= 37 === Date: Fri, 10 Jul 1992 00:33:36 GMT From: Ari.Huttunen@hut.fi (Ari Juhani Huttunen) Subject: Re: Proposed language changes In article <1992Jul9.154716.7869@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.inf ormatik.rwth-aachen.de (Peter Klein) writes: ! a problem. The con side came up only with "MI is hard to understand" (I ! still don't believe that, examples?) It doesn't have to be. I find the Sather way of doing MI very easy to understand. Quoting the Sather report: "A class 'A' inherits the features of another class 'B' when the name 'B' appears in A's feature list. We say that B is a parent class and that A is a child. The semantics is exactly as if the features of B were textually copied into A at the point the name appears. Any references that appear in the inherited feature definitions will be resolved in the new namespace. Later features in a class with the same name as earlier ones override the earlier definitions. This means that the order in which classes are inherited can have an effect on the meaning. A class may inherit from many other classes. This is called MULTIPLE INHERITANCE." Depending on the language, it can be made to look more difficult. But the concept is on that paragraph. -- ............................................................................... Ari Huttunen They say the sky high above 90-7285944 is Caribbean blue... (Enya) ======================================================================= 38 === Date: Fri, 10 Jul 92 15:48:42 EDT From: wyant@centerline.com Subject: RE: Proposed language changes I don't want to debate the question of whether MI is good or bad. The more pertinent question to my mind is: can multiple inheritance be added cleanly and simply to a type system that was designed for single inheritance ? The evidence suggests not: MI was added to SmallTalk in the mid-80's. It never really caught on because it didn't fit naturally into the SmallTalk model. It was added to C++ about 5 years after the C++ type system was initially designed; again I believe this proved to warp the language considerably. In general, I have doubts about adding significant new features to a language after its initial design. It can be done, but it needs to be done with the same care as the original definition process. Most useful and long-lived languages go 5-10 years between major language changes; witness Fortran, ADA, and C. C was in use for a good ten years before the first ANSI standardization efforts, and the changes made by ANSI were relatively straightforward. It has changed very little since the standardization. The C++ language on the other hand is changed in major ways every 2 years. My other sense is that the innovation should not come in the language, but in the accompanying libraries and tools. I would like to see people expending their energies on well-designed and innovative libraries; such things as an interesting data model and database integrated into the M3 environment, libraries for constraint-based programming, rule based systems, computational geometry, algorithm visualization, transaction based systems, ... Well, I've said more than enough, so I'll shut up now. --geoff ======================================================================= 39 === Date: Fri, 10 Jul 92 19:02:35 GMT From: muller@src.dec.com (Eric Muller) Subject: Re: documentation of libraries In article , alanf@cs.monash.edu.au (Al an Grant Finlay) writes: |> I have some tutorials for the standard libraries and trestle but many |> additional libraries have no documentation. I can look in the include |> directory but there are hundreds of interfaces, listed in alphabetical |> order. If these interfaces are the documentation then I need at least a |> list of which interfaces belong to which library and preferably a dependancy |> tree. |> |> I could write a program to read the include directory and contruct a forest |> of dependencies, has anybody else done this. Am I missing something? It is true that today you have no way of finding which libraries you need to link with. We have some prototype programs to do that, I guess we should push forward to make them available (they work by looking at the .ix, .mx and .ax files). It is also true that there is no coherent documentation of the interfaces that are available. We realize that this a real problem, but we haven't found any good solution yet. The most promising solutions rely on stylized comments at the beginning of each interface, for example: (* Keywords: foo, bar, foobar; Classification: user interfaces, text widgets; This is a one line description. This is more complete description of what this interface is about. *) The Keywords field would be used to build an index. The Classification field would be used to include the description at a right place in a document of all the interfaces. The one-line would help for quick selection. But then, we don't really know which tools to use to manipulate that information. We probably need more than on tool: one to get an overview of what is available, one to find which interface to use for a particular job. Producing a formatted output (say using TeX) is almost guaranteed to be obsolete as soon as it is ready, and it is difficult to use on-line. Also, not everybody has TeX. I am tempted to try to use info under gnuemacs. The nice thing is that I could easily get the documentation while I am working on a program. Note that we already have a tags mechanism for Modula-3. Of course, it may be that this kind of problem has already been solved, and that we could reuse the solution. If you know of one, please let us know. Also, if you have a working documentation system, we are ready to modify the interfaces so that they include the needed information in the right format. -- Eric. ======================================================================= 40 === Date: 11 Jul 92 15:04:51 GMT From: ark@alice.att.com (Andrew Koenig) Subject: Re: Proposed language changes In article <9207101948.AA26823@riposte> wyant@centerline.com writes: > It [multiple inheritance] was added to C++ about > 5 years after the C++ type system was initially > designed; again I believe this proved to warp the > language considerably. Oh? Can you give us some concrete examples of that warpage? For instance, can you show a case where the existence of multiple inheritance in C++ inconveniences programmers that don't use it? -- --Andrew Koenig ark@europa.att.com ======================================================================= 41 === Date: Sat, 11 Jul 92 19:50:10 -0400 From: Norman Ramsey Subject: installing src m3 Installing m3 is getting to be a big chore, because there are so many packages. I'm delighted to have access to so much interesting software, but there has to be a better way to build it. Here are some suggestions. - put the boot files and the rest of the stuff in separate directores, so that I can use ftp to mget *.tar.Z without getting boot files that I don't need. also place in a separate directory compiler, driver, doc, and the other packages that are included in the boot files So I am proposing three subdirectories of release: boot: holds boot files for the various architectures basics: holds only those packages include in boot others: holds libm3 and all the other packages now when I want a new compiler, I can get one file from the boot directory, everything from the others directory, and I don't have any duplicates. I assume there is a scenario where it's advantageous to get compiler, driver, etc. from the others directory, instead of using the boot files, but I don't understand what that scenario might be. - Once I have ftp'ed a collection of stuff, I want to be able to build it all with a single command. The problem is, I have to build things in a certain order (e.g. X11R4 before trestle). So could SRC provide some sort of makefile or shell script to use to build whatever's present, in an order that works? Given the dependencies between packages, it is easy to generate a script like this one: build boot build libm3 if [ -r m3makefile.X11R4 ]; then build X11R4; fi if [ -r m3makefile.X11R4 -a -r m3makefile.trestle ]; then build trestle fi ... where `build x' == m3make -f m3makefile.x all install Norman Ramsey ======================================================================= 42 === Date: Sun, 12 Jul 92 00:07:51 GMT From: muller@src.dec.com (Eric Muller) Subject: Re: installing src m3 In article <9207112350.AA21799@cs.Princeton.EDU>, Norman Ramsey writes: |> Installing m3 is getting to be a big chore, because there are so many |> packages. I'm delighted to have access to so much interesting |> software, but there has to be a better way to build it. Here are some |> suggestions. [...] |> |> So I am proposing three subdirectories of release: |> |> boot: holds boot files for the various architectures |> basics: holds only those packages include in boot |> others: holds libm3 and all the other packages Sounds fine with me. If there are no objections, we'll do that for the next release. |> - Once I have ftp'ed a collection of stuff, I want to be able |> to build it all with a single command. I'll put a script that does that in the next release. -- Eric. ======================================================================= 43 === Date: Sat, 11 Jul 92 17:54:20 -0400 From: Norman Ramsey From: nr@cs.Princeton.EDU (Norman Ramsey) Newsgroups: comp.lang.modula3 Subject: elapsed time spent in threads Summary: Followup-To: Distribution: world Organization: Princeton University, Dept. of Computer Science Keywords: I want to learn how much elapsed time is spent in a particular thread, in the style of ETimer.T. Is there some way for the scheduler and ETimer to get in cahoots, or is there some other good way to find out how much elapsed time is spent in a thread? ======================================================================= 44 === Date: 12 Jul 92 20:13:32 GMT From: mbk@lyapunov.ucsd.edu (Matt Kennel) Subject: Re: Proposed language changes ark@alice.att.com (Andrew Koenig) writes: : In article <9207101948.AA26823@riposte> wyant@centerline.com writes: : : > It [multiple inheritance] was added to C++ about : > 5 years after the C++ type system was initially : > designed; again I believe this proved to warp the : > language considerably. : : Oh? Can you give us some concrete examples of that warpage? : : For instance, can you show a case where the existence of : multiple inheritance in C++ inconveniences programmers that : don't use it? I don't think that's exactly the problem. It's that those people who *want* to use multiple inheritance have to deal with its problems and evolutionary vestiges. A difficult-to-use-MI also affects the way that libraries are designed and implemented, and a programmer not directly using MI often uses libraries. Unfortunately despite OOP becoming so popular, there's still an emphasis on the language rather than really good libraries. -------------------------------------- Personally, I don't like C++ at all--I think it's much too complicated and difficult for what it does. The syntax is too hard for humans to parse. One of the languages I like best is Sather. It was amazing to nearly completely understand it in 45 minutes. It's very simple. Perhaps a bit too spare, but otherwise I like it alot. It has multiple inheritance and parameterized types and for the first time I really understood what these did. It seems thought that classes can only take types as arguments, and not values. I.e. with a generic list class you can make a list of foobars class, but not a list of foobars of size 11. One nice thing is that it generates code made *specific* for the paramterized class, and not only the general case with tons of indirect function calls. I might actually start using it for my work were it not for the fact that there isn't even a "do loop" construct, i.e. only a general loop and you have to 'manually' increment a counter. It's simply a minor syntactical convenience, but such a common case (especially in numerical programming). (Of course, I'd really like index notation for arrays, but that's another long story...) : -- : --Andrew Koenig : ark@europa.att.com -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego ======================================================================= 45 === Date: Sun, 12 Jul 1992 23:47:16 GMT From: dmb@srl02.cacs.usl.edu (David M. Brumley) Subject: Does NEW() accept positional bindings for OBJECTS? Page 46 of _SPwM3_ shows a generic stack module: GENERIC MODULE Stack (Elem); REVEAL T = BRANDED OBJECT n: INTEGER; a: REF ARRAY OF Elem.T END; PROCEDURE Create(): T = BEGIN RETURN NEW(T, 0, NIL) END Create; ... Can a new T be initialized this way? ======================================================================= 46 === Date: Mon, 13 Jul 1992 09:01:45 GMT From: harald@cs.ruu.nl (Harald Vogt) Subject: Thread Aqcuire and Release problem Hello, we installed the newest m3 from gatekeeper on our HP900/400 machines and have problems with the Thread module, especially with the implementation of the binary semaphore (Mutex, NewMutex, Acquire, Release). It used to run on an earlier version of m3. We would like to use m3 for a course on Parallel Programming. Below follows a test program which demonstrates our problems in detail. Is there anoybody out there with an m3 implementation on which the program below runs? If yes, which version of m3 and which C-compiler do you use? Or, is my test program not OK? Any help is appreciated, -- Harald* Vogt, Department of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. E-mail: harald@cs.ruu.nl, Phone:+31-30-532249, Fax:+31-30-513791 MODULE Main; (* This little program demonstrates that the Acquire and Release calls do not function properly. Two processes are started: a producer and consumer. The consumer waits on the producer. Output when run: CONSUMER Quit (core dumped). However, the processes do run concurrently when no Release and Acquire is used. HARDWARE-CONFIG: HP9000/425 HP-UX 8.0 SYSV M68000 SOFTW-CONFIG: Newest m3 version 2.07 from gatekeeper and gcc is used Harald Vogt *) IMPORT Wr, TextWr, Word; FROM Stdio IMPORT stdout; FROM Thread IMPORT IncDefaultStackSize,Fork, T, Join, Closure, Mutex, NewMutex, Acquire, Release; TYPE Procobj = Closure BRANDED "p007 T" OBJECT local : PROCEDURE(); END; VAR p1, p2 : T; sp, sc : Mutex; PROCEDURE work (self: Procobj): REFANY RAISES {}= BEGIN self.local(); RETURN NIL; END work; PROCEDURE StartProcess (proc: PROCEDURE()): T= VAR process : Procobj; handle : T; BEGIN process := NEW( Procobj, local := proc, apply := work ); handle := Fork( process ); RETURN handle; END StartProcess; PROCEDURE WaitFor (VAR handle: T)= BEGIN EVAL Join(handle); END WaitFor; PROCEDURE PRODUCER()= BEGIN FOR i := 1 TO 10 DO Acquire(sc); Wr.PutText(stdout, "PRODUCER\n"); Release(sp); END END PRODUCER; PROCEDURE CONSUMER()= BEGIN FOR i := 1 TO 10 DO Acquire(sp); Wr.PutText(stdout, "CONSUMER\n"); Release(sc); END END CONSUMER; BEGIN IncDefaultStackSize(10000); (* To be sure *) sp := NewMutex(); Acquire(sp); sc := NewMutex(); p1 := StartProcess (PRODUCER); p2 := StartProcess (CONSUMER); WaitFor( p1 ); WaitFor( p2 ); END Main. -- Harald* Vogt, Department of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. E-mail: harald@cs.ruu.nl, Phone:+31-30-532249, Fax:+31-30-513791 ======================================================================= 47 === Date: 13 Jul 92 06:12:05 GMT From: johng@otc.otca.oz.au (John Gibbons) Subject: how do I get the modula3 revised report? Is the modula-3 revised report available over the net? ======================================================================= 48 === Date: 13 Jul 92 16:22:51 GMT From: os102@cl.cam.ac.uk (Oliver Stephens) Subject: Re: installing src m3 In article <9207112350.AA21799@cs.Princeton.EDU>, Norman Ramsey writes: |> |> I assume there is a scenario where it's advantageous to get |> compiler, driver, etc. from the others directory, instead of using |> the boot files, but I don't understand what that scenario might |> be. |> I have a scenario where these are useful (although it does not strictly fit this category as the bootstrapped version was also required). After building the bootstrapped compiler for SPARC, I built libm3 then made a shared library version of it. I then rebuilt the compiler and driver from the M3 source to produce versions which used the shared library. Resulting saving in space is : m3 - from 2.8 to 0.5 Mbytes m3compiler - from 5.3 to 3.1 Mbytes ------------------------------------------------------------------------- Olly Stephens oliver.stephens@cl.cam.ac.uk Computer Laboratory University of Cambridge Loved you there and then, and now like a sheep United Kingdom - Van Morrison ======================================================================= 49 === Date: 13 Jul 92 10:17:39 From: thewalt@canuck.ce.berkeley.edu (C. Thewalt) Subject: Re: Proposed langauge changes Regarding my request for complex number support and an exponentiation operator. In article <1992Jul13.150924.1971@exu.ericsson.se> exuhag@exu.ericsson.se (Jame s Hague) writes: Big, bloated languages are made up of lots of little things... What bloat does complex number support cost when you already have all the operators you need for integer and floating point support? While I might back off the exponentiation operator request, since you can get by without it with minor pain (although I think it is silly not to include it), the cost of supporting complex numbers on the user code side is way too great considering the minor impact it would have on langauge syntax. Chris -- Christopher Robin Thewalt (thewalt@ce.berkeley.edu) Dept. of Civil Engineering These opinions are not necessarily University of California, Berkeley shared by my employer... ======================================================================= 50 === Date: Mon, 13 Jul 92 11:09:38 EDT From: wyant@centerline.com Subject: re: question on generics About a week ago, I posted >I may not be thinking about this in the right way... > >I have a generic interface, say "List", and >a non-generic interface say "Foo". Foo exports >an object type, say "Bar". Bar has an operation >which wants to return a "List of Bar", using the >generic "List" interface. > [ ... ] >As I said, I may just be thinking of this in the >wrong way. Well, I was thinking about it in the wrong way. I was revealing too much information in the interface; namely that a "Bar" contains a "List of Bar". By making Bar opaque and requiring clients to call an iterator, I broke the apparent circularity. Clients only ever deal with the opaque type 'Bar.T" while the implementation is revealed to have a "List of Bar.T" which is trivial to instantiate from the generic "List" interface at this point. Thanks to all those that help break my mental "circularity". --geoff Geoff Wyant wyant@centerline.com Centerline Software, Inc. (Formerly Saber Software, Inc) 10 Fawcett Street Cambridge, Ma. 01238 ======================================================================= 51 === Date: Mon, 13 Jul 92 16:32:50 +0200 From: a.vermeulen@ECN.NL (Vermeulen A.T.) Subject: Manuals on vbtkit, formsvbt and miniformsedit etc... The new release (2.07) of SRC Modula-3 seems to deliver a really workable syste m to the users. I was impressed by the demos (fisheye, cube , calculator) which show how good libraries and good (language) design can alleviate the life of application prog rammers. Documentation is still a weak point however and commenting in the sources and i nterface units is very sparse until now. This surely does stimulate experimenting but it would be nice if the labour cou ld be directed towards further enhancement and just using the libraries instead of tr ying to figure out how this and that works. Are there any plans to bring out some documentation on vbtkit and vbtforms? Th e IMHO very useful interface contruction kit miniformsedit should get the attenti on of all M3-programmers! -- Netherlands Energy Research Foundation Email: a.vermeulen@ecn.nl P.O. Box 1 Phone: (+31) 2246 4194 1755 ZG Petten, The Netherlands ======================================================================= 52 === Date: 13 Jul 92 15:09:24 GMT From: exuhag@exu.ericsson.se (James Hague) Subject: Re: Proposed langauge changes C. Thewalt writes: > >While I understand the reserve expressed in making dramatic changes, I >don't understand why the same reserve is applied to relatively trivial >extensions like complex number support and an exponentiation operator. >The latter may require considerable discussion to nail down the >semantics, but in terms of language extension both of these seem pretty >minor. Big, bloated languages are made up of lots of little things... -- James Hague exuhag@exu.ericsson.se ======================================================================= 53 === Date: 13 Jul 92 14:50:50 GMT From: andy@brian.informatik.rwth-aachen.de (Andreas Schuerr) Subject: Re: Proposed language changes Well, I agree with you that a language with a large number of STANDARD libraries is a better development tool than a programming language without libraries or a language the compilers of which each have a different set of libraries (as e.g. in Modula-2). But you will have difficulties to find language users or library developers for a brand-new language which doesn't contain at least all really important concepts of its direct competitors Eiffel, C++, etc. For instance, our group is busy with the development of integrated software development environments, and we have implemented many (generic) tools using the language Modula-2 (producing some hundred thousands lines of code). There is e.g. a graph-oriented nonstandard DBMS which is currently extended by a front-end for a data modelling and database programming language. This DBPL offers the concept of MI and we are continously using MI on the conceptual level as well as on the implementation level. Up to now we have to implement inheritance and dynamic binding in Modula-2 using many tricks (type-casts, procedure arrays, ...). You may guess from the above written lines that we are looking for another implementation language * which has a Modula-2-like "look&feel" * which doesn't permit a C-like style of programming * and which supports MI. Therefore, we would like to use Modula-3, but we will never use a language forcing us to simulate MI further- on. To summarize: its true that nobody will try to use a new language without usefull standard libraries, but it's also true that nobody will spend many efforts to supply libraries for a new language which has up-to-now neither a large user community nor contains new important concepts like MI. Dr. Andy Schuerr, Lehrstuhl fuer Informatik III RWTH Aachen D-5100 Aachen (Germany) ======================================================================= 54 === Date: 13 Jul 92 18:22:05 GMT From: schilit@Xerox.com (Bill Schilit) Subject: BUG in PQueueADT.ig Problem: building a program with PQueueADT.ig causes: *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0xf7ffeee8 *** Cure: In PQueueADT.ig change: T = OBJECT METHODS new (): T; (* create (self = NIL) or initialize (self # NIL) a PQueue.T *) To: T = OBJECT METHODS new (): T := new; (* create (self = NIL) or initialize (self # NIL) a PQueue.T *) - Bill ======================================================================= 55 === Date: Mon, 13 Jul 92 12:00:31 -0700 From: Subject: Re: Manuals on vbtkit, formsvbt and miniformsedit etc... Manuals for VBTkit and FormsVBT are being polished as I typed. (Well, acutally they are in other windows on my screen and on Jim Meehan's screen....) The code for VBTkit and FormsVBT was put on the "test" distribution a few weeks ago for a couple of alpha testers who really needed the functionality. It was moved to the "release" distribution unintentionally, since the documentation wasn't there yet. The VBTkit reference manual will be like Chapters 4, 5 and 6 of the Trestle reference manual: TeXified .i3 files with some additional prose giving the ``big picture''. The FormsVBT Reference Manual is intended for less sophisticated clients, so it will be less terse. Stay tuned. ======================================================================= 56 === Date: 13 Jul 1992 21:54:06 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: Proposed langauge changes / MI In article <1992Jul9.154716.7869@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.inf ormatik.rwth-aachen.de writes: >Since you mentioned the MI thing again: I still don't see any problem with >it. There's a couple of problems -- sorry if I didn't go into details. (1) Define the semantics of TYPECASE (which case is chosen?) (2) Can we add MI without slowing down SI? (This is a trick question, because you need to worry about both current (sleazy compilers) and future (good compilers) performance.) (3) MI has some weird interactions with opaque supertypes. Suppose you get something like (pardon my mangling of the syntax): TYPE X <: OBJECT; TYPE Y <: OBJECT; A = X OBJECT METHODS ... END; B = Y OBJECT METHODS ... END; C = A,B OBJECT METHODS ... END; Now, what if it turns out that X and Y actually share a common ancestor? Are the data fields and methods shared, or no? (sharing is not consistent with encapsulation -- my conclusion is that sharing should not occur in this case. However, for mix-ins it appears that sharing is what you want. One resolution is to only allow sharing to occur when it is not hidden. However, I don't know if this can be done in a consistent and reliable fashion; what happens if there are multiple views of the objects involved?) (4) How does narrow work in the presence of repeated inheritance? (a) what is the right answer? (b) can we implement this efficiently? That is, suppose you have: TYPE X <: OBJECT; A = X OBJECT METHODS ... END; B = A,X OBJECT METHODS ... END; C = A,B OBJECT METHODS ... END; Suppose I narrow an "X" to an "A", given that what I've really got is a C. Which one? How efficient is "NARROW" now? (5) Discover and document any remaining semantic/implementation gotchas. My concern about efficiency may seem misplaced, but if what you're after is flexibility with no major concern for performance, you can get that already from CLOS. (And yes, I am *very* interested in Dylan, which I am told is something like Scheme+CLOS.) Comparisons with bullet-items on the C++ Real-Soon-Now list are also unfair. It could be that they are unimplementable, or come with horrible interactions, or maybe there is more sizzle than steak (e.g., maybe the feature is "provided" but in a useless fashion). David Chase Sun ======================================================================= 57 === Date: Tue, 14 Jul 92 02:59:53 GMT From: news@massey.ac.nz (USENET News System) Subject: Re: Proposed langauge changes In article <1992Jul13.150924.1971@exu.ericsson.se>, exuhag@exu.ericsson.se (Jam es Hague) writes: > > C. Thewalt writes: > > > >While I understand the reserve expressed in making dramatic changes, I > >don't understand why the same reserve is applied to relatively trivial > >extensions like complex number support and an exponentiation operator. > >The latter may require considerable discussion to nail down the > >semantics, but in terms of language extension both of these seem pretty > >minor. > > Big, bloated languages are made up of lots of little things... > -- I agree. We should get rid of a few more inessential little things. Let's see... If we eliminated the division and subtraction operators, ah, what about multiplication? I'm getting quite enthusiastic about this, perhaps we only need the Boolean data type and a couple of logical operations. We can implement everything else in terms of these. It may be a bit of trouble, but, after all, as it's in the interest of a more parsimonious language, I'm sure to get a lot of support. ======================================================================= 58 === Date: Tue, 14 Jul 92 11:20:20 GMT From: mw@frodo.ki.fht-mannheim.de (Marc Wachowitz) Subject: Re: Sather (was: Re: Proposed language changes mbk@lyapunov.ucsd.edu (Matt Kennel) writes: : Despite what all the proponents of OOP say, either explicitly or by : their textbook examples, I do *not* think that a class structure is the : best solution for this problem (i.e. matrix and vector and tensor classes : and overload the + and the - and the blah blah blah). There's another soluti on : that's cleaner and more general, at least in the (important!) domain of : array operations. IMO the problem isn't that classes are wrong (though I prefer CLOS-like decoupling of classes and generic functions, with the ability to specialize on the types of all arguments), but the lack support for building new control structure abstractions, like macros is Lisp. Probably it wouldn't be particularly difficult to write a macro that does what you want - and you could specify whatever special-case optimizations you knew of (which "level" of programmer does that is another question, but IMO it shoul d be available at every level). ------------------------------------------------------------------------------- Marc Wachowitz, mw@gandalf.ki.fht-mannheim.de, 75742@novell1.rz.fht-mannheim.de * wonder everyday * nothing in particular * all is special * ======================================================================= 59 === Date: 14 Jul 92 00:48:18 GMT From: Ari.Huttunen@hut.fi (Ari Juhani Huttunen) Subject: Sather (was: Re: Proposed language changes In article <13q3pdINNk5u@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes: ! One of the languages I like best is Sather. It was amazing ! to nearly completely understand it in 45 minutes. It's very simple. ! Perhaps a bit too spare, but otherwise I like it alot. ! I might actually start using it for my work were it not for the ! fact that there isn't even a "do loop" construct, i.e. only a general ! loop and you have to 'manually' increment a counter. It's simply a ! minor syntactical convenience, but such a common case (especially ! in numerical programming). (Of course, I'd really like index notation ! for arrays, but that's another long story...) Take a look at lib/base/do.sa. It implements some loop constructs. You are able to say things like: c: DO := DO::times(100); until c.is_done loop ..foobar.. end; No, I haven't tried to use it. (What do you mean by index notation?) -- ............................................................................... Ari Huttunen They say the sky high above 90-7285944 is Caribbean blue... (Enya) ======================================================================= 60 === Date: 14 Jul 1992 07:42:31 GMT From: mbk@lyapunov.ucsd.edu (Matt Kennel) Subject: Re: Sather (was: Re: Proposed language changes Ari.Huttunen@hut.fi (Ari Juhani Huttunen) writes: : In article <13q3pdINNk5u@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel ) writes: : : ! One of the languages I like best is Sather. It was amazing : ! to nearly completely understand it in 45 minutes. It's very simple. : ! Perhaps a bit too spare, but otherwise I like it alot. I should remind people that I'm not a computer scientist, but a (probably future unemployed) physicist. : ! I might actually start using it for my work were it not for the : ! fact that there isn't even a "do loop" construct, i.e. only a general : ! loop and you have to 'manually' increment a counter. It's simply a : ! minor syntactical convenience, but such a common case (especially : ! in numerical programming). (Of course, I'd really like index notation : ! for arrays, but that's another long story...) : : Take a look at lib/base/do.sa. It implements some loop constructs. You : are able to say things like: : c: DO := DO::times(100); until c.is_done loop ..foobar.. end; I did. It still seems unnatural. Seems, hell. It is. Take a look at it, and be honest. I think "do loops" were deleted from Modula-2 in going to Oberon (an intentionally small language, like Sather), and reinstated after practical experience in Oberon-2. A simple, very common concept deserves a simple, idiomatic statement. : No, I haven't tried to use it. : : (What do you mean by index notation?) Implied iteration and summation over repeated indices. (a.k.a. Einstein summation convention). It's a common notation in math and science--computer or no. E.g. Vector A = Matrix B times vector C: A(i) = B(i,j)*C(j) or more explicitly "for all i" A(i) = "sum over j" B(i,j)*C(j). This concept subsumes nearly all of Fortran 90's matrix & vector operations. Explicitly parallel too. In comp.lang.misc there was a long debate on this a couple of months ago. Jim Giles also had the same position, and in fact I think his operation even designed specific extensions to Fortran to express this concept. (In fact if I were to design an optimizer for an F90 compiler, I might want to internally represent array operations in this generalized form so I could write only 1 code generator). Despite what all the proponents of OOP say, either explicitly or by their textbook examples, I do *not* think that a class structure is the best solution for this problem (i.e. matrix and vector and tensor classes and overload the + and the - and the blah blah blah). There's another solution that's cleaner and more general, at least in the (important!) domain of array operations. In case you're wondering: Yes, I do think that iteration and arithmetic on arrays deserves special case attention in the language. I think possible solutions can be elegant, clean, with a strong non-computer precedents, and not at all interfere with other aspects of the language. Nobody's done it really 'right' yet. (Sather with index operations might be very attractive though. It would have that 'killer' feature that nobody else has, and do all the normal stuff easier. With a good enough library and optimization it would be at least technically, a formidable competitor to Fortran.). : -- : ............................................................................. .. : Ari Huttunen They say the sky high above : 90-7285944 is Caribbean blue... (Enya) -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego ======================================================================= 61 === Date: Tue, 14 Jul 92 18:09:54 GMT From: detlefs@src.dec.com (Dave Detlefs) Subject: Re: Proposed language changes In his article of July 9, 1992, David Chase does an admirable thing: he lays some concrete objections to multiple inheritance, rather than heaping non-specific scorn on the concept. While not completely convinced that MI in M3 is a good idea, I tend to lean that way, and will attempt to play the devil's advocate and respond to his points. > (1) Define the semantics of TYPECASE (which case is chosen?) This seems pretty easy; the current rule says that the first case arm whose type is a supertype of the case expression is chosen, which seems to work just as well in the MI case. > (2) Can we add MI without slowing down SI? (This is a trick > question, because you need to worry about both current > (sleazy compilers) and future (good compilers) performance.) The C++ experience seems to answer yes to this question, though, as you implicitly point out below, this experience may not carry over to Modula-3. > (3) MI has some weird interactions with opaque supertypes. > Suppose you get something like (pardon my mangling of the > syntax): > > TYPE X <: OBJECT; > TYPE Y <: OBJECT; > > A = X OBJECT METHODS ... END; > B = Y OBJECT METHODS ... END; > > C = A,B OBJECT METHODS ... END; > > Now, what if it turns out that X and Y actually share > a common ancestor? Are the data fields and methods shared, or no? > (sharing is not consistent with encapsulation -- my conclusion is > that sharing should not occur in this case. However, for mix-ins > it appears that sharing is what you want. One resolution is to > only allow sharing to occur when it is not hidden. However, I > don't know if this can be done in a consistent and reliable > fashion; what happens if there are multiple views of the objects > involved?) Again, I'll argue from the viewpoint that C++ faces many of the same problems and gives a solution that at least addresses all the problems. As you point out, there are times when sharing is appropriate, and times when it is not. (I tend to think that sharing is almost always the right choice, but let's push that discussion.) C++ lets you specify both: a supertype may be virtual or not; all virtual instances of a type in a MI subtype lattice are collapsed into a single node. Another principle guiding the design of MI in C++ is that any ambiguity must be explicitly resolved by the programmer; in the example above, if A and B had defined fields with the same name, then a C method would have to narrow 'self' to an A or a B before selecting that field. So, one answer to the question is that we add some syntax allowing us to specify whether a supertype is the-M3-equivalent-of-virtual. Then, in the example you've given, in any scope in which it is revealed that X and Y are both subtypes of Z, those revelations will say whether Z is a virtual supertype or not. Let's say that Z has a field a. If Z is a virtual supertype in both cases, then there is only one copy of a Z in a C, and it is clear what c.a means if c is a C. If Z is not virtual in both cases, then c.a is ambiguous; to eliminate the ambiguity, the programmer would have to write NARROW(c, A).a or NARROW(c, Y).a. If there is a scope in which it is revealed that X is a subtype of Z, then there is still no problem, since c.a is unambiguous in all the cases: if Z is not a supertype of Y, then there is no conflict, if Z a virtual supertype of both X and Y, then there is no ambiguity, since c.a refers to the same field; if Z is a non-virtual supertype of both X and Y, in this scope c.a must refer NARROW(c, X).a, since we don't know of anything about Y and Z in this scope. > (4) How does narrow work in the presence of repeated inheritance? > (a) what is the right answer? > (b) can we implement this efficiently? > > That is, suppose you have: > > TYPE X <: OBJECT; > > A = X OBJECT METHODS ... END; > B = A,X OBJECT METHODS ... END; > > C = A,B OBJECT METHODS ... END; > > Suppose I narrow an "X" to an "A", given that what I've really got > is a C. Which one? How efficient is "NARROW" now? Again, the C++ answer is: if A and X are virtual supertypes in all cases, the right answer is clear, since there is just one subobject of each type in a C. If A and X are not virtual supertypes, and x is a variable whose static type is X containing a value whose allocation type is C, then we have the following type graph: X (1) | | (2) X A | | | | A B \ / \ / C How did we get a variable with static type X and allocation type C? We originally allocated a C and assigned to a variable of some supertype. If we assigned it to a B variable there is no ambiguity; we could then assign that result to an X variable and end up at (1). If we assigned the C value directly to an A variable or an X variable, however, there would be ambiguity, so the compiler would have to complain. So, the C++ answer says that there is no way to get from a C value to the X subobject labelled (2). (This ambiguity is one of the reasons I recommend the ubiquitous use of virtual base classes whenever I'm asked.) Given that we're at the X labelled (1), then NARROW's of the value to any of an A, B, or C is well-defined. Perhaps a the confusing example you want to bring out is if X is a virtual supertype, but A is not. This this case you get X / \ / \ + A | | | | A B \ / \ / C Now we can assign a C value directly to an X variable, but what if we NARROW it back to an A? How about: that's ambiguous, and therefore illegal. As an overall comment, note that there is a certain consistency in the C++ approach to MI: if we it isn't completely obvious what the compiler should do, the compiler rejects the program, and requires you to be a little more explicit. This tends to prevent at least some potential misuses of MI. So, this little missive makes a small start at addressing what MI would mean if we added it; it does nothing to argue that it would be a good thing if we did. I happen to believe that it would; but I'll leave that argument for another time. I look forward to further debate. Dave ======================================================================= 62 === Date: 14 Jul 92 15:09:29 GMT From: tlai@cs.toronto.edu (Tony Wen Hsun Lai) Subject: Re: Proposed langauge changes In article <1992Jul14.025953.24560@massey.ac.nz> news@massey.ac.nz (USENET News System) writes: >In article <1992Jul13.150924.1971@exu.ericsson.se>, exuhag@exu.ericsson.se (Ja mes Hague) writes: >> C. Thewalt writes: >> >While I understand the reserve expressed in making dramatic changes, I >> >don't understand why the same reserve is applied to relatively trivial >> >extensions like complex number support and an exponentiation operator. [stuff deleted] >> >> Big, bloated languages are made up of lots of little things... > >I agree. We should get rid of a few more inessential little things. > >Let's see... If we eliminated the division and subtraction operators, >ah, what about multiplication? > >I'm getting quite enthusiastic about this, perhaps we only need the Boolean >data type and a couple of logical operations. We can implement everything >else in terms of these. It may be a bit of trouble, but, after all, as it's >in the interest of a more parsimonious language, I'm sure to get a lot of >support. Theoretically, you need only two counters, increment, decrement, and compare with zero. Writing efficient programs is a bit harder though. :) Seriously, to quote from Systems_Programming_with_Modula-3, "C.A.R. Hoare has suggested that as a rule of thumb a language is too complicated if it can't be described precisely and readably in fifty pages. The Modula-3 committee elevated this to a design principle.... There are so many good ideas in programming language design that some kind of arbitrary budget seems necessary to keep a language from getting too complicated." Tony Lai -- Usenet. The triumph of noise over signal. ======================================================================= 63 === Date: 14 Jul 1992 17:47:04 GMT From: ceeunex@garnet.berkeley.edu (UC Extension Engineering) Subject: Short course announcement University Extension, University of California, Berkeley presents...a course on Object-Oriented Programming in C++ in two locations: August 31-September 3, 1992/UC Berkeley September 14-17, 1992/New Orleans, Louisiana Course introduces object-oriented methodology in C++, and presents specific techniques using C++ that illustrate essential concepts in object-oriented programming. It highlights key points of working code to demonstrate C++ capabilities. Participants are expected to know the basics of C++ programming; this is not a hands-on course. For a detailed course brochure, send request to: Carol Abrahamson, Continuing Education in Engineering, UC Berkeley Extension e-mail: ceeunex@garnet.berkeley.edu fax: (510) 643-8683 phone: (510) 642-4151 ======================================================================= 64 === Date: 13 Jul 92 14:23:43 GMT From: sakkinen@jyu.fi (Markku Sakkinen) Subject: Re: Proposed language changes In article <9207101948.AA26823@riposte> wyant@centerline.com writes: >I don't want to debate the question of whether >MI is good or bad. The more pertinent question > ... >My other sense is that the innovation should not come in the >language, but in the accompanying libraries and tools. I would >like to see people expending their energies on well-designed >and innovative libraries; such things as an interesting data >model and database integrated into the M3 environment, libraries >for constraint-based programming, rule based systems, computational >geometry, algorithm visualization, transaction based systems, ... > ... However, the existence of good (class) libraries for specialised purposes tends to increase the demand for MI, since in many cases one has to inherit some class from each library in order to exploit its facilities. (This has at least been the experience of many people who have used some generally available C++ class libraries.) ---------------------------------------------------------------------- Markku Sakkinen (sakkinen@jytko.jyu.fi) SAKKINEN@FINJYU.bitnet (alternative network address) Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland ---------------------------------------------------------------------- ======================================================================= 65 === Date: 13 Jul 92 14:18:34 GMT From: sakkinen@jyu.fi (Markku Sakkinen) Subject: Re: Proposed language changes In article Ari.Huttunen@hut.fi (Ari Juhani Huttunen) writes: >In article <1992Jul9.154716.7869@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.in formatik.rwth-aachen.de (Peter Klein) writes: > >! a problem. The con side came up only with "MI is hard to understand" (I >! still don't believe that, examples?) > >It doesn't have to be. I find the Sather way of doing MI very easy to >understand. Quoting the Sather report: > > "A class 'A' inherits the features of another class 'B' when the > name 'B' appears in A's feature list. We say that B is a parent class > and that A is a child. The semantics is exactly as if the features > of B were textually copied into A at the point the name appears. > Any references that appear in the inherited feature definitions will > be resolved in the new namespace. Later features in a class with > the same name as earlier ones override the earlier definitions. This > means that the order in which classes are inherited can have an > effect on the meaning. A class may inherit from many other classes. > This is called MULTIPLE INHERITANCE." > >Depending on the language, it can be made to look more difficult. But >the concept is on that paragraph. Independently of the language, it _is_ more difficult if it is to remain sensible even in complicated situations. According to the quote, it would seem that parallel superclasses can interfere surprisingly with each other in Sather. However, I am more optimistic than e.g. Alan Snyder (if the quote, "multiple inheritance is a good thing, but nobody knows how to do it right", is correctly accredited to him). I think that MI can even be done right, but have not studied whether and how it could be retrofitted to Modula-3. ---------------------------------------------------------------------- Markku Sakkinen (sakkinen@jytko.jyu.fi) SAKKINEN@FINJYU.bitnet (alternative network address) Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland ---------------------------------------------------------------------- ======================================================================= 66 === Date: 13 Jul 92 14:39:34 GMT From: sakkinen@jyu.fi (Markku Sakkinen) Subject: Re: Proposed language changes In article <23145@alice.att.com> ark@alice.UUCP () writes: >In article <9207101948.AA26823@riposte> wyant@centerline.com writes: > >> It [multiple inheritance] was added to C++ about >> 5 years after the C++ type system was initially >> designed; again I believe this proved to warp the >> language considerably. > >Oh? Can you give us some concrete examples of that warpage? > >For instance, can you show a case where the existence of >multiple inheritance in C++ inconveniences programmers that >don't use it? Well, if any class B inherits some other class A as _public_ (or protected), and the designer of B has even the least doubt that somebody might later use B in a "fork-join" (*) situation, it would be very sensible to declare the inheritance as "virtual" (meaning a sharable superclass part). However, besides the performance penalty, this causes two drawbacks: 1. If non-default initialisation for A is needed, every constructor of every subclass (direct or indirect) of B must explicitly restate that initialisation. 2. "Downcasting" a pointer of type A* to a pointer of type B* becomes absolutely impossible (of course this is a very dangerous operation even in the allowed situations). (*) This means that there is some other direct subclass of A, say C, such that neither B nor C is a subclass of the other, and some further class inherits both B and C (directly or indirectly). Shameless plug: see my paper, "A critique of the inheritance principles of C++" (Computing Systems, Winter 1992), for eshasutinxhaustin. ---------------------------------------------------------------------- Markku Sakkinen (sakkinen@jytko.jyu.fi) SAKKINEN@FINJYU.bitnet (alternative network address) Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland ---------------------------------------------------------------------- ======================================================================= 67 === Date: Wed, 15 Jul 1992 08:02:49 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: Re: installing src m3 Oliver Stephens writes: > After building the bootstrapped compiler for SPARC, I built libm3 then made > a shared library version of it. I then rebuilt the compiler and driver from > the M3 source to produce versions which used the shared library. Whoa! Having just built the stuff and installed it, and not having found any remarks about this in the README, I didn't even try. Can you give me a 'ten easy steps to shared-lib happyness'? > Resulting saving in space is : > > m3 - from 2.8 to 0.5 Mbytes > m3compiler - from 5.3 to 3.1 Mbytes Boy, our system maintainer will be tickled pink when he hears that. We get alarmed shouts about lack of disk space allmost at a weekly basis. Greetings, Bert -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null ======================================================================= 68 === Date: Tue, 14 Jul 92 23:57:45 -0700 From: nolan@pavone.enet.dec.com (Chris @ VAR - DTN: 787-8460 15-Jul-1992 085 5) Subject: PLEASE REMOVE ME FROM THE MODULA-3 INTEREST LIST Fort the second time of asking I wish to be removed from the M3 interest and distribution lists. I am getting FAR too much mail and I wish it to STOP. thanks, chris. ======================================================================= 69 === Date: 15 Jul 1992 22:23:14 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: Proposed language changes >In article <9207101948.AA26823@riposte> wyant@centerline.com writes: >> It [multiple inheritance] was added to C++ about >> 5 years after the C++ type system was initially >> designed; again I believe this proved to warp the >> language considerably. In article <23145@alice.att.com> ark@alice.UUCP () writes: >Oh? Can you give us some concrete examples of that warpage? >For instance, can you show a case where the existence of >multiple inheritance in C++ inconveniences programmers that >don't use it? Okey-dokey, I'll bite. (Cut to the end to skip the long-winded stuff). Right now, C++ (2.1, 3.0) requires that I read about virtual and non-virtual base classes. Without MI, these wouldn't be there. Right now, C++ (2.0, 2.1, 3.0) lacks the ability to cast from a base type to a derived type in certain situations. It is, in fact, an intellectual burden to discover and remember those situations. I believe that this is a consequence of multiple inheritance, since single inheritance does not require any offsets of the "this" pointer. Right now, C++ (2.0, 2.1, 3.0) pretty much requires (but does not enforce) virtual destructors in certain single-inheritance situations. As you can see already, I don't recall quite when that is, and this is a bug. I believe this weird requirement is a consequence of multiple inheritance (same as above -- an offset "this" pointer). Right now, C++ (same versions) lacks run-time type checking. I don't know why it doesn't have it, but I do know that it is more difficult to define, implement, and explain this in the presence of multiple inheritance. Having implemented this in the past for a language with single inheritance, I know that it is not terribly hard in that case. This is an example of where the addition of one feature may have prevented/delayed the addition of another feature. In the future, C++ may have some form of run-time type-checking. In a language with single inheritance (like Modula-3) this can be implemented in a way that it requires a constant amount of time to perform any type check, and log(#cases) time to execute a typecase statement (with arbitrary depth in the cases and the type tree). Will C++'s versions of these statements have similar efficiency, assuming that I don't use multiple inheritance? (I've been trying to figure out how one might search the DAG quickly, but haven't had the time to really make much progress.) This is an example of where the addition of one feature may have prevented the best presentation or implementation of another feature. In the future, it might be nice to add garbage collection to C++. I know it is easy to do a good garbage collection in a SI system, but I'm not sure of what the MI interactions are. It does not simplify the garbage collector or make it faster (the offset pointers are the basic pain here. References cause similar problems.) I'm a little curious where all this goes with (say) persistent data, or pickled data, or dynamically loaded libraries. I've done the homework (other people have helped) to convince myself that I implement a single-inheritance type system that would provide efficient NARROW and concurrent introduction of new types (no locking, assumes certain consistency properties of the underlying memory system). TYPECASE is a little harder, but I think about it from time to time. I wouldn't be surprised if MI had bad interactions with these features. Note that these are features that I have used in the past (in the Olivetti M-3 system) and wished that I had access to now in C++. I have not experienced such a burning need for MI. This doesn't mean that MI is never useful, but if most of the cases where it is useful sound something like "A friend of a grandmother of an old boss of mine was working on this window system..." then I remain skeptical. (This is an exaggeration. Several people have told me good stories about mix-ins. However, the C++ MI system is considerably larger than mix-ins, and it might be possible to add mix-ins w/o all the other restrictions.) So in summary: 1. MI makes the language bigger, even if I confine myself to a SI subset. (virtual base classes) 2. MI adds more rules that a SI user must follow. (restrictions on down-casting; virtual destructors) 3. MI may have delayed other useful features. (run-time types) 4. MI may prevent other useful features from being implemented in their most useful fashion. Speaking for myself, I've used and liked those features (run-time types, garbage collection, pickled data), but MI has never done much for me. David Chase Sun ======================================================================= 70 === Date: Thu, 16 Jul 92 09:52:51 +0200 From: a.vermeulen@ECN.NL (Vermeulen A.T.) Subject: Redundant files in trestle-archive In the archive trestle-2.07.tar.Z on gatekeeper a redundant compiled executable has not been deleted (it's not a SPARC executable). It's called BadBricks. Also the .mx and the .mo file are redundant. Removing them from the archive could reduce the amount of data transported over the net considerably. -- Netherlands Energy Research Foundation Email: a.vermeulen@ecn.nl P.O. Box 1 Phone: (+31) 2246 4194 1755 ZG Petten, The Netherlands ======================================================================= 71 === Date: 15 Jul 92 23:07:43 GMT From: Ari.Huttunen@hut.fi (Ari Juhani Huttunen) Subject: Re: Sather (was: Re: Proposed language changes In article <13u0h7INN43r@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes: ! I should remind people that I'm not a computer scientist, but a ! (probably future unemployed) physicist. Warning! This text was written by a computer science student. ;-) ! : Take a look at lib/base/do.sa. It implements some loop constructs. You ! : are able to say things like: ! : c: DO := DO::times(100); until c.is_done loop ..foobar.. end; ! I did. It still seems unnatural. Seems, hell. It is. Take a look at ! it, and be honest. I think "do loops" were deleted from Modula-2 in ! going to Oberon (an intentionally small language, like Sather), and ! reinstated after practical experience in Oberon-2. A simple, very common ! concept deserves a simple, idiomatic statement. It's very easy for me to be honest: that DO-loop looks awful. But I don't think adding the DO-loop to Sather would solve more problems than it creates. Should there also be for-, while-do-, do-while- and do-until-loops? A single loop construct makes more easily readable code. Also, in Sather a very common thing is a 'cursor' that goes through the elements of a container class (like a list) in some order. The until-loop-end style loop is very good for this. UNTIL we_have_gone_through_all_the_elements_ _in_this_container LOOP use_the_element_in_the_container END; ! Implied iteration and summation over repeated indices. (a.k.a. Einstein ! summation convention). It's a common notation in math and science--computer ! or no. ! E.g. Vector A = Matrix B times vector C: ! A(i) = B(i,j)*C(j) ! or more explicitly ! "for all i" A(i) = "sum over j" B(i,j)*C(j). ! This concept subsumes nearly all of Fortran 90's matrix & vector operations. ! Explicitly parallel too. In comp.lang.misc there was a long debate ! on this a couple of months ago. Jim Giles also had the same position, and ! in fact I think his operation even designed specific extensions to Fortran ! to express this concept. (In fact if I were to design an optimizer for ! an F90 compiler, I might want to internally represent array ! operations in this generalized form so I could write only 1 code generator). ! Despite what all the proponents of OOP say, either explicitly or by ! their textbook examples, I do *not* think that a class structure is the ! best solution for this problem (i.e. matrix and vector and tensor classes ! and overload the + and the - and the blah blah blah). There's another soluti on ! that's cleaner and more general, at least in the (important!) domain of ! array operations. The array operations are important to you. To others they might not be so important. Furthermore, adding such constructs would change the language radically. That seems a little too high price for not having to use objects and redifine their methods/member functions/features. No-one forces you to use an object-oriented language against your will. -- ............................................................................... Ari Huttunen They say the sky high above 90-7285944 is Caribbean blue... (Enya) ======================================================================= 72 === Date: 16 Jul 92 12:25:20 GMT From: ark@alice.att.com (Andrew Koenig) Subject: Re: Proposed language changes In article chased@rbbb.Eng.Sun.COM (David Cha se) writes: > Right now, C++ (2.1, 3.0) requires that I read about virtual and > non-virtual base classes. Without MI, these wouldn't be there. Virtual base classes are part of MI. A program that doesn't use MI won't use virtual base classes either. > Right now, C++ (2.0, 2.1, 3.0) lacks the ability to cast from a base > type to a derived type in certain situations. Those situations all involve virtual base classes. > Right now, C++ (2.0, 2.1, 3.0) pretty much requires (but does not > enforce) virtual destructors in certain single-inheritance > situations. This has nothing to do with MI. You need a virtual destructor if you use a base class pointer to delete a derived class object. In this respect, operator delete is much like any other member function. > Right now, C++ (same versions) lacks run-time type checking. No fair complaining about parts of C++ that don't exist! :-) Seriously, I don't see why MI should make this any harder: it is already necessary to figure out which virtual functions to call and any run-time type information can use the same mechanism as virtual functions. > In the future, it might be nice to add garbage collection to C++. I > know it is easy to do a good garbage collection in a SI system, but > I'm not sure of what the MI interactions are. It does not simplify > the garbage collector or make it faster (the offset pointers are the > basic pain here. References cause similar problems.) I don't think it makes an awful lot of difference. Again, it doesn't seem to be any more difficult than getting the right information into virtual function tables. > I'm a little curious where all this goes with (say) persistent data, > or pickled data, or dynamically loaded libraries. This is getting a little off the point. The original claim was that `MI warps the language' and I asked for examples. All of the above examples are either integral parts of MI, which therefore cannot be said to be effects on the rest of the language, or speculations about things that do not currently exist. > 1. MI makes the language bigger, even if I confine myself to a SI > subset. (virtual base classes) Virtual base classes are part of MI. > 2. MI adds more rules that a SI user must follow. > (restrictions on down-casting; virtual destructors) The first restriction applies only to programs using virtual base classes, which art part of MI; the second is unrelated to MI. > 3. MI may have delayed other useful features. > (run-time types) Every feature delays other useful features. > 4. MI may prevent other useful features from being implemented in > their most useful fashion. I haven't seen any real evidence for this. -- --Andrew Koenig ark@europa.att.com ======================================================================= 73 === Date: Thu, 16 Jul 92 14:36:47 BST From: Grant "M." Friel Subject: Problem compiling demos archive I've just been trying to compile the demo programs for modula3-2.07. columns and tetris appear to be ok, but quite a few errors were reported when trying to make solitaire. It is reporting "missing file" and "number of actuals doesn't match number of generic formals" in most of the solitaire source files. Am I doing something wrong? (The trestle and bicycle libraries appear to have been generated and installed ok) I also got the following during the make process for both tetris and columns, but both programs worked. Is this safe to ignore or what ? ld: Undefined symbol _get_wmShellWidgetClass _get_applicationShellWidgetClass Thanks in advance for any help. Grant -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Email : (JANET) grant@uk.ac.keele.cs (BITNET) grant%cs.kl.ac.uk@ukacrl (UUCP) ...!uknet!kl-cs!grant (other) grant@cs.keele.ac.uk +---------------------------------------------------------------------------+ "We shall not cease from exploration, And the end of all our exploring will be to arrive where we started and know the place for the first time." T.S. Elliot (deep huh!) +---------------------------------------------------------------------------+ ======================================================================= 74 === Date: 16 Jul 92 10:54:51 GMT From: os102@cl.cam.ac.uk (Oliver Stephens) Subject: Re: installing src m3 OK, shared libraries under SunOS. The trick is to compile all the C files with -PIC (Position Independent Code), then link to produce shared library object (linked with -assert pure-text to make sure it is possible). Below are two scripts which create shared library versions of libm3 and libm3ui (trestle). I am a third of the way through incoporating more general code into m3make to do this stuff automatically on request: will post the results. As far as disc space goes, there is a minus in that you still need the ordinary libraries present. This is not as bad as it sounds because the shared library is much smaller than the ordinary : 5416 -rw-rw-r-- 1 os102 5531122 Jul 12 19:17 libm3.a 456 -rw-rw-r-- 1 os102 458016 Jul 12 19:16 libm3.ax 1512 -rwxrwxr-x 1 os102 1540096 Jul 12 20:34 libm3.so.1.1* 3024 -rw-rw-r-- 1 os102 3085202 Jul 12 18:30 libm3ui.a 272 -rw-rw-r-- 1 os102 269321 Jul 12 18:28 libm3ui.ax 832 -rwxrwxr-x 1 os102 843776 Jul 12 18:48 libm3ui.so.1.1* And the advantages are great : m3 from 2809856 to 524288 bytes m3compiler from 5332992 to 3072000 bytes replayheap from 3899392 to 245760 bytes showthread from 3940352 to 237568 bytes m3pp from 1228800 to 180224 bytes miniformsedit from 1245184 to 245760 bytes (this uses shared library versions of vbtkit and miniformsvbt as well) ---+---+---+---+--- mklibm3-so.sh ---+---+---+---+--- #! /bin/csh -f # # Makes SunOS shared library version of libm3 # # First make libm3.a, but with the -k flag, so that you can # keep the generated _m3lib.c. You also need to do a preliminary make # to get the .PGM_SOURCES file. # # set PREFIX variable in this script with the location of your # installed binaries (PREFIX in the config file), run this script in # libm3/SPARC, then install the resulting libm.so.1.1 in # PREFIX/lib/m3 # set PREFIX=/usr set m3src=`cat .PGM_SOURCES` if (! -e .m3path) then cat > .m3path < .m3path < Right now, C++ (2.0, 2.1, 3.0) pretty much requires (but does not > enforce) virtual destructors in certain single-inheritance > situations. As you can see already, I don't recall quite when that > is, and this is a bug. I believe this weird requirement is a > consequence of multiple inheritance (same as above -- an offset "this" > pointer). Since you don't quite recall what the problem is I can't quite be specific, but I see no such problem. > Right now, C++ (same versions) lacks run-time type checking. I don't > know why it doesn't have it, but I do know that it is more difficult > to define, implement, and explain this in the presence of multiple > inheritance. Having implemented this in the past for a language with > single inheritance, I know that it is not terribly hard in that case. > This is an example of where the addition of one feature may have > prevented/delayed the addition of another feature. That is pure conjecture, and wrong. C++ was designed without run-time type information mechanisms because I disliked the effect of their use in Simula programs. When I was convinced that having such mechanisms was less trouble than not having them I implemented it in two morning's of real time, about 4 hours of solid work. The amount of code needed (combined compiler and run-time support code is less than 150 lines of C++). > In the future, C++ may have some form of run-time type-checking. In a > language with single inheritance (like Modula-3) this can be > implemented in a way that it requires a constant amount of time to > perform any type check, and log(#cases) time to execute a typecase > statement (with arbitrary depth in the cases and the type tree). Will > C++'s versions of these statements have similar efficiency, assuming > that I don't use multiple inheritance? (I've been trying to figure > out how one might search the DAG quickly, but haven't had the time to > really make much progress.) This is an example of where the addition > of one feature may have prevented the best presentation or > implementation of another feature. Maybe, but that again is conjecture. The dumb and easy implementation of a downcast involves n-1 calls of a trivial recursive function where n is the distance betwwen the static type of the object and the desired static type. ======================================================================= 77 === Date: Fri, 17 Jul 92 21:08:37 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Proposed langauge changes / MI In article l63uruINNl6m@exodus.Eng.Sun.COM, chased@rbbb.Eng.Sun.COM (David Chas e) writes: >In article <1992Jul9.154716.7869@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.in formatik.rwth-aachen.de writes: >>Since you mentioned the MI thing again: I still don't see any problem with >>it. > >There's a couple of problems -- sorry if I didn't go into details. > I think that we should discuss exactly those details (instead of personal opinions about "good" or "bad" language features). So, before I deal with your points, let me point out what kind of MI I would support. - A may inherit from B and C only if B and C themselves are subtypes of D. This does not only solve some of your problems, it also forces the designer to think about common properties of B and C. This improves reusability, data abstraction etc. If this restriction forces you to include a class which seems "artificial", you are probably composing two classes which should not be composed (just because they have nothing in common). - A should have only one copy of D's data fields. I can't think of any problem where you would like to have two copies (one from B, one from C). This is likely a case where an OBJECT b:B; c:C; END; should be used. - If there are name clashes between data fields in B and C, these should be resolved internally. Everything else will interfere with data abstraction. - Methods from D, which are redefined differently in B and C, have to be redefi ned in A. This can be checked statically. >(1) Define the semantics of TYPECASE (which case is chosen?) > I agree, this is a problem. One simple solution comes into my mind: For A, B, a nd C, TYPECASE would only select D. This is not very satisfying, although it does fit into the existing language. TYPECASE in general is a statement only useful in SI systems. But this is not a fault of MI. If you would include a feature into some language which would not allow, let's say, pointers, does this imply that pointers are not useful? To me, TYPECASE is a construct for easy handling of objects with a "variant REC ORD" semantics (correct me if I'm wrong). Such objects are SI by nature. My proposal for a modified TYPECASE still allows such usage. >(2) Can we add MI without slowing down SI? (This is a trick > question, because you need to worry about both current > (sleazy compilers) and future (good compilers) performance.) > Who knows? I'd like to take a chance. Many features, which are common today, we re regarded as "unimplementable" some years ago (and some still are, look at the discussion about garbage collection in comp.lang.object). Most other OO languages have it, so it shouldn't be that bad. >(3) MI has some weird interactions with opaque supertypes. > Suppose you get something like (pardon my mangling of the > syntax): > > TYPE X <: OBJECT; > TYPE Y <: OBJECT; > > A = X OBJECT METHODS ... END; > B = Y OBJECT METHODS ... END; > > C = A,B OBJECT METHODS ... END; > > Now, what if it turns out that X and Y actually share > a common ancestor? Are the data fields and methods shared, or no? > (sharing is not consistent with encapsulation -- my conclusion is > that sharing should not occur in this case. However, for mix-ins > it appears that sharing is what you want. One resolution is to > only allow sharing to occur when it is not hidden. However, I > don't know if this can be done in a consistent and reliable > fashion; what happens if there are multiple views of the objects > involved?) > Well, I've answered this already. I think they should be shared. Why does this interfere with data abstraction? B and C (in my example) may act upon D's data only through D's methods. This should assert the integrity of D's data. B and C offer methods to change their own data, as well as modified or complex combinat ions of D's methods. So data hiding is supported (am I missing a point?). The only problem I do see here is that A has to know that B and C both inherit from D. But then: according to my proposal, if A may inherit from B and C, it already knows that there *has* to be some common ancestor of B and C. A should be aware of this, because it makes A itself a subclass of D. But this is not so very different from SI: If A is a subclass of B and B of C, then A also knows that it's a subclass of C. Otherwise, it can't use C's methods and the inherita nce is useless. >(4) How does narrow work in the presence of repeated inheritance? > (a) what is the right answer? > (b) can we implement this efficiently? > > That is, suppose you have: > > TYPE X <: OBJECT; > > A = X OBJECT METHODS ... END; > B = A,X OBJECT METHODS ... END; > > C = A,B OBJECT METHODS ... END; > > Suppose I narrow an "X" to an "A", given that what I've really got > is a C. Which one? How efficient is "NARROW" now? > This is not allowed in my proposal, because there is no common superclass for A and X. Besides, I can't see any sense in this class hierarchy. >(5) Discover and document any remaining semantic/implementation > gotchas. > Yes. >My concern about efficiency may seem misplaced, but if what you're >after is flexibility with no major concern for performance, you can >get that already from CLOS. (And yes, I am *very* interested in >Dylan, which I am told is something like Scheme+CLOS.) > I don't see any efficiency drawbacks from MI. Of course, there is more work to do for the compiler. But how does it affect execution speed? >Comparisons with bullet-items on the C++ Real-Soon-Now list are also >unfair. It could be that they are unimplementable, or come with >horrible interactions, or maybe there is more sizzle than steak (e.g., >maybe the feature is "provided" but in a useless fashion). > You're right. But nevertheless, M3 has to compete with C++ and others. And, as I stated in some earlier posting, if you want people to use M3 instead of C++ (or Sather, Eiffel, ..., all of which *have* MI), you have to give them some *real* good reasons why M3 hasn't MI. I'm not convinced yet. But any suggestions are welcome. --- 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 ======================================================================= 78 === Date: 17 Jul 1992 23:04:58 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: Proposed language changes / comparisons >In article chased@rbbb.Eng.Sun.COM (David Ch ase) writes: >> In article <23185@alice.att.com> ark@alice.UUCP () writes: > >No fair complaining about parts of C++ that don't exist! :-) No, exactly fair. Time spent designing and implementing multiple inheritance is time not spent doing other things. This may not be what you thought "warping the language" means, but it is good enough for me. >> [run-time type-checking] >Seriously, I don't see why MI should make this any harder: >it is already necessary to figure out which virtual functions >to call and any run-time type information can use the same >mechanism as virtual functions. I think you are being a bit glib here. For a single-inheritance type system, the virtual function tables contain a constant amount of additional information describing the position of a type in a type tree (the technique described in a letter in TOPLAS recently is inferior). To determine if type A is an ancestor of type B, it suffices to know that lr_pre_number(A) <= lr_pre_number(B) and that lr_post_number(A) >= lr_post_number(B). See Paul Dietz, "Maintaining Order in a Linked List", STOC 1982. For single inheritance, we're talking about one word per VFT to a type descriptor, and each type descriptor can contain as little as two words encoding pre- and post-order numbers. I'm pretty sure it is not this simple for multiple inheritance. On the other hand, the TOPLAS technique seems like it could be hacked to work for MI. The space cost goes up (O(max inheritance depth) per VFT, I think), but the time cost stays low (assuming that the hack works, of course). I'm not sure what happens if a new type is loaded into a running system, since it could increase the inheritance depth, and thus require changing the sizes of the VFTs. The problem gets worse if you consider TYPECASE (if you choose to implement it). Using techniques described in the Dietz paper, you can implement typecase for single inheritance to run in O(log # cases) time, with O(#cases) space cost. For multiple inheritance? (Again, I'd love to be enlightened.) >> 4. MI may prevent other useful features from being implemented in >> their most useful fashion. >I haven't seen any real evidence for this. It's difficult to prove this, but I'll try a comparison with Modula-3. The Olivetti M-3 implementation required < 10 people-years to obtain roughly cfront functionality, PLUS garbage collection, PLUS automatic makefile generators and dependency checkers, PLUS (an instance of) an interpreter, PLUS automatic generation of marshalling code, PLUS a compiler-server (cached interface files, a big win), PLUS run-time types, PLUS a skeleton AST system used to build pretty printers and implementation stub generators, PLUS a threads library (briefly ported to multi-threaded Mach on a '386 before Olivetti shut the lab down -- presumably, we were insufficiently productive :-). Like C++, we churned through a couple of versions of the language in the process. Like C++, we targeted multiple archictectures. (Note that there are several interesting language tools in the list, as opposed to "language features".) Now, compare this with what has appeared for C++, a language of much greater commercial significance. Either the crew at Olivetti (some working part-time, some also writing papers, some working on another continent) was phenomenally good, or else we were working on a much easier problem. I'd like to think that we were good, but we weren't that good. It's been two years since I last worked on Modula-3, and presumably more than 10 people-years have been spent since then (at various software houses) improving C++ and building tools, and that's on top of whatever was already available in 1990. Where's the goodies? *Something* has prevented those other features from appearing. (To be fair, I'm certain that backward semi-compatibility with C is the biggest obstacle.) David Chase Sun ======================================================================= 79 === Date: 17 Jul 1992 23:31:16 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: Proposed language changes In article <23207@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes: >chased@rbbb.Eng.Sun.COM (David Chase @ Sun Microsystems, Mt. View, Ca.) > > In the future, C++ may have some form of run-time type-checking. In a > > language with single inheritance [this is cheap]. ... Will > > C++'s versions of these statements have similar efficiency, assuming > > that I don't use multiple inheritance? > >This is an example of where the addition > > of one feature may have prevented the best presentation or > > implementation of another feature. >Maybe, but that again is conjecture. The dumb and easy implementation of >a downcast involves n-1 calls of a trivial recursive function where n is >the distance betwwen the static type of the object and the desired static >type. "Trivial" is not necessarily cheap, depending upon the shape of the type DAG and the dynamic frequency of type checks (*). It is also a bit worrying (as a potential future user of RTTI in C++) that the best refutation available to my inefficiency fears is "that again is conjecture". This implies that a feature is being added to the language without a clear handle on the costs of its use (because if you had a cost estimate, if it was any good, you could remove my fears and make me look like an ignoramus by revealing the efficient algorithm, instead of by saying "conjecture". Therefore I must conclude that no good time bound is known). Is this good language design? (Unfair question -- given that MI has already been added, it is almost impossible to remove. Since RTTI is necessary, it must also be added, and let the costs fall where they will. However, this supports the assertion "MI has warped the language", if one believes that RTTI is more important than MI, or if one believes that the wrong kind of MI was chosen w/o taking the needs of an important feature like RTTI into account.) (*) I believe Mick Jordan has reported substantial speedups in his AST system by making all the types visible and "flattening" the TYPECASE statements into ordinary switch statements. The last time I was near M-3, TYPECASE and NARROW were implemented using the algorithm Stroustrup describes, since (as noted in Stroustrup's post) that is the easy way to do it. This is evidence that trivial is not necessarily cheap. David Chase Sun ======================================================================= 80 === Date: Fri, 17 Jul 92 21:24:32 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Proposed langauge changes / MI >One simple solution comes into my mind: For A, B, and >C, TYPECASE would only select D. Sorry, this is nonsense. I meant: D should only select A. If both B and C are given, but not A, the ELSE-case is chosen. --- 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 ======================================================================= 81 === Date: 18 Jul 92 01:03:48 GMT From: mbk@lyapunov.ucsd.edu (Matt Kennel) Subject: Sather's Multiple Inheritance The more I read about it, the more I like way Sather does inheritance: simply and easily. ("Omit needless brain" :-) ) I'll quote from it's manual: ============ 3.2 Inheritance A class "A" inherits the features of another class "B", when the name "B" appear's in A's feature list. We say that B is a parent class and that A is a child. The semantics is exactly as if the features of B were textually copied into A at the point the name appears. Any references that appear in the inherited feature definitions will be resolved in the new namespace. Later features in a class with the same name as earlier ones override the earlier definitions. This means that the order in which classes are inherited can have an effect on the meaning. A class may inherit from many other classes. {And then, "you can't have cycles in the inheritance graph"---my paraphrase} =============== That's it! (well almost...see below) I.e. you do: class CHILD is PARENT_CLASS_ONE; --- That inherits one class PARENT_CLASS_TWO; --- That inherits another new_variable : INT; --- A new feature of this class new_method is --- a new method for this class end; end; Now what if both PARENT_CLASS_ONE and PARENT_CLASS_TWO have two features, say integer variables "count": Then you can use "alias new_name old_name": =========== class CHILD is PARENT_CLASS_ONE; --- That inherits it alias count_one count; --- rename "count" from P_C_O PARENT_CLASS_TWO; --- That inherits another alias count_two count; --- Rename that one as well count : INT; --- A third "count" different from the --- other two. new_variable : INT; --- A new feature of this class new_method is --- a new method for this class end; end; ============ I don't know if this solution is perfect for all circumstances, but it appears to a layman to cover a whole lot, and it's very easy to understand. Does OOP help real productivity if you have to spend a tremendous amount of brainpower on figuring out the rules of the language? I don't think so--- only the real geniuses with a mind for pedantic detail can be more productive, but they were the most productive to begin with anyway. -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego ======================================================================= 82 === Date: 18 Jul 92 15:54:25 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Proposed langauge changes / MI Peter suggests that if D inherits from B and C, then B and C must share a common ancestor A. This condition is trivially satisfied - ROOT is the anscestor of all OBJECT types. Peter, I think perhaps you have a different and stronger condition in mind. Could you try to articulate it? I don't think requiring B and C to have the same immediate ancestor is general enough, and I think saying they have to have a common ancestor other than ROOT requires more defense -- MI ought to allow one to combine completely orthogonal types if that's useful, shouldn't it? Why is it wrong to do so? You seem to have a style or idiom in mind that I have not been able to derive from what you've said so far .... -- 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 ======================================================================= 83 === Date: 18 Jul 92 16:36:30 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Sather's Multiple Inheritance Matt describes Sather's MI aproach from the Sather manual. From that description, it sounds as if Sather does not support encapsulation (or, at least, opaque supertypes) to hide stuff from most subtypes. Once you have opaque supertypes, you have a worse problem with name clashes -- you can't know what's going to clash! (Because you can;t know what's in a supertype.) Sounds to me as if Sather flattens the types out completely, which will interfere with building large system, by undermining encapsulation. -- 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 ======================================================================= 84 === Date: Sat, 18 Jul 1992 18:32:28 GMT From: mday@jukebox.lcs.mit.edu (Mark Day) Subject: Re: Proposed langauge changes / MI pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) writes: You're right. But nevertheless, M3 has to compete with C++ and others. And, as I stated in some earlier posting, if you want people to use M3 instead of C++ (or Sather, Eiffel, ..., all of which *have* MI), you have to give them some *real* good reasons why M3 hasn't MI. I'm not convinced yet. But any suggestions are welcome. Some people have been so burned by MI in C++ that they consider it a good thing to leave out of a language. So it's not obvious to me that you have to have MI to "compete" with C++ and company. --Mark Day mday@lcs.mit.edu ======================================================================= 85 === Date: 18 Jul 92 16:30:17 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Speed of TYPECASE (was Re: Proposed Language Changes) The SRC compiler uses the following technique (I may be paraphrasing a bit, but I think it captures the essence): Take the tree of types and walk it in a depth first manner. Using a global counter, drop numbers off at the nodes, as follows. For an internal node, drop one number off before visiting the children and another afterwards; for leaves, simply drop off one number. The type code of a type is simply the first number dropped at the trees node in the tree. TYPECASE consists of taking the typecode of the item being cased and seeing, for each arm in sequence, if the typecode falls within the range allowed for the arm. If the arm is a leaf type, then there is only one possible value; if the arm is an internal node, then there is an upper and lower bound. A simple implementation would consist of a series of IF tests, each testing either equality or two bounds. Almost any implementation must special case NIL since it is generally not represented as a pointer to a thing that can supply a type code. I will assume that that is done first, before any IFs or CASEs. In SI at least, the order of the cases can be removed by getting rid of later cases that are covered by earlier ones (which I think is an error anyway (don't have my M3 book here)). So we can break it all down into ranges of typecodes and case arms that go with them; a given arm may have several ranges, since earlier arms may handle subtypes. Anyway, given this viewpoint, it is easy to see that an O(arms) linear search can be turned into an O(log(arms)) binary search or, by listing each individual type code in the range of interest, into an O(1) indexed branch. Now Mick can correct me, but I recall discussing this with him a bit at the time of the MUG, so even some details are a little off, I think I can clarify the general point: if you know all the types involved, you can build the type tree and know the type codes at compile time, and turn the sequential-IF implementation of TYPECASE into a CASE statement, which could result in a switch statement in the code output by the SRC compiler (though I am not sure that it actually *does* result in a switch in C; the SRC compiler may insist on deciding how to carry out the CASE that Mick builds). This is an interesting argument in favor of the type numbering, etc., used by the SRC system, which is different from what we've design for the GNU system. I believe that we test TYPECASE arms sequentially, using a different narrowing test. We consider the depth of the two types in the tree. Let's call the (allocated, not static) type of the object the *source* type, and the type we are trying to narrow to the *destination* type. The destination type's depth (distance from the root) in the type tree must be <= the source type's depth, and the source type's supertype at the depth of the destination type must be exactly the destination type. So we have a <= test of a variable against a compile-time known constant, and an equality test of a variable against a constant (we store the vector of supertypes somewhere easily accessible from the type). The advantage of our system is that types can be added without affecting the actual tests in any way. We think this may be important for persistent systems, where new subtypes may be added (and code for them loaded dynamically from the store) after a program is compiled. Hence, the type tree of the SRC approach is not static, and their approach breaks down. We can probably still come up with an O(log(arms)) implementation of our scheme; it is just hard to do it O(1) in the face of a type tree growing dynamically. All of this breaks down in the MI setting. I can't think of an O(1) narrow test, much less an O(log(n)) TYPECASE test, that is at all space efficient and that works in the face of dynamically growing type DAGs. Some of the folks with the logic language project at MCC (I think Hassan Ait-Kaci was one) did some work on making DAG narrow tests efficient, but I believe they assumed a static DAG so you could do a bunch of precomputation. It may turn out that the way to do it is to use a potentially expensive algorithm to check subtypes, and to do one or more kinds of caching to save the results. For example, each TYPECASE statement could have a fixed size cache (organized as a hash table, of course) to say which arm to use for some recently presented types. This may well turn out to be expected O(1) for most programs. If the cache size is 1, this is similar to the inline method cache idea -- if the type is the one we know about, go to the location recorded, otherwise do the more painful technique and update the cache. (If you go implement this and got the idea from me, don't forget to give me credit :-). -- 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 ======================================================================= 86 === Date: Sat, 18 Jul 92 20:14:36 GMT From: muller@src.dec.com (Eric Muller) Subject: Re: how do I get the modula3 revised report? In article <6004@otc.otca.oz>, johng@otc.otca.oz.au (John Gibbons) writes: |> Is the modula-3 revised report available over the net? No, you have to get: 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. -- Eric. ======================================================================= 87 === Date: 18 Jul 92 20:39:36 GMT From: ark@alice.att.com (Andrew Koenig) Subject: Re: Proposed langauge changes / MI In article mday@jukebox.lcs.mit.edu (M ark Day) writes: > Some people have been so burned by MI in C++ that they consider it a > good thing to leave out of a language. So it's not obvious to me that > you have to have MI to "compete" with C++ and company. Whom are you thinking of, aside from Tom Cargill? Note that at various times, Tom has also called for removing constructors and overloaded operators from C++. Moreover, I don't think he's actually been burned from it; he just doesn't think it is useful. -- --Andrew Koenig ark@europa.att.com ======================================================================= 88 === Date: Sat, 18 Jul 92 20:25:02 GMT From: muller@src.dec.com (Eric Muller) Subject: Re: Thread Aqcuire and Release problem In article <1992Jul13.090145.1005@cs.ruu.nl>, Harald Vogt asks about threads. Your program is illegal. SPwM3, p70, describes Thread.Release: PROCEDURE Release (m: Mutex); The calling thread must have m locked. Unlocks m. The precondition is not respected by your program. We have introduced an explicit check of the precondition (to help find bugs in the implementation), which explains the difference of behaviour with the previous releases. You should normally get some message from the runtime; I don't know why you did not get one. -- Eric. ======================================================================= 89 === Date: Sun, 19 Jul 1992 01:27:25 GMT From: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) Subject: Re: Sather's Multiple Inheritance Eliot Moss: Matt describes Sather's MI aproach from the Sather manual. From that description, it sounds as if Sather does not support encapsulation (or, at least, opaque supertypes) to hide stuff from most subtypes. Once you have opaque supertypes, you have a worse problem with name clashes -- you can't know what's going to clash! (Because you can;t know what's in a supertype.) Sounds to me as if Sather flattens the types out completely, which will interfere with building large system, by undermining encapsulation. >From what I read, you can get opacity by the simple expedient of masking the detail you want hidden with a later namespace conflict. You can see the names, but the original definitions are shadowed from the point where you see those names. Similarly, it doesn't seem matter if you don't know the details of a superclass. As long as they're visible from the points that need to know about them, things are ok. The question I'd have, about Sather, is how simple is it to express dynamically structured data? If it's difficult to express such data, you'll have to resort to fancy footwork to express otherwise simple concepts. [This naming stuff is, obviously, not dynamic.] -- Raul Deluth Miller-Rockwell The U.S. government went another thousand million dollars into debt today. ======================================================================= 90 === Date: 19 Jul 1992 19:20:59 GMT From: mbk@lyapunov.ucsd.edu (Matt Kennel) Subject: Re: Sather's Multiple Inheritance rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes: : Eliot Moss: : Matt describes Sather's MI aproach from the Sather manual. From : that description, it sounds as if Sather does not support : encapsulation (or, at least, opaque supertypes) to hide stuff from : most subtypes. Once you have opaque supertypes, you have a worse : problem with name clashes -- you can't know what's going to clash! : (Because you can;t know what's in a supertype.) Sounds to me as if : Sather flattens the types out completely, which will interfere with : building large system, by undermining encapsulation. : : From what I read, you can get opacity by the simple expedient of : masking the detail you want hidden with a later namespace conflict. : You can see the names, but the original definitions are shadowed from : the point where you see those names. I don't know what quite you mean, but there's the "private" attribute: "Any feature definition may be preceded with the keyword "private". Only routines defined within the class itself may access such features. Private features will also be private in any classes which inherit them. ...A common exasmple is to define an attribute as private and to provide a routine which returns its value. This keeps other classes from changing the value while still allowing them to read it." : Similarly, it doesn't seem matter if you don't know the details of a : superclass. As long as they're visible from the points that need to : know about them, things are ok. I don't think I quite know the whole story here, but my opinion is that if you're inheriting a class, then you're on the "implementation" side of things and so it's OK to know the details. If you want to be on the "user" side of things, then just include an object of the pseudo-parent class as a feature of your new class and you can use it like any other object. I guess I don't quite understand the point of having a type that you can inherit from : : The question I'd have, about Sather, is how simple is it to express : dynamically structured data? If it's difficult to express such data, : you'll have to resort to fancy footwork to express otherwise simple : concepts. [This naming stuff is, obviously, not dynamic.] What exactly do you mean here? Do you mean say a routine that could take an object of that could be any one of a few different types? I think in that case you'd have to define a "superclass" from which any of the possible subclasses are derived and then declare the routine to take an argument of type 'superclass', but operates with dynamic runtime dispatching. This is dogma in most object-oriented languages, right? Though actually in Sather you can manually find out the "type" of any random object: ( I guess the only allowed operations are equality and inequality on this. ) =============== 5.5 The type attribute. All classes have a predefined constant attribute named "type". Its value belongs to CLASS_TYPE, a descendent of INT, and equals the tag on objects used to identify the class. It is useful in constructs such as "if a.type = FOO::type then ..." =============== Class relationships are trees, whether for better or worse. (Why not general "bags"?) : -- : Raul Deluth Miller-Rockwell : The U.S. government went another thousand million dollars into debt today. -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego ======================================================================= 91 === Date: Sun, 19 Jul 92 21:45:52 -0700 From: Subject: Re: Does NEW() accept positional bindings for OBJECTS? David Brumley asks: Page 46 of _SPwM3_ shows a generic stack module: GENERIC MODULE Stack (Elem); REVEAL T = BRANDED OBJECT n: INTEGER; a: REF ARRAY OF Elem.T END; PROCEDURE Create(): T = BEGIN RETURN NEW(T, 0, NIL) END Create; ... Can a new T be initialized this way? The answer is no; the book is in error. The NEW expression should be NEW(T, n := 0, a := NIL). The error was corrected in the second printing. Greg ======================================================================= 92 === Date: Mon, 20 Jul 1992 03:06:31 GMT From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) Subject: Re: Sather's Multiple Inheritance > >Class relationships are trees, whether for better or worse. (Why not >general "bags"?) > no, in C++ they're DAGS. Completely new opportunities arise with MI. -- ;---------------------------------------------------------------------- JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------ ======================================================================= 93 === Date: Mon, 20 Jul 92 02:06:32 PDT From: surak!frode (Frode Odegard) Subject: inheritance mbk@inls1.ucsd.edu writes: > [..] > I don't think I quite know the whole story here, but my opinion is that > if you're inheriting a class, then you're on the "implementation" side > of things and so it's OK to know the details. > [..] When you design a class you should take care in defining both the interface to clients, i.e. users of the class as well as to subclassees. Ideally you should be able to change the internals of a class and make few, if any, changes to you r subclasses. Interfaces and partial revelations help - see the stream classes i n libm3. (Under NeWS I didn't like to directly modify instance variables declared in superclasses.) - Frode <* reply-to: frode@odegard.com *> -------------------------------------------------------------------- Odegard Labs, Inc., 100 Bush St., Suite 625, San Francisco, CA 94104-3909, USA; +1-415-434-4242, +1-415-434-4243(fax), frode@odegard.com(internet) ======================================================================= 94 === Date: 19 Jul 1992 18:54:40 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: Sather's Multiple Inheritance In article moss@cs.umass.edu writes: >Matt describes Sather's MI aproach from the Sather manual. From that >description, it sounds as if Sather does not support encapsulation (or, at >least, opaque supertypes) to hide stuff from most subtypes. Once you have >opaque supertypes, you have a worse problem with name clashes -- you can't >know what's going to clash! (Because you can;t know what's in a supertype.) My reading may be wrong, but I didn't read it quite that way. I read that a redeclaration of a name merely hides the former declaration of the name. The clause about "as if substituted in place" also makes this work, because it means that hidden sharing is not possible. That is, given (opaque or not) (pardon the mutilated syntax): A = OBJECT ...0 END; B = A OBJECT ...1 END; C = A OBJECT ...2 END; D = A,B,C OBJECT ...3 END; what you've really got is: D = OBJECT ...0 END (* A *) OBJECT ...0 END OBJECT ...1 END (* B *) OBJECT ...0 END OBJECT ...2 END (* C *) OBJECT ...3 END; The scoping rules mean that the repeated declarations of A are harmless (though in this case, the leading declaration of "A" is somewhat useless), and the "as if substituted" rules mean that B and C do not share the data or methods of their common ancestor "A". This means that the ancestor can be hidden w/o ill effect. There is one problem with this, which is that (as I understand it) there are idioms of MI that profit very much from shared methods and data. However, these idioms apparently require that the sharing be visible for it to be useful, so maybe it is possible to cut this both ways (sharing and opaque supertypes interact in some sane way that allows encapsulation and the useful idioms). However, we're still stuck with broken typecase, at least until someone figures out how to make it go fast again. One thought problem: if MI is used, is TYPECASE quite so necessary? David Chase Sun ======================================================================= 95 === Date: Mon, 20 Jul 1992 09:25:48 GMT From: Ari.Huttunen@hut.fi (Ari Juhani Huttunen) Subject: Re: Sather's Multiple Inheritance In article <147qlkINNft3@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes: ! Now what if both PARENT_CLASS_ONE and PARENT_CLASS_TWO ! have two features, say integer variables "count": ! Then you can use "alias new_name old_name": ! =========== ! class CHILD is ! PARENT_CLASS_ONE; --- That inherits it ! alias count_one count; --- rename "count" from P_C_O ! PARENT_CLASS_TWO; --- That inherits another ! alias count_two count; --- Rename that one as well ! count : INT; --- A third "count" different from the ! --- other two. ! end; ! ============ ! I don't know if this solution is perfect for all circumstances, but it ! appears to a layman to cover a whole lot, and it's very easy to understand. You still have the problem that CHILD, PARENT_CLASS_ONE and PARENT_CLASS_TWO refer to the same 'count' each, unless you re-rewrite the functions in the parent classes. (In some cases this would be desirable, in others it would not.) The problem would be solved, if this were possible: 'rename count_two count'. -- ............................................................................... Ari Huttunen They say the sky high above 90-7285944 is Caribbean blue... (Enya) ======================================================================= 96 === Date: 20 Jul 92 09:04:02 GMT From: Ari.Huttunen@hut.fi (Ari Juhani Huttunen) Subject: Re: Sather's Multiple Inheritance >Eliot Moss: > Sounds to me as if > Sather flattens the types out completely, which will interfere with > building large system, by undermining encapsulation. Well said. That is my understanding also. But the front page of Sather manual says that large systems are not intended to be built with Sather. (No, I don't think it is a good policy either.) "Abstract. This report describes the object-oriented programming lan- guage Sather. Sather is a simplified, optimized variant of Eiffel (Sather tower is a landmark in Berkeley). It is meant to be a working language, focussed on the practical needs of writing efficient, reusable code. It is designed for individual researchers or small groups and eliminates fea- tures which are pedantic, of purely theoretical interest, or necessary only for large or naive programming teams. Sather has clean and sim- ple syntax, parameterized classes, object-oriented dispatch, multiple in- heritance, strong typing, and garbage collection. It generates efficient C code which is easily integrated with existing code. " Rockwell: >From what I read, you can get opacity by the simple expedient of >masking the detail you want hidden with a later namespace conflict. >You can see the names, but the original definitions are shadowed from >the point where you see those names. Kennel: >I don't know what quite you mean, but there's the "private" attribute: Let's consider a simple example: class FATHER is private xyz:INT; foobar is xyz := 123; end; -- foobar end; -- FATHER class CHILD is FATHER; alias father_xyz xyz; xyz:DOUBLE is res := 1.0; end; -- xyz end; -- CHILD When the 'foobar'-procedure is used on an object of type FATHER, it works correctly and assigns 123 to an integer 'xyz'. But when the foobar is used on an object of type CHILD, well, the compiler catches the error... (You cannot assign to a procedure.) The 'private' does not prevent redefinition of 'xyz' in CHILD. Also, the 'foobar' still uses the old name 'xyz' in CHILD, because the 'alias' does not change it. (But you can refer to the integer in CHILD by calling it 'father_xyz'.) (I ran the code through a Sather compiler.) >Though actually >in Sather you can manually find out the "type" of any random object: >( I guess the only allowed operations are equality and inequality on this. ) With the help of library classes you can test if one type is a subtype of another. -- ............................................................................... Ari Huttunen They say the sky high above 90-7285944 is Caribbean blue... (Enya) ======================================================================= 97 === Date: 21 Jul 92 15:10:44 GMT From: os102@cl.cam.ac.uk (Oliver Stephens) Subject: Shared Libraries under SunOS More stuff on shared libraries under SunOS : 1. You don't need the contents of lib.a if you have lib.so.* as programs are never linked with -Bstatic (at least I cannot think of any reason why they should). You do, however, need a file of that name for the driver to work correctly, so you can replace it with a zero-length file to save more disc space 2. Below are some m3make templates for creating shared libraries automatically. They give you two new directives : sharedLibrary(name) - equivalent of library(name) SharedLibrary(name) - equivalent of Library(name) There are three (at least) minor gotchas : A. If you have a lib.a but no lib.so.* then the driver won't bother to rebuild : solution - remove lib.a B. If the link fails (usually because some of the source files have not been compiled with a shared library target in mind) then the driver ignores it - this is because I replace the archive pass of the driver with a link pass, but the driver ignores the exit status of this pass : solution - remove all object files [m3make clean] before starting a shared library build C. If an installed lib.a already exists (from a previous ordinary library build) then it will not change to zero-length when you install the shared library - this is because I use 'touch' to create the file : solution - change it to a zero-length file by hand or delete it first (if you want the extra disk space) ---+--- The following should go in your $(LIB_USE)/toplevel.tmpl file ---+--- #ifdef TARGET_SPARC #define sharedLibrary(name) @@\ all:: lib##name.a @@\ clean:: ; rm -f lib##name.a lib##name.ax lib##name.so.1.1 @@\ lib##name.a: FRC; $(DO_M3) -X1@-PIC@ -Y3@$(LIB_USE)/ld-so@ -Y4@touch@ \ -a lib##name.a $(PGM_SOURCES) $(IMPORT_LIBS) #define SharedLibrary(name) @@\ install:: @@\ INSTALL (lib##name.so.1.1, $(LIB_INSTALL), 755) @@\ INSTALL (lib##name.ax, $(LIB_INSTALL), 644) @@\ touch $(LIB_INSTALL)/lib##name.a @@\ sharedLibrary(name) #else #define sharedLibrary(name) library(name) #define SharedLibrary(name) Library(name) #endif ---+--- And the following shell script should go in $(LIB_USE)/ld-so ---+--- #!/bin/csh -f # # ld-so : shared library linker for m3 # # (just a simple shell around /bin/ld which changes the arguments # so that shared libraries can be created - needed because I don't # have enough control over the commands the m3 driver issues) # # Olly Stephens (os102@cl.cam.ac.uk) - 20/7/92 # set argv[1]=-o # change 'cru' to '-o' set argv[2]=$2:r.so.1.1 # change .a to .so.1.1 /bin/ld -assert pure-text $* ---+--- ------------------------------------------------------------------------- Olly Stephens oliver.stephens@cl.cam.ac.uk Computer Laboratory University of Cambridge Loved you there and then, and now like a sheep United Kingdom - Van Morrison ======================================================================= 98 === Date: 21 Jul 1992 20:04:41 GMT From: mbk@lyapunov.ucsd.edu (Matt Kennel) Subject: Re: Sather's Multiple Inheritance Ari.Huttunen@hut.fi (Ari Juhani Huttunen) writes: : In article <147qlkINNft3@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel ) writes: : : ! Now what if both PARENT_CLASS_ONE and PARENT_CLASS_TWO : ! have two features, say integer variables "count": : : ! Then you can use "alias new_name old_name": : ! =========== : ! class CHILD is : : ! PARENT_CLASS_ONE; --- That inherits it : ! alias count_one count; --- rename "count" from P_C_O : ! PARENT_CLASS_TWO; --- That inherits another : ! alias count_two count; --- Rename that one as well : : ! count : INT; --- A third "count" different from the : ! --- other two. : : ! end; : ! ============ : : ! I don't know if this solution is perfect for all circumstances, but it : ! appears to a layman to cover a whole lot, and it's very easy to understand. : : You still have the problem that CHILD, PARENT_CLASS_ONE and PARENT_CLASS_TWO : refer to the same 'count' each, unless you re-rewrite the functions in : the parent classes. (In some cases this would be desirable, in others it : would not.) : : The problem would be solved, if this were possible: 'rename count_two count'. I think there's a bug in the compiler, actually. As you were, I wasn't able to override an integer feature (storage) with a procedure, but I was able to override that same integer feature with a feature of different type. ============================ class FATHER is private xyz:INT; foobar is xyz := 123; end; -- foobar end; -- FATHER class CHILDBAD is FATHER; alias father_xyz xyz; xyz:DOUBLE is res := 1.0; end; -- xyz end; -- CHILDBAD class CHILDGOOD is FATHER; alias father_xyz xyz; xyz:DOUBLE; end; -- CHILDGOOD class TEST is main is a:FATHER; a.foobar; b:CHILDGOOD; b.foobar; -- c:CHILDBAD; -- c.foobar; -- Compiler gives an error if you uncomment these lines! ??? -- end; end; =================================== : -- : ............................................................................. .. : Ari Huttunen They say the sky high above : 90-7285944 is Caribbean blue... (Enya) -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego ======================================================================= 99 === Date: 23 Jul 92 12:23:24 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: Re: Proposed langauge changes / MI In article 92Jul18115425@ibis.cs.umass.edu, moss@cs.umass.edu (Eliot Moss) writ es: >Peter suggests that if D inherits from B and C, then B and C must share a >common ancestor A. This condition is trivially satisfied - ROOT is the >anscestor of all OBJECT types. Peter, I think perhaps you have a different and >stronger condition in mind. Could you try to articulate it? I don't think >requiring B and C to have the same immediate ancestor is general enough, and I >think saying they have to have a common ancestor other than ROOT requires more >defense -- MI ought to allow one to combine completely orthogonal types if >that's useful, shouldn't it? Why is it wrong to do so? You seem to have a >style or idiom in mind that I have not been able to derive from what you've >said so far .... >-- > > 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 Excuse me for being unclear. (I obviously haven't had my best day when I wrote that article anyway :). Well, although you're questions seem to be a little bit rhetorical: yes, I actually meant *direct* subclasses. To put it in other words: I would agree to MI if it is restricted to very simple fork/join situations. Furthermore, I think that all data from the common superclass should be shared. If you want to combine orthogonal classes, you actually build the cartesian product of these classes. If I'm not completely wrong, this is exactly what RECORDs are good for. So, if B and C are independent, I would combine these using A = OBJECT b: B; c: C; END. I'm totally aware of the fact that this is a little bit awkward for the people used to MI from other languages, because you have to copy and merge B and C's interfaces to get an interface for A. But it *can* be done. On the other hand, if you have a (virtual in the C++ sense) superclass D and subclasses B and C from D, there is no way to simulate A = B, C OBJECT END with SI without loosing data hiding. So, my proposal is sort of a compromise. It prevents MI from getting too complicated - for the user as well as for the compiler/run time system. But I don't think it prohibits the essential point about MI. --- 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 ======================================================================= 100 === Date: Mon, 27 Jul 92 14:39:59 GMT From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) Subject: M3 and Solaris Well, the subject line almost says it: Will the current Sparc4 version of SRC M 3 run under Solaris? If not, will there be a Solaris port? --- 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 ======================================================================= 101 === Date: Mon, 27 Jul 92 23:04:37 GMT From: muller@src.dec.com (Eric Muller) Subject: Re: M3 2.03 - does not install -> help me, please In article <1992Jul27.210919.18395@Informatik.TU-Muenchen.DE>, kirschnt@Informa tik.TU-Muenchen.DE (Torsten R. Kirschner) writes: |> I had ftp'ed M3 2.03 when it was out and wanted to install it today, but |> I ran into this problem: [...] |> After decompressing and untar'ing all the files One possible explanation is that you did not grab boot.DS3100-2.03.tar.Z, or that its unpacking did not go well. (This is assuming that 2.03 was organized similarly to 2.07 - I can't remember if that is the case) In any case, you probably want to use 2.07 which is now available. -- Eric. ======================================================================= 102 === Date: Mon, 27 Jul 1992 21:09:19 GMT From: kirschnt@Informatik.TU-Muenchen.DE (Torsten R. Kirschner) Subject: M3 2.03 - does not install -> help me, please Dear Netfellows, I had ftp'ed M3 2.03 when it was out and wanted to install it today, but I ran into this problem: After decompressing and untar'ing all the files and setting them up under /usr/local/src/m3 I created the correct m3make/config/config file and ran (cd m3make ; make all install ). But when I want to run m3make build_boot, I get the following error: > /usr/local/src/m3 508 # m3make build_boot > cd driver/boot-DS3100; m3make -DBOOT > sh: driver/boot-DS3100: bad directory > *** Error code 1 > > Stop. And he's right there. There simply is no directory driver/boot-DS3100, only an empty driver/DS3100. Do I need additional files or did I miss a point to install M3? I would be very happy if someone working with M3 could give me a hint on how to get M3 installed. Thanks in advance. Torsten -- Torsten R. Kirschner DOMAIN: torki@mpipf-muenchen.mpg.dbp.de Christoph-Probst-Str. 8/818 FAX: +49 89 342473 8000 Muenchen 40 HOME: +49 89 3234102 Deutschland X.400: /C=de/ADMD=dbp/PRMD=mpg/O=mpipf-muenchen/s="torki" ======================================================================= 103 === Date: Tue, 28 Jul 1992 05:13:47 +0200 From: "Torsten R. Kirschner" Subject: Re: M3 2.03 - does not install -> help me, please In article <1992Jul27.230437.23288@src.dec.com> you write: >In article <1992Jul27.210919.18395@Informatik.TU-Muenchen.DE>, kirschnt@Inform atik.TU-Muenchen.DE (Torsten R. Kirschner) writes: > >|> I had ftp'ed M3 2.03 when it was out and wanted to install it today, but >|> I ran into this problem: >[...] >|> After decompressing and untar'ing all the files > >One possible explanation is that you did not grab >boot.DS3100-2.03.tar.Z, or that its unpacking did not go well. (This >is assuming that 2.03 was organized similarly to 2.07 - I can't >remember if that is the case) > >In any case, you probably want to use 2.07 which is now available. > >-- >Eric. Dear Eric, thank You for Your information. As I currently lack FTP access (my institution goes for the OSI stack) it could take me some time to get it, but I'll have to do it anyway, I guess. Yours thankfully Torsten -- Torsten R. Kirschner DOMAIN: torki@mpipf-muenchen.mpg.dbp.de Christoph-Probst-Str. 8/818 FAX: +49 89 342473 8000 Muenchen 40 HOME: +49 89 3234102 Deutschland X.400: /C=de/ADMD=dbp/PRMD=mpg/O=mpipf-muenchen/s="torki" ======================================================================= 104 === Date: 28 Jul 92 14:53:04 GMT From: Steve.Freeman@cl.cam.ac.uk (Steve Freeman on ely.cl.cam.ac.uk) Subject: SIGPIPE raised during file IO I've found that, running under SunOS, if a connection such as a pipe or socket is broken a SIGPIPE is raised at the next write and the whole process dies. Shouldn't this be managed by the UFileRdWr library, perhaps a SIG_IGN set? Steve - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Steve Freeman, Computer Lab, University of Cambridge, UK Steve.Freeman@computer-lab.cambridge.ac.uk ======================================================================= 105 === Date: 27 Jul 92 09:09:55 GMT From: olm@daimi.aau.dk (Ole Lehrmann Madsen) Subject: ECOOP'92 proceedings I have been asked about how to get the proceedings of ECOOP'92. Here is the reference: O. Lehrmann Madsen (Ed.) ECOOP'92, European Conference on Object-Oriented Programming Utrecht, The Netherlands, June/July 1992, Proceedings Lecture Notes in Computer Science 615 ISBN 3-540-55668-0 Springer Verlag Berlin Heidelberg New York ISBN 0-387-55668-0 Springer Verlag New York Berlin Heidelberg ---olm ======================================================================= 106 === Date: Wed, 29 Jul 1992 20:56:35 GMT From: dave@kanga.lcs.mit.edu (David Sternlicht) Subject: trestle -- Has anybody built trestle with X11R5? dave sternlicht mit X consortium dave@expo.lcs.mit.edu ======================================================================= 107 === Date: Thu, 30 Jul 92 08:41:01 +0200 From: a.vermeulen@ECN.NL (Vermeulen A.T.) Subject: Re: trestle > Has anybody built trestle with X11R5? Yes, I did, no problems at all. I use the X11R5-library on a Sun IPX under SunOS 4.1.1. running OpenWindows 2.0. -- Netherlands Energy Research Foundation Email: a.vermeulen@ecn.nl P.O. Box 1 Phone: (+31) 2246 4194 1755 ZG Petten, The Netherlands ======================================================================= 108 === Date: Thu, 30 Jul 1992 01:12:06 GMT From: dave@kanga.lcs.mit.edu (David Sternlicht) Subject: trestle... ------------------------------------------------------------ Hello again modula-3 people! I pulled the m3 X11R4 package off gatekeeper and incanted: m3make -f m3makefile.X11R4 all install on it (even though I have r5 installed...) This allowed me to sucessfully do: m3make -f m3makefile.trestle all install Great! Now I go to trestle/apps and say: m3make Hello and I get the following... /usr/local/bin/m3 -w1 -make -why -g -D../src/xvbtm3:../src/vbtm3:../src/splitm3 :../src/trestlem3 -commands -o Hello Hello.m3 ../mips/libm3ui.a -lm3X11R4 -l X11 inhale ../mips/libm3ui.a inhale /usr/local/lib/m3/libm3X11R4.a inhale -lX11 inhale /usr/local/lib/m3/libm3.a inhale -lm program missing -> link Hello missing interface "Trestle" imported by: Hello.m3 missing interface "TextVBT" imported by: Hello.m3 Fatal Error: incomplete program Fatal Error: incomplete program *** Error code 255 make: Fatal error: Command failed for target `Hello' could some kind person tell me what I did wrong? I found latex documentation but so far, no man pages for the compiler... ------------------------------------------------------------ dave sternlicht mit X consortium dave@expo.lcs.mit.edu ======================================================================= 109 === Date: Thu, 30 Jul 92 03:01:16 GMT From: muller@src.dec.com (Eric Muller) Subject: Re: trestle... Unfortunately, the m3makefile in trestle/apps is not portable. You need to edit it and replace "mips" by the name of your architecture (DS3100, SPARC, whatever). I'll try to make things better for the next release. Sorry for the trouble. Also, X11R5 should be fine; isn't it compatible with X11R4 clients ? -- Eric. ======================================================================= 110 === Date: Thu, 30 Jul 1992 10:10:50 GMT From: ddean@sapphire.risc.uni-linz.ac.at (Drew Dean) Subject: Building SRC M3-2.07 on a NeXT I'm having trouble building 2.07 on a NeXT running NeXT's 2.2 OS. The compiler built fine, but I can't build libm3. First problem was that dirname is missing, but I wrote it in C (:-() after consulting an Ultrix system. Now, however, I get the following in response to a m3make -f m3makefile.libm3: Make: Don't know how to make /M3Config.m3. Stop. Ok, so something somewhere is inserting a space where there shouldn't be one...But if I hand tweak the .makefile to get around this, the compiler then dies (sorry, I don't remember the exact error, but it's a seg fault or something similar). I'm interested in Modula-3, but I can't really good a grip on the language until the compiler works... :-) Thanks, Drew Dean ddean@risc.uni-linz.ac.at My opinions, not RISC's. ======================================================================= 111 === Date: Thu, 30 Jul 1992 13:07:50 GMT From: dave@kanga.lcs.mit.edu (David Sternlicht) Subject: trestle Thankyou for all the help I recieved in getting my trestle apps to work. My primary interest at this point is in multithreading a c++ toolkit for adoption as an X Consortium standard. Evidently the modula-3/trestle community is a little further ahead in mt user interface toolkits than I am so I wish to learn... Being a newcommer to this list I would be interested in who is doing industrial or academic code development work with trestle and maby a little about there applications. This news group is sure alot easier to foll ow than comp.lang.c++ :-) -- dave sternlicht mit X consortium dave@expo.lcs.mit.edu ======================================================================= 112 === Date: Tue, 28 Jul 1992 11:46:12 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: The HP 'snake' Er, I know I posted about this before, but some folks here are starting to press me about it. How's the status on the HP9000/720 port of SRC-m3? I remember we had to wait on a major overhaul of the Thread implementation, but wasn't that done in 2.07? So how about it? Need any help on it? Greetings, Bert -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null ======================================================================= 113 === Date: Thu, 30 Jul 92 19:18:55 GMT From: muller@src.dec.com (Eric Muller) Subject: Re: M3 2.07 Compiler/Trestle/HP 9000s300 problem In article , dg@dgupta.hpl.hp.com (Dipankar Gupta) writes: |> I have a problem with compiling trestle from the 2.07 distribution on |> an HP 9k/3xx running HPUX 8.0. The compiler barfs: The lines in question look simple to me, so it is probably something more complex than just big expressions. You should get in touch with HP people to find out if their C compiler has been fixed. |> Could it be due to my having compiled |> the driver with -O (full optimisation) on the HP C compiler? It is the C compiler that is complaining. Optimization of the driver or the Modula-3 compiler does not change the C produced, hence should have no effect. -- Eric. ======================================================================= 114 === Date: Thu, 30 Jul 92 18:49:07 GMT From: muller@src.dec.com (Eric Muller) Subject: help with Umman.i3 I wrote the interface Umman, which is supposed to capture the /usr/include/sys/mman.h header file. I have a version for DECstation and VAX runing Ultrix, and a version for DEC OSF/1 (see below). If somebody could send me the versions for the other platforms, it would be great. Thanks for your help, Eric. (* Copyright (C) 1992, Digital Equipment Corporation *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* *) (* Last modified on Thu Jul 30 11:49:02 PDT 1992 by muller *) INTERFACE Umman; (* DS3100, VAX *) FROM Ctypes IMPORT int; FROM Utypes IMPORT caddr_t, size_t, off_t; (*** sys/mman.h ***) CONST PROT_READ = 16_1; PROT_WRITE = 16_2; PROT_EXEC = 16_4; MAP_SHARED = 1; MAP_PRIVATE = 2; MAP_FIXED = 16_100; MADV_NORMAL = 0; MADV_RANDOM = 1; MADV_SEQUENTIAL = 2; MADV_WILLNEED = 3; MADV_DONTNEED = 4; <*EXTERNAL*> PROCEDURE mmap (addr: caddr_t; len: size_t; prot,flags,fd: int; off: off_t): caddr_t; <*EXTERNAL*> PROCEDURE munmap (addr: caddr_t; len: size_t): caddr_t; <*EXTERNAL*> PROCEDURE mprotect (addr: caddr_t; len, prot: int): int; END Umman. (* Copyright (C) 1992, Digital Equipment Corporation *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* *) INTERFACE Umman; (* DEC OSF/1 *) FROM Ctypes IMPORT int; FROM Utypes IMPORT caddr_t, size_t, off_t; (*** sys/mman.h ***) CONST PROT_NONE = 0; PROT_READ = 16_1; PROT_WRITE = 16_2; PROT_EXEC = 16_4; MAP_SHARED = 1; MAP_PRIVATE = 2; MAP_FILE = 16_00; MAP_ANONYMOUS = 16_10; MAP_ANON = 16_10; MAP_TYPE = 16_F0; MAP_FIXED = 16_100; MAP_VARIABLE = 16_00 MAP_HASSEMAPHORE = 16_0200; MAP_INHERIT = 16_0400; MAP_UNALIGNED = 16_0800; MADV_NORMAL = 0; MADV_RANDOM = 1; MADV_SEQUENTIAL = 2; MADV_WILLNEED = 3; MADV_DONTNEED = 4; MADV_SPACEAVAIL = 5; TYPE msemaphore = RECORD msem_state: int; msem_wanted: int; END; msemaphore_star = UNTRACED REF msemaphore; CONST MSEM_UNLOCKED = 0; MSEM_LOCKED = 1; MSEM_IF_NOWAIT = 2; MSEM_IF_WAITERS = 3; MS_ASYNC = 1; MS_SYNC = 3; MS_INVALIDATE = 4; <*EXTERNAL*> PROCEDURE madvise (addr: caddr_t; len: size_t; behav: int): int; <*EXTERNAL*> PROCEDURE mmap (addr: caddr_t; len: size_t; prot,flags,fd: int; off: off_t) : caddr_t; <*EXTERNAL*> PROCEDURE msync (addr: caddr_t; len: size_t; flags: int): int; <*EXTERNAL*> PROCEDURE munmap (addr: caddr_t; len: size_t): int; <*EXTERNAL*> PROCEDURE mprotect (addr: caddr_t; len: size_t; prot: int): int; <*EXTERNAL*> PROCEDURE mvalid (addr: caddr_t; len: size_t; prot: int): int; <*EXTERNAL*> PROCEDURE msem_init (sem: msemaphore_star; initial_value: int); <*EXTERNAL*> PROCEDURE msem_lock (sem: msemaphore_star; condition: int): int; <*EXTERNAL*> PROCEDURE msem_remove (sem: msemaphore_star): int; <*EXTERNAL*> PROCEDURE msem_unlock (sem: msemapore_star; condition: int): int; (* shm_open and shm_unlink have no man pages *) END Umman. -- Eric. ======================================================================= 115 === Date: 30 Jul 92 16:18:08 GMT From: dg@dgupta.hpl.hp.com (Dipankar Gupta) Subject: M3 2.07 Compiler/Trestle/HP 9000s300 problem I have a problem with compiling trestle from the 2.07 distribution on an HP 9k/3xx running HPUX 8.0. The compiler barfs: dgupta.hpl.1675> m3make -f m3makefile.trestle cd trestle; /users/dg/bin/m3make all ============================= Building in HP300 /users/dg/bin/m3 -w1 -make -why -O -a libm3ui.a -F.PGM_SOURCES -lm3X1 1R4 new source -> compile ../src/splitm3/TranslateVBT.m3 "TranslateVBT.m3", line 47: compiler error: register allocation error new source -> compile ../src/splitm3/RigidVBT.m3 "RigidVBT.m3", line 28: compiler error: register allocation error new source -> compile ../src/xvbtm3/XClient.m3 "XClient.m3"verflow, line 755: compiler error: register allocation error compilation failed => not building library "libm3ui.a" Anyone else have this problem? Could it be due to my having compiled the driver with -O (full optimisation) on the HP C compiler? Thanks muchly, Dipankar Gupta HPLabs Bristol UK dg@hplb.hpl.hp.com -- -- ======================================================================= 116 === Date: Fri, 31 Jul 92 06:34:08 PDT From: bates@salm04.boeing.com Subject: Language definition ambiguity I am reading the latest M3 language definition in the August SIGPLAN. Section 3.2 says: "For a VAR parameter, the actual must be a writable designator whose type is the same as that of the formal, or, in case of a VAR array parameter, assignable to that of the formal." I first parsed this to mean: "in case of a VAR array parameter, the actual's type must be assignable to the type of the formal." Looking at the definitions of assignability of types to types, of subtypes, and specializing to arrays, this would allow an open array actual to be passed to a fixed array formal without a shape check, which isn't safe. So, a reread gave me this alternate interpretation: "in case of a VAR array parameter, the actual must be assignable to the type of the formal." This invokes assignability of an expression to a type, which includes the shape check. I presume this is the right interpretation. I think the English is ambiguous, or possibly even misleading, since we don't know if the implied parallel text before "assignable" is "a writable designator whose type is" or "a writable designator .. (which) is" Rodney M. Bates Boeing P.O. Box 7730, MS K80-13 Wichita, KS 67277-7730 316-523-2015 bates@awsil4.boeing.com ======================================================================= 117 === Date: Fri, 31 Jul 1992 21:53:53 GMT From: andru@meson.lcs.mit.edu (Andrew Myers) Subject: m3process - new version available This is essentially the same program previously advertised, but with many minor tweaks and improvements. It converts "M3SU", which is "Modula-3 without Semicolons and required Uppercase keywords", into Modula-3. It does syntax-checking on M3SU, so you receive rapid feedback on syntactic errors. m3make support is included. Send me mail if you want a copy. Andrew