======================================================================= 1 === Date: Wed, 1 Apr 92 08:03:16 EST From: wyant@centerline.com Subject: email address for requesting Trestle report ? Is there an email address from which the the Trestle report can be requested ? thanks, Geoff Geoff Wyant wyant@centerline.com Centerline Software, Inc. (Formerly Saber Software, Inc) 10 Fawcett Street Cambridge, Ma. 02137 ======================================================================= 2 === Date: Wed, 1 Apr 92 15:43:17 PST From: msm@src.dec.com (Mark S. Manasse) Subject: Re: email address for requesting Trestle report ? Send mail to src-report@src.dec.com asking for report #68, the Trestle Reference Manual. Mark ======================================================================= 3 === Date: 29 Mar 92 16:35:24 From: vixie@pa.dec.com (Paul A Vixie) Subject: Re: are Modula-3 records redundant? A record has the option of existing directly, being passed by value, and so on. Objects exist only by reference. There's not much difference in actual perfor- mance between the two, but certainly if you're just trying to aggregate some variables together or you need substructures in an Object, you'd use a Record. -- Paul Vixie, DEC Network Systems Lab Palo Alto, California, USA "Ready, Fire, Aim" decwrl!vixie vixie!paul ======================================================================= 4 === Date: 30 Mar 92 16:18:28 GMT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: Comments on Modula 3 Books I just got a copy of the Book "Modula 3" by Sam Harbison and read it over the weekend. It is clear and concise and contains a good number of examples. The targeted audience is rather wide as it can be used for a first programming language, replacing something like Introduction to Pascal. Because of that, i feared that i would get bored. However, the first 2 or 3 chapters are quickly over and, because of the language simplicity, you rapidly become involved with interesting features like interfaces and modules all the way to threads. I found the progression interesting and natural as new elements were smoothly introduced from chapter to chapter. It does not replace Systems Programming with Modula 3 which contains the precise language reference and discussions about Trestle, Larch specification language and discusses some of the choices made while designing Modula 3. In summary, i am happy to have both books on my shelves (eventually when i finish lending them to other people). Students for graduate and undergraduate projects in Modula 3 will probably want to buy "Modula 3". Some of them will want to dig further and read "Systems programming with Modula 3". This 266 pages (plus appendix) book is easy to read yet keeps a good pace and goes further (threads) than equivalent 600+ pages books on C++. A good part of the credit goes to the language itself but the author certainly deserves some as well! Final verdict: among the 10% best written books on this kind of topic. Disclaimer: i have no ties with the author other than the fact that we both subscribe to comp.lang.modula3 :-) -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 5 === Date: 29 Mar 92 22:20:44 GMT From: n8243274@gonzo.cc.wwu.edu (steven l. odegard) Subject: are Modula-3 records redundant? A Styleist's question: I see the recommendation that objects be used instead of records to allow for possible future expansions. If record types are functionally equivalent to methodless object types, does the need for records remain? How should I include record types in the coding design? ======================================================================= 6 === Date: Mon, 30 Mar 1992 08:19:24 GMT From: mathew@elroy.jpl.nasa.gov (Mathew Yeates) Subject: SRC tests on SparcStation When I try and compile the ptests given with SRC compiler I get strange behavior.After building libtest.a and cd' ing to p001_X I type (I'm attempting to mimic the m3makefile) m3 -g -w1 -D../.. -debug -v -o pgm ../base.b ../p001 and get using ../base.b (Note: base.b was built in a preceeding step) Looking in ../p001/ Looking in ../p001// Looking in ../p001/// Looking in ../p001//// ad infinitum. 1) Shouldnt the compiler quit at some point instead of just hanging? 2) What do the above debug statements indicate? WHATS GOING ON? -Mathew Yeates ======================================================================= 7 === Date: 27 Mar 92 19:10:14 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Errata list for book "Modula-3" It is time for one of the author's least-loved task--the publishing of the errata sheet. FYI, when an author discovers an error he or she ships the change off to the publisher, who stores it until time for the next printing. Corrections have a cost (in time and money), so cosmetic problems and problems that aren't likely to confuse the reader typically don't get corrected, unless they are lewd or embarassing or they occur on a page that is changed for some other reason. Anyway, here are ALL the problems I know of. Thanks to those of you reporting problems, and feel free to report more. (Compliments are accepted also, of course.) Errata list for "Modula-3", by S. P. Harbison, Prentice Hall, 1992. As of: March 27, 1992. Page Line Description ---- ----- ------------------------------------------------------ 1 -4 Change "it easy" to "it is easy".--> 2 3 -6 Change "MODULE Main" to "MODULE Hello1 EXPORTS Main".--> 2 3 -1 Change "END Main" to "END Hello1".--> 2 5 -13 Change "MODULEHello1" to "MODULE Hello1".--> 2 5 -5 Change "MODULE Main" to "MODULE Hello1 EXPORTS Main".--> 2 5 -4 Change "END Main" to "END Hello1".--> 2 8 7 Change "Hello, World!" to "Hello, World!\n"--> 2 8 Swap positions of Example 1-4 and Figure 1-3.--> 2 10 -4 Rewrite last paragraph; mention left-associativity.--> 2 20 -5 Mention that loop variable i is declared in FOR statement.--> 2 20 Swap positions of Box and Example 2-5.--> 2 32 1 Add space before "By".--> 2 32 6 Change "n := n" to "n := BITSIZE(n)"--> 2 32 7 Add "because the result type of BITSIZE is always CARDINAL."--> 2 33 -4 Add missing ")" at end of declaration.--> 2 33 -5 Add missing ")" at end of declaration.--> 2 33 8 Fix typeface of exercise 4d.--> 2 38 -17 Change "a,pos" to "a, pos".--> none 43 5 Modula-2 requires "()" in function calls, but not proper procedure calls.--> 49 8 "Solution" should be boldface.--> none 50 1 In box, keywords should not be boldface.--> none 57 -9 Rephrase as: "Which of the three versions is more readable?"--> 2 57 -5 Change "page 49" to "page 50".--> 2 64 -10 -8 MOD 3 is 1, not -1--> 2 64 -5 x MOD 2 is 1 if x is odd; it cannot be -1--> 2 67 19 Change "volume : [0..10]" to "volume: [0..10]".--> none 74 -4 Add: The type of FIRST and LAST is the base type of T.--> 2 74 -4 Add: The type of NUMBER is CARDINAL.--> 2 74 -3 Add: "and has type T" to example of FIRST and LAST.--> 2 111 6 Change "Point, the" to "Point (page 107), the".--> 2 111 -6 Change "SET OF t" to "SET OF T".--> 2 112 -5 Change "CARDINALITY" to "Cardinality".--> none 112 -2 Identifiers in italics should be in the program typeface.--> none 113 3 Change ":=" to "=".--> 2 129 1 Remove "[A]".--> 2 129 -3 Add "(or LAST(CARDINAL) if the array is empty)" before ":".--> 2 129 -10 Change "the procedure" to "ForAllElements".--> 2 141 18 Change "in procedure Forever" to "in the procedure".--> 2 141 -14 Change "ELSE =>" to "ELSE".--> 2 141 -9 Change "Chapter 12 (Threads)" to "Chapter 12".--> 2 168 1 In box, keyword "END" should not be boldface--> none 214 Add "RETURN self" to InitPostion and InitRectangle.--> 2 214 -19 Editorial changes to paragraph "The Rectangle.init method...".--> 2 218 Add "RETURN self" to InitPosition and InitRectangle.--> 2 219 Add "RETURN self" to InitCircle.--> 2 219 -8 Editorial changes to last paragraph--> 2 226 -7 Change typeface of "Child".--> none 227 8 Mention that untraced things are discussed in 13.2 on p. 258.--> 2 227 -6 Change typeface of "name".--> 2 234 Change "94681" to "94861" (four times).--> 2 299 7 The answer to D.1.5(c) is 11, not 3.--> 2 300 8 Change "a := y" to "b := y".--> 2 300 -16 Change all "A" and "B" to "a" and "b" in answer to exercise 9.--> 2 300 -11 Delete procedure heading; the solution is a block statement.--> 2 305 Correct typeface of leading entry in letter groups as necessary.--> none 305 Add "Alerted (Thread)" to the index (cite p. 250)--> ---------- Line n means the n'th line from the top of the page Line -n means the n'th line from the bottom of the page "--> n" means the correction should appear in the n'th printing "--> none" means the correction won't be made in the book unless the page is corrected for some other reason "--> (blank)" means no decision has been made on making the correction ---------- Please send all comments and corrections to harbison@bert.pinecreek.com. Sam Harbison Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. ======================================================================= 8 === Date: 27 Mar 92 14:05:58 GMT From: bruce@utafll.uta.edu (Bruce Samuelson) Subject: Modula-3 vs Eiffel I have a naive question as a Smalltalk programmer who hasn't used either of these languages. Eiffel has some nice software engineering constructs but is struggling to establish a commercial beachhead in the face of the C++ juggernaut. Modula-3 resembles Eiffel but is in an earlier stage of free availability and intellectual ferment. What features of Modula-3 make it more desirable than Eiffel, and do you envision its becoming a viable commercial language some day? I'm not trying to start a language war at all, but just trying to satisfy my curiosity. -- ********************************************************** * Bruce Samuelson Department of Linguistics * * bruce@ling.uta.edu University of Texas at Arlington * ********************************************************** ======================================================================= 9 === Date: Fri, 27 Mar 1992 21:01:52 GMT From: mathew@elroy.jpl.nasa.gov (Mathew Yeates) Subject: Problems on a SparcStation Anyone with any experience using the SRC Modula 3 on a Sun SparcStation? I'm a C++ refugee checking out modula3 and know very little about the language. However, I installed the SRC compiler and tried to run their demos. Heres what happened. Solitaire crashes my window manager (olwm). Tetris dumped core. I traced the problem to a bad return of Uutmp.getlogin in Main.m3. I fixed the problem by setting the environment variable TETRIS so the above function would not be called. After this it worked okay. How do you use dbx on this stuff. I compiled with -keep so I would have the c files still around but dbx complains about not being able to find the files(actually, its looking for foo_m.c instead of foo.mc) This is SunOs 4.1.2, openwindows 3.0, olwm. Also, I had to link the X libs statically by compiling with -X2@-Bstatic@ because Sun's patched loader is a piece of crap. Anybody?? -Mathew Yeates ======================================================================= 10 === Date: 27 Mar 92 22:06:12 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Scan.i3 suggestions First, I'd like Scan (and Fmt) to have "Extended" procedures to go with "Real" and "LongReal". I like to suggest to people that they use "Extended" routinely, but the lack of runtime routines makes it difficult to do this. Math.i3 is another problem... Next, I discovered that Scan.LongReal(t) and Scan.Real(t) pick off whatever initial prefix of t seems to make up a number and return it. They happily accept stuff like "0.1.2.3" (returns 0.1) and "1eee4" (returns 1). Here's why this is Inconvenient: It's very cumbersome to test if an ASCII floating-point number is correctly formatted, although it's easy to separate out a string of digits and other characters that might be part of a floating-point number. What you'd like to do is pick a candidate and let Scan.LongReal do the final test and conversion, e.g., TRY x := Scan.LongReal(t); (* It was OK *) ... EXCEPT | Scan.BadFormat => (* whoops, not formatted correctly *) ... END This won't work in the current implementation, but it's easy to fix. The lower-level Convert module tells you how many characters were converted. In the Scan.Real and Scan.LongReal routines, the test-for-failure IF used = 0 THEN ... can be changed to IF used # NUMBER(x^) THEN ... Also, Scan.Real/Scan.LongReal treat the exception Convert.Failed as a fatal error. I don't see any reason not to turn that exception into Scan.BadFormat. Sam Harbison Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. ======================================================================= 11 === Date: 26 Mar 92 22:19:44 GMT From: adam@visix.com Subject: Re: Modula-3, Fortran, Numbers & Aliens In article <1992Mar24.061919.21496@yrloc.ipsa.reuter.COM>, rbe@yrloc.ipsa.reute r.COM (Robert Bernecky) writes: |> In article <1992Mar20.154100.1603@visix.com> adam@visix.com writes: |> >The point is, arguments of generality don't cut it with people who |> >never have to deal with the extra cases. If all they do is limited |> >to a particular domain, then all they want is a notation that fits |> >that domain. |> > |> >Is that wrong? |> Well, no, it isn't wrong. |> |> BUT, it does mean that they don't tend to think about ideas like: |> (examples elided)... as ALL being minor variations on the SAME idea... Agreed, they don't think that way. Again, the point is that they never have to. |> I don't see how sigma and pi notation are easier, You don't agree that using something you already know is easier than learning something new? |> except for the braindead who are unable to learn anything new. Is this really necessary? |> The insert notation |> is easier to teach to children(not sure about grad students and doddering |> professors) But we are not discussing better notations for teaching children. |> and is consistent, as well as generalizing to ANY function. Again, arguments of generality don't cut it with people who never have to deal with the extra cases. Adam ======================================================================= 12 === Date: Fri, 27 Mar 1992 14:51:28 GMT From: lowry@watson.ibm.com (Andy Lowry) Subject: Re: Checking Subtype relationships. In article chased@rbbb.Eng.Sun.COM (David Cha se) writes: I heard that there was some paper (in TOPLAS, I think, last year or two) on efficiently performing lattice operations that might be of some help here. That's all I know for now -- I have't had time to get to it. David Chase Sun @article{aitkaci89a.B, author={A\"it-Kaci, Hassan and Robert Boyer and Patrick Lincoln and Roger Nasr}, title={Efficient Implementation of Lattice Operations}, month=jan, year=1989, journal=toplas, pages={115-146}, volume=11, number=1 } -- Andy Lowry, lowry@watson.ibm.com, (914) 784-7925 IBM Research, P.O. Box 704, Yorktown Heights, NY 10598 ======================================================================= 13 === Date: Sat, 28 Mar 1992 01:24:11 GMT From: melling@cs.psu.edu (Michael D Mellinger) Subject: Re: why modula3? In article chased@rbbb.Eng.Sun.COM (David Cha se) writes: VERBOSE UPPERCASE IDENTIFIERS. Will this be "fixed"? My fingers bother me enough as it is without having to reach for the shift key all the time. -Mike ======================================================================= 14 === Date: Fri, 27 Mar 1992 21:11:06 GMT From: mathew@elroy.jpl.nasa.gov (Mathew Yeates) Subject: why modula3? While I'm at it...... I'm interested in the relative advantages and disadvantages of C++ versus Modula3. I'm an applications programmer so my concern is not with the aesthetics of the language. Rather, I want something thats going to help me quickly write applications. Also, should I even be attempting this on a Sun SparcStation? The SRC Modula3 compiler demo programs dumped core or crashed my window manager. (Version 2.04). -Mathew ======================================================================= 15 === Date: 26 Mar 92 08:59:42 GMT From: ske@pkmab.se (Kristoffer Eriksson) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article <1992Mar25.004218.12233@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: > And, in fact, new notations are invented by every other >author in these fields - and the best of these notations survive. Why do you think it is the _best_ notation that survives? I would think that is far from obvious. -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcsun}!mail.swip.net!kullmar!pkmab!ske ======================================================================= 16 === Date: 27 Mar 92 14:06:42 GMT From: collberg@dna.lth.se (Christian S. Collberg) Subject: Subtype checking. Thanks to those who responded to my query. Here are the relevant references: @CONFERENCE{Dietz82, AUTHOR = "Paul F. Dietz", TITLE = "Maintaining Order in a Linked List", BOOKTITLE = "Proceedings of the 14th Annual ACM Symposium on Theory of Computing", ADDRESS = "San Francisco, California, PAGES = {122--127}, MONTH = may, YEAR = 1982 } @ARTICLE{Cohen91, AUTHOR = "Norman H. Cohen", TITLE = "Type-Extension Type Tests Can Be Performed in Constant Time", JOURNAL = "Transactions on Programming Languages and Systems", VOLUME = 13, NUMBER = 4, PAGES = {626--629}, MONTH = oct, YEAR = 1991 } -- Christian.Collberg@dna.lth.se Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden ======================================================================= 17 === Date: 28 Mar 92 01:05:51 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: why modula3? In article mathew@elroy.jpl.nasa.gov (Mathew Yeates) w rites: >While I'm at it...... >I'm interested in the relative advantages and disadvantages of >C++ versus Modula3. I'm an applications programmer so my concern >is not with the aesthetics of the language. Rather, I want >something thats going to help me quickly write applications. Advantages of C++: Everyone else is doing it. It looks a lot like C, so if you already know C, you should be somewhat happy for a little while. It takes fewer keystrokes to type in your programs. It has multiple inheritance. It has templates. It has exception handling. It has operator overloading. Disadvantages of C++: It is easier to write programs than it is to read them. No garbage collection (yes, I know I can implement a garbage collection class. I'm not interested in Turing-equivalence.) No thread support. No run-time type system (yet). I haven't found a use for multiple inheritance in 2 years of programming in C++. Templates are not widely implemented (yet). Exception handling is not widely implemented (yet), and asynchronous exceptions are not supported. Use of longjmp is also banned. C++ lacks a clean split between interface and implementation; all else being equal, this makes it more difficult to write tools to manipulate programs. Many of the recent extensions don't mesh well with the rest of the language (for example, template syntax). Advantages of Modula-3: Programs tend to be more readable. It has garbage collection. It has threads. It has exception handling. It has generic modules. It has a run-time type system. It has checking for array accesses and base-to-derived type conversions. It has nested functions. It is pretty easy to write tools to manipulate Modula-3 programs. Opaque supertypes allow you to avoid gratuitous recompilations. Nifty tools are available now (e.g., pickling). Disadvantages of Modula-3: Insufficient bandwagon. VERBOSE UPPERCASE IDENTIFIERS. It lacks multiple inheritance. I think that's a not-too-biased comparison. My opinion (removing all pretense of objectivity) is that C++ is one of the worst languages I've ever come across. It is *possible* to write good code in C++, but it is *easy* to write terrible code in C++, and features already present in the language will make it difficult to support truly useful features like garbage collection. Many of the techniques proposed for doing "automatic" garbage collection in C++ (e.g., reference counting) fall to pieces in a multi-threaded world. I'm not too fond of the exception handling model either -- no asynchronous exceptions (easy to implement, but not quite what people want in practice), but the dispatcher must implement "typecase" for multiple-inheritance class types. This is rarely useful (in full MI generality) but is a pain to implement. Multiple inheritance seems to be the source of many implementation problems, actually. David Chase Sun ======================================================================= 18 === Date: 27 Mar 92 15:40:16 GMT From: jm13@GTE.COM (Joe Morrison) Subject: Pkl.Write generates ASSERT failure (M3 2.03 on sparcstation) The following program (taken from pg. 81 of SPwM3) compiles without error on our system, but when executed, produces the error message shown below. Apart from this problem with pickles, our M3 installation seems fine (we've written, compiled and tested plenty of pickle-free code...) Is this any kind of known problem? Might it be fixed in 2.04? Thanks in advance... Joe Morrison -- GTE Laboratories Incorporated Email: jmorrison@gte.com 40 Sylvan Road Phone: (617) 466-2614 Waltham, Massachusetts, 02254 -------------------------------------------------- MODULE P1 EXPORTS Main; IMPORT Pkl, FileStream, Wr, Thread; TYPE T = REF RECORD val: INTEGER END; VAR r := NEW (T, val:=6); wr := FileStream.OpenWrite ("A.pickle"); <*FATAL Wr.Failure, Pkl.Error, Thread.Alerted *> BEGIN Pkl.Write (r, wr); Wr.Close (wr); END P1. -------------------------------------------------- When executed: -------------------------------------------------- *** runtime error: ASSERT failed *** Quit (core dumped) -------------------------------------------------- Here is the stack backtrace: (gdb) where #0 0xf775c120 in ?? () #1 0x10dfc in RTMisc__FatalError (msgA=(char *) 0x56634 , msgB=(char *) 0x0, m sgC=(char *) 0x0) (RTMisc.m3 line 95) #2 0x10f44 in RTMisc__AssertFault () (RTMisc.m3 line 121) #3 0x16ee0 in RTTypeFP__Init () (RTTypeFP.m3 line 176) #4 0x15f6c in RTTypeFP__ToFingerprint (tc=108, _return=(struct _array_tbd06c37 7 *) 0xf7fff91c) (RTTypeFP.m3 line 55) #5 0x381d8 in PklWrite__WriteTypes (s=(_t8feaadfc) 0x65a90) (PklWrite.m3 line 303) #6 0x35608 in Pkl__Write (r=(char *) 0x65a58 , wr=(char *) 0x65a60 , lg2maxObj s=14) (PklWrite.m3 line 96) #7 0x242c in _init_ () (p1.m3 line 14) #8 0x174a0 in RTMain__Run () (RTMain.m3 line 60) #9 0x22f8 in main (argc=1, argv=(_td88ff127) 0xf7fffbd4, envp=(_td88ff127) 0xf 7fffbdc) (_m3main.c line 1473) (gdb) ======================================================================= 19 === Date: Thu, 2 Apr 92 12:52:03 PST From: mjordan@src.dec.com (Mick Jordan) Subject: Re: why modula3? In article , melling@cs.psu.edu (Michael D Mellinger) wri tes: > > In article chased@rbbb.Eng.Sun.COM (David C hase) writes: > > VERBOSE UPPERCASE IDENTIFIERS. > > Will this be "fixed"? My fingers bother me enough as it is without > having to reach for the shift key all the time. > > -Mike > I suggest you use the gnuemacs modula-3 mode in which case you will not have to type reserved words very often. Mick Jordan ======================================================================= 20 === Date: 28 Mar 92 22:50:48 GMT From: nr@dynamic (Norman Ramsey) Subject: Re: Scan.i3 suggestions I second Sam's comments about the Scan interface. In fact, I even seem to recall complaining about it earlier. I'm willing to write the new implementation if Sam will test it and the SRC guys will install it. ======================================================================= 21 === Date: Thu, 2 Apr 92 13:50:03 PST From: mjordan@src.dec.com (Mick Jordan) Subject: Re: terminology wanted In article <1992Mar28.230249.2165@newross.Princeton.EDU>, nr@cs.Princeton.EDU w rites: > Do we have a standard word for a type that is never instantiated > directly (only subtypes are actually instantiated)? I've been using > ``class,'' but I would happily use some other word that people would > understand better. > I use "class" with the same interpretation in the Modula-3 AST and am quite happy with it. Mick ======================================================================= 22 === Date: 27 Mar 92 02:33:54 GMT From: pereira@alice.att.com (Fernando Pereira) Subject: Re: Checking Subtype relationships. In article chased@rbbb.Eng.Sun.COM (David Cha se) writes: >I heard that there was some paper (in TOPLAS, I think, last year or >two) on efficiently performing lattice operations that might be of >some help here. That's all I know for now -- I have't had time to get >to it. Indeed. I don't have the reference and title here, but the authors are Hassan Ait-Kaci, Robert Boyer, Pat Lincoln and Roger Nasr (or some subset thereof). Fernando Pereira AT&T Bell Laboratories, Murray Hill ======================================================================= 23 === Date: 29 Mar 92 16:56:22 GMT From: diwan@cs.umass.edu (Amer Diwan) Subject: Re: terminology wanted >>>>> On 28 Mar 92 23:02:49 GMT, nr@cs.Princeton.EDU said: nr> Do we have a standard word for a type that is never instantiated nr> directly (only subtypes are actually instantiated)? I've been using nr> ``class,'' but I would happily use some other word that people would nr> understand better. C++ uses the term "Abstract Class" for such classes. These are classes that don't give have an implementation for one or more methods. These classes can never be instantiated, only inherited from. Eiffel uses the term "Deferred Class", which IMHO is a much more descriptive term. Amer -- ------------------------------------------------------------------------------ Amer Diwan Department of Computer Science University of Massachusetts Amherst, MA 01003 (413) 545-0256 diwan@cs.umass.edu ------------------------------------------------------------------------------ ======================================================================= 24 === Date: 28 Mar 92 23:02:49 GMT From: nr@cs.Princeton.EDU Subject: terminology wanted Do we have a standard word for a type that is never instantiated directly (only subtypes are actually instantiated)? I've been using ``class,'' but I would happily use some other word that people would understand better. -- Norman Ramsey nr@princeton.edu ======================================================================= 25 === Date: Fri, 27 Mar 1992 23:32:20 GMT From: schwartz@roke.cs.psu.edu (Scott Schwartz) Subject: Re: Problems on a SparcStation mathew@elroy.jpl.nasa.gov (Mathew Yeates) writes: Anyone with any experience using the SRC Modula 3 on a Sun SparcStation? 2.03 works for me. I'm running 4.1.1 with MIT's X server. ======================================================================= 26 === Date: 29 Mar 92 19:30:40 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: terminology wanted I think "abstract" and "deferred" are reasonable options, and the abstract class concept comes from Smalltalk, or even earlier. Personally, I think of it this way: an abstract type is one that requires various representation (fields) and/or methods to be implemented in each subtype, and may offer some fields and methods itself, and those methods may rely on the subtype methods. I use the term "deferred methods" for the subtype methods that must be supplied. This all works nicely with M3's allowing an object type not to specify the default binding for a method. -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================= 27 === Date: Fri, 27 Mar 1992 18:42:00 GMT From: schwartz@roke.cs.psu.edu (Scott Schwartz) Subject: make vs m3 In the trestle/apps directory, I type ; touch Monster.m3 ; m3make ; The m3makefile doesn't correctly encode the dependencies between files, so nothing is recompiled. M3 and make are at odds, to an extent, since m3 will decide for itself when to regenerate certain files. But if you want to use make to control recompilation, you need to give it accurate information. Putting `pgm: pgm.m3 sources; ...'' in the #define for test_pgm more or less fixes it in this case. ======================================================================= 28 === Date: 28 Mar 92 15:32:39 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Scan.i3 suggestions >>>>> On 27 Mar 92 22:06:12 GMT, harbison@bert.pinecreek.com (Sam Harbison) >>>>> said: Sam> Also, Scan.Real/Scan.LongReal treat the exception Convert.Failed as a Sam> fatal error. I don't see any reason not to turn that exception into Sam> Scan.BadFormat. Well, it might be useful to distinguish a legally formatted number that cannot be represented on the machine (overflow) from a badly formatted number. I tend to agree that there is no reason why such errors should be fatal; I'd be inclined to report tham as distinct exceptions (Scan.BadFormat, Scan.ConversionFailed) and let the programmer do with them what she will .... -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================= 29 === Date: 29 Mar 92 12:55:01 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: Re: Problems on a SparcStation Mathew Yeates writes: > Anyone with any experience using the SRC Modula 3 on a Sun > SparcStation? I'm a C++ refugee checking out modula3 and know > very little about the language. However, I installed the SRC > compiler and tried to run their demos. Heres what happened. We have SRC-m3 running on SPARC SLC's and a SUN 4/something server. > Solitaire crashes my window manager (olwm). Works fine. > Tetris dumped core. I traced the problem to a bad return of > Uutmp.getlogin in Main.m3. I fixed the problem by setting the > environment variable TETRIS so the above function would not be > called. After this it worked okay. Haven't tried tetris for version 2. version 1.6 worked, but I didn't keep it. > How do you use dbx on this stuff. I compiled with -keep so I > would have the c files still around but dbx complains about > not being able to find the files(actually, its looking for > foo_m.c instead of foo.mc) Those are symbolic links generated and removed by m3... > This is SunOs 4.1.2, openwindows 3.0, olwm. Also, I had to link > the X libs statically by compiling with -X2@-Bstatic@ because > Sun's patched loader is a piece of crap. Ah! We run SunOS 4.1 also, but I have a HP 700/RX X terminal, with tvtwm and _real_ X libraries. The Openwindows libraries are notoriously different... :-( Greetings, Bert -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null ======================================================================= 30 === Date: Thu, 2 Apr 92 14:04:26 PST From: muller@src.dec.com (Eric Muller) Subject: Re: make vs m3 In article <2w9Hk6na6@cs.psu.edu>, schwartz@roke.cs.psu.edu (Scott Schwartz) wr ites: > > In the trestle/apps directory, I type > > ; touch Monster.m3 > ; m3make > ; > > The m3makefile doesn't correctly encode the dependencies between > files, so nothing is recompiled. > > M3 and make are at odds, to an extent, since m3 will decide for itself > when to regenerate certain files. But if you want to use make to > control recompilation, you need to give it accurate information. > > Putting `pgm: pgm.m3 sources; ...'' in the #define for test_pgm more > or less fixes it in this case. Actually, the right thing is to have 'pgm: FRC; ...'. We decided that make was not good enough to do the dependency checking, and that m3 should do all of that work (with the -make option, it will do a fine analyzis; without, it will simply recompile everything). The trouble in this case is that m3 is not invoked. I have fixed our version. Thanks for the report, Eric. ======================================================================= 31 === Date: Fri, 3 Apr 92 01:43:18 MST From: ggf@saifr00.cfsat.honeywell.com (Gary Frederick) Subject: Porting Modula-3 to VMS I am evaluating support for POSIX under VMS. I was thinking of ways of testing how much trouble it was to get 'UNIX' code to work on VMS using POSIX when I had the idea of trying to port Modula-3. That should give POSIX a good work out, or point out areas that will cause problems. Is it nuts to try to port Modula-3 to VMS using the POSIX support? If it is worth trying, which version of the source is the best to use as a starting point? I have access to a Sun 4 and limited access to a Decstation. Which would be a better host for a cross to VMS? Gary Frederick ggf@saifr00.cfsat.honeywell.com ======================================================================= 32 === Date: 30 Mar 92 10:46:26 GMT From: hendriks@serc.nl (Paul Hendriks) Subject: ECOOP'92: Workshop Program ************************************************************************ * * * EEEEEEE CCCCCC OOOOO OOOOO PPPPPP '' 99999 2222 * * E C O O O O P P '' 9 9 2 2 * * E C O O O O P P 9 9 2 * * EEEE C O O O O PPPPPP 999999 2 * * E C O O O O P 9 2 * * E C O O O O P 9 2 * * EEEEEEE CCCCCC OOOOO OOOOO P 99999 222222 * * * ************************************************************************ The sixth European Conference on Object Oriented Programming ------------------------------------------------------------ 29 June - July 3, 1992 Utrecht, the Netherlands Note: This posting does not include the complete conference program for ECOOP'92, nor does it contain registration information. This can be found in a separate posting. If you would like to receive the complete preliminary program, please contact: Gert Florijn Software Engineering Research Centre - SERC P.O. Box 424 3500 AK Utrecht The Netherlands E-mail: ecoop92@serc.nl Phone: +31 30 322640 Fax: +31 30 341249 ************************************************************************ * * * WORKSHOP PROGRAM * * * ************************************************************************ ------------------------------------------------------------------------ - Monday, June 29, 1992 - ------------------------------------------------------------------------ 8.00 - 18.00: REGISTRATION 9.00 - 17.00: WORKSHOPS: - W1: Markku Sakkinen (University of Jyvaskyla, Finland) "Multiple Inheritance and Multiple Subtyping" - W2: Yolande Berbers (K.U.Leuven, Belgium) and Peter Dickman (ERCIM, currently at INRIA Rocquencourt, France) "Dynamic Object Placement and Load Balancing in Parallel and Distributed Systems" - W3: Matti Rossi (University of Jyvaskyla, Finland) "CASE for Object-Oriented methods" - W4: Pieter Jan Morssink (Leiden University, the Netherlands) and Jan Overbeck (Vienna Technical University, Austria) "Second European Workshop for Doctoral Students in Object-Oriented Systems" ------------------------------------------------------------------------ - Tuesday, June 30, 1992 - ------------------------------------------------------------------------ 8.00 - 18.00: REGISTRATION 9.00 - 17.00: WORKSHOPS: - W5: Brian Foote (University of Illinois, USA), Pierre Cointe (Universite Pierre et Marie Curie, France), Mamdouh Ibrahim (EDS/Artificial Intelligence Services, USA), Gregor Kiczales (Xerox Palo Alto Research Center, USA), and Satoshi Matsuoka (University of Tokyo, Japan) "Object-Oriented Reflection and Meta-level Architectures" - W6: Michael Papathomas and Oscar Nierstrasz (University of Geneva, Switzerland) "Object-Based Concurrency and Reuse" - W7: Dennis de Champeaux (Hewlett-Packard Labs, USA) "The Object-Oriented Software Development Process" ************************************************************************ * * * DESCRIPTIONS * * * ************************************************************************ ------------------------------------------------------------------------ - Workshop W1: Multiple Inheritance and Multiple Subtyping - ------------------------------------------------------------------------ Organiser: Markku Sakkinen (University of Jyvaskyla, Finland) Time: Monday, June 29: 9.00 - 17.00. Who should attend: Researchers interested in analysing and developing multiple inheritance and related concepts and implementing them in object-oriented systems, or strongly arguing that multiple inheritance should be avoided. Topic: There seems to be a scale of different attitudes toward multiple inheritance. - There is no need for it; at least nobody has presented programming problems that could not be solved adequately with single inheritance. - Its disadvantages are greater than its benefits, so it should be avoided. - It is useful in principle, but its problems have not been satisfactorily solved (yet). - It is a good thing and there are conceptually sound approaches, but (perhaps) they cannot be implemented (at least not efficiently enough). - It can be implemented in a manner that is satisfactory both conceptually and pragmatically. - It is (almost) necessary for a good object-oriented language. All viewpoints supported by good arguments are welcome. There have been some discussions at earlier ECOOPs and elsewhere about the relationship of inheritance and subtyping (or conformance). Some people advocate a complete separation of these properties, while others think that they should largely coincide. Does multiple inheritance have any effect on this issue? Are the different approaches to multiple inheritance (e.g., "mixin" inheritance) in the end equally powerful and useful, or are there essential differences? Does multiple inheritance cause additional difficulties for concurrent objects? How to apply: Inform the organiser preferably before 4 May. Short position papers or abstracts of current research (say 2 or 3 pages of A4) are solicited, but "passive" applicants can also be accepted unless the attendance would become too large for a convenient workshop. Notification of acceptance will be sent by 18 May, and the preliminary programme in reasonable time before the conference. Alternatives for sending the paper: - good quality print by mail; - PostScript by e-mail; - troff source text (possible macros: -me, -ms, -mm; indicate any required preprocessors) by e-mail; - TeX or LaTeX source text by e-mail; - Fax (not recommended because of print quality); - other formats by agreement with the organiser. Accepted papers and abstracts will at least be distributed to workshop participants. They might also be published (without further editing) as a department report; any applicant who does not want his/her paper to be included in such a collection should clearly say so. Contact: Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla PL 35 SF-40351 Jyvaskyla Finland Internet: sakkinen@jytko.jyu.fi Bitnet/EARN: SAKKINEN@FINJYU Phone: +358 41 603016 Fax: +358 41 603611 ------------------------------------------------------------------------ - Workshop W2: Dynamic Object Placement and Load Balancing in - - Parallel and Distributed Systems - ------------------------------------------------------------------------ Organisers: Yolande Berbers (K.U.Leuven, Belgium) and Peter Dickman (ERCIM, currently at INRIA Rocquencourt, France) Time: Monday, June 29: 9.00 - 17.00. Topic: Recent years have seen the emergence of distributed and parallel systems in which "objects" play a central role. Many of these systems attempt to achieve (some form of) load balancing through dynamic object placement, dynamic object replication, and/or object migration. This workshop will provide a forum for the presentation and discussion of ideas, research proposals, new developments, experiences, and research results in this area. Relevant subjects of interest include, but are not limited to: - object-oriented systems with dynamic load balancing, - object models suited for dynamic (re)placement, - object migration mechanisms, - dynamic object replication mechanisms, - techniques for object and node load measurement and evaluation, - strategies for load information exchange between nodes, - detection of dynamic interdependencies and use of this information, - load balancing strategies, - scalable mechanisms and strategies. Workshop Committee: - Yolande Berbers, yolande@cs.kuleuven.ac.be - Peter Dickman, dickman@corto.inria.fr How to apply: Each attendee is requested to submit a position paper of 3 to 6 pages. Please send your submission both by surface mail (three copies) and also electronically in Postscript, troff, TeX or LaTeX format to Yolande Berbers at the address mentioned below. Please ensure that the electronic submission can be printed without alteration on both European (A4) and US paper sizes. Accepted submissions will be made available to attendees, by electronic means, before the workshop. The deadline for submission is Monday, March 16th, 1992. Notification of acceptance will be sent out by Wednesday, April 29th, 1992. If this early date will cause you problems please contact one of the committee by e-mail, extensions permitting submissions to be accepted until late April may be granted in exceptional cases. The committee will group the submissions into relevant categories and select both long and short presentations. Ample time will be reserved for discussions. Contact: Yolande Berbers K.U.Leuven Department of Computer Science Celestijnenlaan 200 A B-3001 Leuven Belgium E-mail: yolande@cs.kuleuven.ac.be Phone: +32 16 201015 Fax: +32 16 205308 ------------------------------------------------------------------------ - Workshop W3: CASE for Object-Oriented Methods - ------------------------------------------------------------------------ Organiser: Matti Rossi (University of Jyvaskyla, Finland) Who should attend: Researchers and developers of object-oriented methods and tools. Time: Monday, June 29: 9.00 - 17.00. Topic: Automated tools for object-oriented methods have existed for some time now. Various tool builders have presented different solutions to incorporate these new methods into CASE tools. Some vendors have added a new layer over a traditional ER-based model, whereas others have developed new platforms that use object oriented building blocks to support the new methods. The aim of the workshop is to bring together method and tool developers and researchers to discuss the concepts of object-oriented methods and how they can be defined or implemented in a CASE tool. The requirements for modelling the object-oriented methods (Booch, Yourdon, Rumbaugh, etc.) successfully and how they can be applied in CASE tools could be discussed. In other words, can we implement the new methods with traditional CASE tools (Excelerator etc.); do we need new dedicated tools (OOTool); or can we use tools with definable meta-models i.e., CASE shells (Paradigm+, VSF etc)? Experiences of defining and using different approaches to this problem would be the main topic of the workshop. Another topic could be, how to add measurement and project management features for an object-oriented method into a CASE tool. Also of interest are the ways to enhance the methods by the use of automated tools (for example the reuse of object-oriented specifications). How to apply: Inform the organiser no later than 4th of May. Notification of acceptance will be sent by 20th of May, and the preliminary programme a few weeks before the conference. The main focus should be on short papers (2-5 pages) describing the implementation and use of object-oriented methods in various CASE tools. Also papers presenting ideas to extract metrics and project management information from object-oriented descriptions would be interesting. The alternative ways of sending your contribution are: - good quality print by mail; - uuencoded PostScript by e-mail; - uuencoded RTF by e-mail; - MS Word for Windows file on disk. Accepted papers and abstracts will be available for workshop participants and they will probably be published as a department report. Contact: Matti Rossi Department of Computer Science and Information Systems University of Jyvaskyla PL 35 SF-40351 Jyvaskyla Finland E-mail: Matti.Rossi@jyu.fi Phone: +358 41 603030 ------------------------------------------------------------------------ - Workshop W4: Second European Workshop for Doctoral Students in - - Object-Oriented Systems - ------------------------------------------------------------------------ Organisers: Pieter Jan Morssink (Leiden University, the Netherlands) and Jan Overbeck (Vienna Technical University, Austria) Time: Monday, June 29: 9.00 - 17.00. Topic: This one-day-workshop is intended to enhance the personal and professional development of about 35 PhD-level students who are working in the field of object-oriented systems. It shall enable them to meet, to discuss their research, and to develop their working skills. It will also serve as the continuation and enlargement of a European network of PhD students in object-oriented systems, which has been initiated at the "First Workshop for Doctoral Students in Object-Oriented Systems" held in conjunction with ECOOP'91 in Geneva/Switzerland. This network enables the participants to exchange information, give help and support, and to give wider access to resources and methods (Although the network is set up and based in Europe, non-European participants are welcome). The workshop is intended to focus on both technical exchange of ideas among the participants and a non-technical discussion of issues of particular interest to PhD students. Last year the workshop focussed on the writing of papers. This year the topic of writing a PhD thesis will be discussed. This discussion will be supported by a talk of an experienced researcher in the field of object-oriented systems. For this and other topics, senior facilitators will be invited. The general form of the workshop shall be interactive, focussing on active work in small groups and in the whole group. The workshop shall be divided into three major parts: - mutual introduction - technical program - non-technical program Each of the parts will be covered in one or more sessions over the day. The results shall be covered in a report covering the technical as well as the non-technical results of the day. Parts of the report will be written by the participants during the workshop. The report will either be published in conjunction with other ECOOP'92 workshop publications or, if this is not possible, as a distinct publication. How to apply: Attendants of the workshop are asked to either send a one-page abstract of their dissertation research (first-time-attendants) or a technical position statement of particular interest to PhD students in object-oriented systems (second-time-attendants). The abstracts should be submitted electronically before April 30 to one of the two e-mail addresses given below. They will be distributed electronically to the workshop participants prior to the workshop. They will serve as the basis for the technical discussion at the workshop. Contacts: Pieter Jan Morssink Department of Computer Science Leiden University Niels Bohrweg 1 P.O. Box 9512 2300 RA Leiden The Netherlands E-mail: morssink@rulcri.leidenuniv.nl Phone: (+31)-71-277101 Jan Overbeck Vienna Technical University Institute for Information Systems Paniglgasse 16 A-1040 Vienna Austria E-mail: overbeck@vexpert.dbai.tuwien.ac.at Phone: (+43)-1-58801-6141 Fax: (+43)-1-505-5304 ------------------------------------------------------------------------ - Workshop W5: Object-Oriented Reflection and Meta-level - - Architectures - ------------------------------------------------------------------------ Organisers: Brian Foote (University of Illinois, USA), Pierre Cointe (Universite Pierre et Marie Curie, France), Mamdouh Ibrahim (EDS/Artificial Intelligence Services, USA), Gregor Kiczales (Xerox Palo Alto Research Center, USA), and Satoshi Matsuoka (University of Tokyo, Japan) Time: Tuesday, June 30: 9.00 - 17.00. Topic: The marriage of reflection with object-oriented programming and design techniques holds out the promise of dramatically changing the way that we think about, organise, implement, and use programming languages and systems. A programming language with an object-oriented meta-level architecture is one in which programs are themselves constructed out of first-class objects. A reflective object-oriented language allows a running program to look at or change the objects out of which it is built. Reflection can extend the reach of a programming system inward into the definition of the language itself, downward into its implementation, and outward into realms currently considered the provinces of operating systems, programming environments and database systems. Object-oriented reflective architectures allow issues that have heretofore been dealt with in ad hoc, extra-linguistic fashions, such as debugging and tracing, to be dealt with in a consistent fashion. Issues such as distributed computation, concurrency and object persistence are among those that be addressed using reflective approaches as well. This workshop is the third in a series that began at ECOOP/OOPSLA'90 in Ottawa, and continued at OOPSLA'91 in Phoenix. It is intended to provide researchers who are interested in reflection with a forum in which they can present recent findings, debate outstanding issues in the area, and explore new ideas. The workshop will be organised into several sessions, each of which will be comprised of invited presentations and moderated discussions. Likely session topics include: - Reflective theory, definitions and terminology - The design and architecture of reflective languages and systems - The efficient implementation of reflective facilities - Reflection in concurrent and distributed systems - Applications and implications of reflective approaches Workshop Committee: Questions concerning the workshop may be directed to any of the members of the workshop committee: - Brian Foote, foote@cs.uiuc.edu - Pierre Cointe, pc@rxf.ibp.fr - Mamdouh Ibrahim, mhi@ais.tsd.eds.com - Gregor Kiczales, gregor@parc.xerox.com - Satoshi Matsuoka, matsu@is.s.u-tokyo.ac.jp How to apply: Potential participants are asked to submit a position paper of no more than 5 (single-spaced) pages. These papers may be extended abstracts of original work in progress, or position statements that outline the author's opinions on one or more issues in the area. We intend to distribute copies of all accepted position papers to all participants prior to the workshop. We will invite a number of authors to present their position papers at the workshop. Position papers should be submitted by Friday, 17 April 1992. Notifications of acceptance will be sent before Friday, 15 May 1992. Please send 5 copies and an electronic copy of your position paper to: Contact: Brian Foote 681 Psychology Building University of Illinois 603 E. Daniel Champaign, IL 61820 USA E-mail: reflection-workshop@p300.cpl.uiuc.edu ------------------------------------------------------------------------ - Workshop W6: Object-Based Concurrency and Reuse - ------------------------------------------------------------------------ Organisers: Michael Papathomas and Oscar Nierstrasz (University of Geneva, Switzerland) Time: Tuesday, June 30: 9.00 - 17.00. Topic: The purpose of this one-day workshop is to identify the difficulties in taking advantage of the reuse potential of object-oriented programming techniques in developing concurrent software, to bring together and examine potential solutions, and to identify open problems and promising research directions. How to apply: Prospective participants are invited to submit position papers stating how their research addresses the following questions: - To what extent is reuse of concurrent software a language design issue? What, if any, are the limitations, with respect to reuse, of library-based concurrency extensions to existing languages? - What are the most important language design issues in combining concurrency and object-oriented features? What is the relative importance of inheritance? Which specific language features will ease the development of reusable frameworks for concurrent object-oriented applications? - What criteria should be used to evaluate language features with respect to reuse of concurrent software? Are example problems satisfactory? What would constitute a canonical list of problems? - Are formal semantic models important or relevant to concurrent object-oriented reuse? If yes, what specific issues should they address? Submissions should be made by e-mail, if possible, and should include the author's full coordinates, including e-mail address. Submissions should not exceed 6 formatted pages and should be received before May 15 at the address given below. Standard LaTeX is preferred, though plain ASCII files, troff, Framemaker MIF files or PostScript will also be accepted. Contact: Michael Papathomas Centre Universitaire d'Informatique 12 rue du Lac CH-1207 Geneva Switzerland E-mail: michael@cui.unige.ch ------------------------------------------------------------------------ - Workshop W7: The Object-Oriented Software Development Process - ------------------------------------------------------------------------ Organiser: Dennis de Champeaux (Hewlett-Packard Labs, USA) Time: Tuesday, June 30: 9.00 - 17.00. Topic: Software development is an expensive, labor intensive complex process. Carnegie-Mellon's Software Engineering Institute has defined development maturity levels ranging from "chaotic happy hacking" at level 1 to the application of a systemic process with continuous self improvement at level 5. Most software development organisations are still below level 2. Finding ways to push the SEI maturity level up for an organisation is highly desirable. The object-oriented paradigm promises to facilitate software development by several avenues. On the one hand development occurs by virtue of encapsulation which, among other advantages, should enhance re-usability. On the other hand development proceeds by the "naturalness" of the object notion which facilitates moving smoothly from requirements via analysis and design to an implementation. In addition, we suspect that object-oriented analysis yields qualitatively better models than structured analysis modelling. This should result in a deeper understanding of the requirements of systems and hence will reveal fatal misunderstandings earlier. At the same time, object-oriented methodologists are as yet, fairly uncommitted as to how to do object-oriented software development beyond denouncing the waterfall model and embracing the spiral model or relying upon muddled models that require an arbitrary number of backtrackings and iterations. The latter models are perhaps attractive from a software engineers perspective but are highly unattractive from a planning and management perspective. It would be quite helpful for the object-oriented paradigm to be able to outline a generic scenario/cook book/pseudo algorithm that would guide the object-oriented development process. It is quite plausible that the commitment to the object-oriented paradigm will allow identification of development sub-phases and sub-activities in the classic trio: analysis/design/implementation. How to apply: In general, we invite contributions to this workshop that either: - contain reasoned proposals for the procedural dimension of (segments of) the object-oriented life cycle, and/or - describe an object-oriented development process on the basis of experience. Submissions should be in plain ASCII or vanilla LaTeX source and should contain less than 10K bytes. They should be submitted before May 15 to the following address. Contact: Dennis de Champeaux Hewlett-Packard Labs, MS 1U-14 P.O. Box 10490 Palo Alto, CA 94303-0969 USA E-mail: champeaux@hplabs.hp.com Phone: USA-(415) 857 6674 Fax: USA-(415) 857 8526 ======================================================================= 33 === Date: 30 Mar 92 10:45:43 GMT From: hendriks@serc.nl (Paul Hendriks) Subject: ECOOP'92: Tutorial Program ************************************************************************ * * * EEEEEEE CCCCCC OOOOO OOOOO PPPPPP '' 99999 2222 * * E C O O O O P P '' 9 9 2 2 * * E C O O O O P P 9 9 2 * * EEEE C O O O O PPPPPP 999999 2 * * E C O O O O P 9 2 * * E C O O O O P 9 2 * * EEEEEEE CCCCCC OOOOO OOOOO P 99999 222222 * * * ************************************************************************ The sixth European Conference on Object Oriented Programming ------------------------------------------------------------ 29 June - July 3, 1992 Utrecht, the Netherlands Note: This posting does not include the complete conference program for ECOOP'92, nor does it contain registration information. This can be found in a separate posting. If you would like to receive the complete preliminary program, please contact: Gert Florijn Software Engineering Research Centre - SERC P.O. Box 424 3500 AK Utrecht The Netherlands E-mail: ecoop92@serc.nl Phone: +31 30 322640 Fax: +31 30 341249 ************************************************************************ * * * TUTORIAL PROGRAM * * * ************************************************************************ ------------------------------------------------------------------------ - Monday, June 29, 1992 - ------------------------------------------------------------------------ 8.00 - 18.00: REGISTRATION 9.00 - 17.00: FULL-DAY TUTORIALS: - T1: Jean-Pierre Briot (LITP, France) "Object-Oriented Concurrent Programming" - T2: Michael Blaha and Frederick Eddy (GE Corporate Research & Development, USA) "Object-Oriented Modelling and Design" 9.00 - 12.30: HALF-DAY TUTORIAL: - T3: Derek Coleman and Patrick Arnold (Hewlett-Packard Laboratories, United Kingdom) "The Anatomy of an Analysis and Design Method" 14.00 - 17.30: HALF-DAY TUTORIAL: - T4: Ray Weedon (Open University, United Kingdom) "Introduction to Eiffel" ------------------------------------------------------------------------ - Tuesday, June 30, 1992 - ------------------------------------------------------------------------ 8.00 - 18.00: REGISTRATION 9.00 - 17.00: FULL-DAY TUTORIALS: - T5: Roberto Zicari (Johann Wolfgang Goethe-Universitat, Germany) "Object-Oriented Database Management Systems" - T6: Stanley Lippman (AT&T Bell Laboratories, USA) "Introduction to C++" - T7: Karl Lieberherr (Northeastern University, USA) "The Demeter Method for Object-Oriented Software Development" 9.00 - 12.30: HALF-DAY TUTORIAL: - T8: Anand Tripathi (University of Minnesota, USA) "Object-Oriented Concepts in Operating Systems" 14.00 - 17.30: HALF-DAY TUTORIAL: - T9: Urs Holzle (Stanford University, USA) "The Self Programming Language" ************************************************************************ * * * DESCRIPTIONS * * * ************************************************************************ ------------------------------------------------------------------------ - Tutorial T1: Object-Oriented Concurrent Programming - ------------------------------------------------------------------------ Instructor: Jean-Pierre Briot (LITP, France) Time: Monday, June 29: 9.00 - 17.00. Level: Intermediate to advanced. Objectives: Concurrent programming is one of the key issues in achieving higher performance in modern computation. Object-oriented concurrent programming (OOCP) is the natural unification of object-oriented and concurrent programming. The resulting programming methodology allows decomposing large program as a collection of small modules that run and interact concurrently and capable in exploiting parallel hardware. This tutorial is attempted at introducing basic concepts and methodology of object-oriented concurrent programming. Content: We consider that object-oriented concurrent programming is the natural generalisation of object-oriented programming. We discuss various levels of integration between object-oriented programming and concurrency, leading ultimately to the notion of active object which unifies object and activity, message passing and synchronisation. We selected an object-oriented concurrent programming language, namely ConcurrentSmalltalk, based on Smalltalk, in order to describe concepts, constructs, methodology and examples. Examples include programming with continuations, divide and conquer, pipeline strategies. We then shortly discuss implementation of active objects in Smalltalk. This implementation is the kernel of a platform, named Actalk, used to describe various OOCP models and languages. We will survey and compare some of the main OOCP models, with a special focus on the Actor computation model. We will conclude by surveying current and prospective application fields and research issues. A concise bibliography will be provided. Who should attend: This tutorial is organised for those who are familiar with object-oriented programming in general and wish to comprehend and practically use object-oriented concurrent programming. The tutorial covers both a progressive introduction to concepts, a sample of program examples, and a survey of current state of the art. Required previous knowledge: Some prior exposure to basic concepts of object-oriented programming is advisable. The Smalltalk language will be used as the programming language basis, therefore some notion of Smalltalk syntax is advisable, although definitely not necessary. Instructor's profile: Jean-Pierre Briot is a researcher working at LITP, Institut Blaise Pascal, Paris. He took part in the design of several OOCP systems and applications to computer music and distributed AI. He designed the Actalk test bed as a means to model, classify and experiment with various OOCP models in some unified programming environment. This platform gave rise to various experiments in modelling OOCP languages and building distributed AI platforms. Jean-Pierre Briot is co-heading an Esprit parallel computing action to develop an OOCP programming environment on multiprocessors. ------------------------------------------------------------------------ - Tutorial T2: Object-Oriented Modelling and Design - ------------------------------------------------------------------------ Instructors: Michael Blaha and Frederick Eddy (GE Corporate Research & Development, USA) Time: Monday, June 29: 9.00 - 17.00. Objectives: The primary objective of this tutorial is to teach an object-oriented methodology for developing software systems. Attendees will learn how to construct object-oriented models of the real world and then transform the models into a design of programming language and/or database code. Content: This tutorial will be based on our recent book "Object-Oriented Modelling and Design" published by Prentice Hall. This tutorial lies at the intersection of object-oriented technology and software engineering. We stress modelling a system from three distinct but related views: object model (static structure), dynamic model (interactions and control), and functional model (computation of values). The object model serves as the integrating vehicle for combining the information for design and implementation. The early object-oriented literature emphasized object-oriented programming but more recently there has been an appreciation of the usefulness of object-oriented concepts for analysis and design. Our course will emphasize that coding is the last stage in a process of development that includes stating a problem, understanding its requirements, designing a solution, and implementing a program in a particular language. However, our approach is not strictly linear; the seamless transformation from analysis to design facilitates incremental development. Who should attend: Persons who would like to learn about an object-oriented software development methodology would benefit from this course. The course is also intended for persons who have read our book or a comparable book: We will be treating several advanced topics and have scheduled frequent question breaks. Required previous knowledge: We rate the tutorial as intermediate level. We assume that attendees are familiar with object-oriented concepts and have read our book or a comparable book. Instructor's profile: Michael Blaha received his D.Sc. in Chemical Engineering from Washington University in St. Louis. His dissertation applied database technology to chemical engineering applications. Dr. Blaha is a computer scientist at GE Corporate R&D and is currently interested in database theory, object-oriented concepts and methodologies, and unusual engineering database problems. He has published papers in various computer science and engineering forums. Frederick Eddy has a bachelors degree in physics from Yale University, and a masters degree in mathematics from the University of Vermont. He has been a Computer Scientist at GE R&D since 1984 where he has applied the OMT methodology to several projects including graphical editors, a language compiler, a production planning system, and a prototyping environment. He is active in consulting and training for other departments in GE. ------------------------------------------------------------------------ - Tutorial T3: The Anatomy of an Analysis and Design Method - ------------------------------------------------------------------------ Instructors: Derek Coleman and Patrick Arnold (Hewlett-Packard Laboratories, United Kingdom) Time: Monday, June 29: 9.00 - 12.30. Level: Intermediate to advanced. Objectives: The practitioner faces a bewildering profusion of OOA/D methods and notations. This tutorial provides a framework for understanding and evaluating current methods and applies it to three recent methods. The tutorial introduces a new best practice method, and its underlying rationale, which has been developed for use in Hewlett-Packard. Content: The essence of the object-oriented analysis and design task is how to systematically map requirements onto the object-oriented computational model. Currently there are a large number of methods aimed at solving this problem. The methods are all different, employing a variety of models, notations and processes. The tutorial introduces a set of criteria for evaluating methods from the viewpoint of the object-oriented concepts they support, the kinds of models and notations they employ and the process steps that they recommend. The criteria provides a way of understanding the underlying similarities and differences between methods. The criteria were developed as part of a programme to assess what kind of method should be made available to HP engineers. The work has led to the development of a synthesised method which integrates the best aspects of existing techniques. The method and its rationale will be explained by means of an example. The tutorial ends with a brief account of the usefulness of the method in practice. Who should attend: The target audience is software engineers and project managers who intend to use or who are interested in object-oriented analysis and design methods. The tutorial will also be of interest to research workers in the area. Required previous knowledge: It will be assumed that the audience have at least some knowledge of software engineering and object-oriented programming. An understanding of the basic concepts of an object-oriented method would be an advantage. Instructor's profile: Derek Coleman is a Project Manager at HP Laboratories leading a research and consultancy team working on object-oriented methods. The team have produced a method tailored to the needs of HP engineers and are currently evaluating its practical use. Derek is an active member of the object-oriented research community and the author of many papers on software engineering. Patrick Arnold has worked as a researcher in software engineering at HP Laboratories for the past five years. He has extensive experience of the development of formal specification languages and CASE tools to support them. For the past 18 months he has worked on object-oriented analysis and design. A paper evaluating five object-oriented methods, co-authored by the HP Laboratories research team, was published by the JOOP Focus on Analysis and Design in October 1991. ------------------------------------------------------------------------ - Tutorial T4: Introduction to Eiffel - ------------------------------------------------------------------------ Instructor: Ray Weedon (Open University, United Kingdom) Time: Monday, June 29: 14.00 - 17.30. Level: Introductory. Objectives: The main objective is to demonstrate how the design of Eiffel facilitates the development of quality production-level software using reusable software components. Participants will be given a clear understanding of the features of the design which do this and how they compare with those available in other important object-oriented languages. Content: The design of Eiffel is based on Abstract Data Types (ADTs). An example will be given showing how a simple ADT (formally specified) is implemented as an Eiffel class. This will illustrate the use (and limitations) of Eiffel assertions. It will also lead to a discussion of the uses of assertions (programming by contract, the exception mechanism, documentation, debugging, etc.). If facilities are available, a demonstration will be given of how the example ADT implementation can be used in an actual Eiffel application. This will also provide a context in which to discuss the compilation of an Eiffel program (including the use of C as an intermediate language), debugging, and the browsing facilities available in the environment. Eiffel supports multiple inheritance, genericity, deferred classes, polymorphism and dynamic binding. These will be fully explained using examples and compared where appropriate with the facilities offered in other object-oriented languages (particularly C++, but also Smalltalk and Objective-C). Eiffel 's library and persistence mechanism will also be explained. Who should attend: The tutorial should interest all those with experience in software development who want to know about the features of an object-oriented language and how these can contribute to meeting the goals of software development. It should also interest those already familiar with object-oriented technology who wish to know what features are offered in Eiffel and how these differ from those in other important object-oriented languages. Required previous knowledge: Some experience in software development will be essential to get the most out of the tutorial. Knowledge of another object-oriented language is not essential but would be helpful. Instructor's profile: Ray Weedon is a lecturer in Computing Science at the Open University, Milton Keynes, United Kingdom. He has been involved in the writing of the following 3rd level courses: - Data models and databases - Programming and programming languages (abstract data types, Prolog, and Eiffel) He has also written a book on Prolog (with 8 colleagues). His research is in Object Algebras. ------------------------------------------------------------------------ - Tutorial T5: Object-Oriented Database Management Systems - ------------------------------------------------------------------------ Instructor: Roberto Zicari (Johann Wolfgang Goethe-Universitat, Germany) Time: Tuesday, June 30: 9.00 - 17.00. Level: Introductory. Objectives: This tutorial will provide attendees with an introduction to the basic concepts of object-oriented databases. The tutorial will provide a complete overview of the field: limitations of current database management systems, new application requirements, definition of an object-oriented database system (OODBMS), survey and comparison of existing systems and prototypes. Content: Recently several new database products have been launched based on the object-oriented approach. There is no common agreement on what an OODBMS is, but many people agree on functionalities that such systems must provide. An OODBMS can be defined as a system which is a DBMS and is consistent with the object-oriented paradigm. The first part of this tutorial will introduce the basic functionalities of an Object Oriented Database System, namely: - Support for Complex Objects - Object Identity - Encapsulation - Types and Classes - Inheritance, Class or Type Hierarchies - Overriding, Overloading and Late Binding - Computational Completeness - Extensibility - Persistence - Secondary Storage Management - Concurrency - Recovery - Ad Hoc Query Facility The second part of the tutorial will review some of the most significant OODBMS products/prototypes available on the market; namely: - GemStone (Servio), - Iris (Hewlett-Packard), - O2 (O2Technology), - Orion (MCC). There is a strong debate on what will be the next generation of database systems. On one side, new object-oriented startups are engaged in a tight competition between them. On the other side, the vendors of relational systems are extending their functionalities and moving in the direction of the object features. The third and final part of the tutorial will compare the two approaches to develop database systems: Object-Oriented and Relational, with respect to the requirements posed by a variety of complex applications. Who should attend: Software Engineers, Programmers, EDP Managers, Software developers. Required previous knowledge: Attendees should have a basic knowledge of programming languages and databases. Instructor's profile: Roberto Zicari is Full Professor of Computer Science (Databases and Information Systems) at the Johann Wolfgang Goethe Universitat - Frankfurt, Germany. Prior to that, he was Associate Professor of Computer Science at the Politecnico di Milano, Italy. He was Visiting Scientist at the University of California at Berkeley, USA (1985), IBM Almaden Research Laboratory, USA (1986), GIP Altair, France (1989),and Visiting Professor at the Ecole Polytechnique Federal de Lausanne, Switzerland (1991). He received his Doctor of Engineering degree in 1979 from Politecnico di Milano. His current research and professional interests are in object-oriented database systems and their applicability to complex applications. Professor Zicari has published in the major database journals and conferences and has extensively lectured both in Europe and in North America. ------------------------------------------------------------------------ - Tutorial T6: Introduction to C++ - ------------------------------------------------------------------------ Instructor: Stanley Lippman (AT&T Bell Laboratories, USA) Time: Tuesday, June 30: 9.00 - 17.00. Objectives: To survey the main features of C++, illustrating both effective and ineffective uses. C++ is considered from three perspectives: briefly, as a "better" C; as a language supporting abstract data types through its class mechanism; and, finally, as a language supporting object-oriented programming through inheritance and dynamic binding. Content: A Tour of C++: show the use of an abstract data type, then extend it by subtyping, illustrating inheritance and dynamic binding. That done, combine subtypes using multiple inheritance, and show how shared virtual base classes solve a particular design problem. Finally, illustrate how templates allow for the design of generic types. A Better C: support of strong type checking, function overloading, in-line functions, and template functions. Abstract Data Types: present a rationale. Show how C++ supports abstract data types, public interface, automatic class specific memory management, pointer to member functions, operator overloading, conversion operators, and class templates. Object-Oriented Programming: present a rationale. Show how C++ supports inheritance. Discussion of subtyping versus inheritance and the use of composition. A detailed example illustrating dynamic binding, multiple inheritance and the use of virtual base classes using templates. Who should attend: The Tutorial is aimed at application and system programmers who either have begun to work in C++ or are considering using it. Required previous knowledge: Some knowledge of C is assumed. Knowledge of object-oriented programming or data abstraction is not required. Instructor's profile: Stanley Lippman is a member of technical staff of the C++ Software Technology Center Laboratory of AT&T Bell Laboratories. He was one of the original members of the development team responsible for the AT&T C++ compiler, cfront. His book "A C++ Primer", 2nd Edition, published by Addison-Wesley, is considered by many to be the standard introductory book on C++. He has lectured widely on C++ for both novice and advanced users. ------------------------------------------------------------------------ - Tutorial T7: The Demeter Method for Object-Oriented Software - - Development - ------------------------------------------------------------------------ Instructor: Karl Lieberherr (Northeastern University, USA) Time: Tuesday, June 30: 9.00 - 17.00. Level: Intermediate. Objectives: Mastering a formally defined object model and its mapping to programming languages. To learn well tested, yet very novel, design and programming techniques for developing object-oriented applications. The material is partitioned into easy to learn behavioral objectives as outlined in our OOPSLA'89 paper. Content: You will learn a novel and effective approach to object-oriented design and programming, called the Demeter Method for object-oriented software development. The techniques you learn, such as propagation patterns and class optimisation, are programming language independent but we show their concrete use with C++ syntax. Key features of the Demeter Method are: - A simple and concise notation for conceptual modelling which has a mathematical foundation. - A class calculus for optimising class hierarchies which allows you to measure the quality of class hierarchies. - Propagation patterns, for describing groups of collaborating classes, leading to a remarkable reduction in the length of programs. The re-usability of programs is increased significantly. - A programming and design guideline, known as the "Law of Demeter" which promotes a clear programming style and which helps you distinguish good designs from bad designs. - A systematic way to develop an application development plan and a test plan based on the result of conceptual modelling. - A flexible technique to define application-specific objects in a declarative style. Who should attend: Analysts, designers, and programmers who want to learn new formal methods for object-oriented software engineering. Managers of software projects will learn about planning object-oriented applications and they will benefit from the elegant and easy to learn theoretical foundations taught in this tutorial. Required previous knowledge: Some experience with writing programs in object-oriented languages is expected. The programming language dependent part will rely on the C++ notation. We will use elementary graph theory (e.g., cycle checking, finding a path between two vertices, etc.) Instructor's profile: Karl Lieberherr is the principal designer of the Demeter System. He has a Ph.D. from ETH Zurich, Switzerland and he was Assistant Professor of Computer Science at Princeton University and a Principal Member of Technical Staff at GTE Laboratories, in Waltham, MA. Since 1985, he is a Professor of Computer Science at Northeastern University and since 1990 he is director of the Center for Software Sciences. Professor Lieberherr has taught courses on object-oriented analysis, design and programming for industry and at Northeastern University for 5 years using the Demeter Method presented in this course. Karl Lieberherr has previously taught for companies such as Data General, IBM, Mettler-Toledo, National Technological University (over 500 attendees), Siemens, both in the US and Europe. He participated at several Summer Schools and Symposia on object-oriented technology in the Netherlands, Finland and Switzerland and recently presented a tutorial at OOPSLA'91 and at ELECTRO'92. ------------------------------------------------------------------------ - Tutorial T8: Object-Oriented Concepts in Operating Systems - ------------------------------------------------------------------------ Instructor: Anand Tripathi (University of Minnesota, USA) Time: Tuesday, June 30: 9.00 - 12.30. Level: Intermediate. Objectives: To present the use of object-oriented concepts in operating systems. The focus will be on three aspects: - use of objects-based and object-oriented concepts in operating system designs, - support for user-level objects and object-oriented application systems, and - object-oriented interfaces to operating system functions. Content: The recent advances in operating systems have focussed on providing support for object-based and distributed computing with emphasis on micro-kernel designs that support user-level extensible environments. Mach and Chorus exemplify this approach. The goal of this course is to present an exposition of object-oriented concepts in operating system designs. We distinguish three aspects in which object-orientation can relate to operating systems. One, an operating system itself is designed and implemented using object concepts. Second, an operating system provides explicit support for implementing objects and object-oriented applications. Third, an operating system provides extensible interfaces based on object-oriented concepts. We present, using examples from Mach, Chorus, and Clouds, the use of object-based concepts in operating system designs. Some of the specific aspects to be discussed include the object model and its relationship to virtual memory management, inter-object communication, protection, and process/thread management. The use of object oriented concepts such as class hierarchical approach to process management, exception handling, and memory management is presented with examples from Choices. The kernel-level support for objects includes functions for object creation, deletion, storage management (persistent objects), migration, network transparency, and remote invocations. Also needed is remote invocation level support for object oriented concepts such as polymorphism. In this context we present examples from Chorus and Nexus. Who should attend: This course is intended for systems programmers/engineers, researchers, and project managers involved in the design and development of object-oriented distributed systems. Required previous knowledge: Understanding of basic concepts in operating systems, distributed computing, and object-oriented programming. Instructor's profile: Anand Tripathi is an Associate Professor in the Department of Computer Science, University of Minnesota, Minneapolis. He received the B.Tech degree from the Indian Institute of Technology, Bombay, India, 1972, and the M.S. and Ph.D. degrees from the University of Texas at Austin in 1978 and 1980, respectively, in Electrical Engineering. From 1972 to 1975 he worked as a research scientist at Bhabha Atomic Research Center, Bombay, India. During 1981 to 1984 he worked as a Senior Principal Research Scientist at Honeywell Computer Sciences Center, Bloomington, MN, where he was involved with the design and evaluation of distributed operating systems for command and control applications. He has designed and implemented an object-oriented distributed operating system called Nexus for supporting experimental studies in distributed computing. His research interests include parallel and distributed systems, object-oriented programming, and fault-tolerant computing. In the past, he has presented tutorials on distributed computing systems at some of the past ICDCS conferences, at some of the IEEE sponsored Tutorial Weeks in Washington DC and Boston, and also a number of times at the Berlin Continuing Engineering Education Program, AMK Berlin. ------------------------------------------------------------------------ - Tutorial T9: The Self Programming Language - ------------------------------------------------------------------------ Instructor: Urs Holzle (Stanford University, USA) Time: Tuesday, June 30: 14.00 - 17.30. Level: Advanced to intermediate. Objectives: To understand Self's object model and inheritance semantics, and the rationale behind them; to explore some typical situations where Self's flexibility allows simpler solutions than are available in more traditional languages like Smalltalk-80 and C++; to discuss techniques that allow an efficient implementation of Self. Content: Self is an object-oriented language for exploratory programming based on a small number of simple yet powerful ideas. We start the tutorial by presenting the design principles underlying Self. Using simple examples, we then demonstrate how easy it is to reuse Self code even in situations where more traditional languages like Smalltalk stand in the programmer's way. The second part of the tutorial covers programming on a larger scale, showing how Self programs can be organised in the absence of classes. We also show how inheritance can be used to model concepts such as global variables and scoping without introducing extra language mechanisms. Finally, we address some of the performance implications of the Self language model and discuss how very good performance can be achieved despite the seemingly costly "everything is a message send" model. Who should attend: Programmers, students and researchers who are interested in a fresh look at object-oriented language design and prototype-based systems; anybody who is wondering why it is often harder than expected to reuse code in his/her favourite programming language. Required previous knowledge: Participants are expected to be familiar with the principles of object-oriented programming and at least one object-oriented programming language. Previous experience with Smalltalk-80 is helpful but not necessary. Instructor's profile: Urs Holzle is a Ph.D. candidate at Stanford University and a Research Assistant at the Center for Integrated Systems. He joined the Self group three years ago and has implemented major parts of the Self system. His current research concentrates on new techniques for the optimisation of pure object-oriented languages. ======================================================================= 34 === Date: 30 Mar 92 18:47:46 GMT From: nr@cs.Princeton.EDU Subject: Division Wars Given that I've seen discussion of division in this space, and that the Modula-3 definitions of DIV and MOD are different from the definitions in e.g. C and Pascal, I thought the following article (from the most recent TOPLAS) might be of interest to the Modula-3 crowd: @article{boute:euclidean, month=apr, pages="127-144", number="2", author="Raymond T. Boute", title="The {Euclidean} Definition of the Functions div and mod", keywords="division arithmetic", annote="Compares the mathematical properties of three definitions of div and m od, based on truncation, floor, and Euclid's theorem respectively. Also compares the advantages and disadvantages for various purposes. Nice ammunication for the division wars.", journal=toplas, year="1992", volume="14"} -- Norman Ramsey nr@princeton.edu ======================================================================= 35 === Date: 30 Mar 92 20:08:20 GMT From: figueroa@SPUNKY.CS.NYU.EDU (Samuel A. Figueroa) Subject: UPPERCASE IDENTIFIERS (was: why modula3?) In article chased@rbbb.Eng.Sun.COM (David Chase) writes: VERBOSE UPPERCASE IDENTIFIERS. My preference would be to make reserved words case insensitive, all other words case sensitive. This way one can choose one's own convention for capitalization of words. ------------ Sam Figueroa (figueroa@cs.nyu.edu) This is not a .signature virus. Do NOT copy me into your .signature file! ======================================================================= 36 === Date: 1 Apr 92 22:42:55 GMT From: mod3sys@gonzo.cc.wwu.edu (modula3 system programmer) Subject: why does my debugger say "source not available"? I spent about an hour trying to tweak dbx into figuring out where the source file is. Is there a standard way for DS-3100 users of SRC Modula-3 Version 2.04 to step through lines, and so on? Yes, I used the -g1 switch at compile and link time. (main source not available) ======================================================================= 37 === Date: 2 Apr 92 00:00:37 GMT From: fn00@gte.com (Farshad Nayeri) Subject: Network Reader and Writer Has anyone implemented a (TCP/IP stream-based) network reader/writer for Modula-3? Thank you, --farshad -- Farshad Nayeri Intelligent Database Systems fn00@gte.com Computer and Intelligent Systems Laboratory (617)466-2473 GTE Laboratories, Waltham, MA ======================================================================= 38 === Date: 1 Apr 92 23:25:21 GMT From: fn00@gte.com (Farshad Nayeri) Subject: Re: Problems on a SparcStation In article <1992Mar29.125501.27339@cs.rug.nl> laverman@cs.rug.nl (Bert Laverman ) writes: Mathew Yeates writes: > Anyone with any experience using the SRC Modula 3 on a Sun > SparcStation? I'm a C++ refugee checking out modula3 and know > very little about the language. However, I installed the SRC > compiler and tried to run their demos. Heres what happened. We have SRC-m3 running on SPARC SLC's and a SUN 4/something server. > Solitaire crashes my window manager (olwm). Works fine. > This is SunOs 4.1.2, openwindows 3.0, olwm. Also, I had to link > the X libs statically by compiling with -X2@-Bstatic@ because > Sun's patched loader is a piece of crap. Ah! We run SunOS 4.1 also, but I have a HP 700/RX X terminal, with tvtwm and _real_ X libraries. The Openwindows libraries are notoriously different... :-( Does anyone know what it takes to get Trestle to work with OpenWindows? Has anyone attempted to get them work together? Thanks, --farshad -- Farshad Nayeri Intelligent Database Systems fn00@gte.com Computer and Intelligent Systems Laboratory (617)466-2473 GTE Laboratories, Waltham, MA ======================================================================= 39 === Date: 30 Mar 92 10:44:47 GMT From: hendriks@serc.nl (Paul Hendriks) Subject: ECOOP'92: Call for Participation & Preliminary Program ************************************************************************ * * * EEEEEEE CCCCCC OOOOO OOOOO PPPPPP '' 99999 2222 * * E C O O O O P P '' 9 9 2 2 * * E C O O O O P P 9 9 2 * * EEEE C O O O O PPPPPP 999999 2 * * E C O O O O P 9 2 * * E C O O O O P 9 2 * * EEEEEEE CCCCCC OOOOO OOOOO P 99999 222222 * * * ************************************************************************ Call for Participation Preliminary Program The sixth European Conference on Object Oriented Programming ------------------------------------------------------------ 29 June - July 3, 1992 Utrecht, the Netherlands ECOOP'92 is the sixth European Conference on Object-Oriented Programming. It will be held in Utrecht, the Netherlands, from June 29 to July 3, 1992. It continues the tradition of previous years, when ECOOP was held in Paris (France), Oslo (Norway), Nottingham (England), Ottawa (Canada, jointly with OOPSLA) and Geneva (Switzerland). The ECOOP conferences are a platform for researchers and practitioners from academia and industry to discuss and exchange new developments in object-oriented languages, systems and methods. The program of events for ECOOP'92 provides an excellent starting point for these stimulating discussions. Contents: - Conference Program - Exhibition, Demonstrations, and Presentations - Organisation - General Information and Registration - Registration Form - Hotel Reservation Form Note: The descriptions of tutorials and workshops are posted separately. ************************************************************************ * * * CONFERENCE PROGRAM * * * ************************************************************************ ------------------------------------------------------------------------ - Monday, June 29, 1992 - ------------------------------------------------------------------------ 8.00 - 18.00: REGISTRATION 9.00 - 17.00: FULL-DAY TUTORIALS: - T1: Jean-Pierre Briot (LITP, France) "Object-Oriented Concurrent Programming" - T2: Michael Blaha and Frederick Eddy (GE Corporate Research & Development, USA) "Object-Oriented Modelling and Design" 9.00 - 17.00: WORKSHOPS: - W1: Markku Sakkinen (University of Jyvaskyla, Finland) "Multiple Inheritance and Multiple Subtyping" - W2: Yolande Berbers (K.U.Leuven, Belgium) and Peter Dickman (ERCIM, currently at INRIA Rocquencourt, France) "Dynamic Object Placement and Load Balancing in Parallel and Distributed Systems" - W3: Matti Rossi (University of Jyvaskyla, Finland) "CASE for Object-Oriented methods" - W4: Pieter Jan Morssink (Leiden University, the Netherlands) and Jan Overbeck (Vienna Technical University, Austria) "Second European Workshop for Doctoral Students in Object-Oriented Systems" 9.00 - 12.30: HALF-DAY TUTORIAL: - T3: Derek Coleman and Patrick Arnold (Hewlett-Packard Laboratories, United Kingdom) "The Anatomy of an Analysis and Design Method" 14.00 - 17.30: HALF-DAY TUTORIAL: - T4: Ray Weedon (Open University, United Kingdom) "Introduction to Eiffel" ------------------------------------------------------------------------ - Tuesday, June 30, 1992 - ------------------------------------------------------------------------ 8.00 - 18.00: REGISTRATION 9.00 - 17.00: FULL-DAY TUTORIALS: - T5: Roberto Zicari (Johann Wolfgang Goethe-Universitat, Germany) "Object-Oriented Database Management Systems" - T6: Stanley Lippman (AT&T Bell Laboratories, USA) "Introduction to C++" - T7: Karl Lieberherr (Northeastern University, USA) "The Demeter Method for Object-Oriented Software Development" 9.00 - 17.00: WORKSHOPS: - W5: Brian Foote (University of Illinois, USA), Pierre Cointe (Universite Pierre et Marie Curie, France), Mamdouh Ibrahim (EDS/Artificial Intelligence Services, USA), Gregor Kiczales (Xerox Palo Alto Research Center, USA), and Satoshi Matsuoka (University of Tokyo, Japan) "Object-Oriented Reflection and Meta-level Architectures" - W6: Michael Papathomas and Oscar Nierstrasz (University of Geneva, Switzerland) "Object-Based Concurrency and Reuse" - W7: Dennis de Champeaux (Hewlett-Packard Labs, USA) "The Object-Oriented Software Development Process" 9.00 - 12.30: HALF-DAY TUTORIAL: - T8: Anand Tripathi (University of Minnesota, USA) "Object-Oriented Concepts in Operating Systems" 14.00 - 17.30: HALF-DAY TUTORIAL: - T9: Urs Holzle (Stanford University, USA) "The Self Programming Language" ------------------------------------------------------------------------ - Wednesday, July 1, 1992 - ------------------------------------------------------------------------ 9.00 - 18.00: EXHIBITION 8.00 - 10.00: REGISTRATION 10.00 - 10.10: OPENING REMARKS - Pierre America (Philips, The Netherlands), Conference Chair 10.10 - 11.10: INVITED SPEAKER - Won Kim (UniSQL, USA) "On Unifying Relational and Object-Oriented Database Systems" 11.30 - 12.30: SESSION: LANGUAGES I (Chair: Markku Sakkinen) - Clemens A. Szyperski (Swiss Federal Institute of Technology, Switzerland) "Import is not Inheritance - Why We Need Both: Modules and Classes" - Craig Chambers (University of Washington, USA) "Object-Oriented Multi-Methods in Cecil" 14.00 - 15.30: SESSION: THEORY I (Chair: Elspeth Cusack) - Thorsten Hartmann, Ralf Jungclaus, and Gunter Saake (Technische Universitat Braunschweig, Germany) "Aggregation in a Behaviour Oriented Object Model" - K.C. Lano (Oxford University, United Kingdom) and H. Haughton (Lloyds Register of Shipping, United Kingdom) "Reasoning and Refinement in Object-Oriented Specification Languages" - Tarmo Uustalu (Estonian Academy of Sciences, Estonia) "Combining Object-Oriented and Logic Paradigms: A Modal Logic Programming Approach" 15.50 - 17.20: SESSION: CLASS EVOLUTION/METHODOLOGY/USER INTERFACES (Chair: Rebecca Wirfs-Brock) - Eduardo Casais (Forschungszentrum Informatik, Germany) "Incremental Class Reorganization Algorithms" - Egil P. Andersen and Trygve Reenskaug (University of Oslo, Norway) "System Design by Composing Structures of Interacting Objects" - Veronique Normand (Bull-IMAG Systemes, France) and Joelle Coutaz (Laboratoire de Genie Informatique, France) "Unifying the Design and Implementation of User Interfaces through the Object Paradigm" 18.30 - 20.30: RECEPTION - Speech: Kristen Nygaard (University of Oslo, Norway) ------------------------------------------------------------------------ - Thursday, July 2, 1992 - ------------------------------------------------------------------------ 9.00 - 18.00: EXHIBITION 9.00 - 10.30: SESSION: CONCURRENCY (Chair: Mario Tokoro) - Rachid Guerraoui, Riccardo Capobianchi, Agnes Lanusse, and Pierre Roux (CE Saclay DEIN/SIR, France) "Nesting Actions through Asynchronous Message Passing: the ACS Protocol" - Svend Frolund (University of Illinois, USA) "Inheritance of Synchronization Constraints in Concurrent Object-Oriented Programming Languages" - J.-M. Jezequel (IRISA, France) "EPEE: an Eiffel Environment to Program Distributed Memory Parallel Computers" 11.00 - 12.30: SESSION: APPLICATIONS/EXPERIENCE (Chair: Walter Olthoff) - Bent Gabelgaard (Dansk MobilTelefon, Denmark) "Using Object-Oriented Programming Techniques for Implementing ISDN Supplementary Services" - Nguyen G.T., D. Rieu (Laboratoire de Genie Informatique, France) "An Object Model for Engineering Design" - Wing-cheong Lau (MCC, USA) and Vineet Singh (Hewlett-Packard Labs, USA) "An Object-Oriented Class Library for Scalable Parallel Heuristic Search" 14.00 - 15.00: INVITED SPEAKER - William Verplank (ID TWO, USA) "Object-Oriented User Interface Design" 15.20 - 16.20: SESSION: LANGUAGES II (Chair: Boris Magnusson) - Bjorn N. Freeman-Benson (University of Victoria, Canada) and Alan Borning (University of Washington, USA) "Integrating Constraints with an Object-Oriented Language" - Ian M. Holland (Northeastern University, USA) "Specifying Reusable Components using Contracts" 17.30 - 18.00: DEPARTURE FOR BANQUET 19.00 - 23.00: BANQUET in "Het Vechthuis" ------------------------------------------------------------------------ - Friday, July 3, 1992 - ------------------------------------------------------------------------ 9.00 - 17.00: EXHIBITION 9.00 - 10.30: PANEL (to be announced) 11.00 - 12.30: SESSION: THEORY II (Chair: Dave Thomas) - Mahesh Dodani and Chung-Shin Tsai (University of Iowa, USA) "ACTS: A Type System for Object-Oriented Programming Based on Abstract and Concrete Classes" - Nicholas Oxhoj, Jens Palsberg, and Michael I. Schwartzbach (Aarhus University, Denmark) "Making Type Inference Practical" - Suresh Jagannathan (NEC Research Institute, USA) and Gul Agha (University of Illinois, USA) "A Reflective Model of Inheritance" 14.00 - 15.30: SESSION: LANGUAGES/DATABASES (Chair: Anna-Kristin Profrock) - Mehmet Aksit, Lodewijk Bergmans, and Sinan Vural (University of Twente, the Netherlands) ************************************************************************ * * * EXHIBITION, DEMONSTRATIONS, AND PRESENTATIONS * * * ************************************************************************ ECOOP'92 will be accompanied by an exhibition in which commercial as well as non-commercial products supporting object-oriented technology will be demonstrated. The exhibition is opened for three days (Wednesday, Thursday, and Friday), not only to the participants of the conference, but also to others that are interested. Exhibitors and demonstrators have the possibility to give a half hour presentation in a presentation session. Exhibition: Companies interested in exhibiting their commercial products should contact Novep Conference Organizers in Amsterdam. They will provide you with an exhibitors kit, and answer all questions about the technical details of the exhibition. Novep can be contacted at: Novep Conference Organizers Paulus Potterstraat 40 1071 DB Amsterdam The Netherlands Phone: +31 20 664 5876 Fax: +31 20 662 8136 All additional questions concerning the exhibition can be directed to: Paul Hendriks Software Engineering Research Centre - SERC P.O. Box 424 3500 AK Utrecht The Netherlands E-mail: ecoop92-exh@serc.nl Phone: +31 30 322640 Fax: +31 30 341249 Demonstrations: Poster sessions and demonstrations of (academic) software can be given to illustrate innovative concepts. A description accompanied by platform requirements should be submitted before April 1 to the following address. A form to fill in this information can be acquired by contacting: Chris Laffra Software Engineering Research Centre - SERC P.O. Box 424 3500 AK Utrecht The Netherlands E-mail: ecoop92-demo@serc.nl Phone: +31 30 322640 Fax: +31 30 341249 Presentations: Participants in the exhibition or demonstrations have the opportunity to elucidate their products in a half hour presentation. They can express their willingness to do so by filling in the corresponding slots in the exhibitors kit or the demonstrations form. ************************************************************************ * * * ORGANISATION * * * ************************************************************************ Sponsor: Software Engineering Research Centre - SERC, the Netherlands Co-sponsoring Organisations: BCS (British Computer Society) Koning en Hartman Datex NGI (Dutch Computer Society) DND (Norwegian Computer Society) Object Management Group Electric Engineering OCG (Austrian Computer Society) Georg Heeg Smalltalk-80-Systems Philips Getronics Network Services RAET Getronics Service SI (Swiss Computer Society) IBM Sun Microsystems Interpersonal Computing Group Organisation: Conference Chair: Pierre America Philips, the Netherlands Program Chair: Ole Lehrmann Madsen Aarhus University, Denmark Organising Chair: Gert Florijn SERC, the Netherlands Tutorials: Mehmet Aksit University of Twente, the Netherlands Exhibition: Paul Hendriks SERC, the Netherlands Demonstrations: Chris Laffra SERC, the Netherlands Program Committee: Ole Lehrmann Madsen (chair) Aarhus University, Denmark Alan Borning University of Washington, USA Jean-Pierre Briot Universite Pierre et Marie Curie, France Pierre Cointe Universite Pierre et Marie Curie, France Elspeth Cusack British Telecom, United Kingdom Nigel Derrett Hewlett-Packard Laboratories, United Kingdom Klaus Dittrich Universitat Zurich, Switzerland Roger Duke University of Queensland, Australia Eric Jul Kobenhavns Universitet, Denmark Boris Magnusson Lund University, Sweden Bertrand Meyer Interactive Software Engineering, USA Ron Morrison University of St. Andrews, United Kingdom Oscar Nierstrasz Universite de Geneve, Switzerland Walter Olthoff German Research Center for AI, Germany Barbara Pernici Universita di Udine, Italy Jean-Francois Perrot Universite Pierre et Marie Curie, France Anna-Kristin Profrock Siemens Nixdorf, Germany Trygve Reenskaug Taskon A/S, Norway Markku Sakkinen University of Jyvaskyla, Finland Dave Thomas Object Technology International, Canada Mario Tokoro Sony CSL, Japan Enn Tyugu Institute of Cybernetics, Estonia Rebecca Wirfs-Brock Instantiations, USA Akinori Yonezawa University of Tokyo, Japan Ed Yourdon American Programmer, USA ************************************************************************ * * * GENERAL INFORMATION AND REGISTRATION * * * ************************************************************************ Conference Venue: ECOOP'92 will be held in the Jaarbeurs Congress Centre in Utrecht. The "Jaarbeurs" is within walking distance of the city centre of Utrecht, and very near to Utrecht's central train station. The address of the Jaarbeurs is: Jaarbeurs Congress Centre Jaarbeursplein 2521 AL Utrecht The Netherlands Transportation to and in Utrecht: Utrecht is one of the largest Dutch cities, and it is situated right in the centre of the Netherlands. Public transportation within Utrecht (by bus and tram) and to other parts of the Netherlands (by train) is excellent. Trains to other major cities such as Rotterdam, the Hague, and Amsterdam leave approximately every half hour, and take 30 to 60 minutes. Since the conference venue is very close to the central station, and Dutch roads and parking places are crowded, it is not advisable to rent a car. Utrecht does not have its own airport. A train-ride from Schiphol (the international airport of Amsterdam) to Utrecht takes about 60 minutes. Trains from Schiphol to Amsterdam central station leave every half hour. There you can get a connection to Utrecht central station. Accommodation: Hotel bookings are handled by the Utrecht Tourist Office (the "VVV"). An application form is enclosed. It should be returned to the tourist office no later than May 1, 1992. For further information, you can contact the tourist office: Hotelreservations VVV Utrecht Vredenburg 90 3511 BD Utrecht The Netherlands Phone: +31 30 331544 Fax: +31 30 331417 Registration The registration for the conference is handled by Novep Conference Organizers in Amsterdam. Questions about registration, payment, etc. should be directed to them. You can contact them at: Novep Conference Organizers Paulus Potterstraat 40 1071 DB Amsterdam The Netherlands Phone: +31 20 664 5876 Fax: +31 20 662 8136 - Copy the following registration form and fax or mail the completed form to Novep Conference Organizers. - All prices are indicated in Dutch guilders (Dfl) and are including VAT. - The conference fee includes a copy of the proceedings, reception, refreshments, and lunches on Wednesday, Thursday, and Friday. - The tutorial fee includes a copy of the tutorial notes, refreshments, and a lunch. - The early registration fee is only applicable if payment is received before May 1, 1992. - The reduced rates are only available to members of the British (BCS), Norwegian (DND), Dutch (NGI), Austrian (OCG), and Swiss (SI) computer societies. - The student rate is only available to full-time students. A photocopy of a valid student card, or other proof of student status has to be included with the registration form. - You will receive a confirmation of your registration as soon as your payment is received. - The organisation of ECOOP reserves the right to cancel a tutorial. In the event of cancellation you will be given the option of attending another tutorial. Cancellation: Notification of cancellation must be sent to Novep Conference Organisers. Cancellation made prior to June 1, 1992 will be subject to a 25% cancellation fee. After this date fees are non-refundable. A substitute can be sent in place. In the event that any one of the advertised speakers is, for reasons outside the control of the organisation committee, unable to attend the conference, the organisation committee reserves the right, without notice, to make such alteration or substitution as it deems fit. Delegates will have no claims against the organisation committee, in respect of such alteration or substitution. Further Information about the Program: For further information about the conference and the programme, please contact: Gert Florijn Software Engineering Research Centre - SERC P.O. Box 424 3500 AK Utrecht The Netherlands E-mail: ecoop92@serc.nl Phone: +31 30 322640 Fax: +31 30 341249 ************************************************************************ * * * Registration Form ECOOP'92 * * * ************************************************************************ Surname: ___________________________ First name: _________ [] Mr. [] Ms. Company name: __________________________________________________________ Address: _______________________________________________________________ City: ____________________________________ Zip code: ___________________ State/Country: _________________________________________________________ Phone: _______________ Fax: _______________ E-mail: ____________________ [] BCS/DND/NGI/OCG/SI member no.: ______________________________________ [] Full-time student (please include a photocopy of a valid student card, or other proof of student status) would like to register for: Early Late Conference: Dfl ______ | Conference: Full-day Tutorials: | Regular Dfl 800,-- Dfl 900,-- [] T1 or [] T2 Dfl ______ | Reduced Dfl 740,-- Dfl 820,-- [] T5, [] T6, or [] T7 Dfl ______ | Students Dfl 350,-- Dfl 400,-- Half-day Tutorials: | Full-day Tutorials: [] T3 Dfl ______ | Regular Dfl 350,-- Dfl 400,-- [] T4 Dfl ______ | Reduced Dfl 300,-- Dfl 350,-- [] T8 Dfl ______ | Students Dfl 175,-- Dfl 215,-- [] T9 Dfl ______ | Half-day Tutorials: Banquet: | Regular Dfl 240,-- Dfl 280,-- Dfl 75,-- x ___ = Dfl ______ | Reduced Dfl 180,-- Dfl 220,-- ========== | Students Dfl 105,-- Dfl 135,-- Total amount to be paid: Dfl ______ | Banquet: (Dfl 75,-- per person) | [] Vegetarian The early registration fee is only applicable if payment is received before May 1, 1992. Please indicate by which means you have paid: [] Remitted to bank account ABN/AMRO Utrecht, account number 55.50.72.487, stating SERC-ECOOP'92 and attendees name. [] Bankers' draft forwarded together with the registration form. The draft should be made out to SERC-ECOOP'92 net of bank charges. [] Credit Card: [] Euro/Master/Access card [] American Express [] Diners Club [] Visa Card Charge my card number: _____________ Expiration date: ____________ This is a company/private card in the name of: ___________________ Place: ________________ Date: _____________ Signature: _________________ Please copy and mail or fax this form as soon as possible to: Novep Conference Organizers Paulus Potterstraat 40 1071 DB Amsterdam The Netherlands Phone: +31 20 664 5876 Fax: +31 20 662 8136 ************************************************************************ * * * Hotel Reservation Form ECOOP'92 * * * ************************************************************************ Surname: ___________________________ First name: _________ [] Mr. [] Ms. Company name: __________________________________________________________ Address: _______________________________________________________________ City: ____________________________________ Zip code: ___________________ State/Country: _________________________________________________________ Phone: _______________ Fax: _______________ E-mail: ____________________ would like to reserve for ______ person(s) ________ single room(s) with/without bath/shower/toilet ________ double room(s) with/without bath/shower/toilet Date of arrival: __________________ Date of departure: _________________ Price Categories (Please mark the requested category) Single Double [] Dfl 175,-- - Dfl 255,-- [] Dfl 225,-- - Dfl 295,-- [] Dfl 115,-- - Dfl 165,-- [] Dfl 150,-- - Dfl 200,-- [] Dfl 75,-- - Dfl 110,-- [] Dfl 110,-- - Dfl 140,-- [] Dfl 45,-- - Dfl 70,-- [] Dfl 70,-- - Dfl 100,-- When the hotels are fully booked, I will/will not accept a reservation in another class/outside Utrecht. Send this form back before May 1, 1992 to: VVV Utrecht Vredenburg 90 3511 BD Utrecht The Netherlands Phone: +31 30 331544 Fax: +31 30 331417 You will receive a confirmation of your reservation from the tourist information office. The reservation has to be paid to the tourist information office in Dutch guilders. Means of payment are indicated in the reservation confirmation. Further information on the hotel reservation: Hotelreservations VVV Utrecht, Phone: +31 30 331544, Fax: +31 30 331417. ======================================================================= 40 === Date: 2 Apr 92 06:48:32 GMT From: nichols@parc.xerox.com (David Nichols) Subject: Re: Network Reader and Writer Yes, just create a socket using Usocket.socket bind it and connect normally, and then use UFileRdWr.CreateFileReader or UFileRdWr.CreateFileWriter to create a reader or writer on it. You don't get access to things like urgent data handling, but it's good for most purposes. David ======================================================================= 41 === Date: Fri, 3 Apr 1992 00:07:42 -0800 (PST) From: "David L. Miller" Subject: Passing Procedure pointers Newsgroups: comp.lang.modula3 Distribution: world Organization: Washington State University Tri-Cities, Richland Keywords: I need to be able to pass a reference to a procedure from one module to another. In C, I would do it something like: struct entry { void (*pfunc)() ; /* pointer to function */ int p0, p1, p2 ; /* parameters to pfunc() */ } struct entry A[100] ; void f1(int q0, q1, q2) { ... } main() { A[0].pfunc = f1 ; A[1].pfunc = f2 ; ... (*(A[0].pfunc))(A[0].p1,A[0].p2,A[0].p0) ; /* execute f1 */ ... } Is there a way to do this in Modula-3? --DLM ***************************************************************************** David L. Miller Internet: dmiller@beta.tricity.wsu.edu Systems Programmer/Network Analyst BITNET: MILLERD@WSUVM1 Washington State University Tri-Cities UUCP: ...!yoda!dmiller 100 Sprout Road Richland, WA 99352 Phone: (509)375-9245 ***************************************************************************** ======================================================================= 42 === Date: 2 Apr 92 15:39:02 GMT From: bs@alice.att.com (Bjarne Stroustrup) Subject: Re: Modula 3 versus C++ libraries mathew@elroy.jpl.nasa.gov (Mathew Yeates @ Image Analysis Systems Group, JPL) w rites > Furthermore, exception handling has not yet been > approved in ANSI C++. Thus implementations are possibly two years away Minor correction: Exception handling was approved by the ANSI/ISO C++ committee last year. Implementations exists an the first commercial ones are shipping thi s year (e.g. IBM has announced a C++ compiler supporting exceptions for their RS/ 6000 series to ship in May or June ((I don't remember which)) ======================================================================= 43 === Date: Wed, 1 Apr 1992 23:26:19 GMT From: nr@elan (Norman Ramsey) Subject: Re: tcl and Modula-3 > Has anyone implemented a Modula-3/TCL interface? A long time back, Eric Muller posted a Modula-3 interface to the C TCL library. I wrote down a Modula-3/TCL interface that used Modula-3 types rather than C types, and that used objects to build closures for commands. I wrote part of the implementation but never finished it. I have mailed copies to carroll@udel.edu, who asked the question, and I will post them if there seems to be general interest. ======================================================================= 44 === Date: Fri, 3 Apr 92 09:32:23 +0200 From: a.vermeulen@ECN.NL (Vermeulen A.T.) Subject: Re: Pkl.Write generates ASSERT failure (M3 2.03 on sparcstation) Joe Morrison (jmorrison@gte.com) states in his email-message of 27 Mar 92 15:40 :16 GMT: > Is this any kind of known problem? Might it be fixed in 2.04? > Thanks in advance... Get V2.04, because this one compiles also succesfully, but what's more importan t, it even runs correctly, so Pickles is corrected in 2.04! Alex Vermeulen -- Netherlands Energy Research Foundation Email: a.vermeulen@ecn.nl P.O. Box 1 Phone: (+31) 2246 4194 1755 ZG Petten, The Netherlands ======================================================================= 45 === Date: Fri, 3 Apr 92 11:09:55 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Passing Procedure pointers In article , "David L. Mill er" writes: > I need to be able to pass a reference to a procedure from one module to > another. In C, I would do it something like: > > struct entry { > void (*pfunc)() ; /* pointer to function */ > int p0, p1, p2 ; /* parameters to pfunc() */ > } > > struct entry A[100] ; > > void f1(int q0, q1, q2) > { > ... > } > > main() > { > A[0].pfunc = f1 ; > A[1].pfunc = f2 ; > ... > (*(A[0].pfunc))(A[0].p1,A[0].p2,A[0].p0) ; /* execute f1 */ > ... > } > Is there a way to do this in Modula-3? Of course ! MODULE Main; TYPE struct_entry = RECORD pfunc: PROCEDURE (q0, q1, q2: INTEGER); p0, p1, p2: INTEGER; END; VAR A : ARRAY [0..99] OF struct_entry; PROCEDURE f1 (q0, q1, q2: INTEGER) = ... PROCEDURE f2 (q0, q1, q2: INTEGER) = ... BEGIN A[0].pfunc := f1; A[1].pfunc := f2; ... A[0].pfunc (A[0].p1, A[0].p2, A[0].p0); ... END Main. This is the strict translation to C. It offers the possibility of building A in Modula-3 and to pass it to C code and use it as in your example (or the other way around). A more Modula-3ish way involves objects: TYPE closure = OBJECT p0, p1, p2: INTEGER; METHOD apply (); END; VAR A : ARRAY [0..99] OF closure; PROCEDURE f1 (self: closure) = ... (* use self.p0, self.p1, self.p2 *) BEGIN A[0] := NEW (closure, apply := f1); ... A[0].p0 := 3; ... A[0].apply (); ... END Main. -- Eric. ======================================================================= 46 === Date: Fri, 3 Apr 92 10:48:16 PST From: muller@src.dec.com (Eric Muller) Subject: Re: why does my debugger say "source not available"? In article , mod3sys@gonzo.cc.wwu.edu (modula3 system programmer) writes: > I spent about an hour trying to tweak dbx into figuring out where the source > file is. Is there a standard way for DS-3100 users of SRC Modula-3 Version > 2.04 to step through lines, and so on? Yes, I used the -g1 switch at > compile and link time. To help debugging, the result of a "normal" compilation contains lines of the form: #line 200 "Foo.m3" However, this does not happens for the piece of C generated by the linker, which defines main(), because there is no corresponding Modula-3 source. You can either: - give the -k option to m3, this will keep this C file around (_m3main.c) and dbx should able to find it. - ignore the message given by dbx, and put a breakpoint in your "real" main program. You can set a breakpoint in the function that implements the boby of module Foo (in the file Foo.m3) by: (dbx) stop in Foo._init_ (this function is static, and there is one _init_ per module; you need to qualify it with the file name). If you are trying to debug the compiler or the driver built from a bootstrap archive, you don't have the Modula-3 sources (distributed separately). If you grab the compiler-2.04 or driver-2.04 archive and unpack it, you will get the sources. You just need to tell dbx where they are: (dbx) use /compiler/src/exprs (dbx) use /compiler/src/types ... or (dbx) use /driver/src You also need to add: (dbx) use /compiler/boot-DS3100 or (dbx) use /driver/boot-DS3100 to get the main program (in _m3main.c). --- Eric. ======================================================================= 47 === Date: Fri, 3 Apr 92 11:00:41 PST From: muller@src.dec.com (Eric Muller) Subject: Re: tcl and Modula-3 In article <1992Apr1.232619.18244@newross.Princeton.EDU>, nr@elan (Norman Ramse y) writes: > > > Has anyone implemented a Modula-3/TCL interface? > > A long time back, Eric Muller posted a Modula-3 interface to the C TCL > library. Here it is. It compiles, but I have no idea of the version of TCL this corresponds to (except that I wrote it in March 91). I'll be happy to put this or an udpated version in the next release. There is also a little test program to show how it works; I cannot rebuild it right now, I don't have TCL installed; I don't even know if it compiles. -- Eric. (* Copyright (C) 1991, Digital Equipment Corporation *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* Last modified on Fri Apr 03 10:57:20 PST 1992 by muller *) (* This file is derived from tcl.h, covered by the following copyright: * Copyright 1987, 1990 Regents of the University of California * Permission to use, copy, modify, and distribute this * software and its documentation for any purpose and without * fee is hereby granted, provided that the above copyright * notice appear in all copies. The University of California * makes no representations about the suitability of this * software for any purpose. It is provided "as is" without * express or implied warranty. *) UNSAFE INTERFACE TclC; FROM Ctypes IMPORT char_star, int_star, int, char, double; IMPORT Word; CONST TCL_OK = 0; TCL_ERROR = 1; TCL_RETURN = 2; TCL_BREAK = 3; TCL_CONTINUE = 4; BRACKET_TERM = 1; NO_EVAL = -1; STATIC = 0; DYNAMIC = 1; VOLATILE = 2; TRACE_READS = 1; TRACE_WRITES = 2; TRACE_DELETES = 4; VARIABLE_UNDEFINED = 8; TYPE Argv = UNTRACED REF ARRAY [0..255] OF char_star; Interp = RECORD result: char_star; (* Points to result string returned by command. *) dynamic: int; (* Non-zero means result is dynamically- allocated and must be freed by Eval before executing the next command. *) errorLine: int; (* When TCL_ERROR is returned, this gives the line number within the command where the error occurred (1 means first line). *) END; InterpStar = UNTRACED REF Interp; ClientData = Word.T; <*EXTERNAL Tcl_AddErrorInfo *> PROCEDURE AddError (interp: InterpStar; message: char_star); <*EXTERNAL Tcl_AppendResult *> PROCEDURE AppendResult (interp: InterpStar; s1, s2, s3, s4, s5: char_star := NIL); TYPE CmdBuf = int_star; <*EXTERNAL Tcl_CreateCmdBuf *> PROCEDURE CreateCmdBuf (): CmdBuf; <*EXTERNAL Tcl_DeleteCmdBuf *> PROCEDURE DeleteCmdBuf (buffer: CmdBuf); <*EXTERNAL Tcl_AssembleCmd *> PROCEDURE AssembleCmd (buffer: CmdBuf; string: char_star): char_star; <*EXTERNAL Tcl_Backslash *> PROCEDURE Backslash (src: char_star; VAR count: int): char; <*EXTERNAL Tcl_Concat *> PROCEDURE Concat (argc: int; argv: Argv): char_star; TYPE CommandProc = PROCEDURE (clientData: ClientData; interp: InterpStar; argc: int; argv: Argv): int; DeleteProc = PROCEDURE (clientData: ClientData); <*EXTERNAL Tcl_CreateCommand *> PROCEDURE CreateCommand (interp: InterpStar; cmdName: char_star; proc: CommandProc; clientData: ClientData; deleteProc: DeleteProc); <*EXTERNAL Tcl_CreateInterp *> PROCEDURE CreateInterp (): InterpStar; TYPE TraceProc = PROCEDURE (clientData: ClientData; interp: InterpStar; level: int; command: char_star; cmdProc: CommandProc; cmdClientData: ClientData; argc: int; argv: Argv); Trace = int_star; <*EXTERNAL Tcl_CreateTrace *> PROCEDURE CreateTrace (interp: InterpStar; level: int; proc: TraceProc; clientData: ClientData): Trace; <*EXTERNAL Tcl_DeleteCommand *> PROCEDURE DeleteCommand (interp: InterpStar; cmdName: char_star); <*EXTERNAL Tcl_DeleteInterp *> PROCEDURE DeleteInterp (interp: InterpStar); <*EXTERNAL Tcl_DeleteTrace *> PROCEDURE DeleteTrace (interp: InterpStar; trace: Trace); <*EXTERNAL Tcl_Eval *> PROCEDURE Eval (interp: InterpStar; cmd: char_star; flags: int; termPtr: Argv): int; <*EXTERNAL Tcl_Expr *> PROCEDURE Expr (interp: InterpStar; string: char_star; VAR value: int): int; <*EXTERNAL Tcl_GetInt *> PROCEDURE GetInt (interp: InterpStar; string: char_star; VAR val: int): int; <*EXTERNAL Tcl_GetDouble *> PROCEDURE GetDouble (interp: InterpStar; string: char_star; VAR val: double): int; <*EXTERNAL Tcl_GetBoolean *> PROCEDURE GetBoolean (interp: InterpStar; string: char_star; VAR value: int): int; <*EXTERNAL Tcl_GetVar *> PROCEDURE GetVar (interp: InterpStar; varName: char_star; global: int): char_star; <*EXTERNAL Tcl_Merge *> PROCEDURE Merge (argc: int; argv: Argv): char_star; <*EXTERNAL Tcl_ParseVar *> PROCEDURE ParseVar (interp: InterpStar; string: char_star; term: Argv): char_star; <*EXTERNAL Tcl_RecordAndEval *> PROCEDURE RecordAndEval (interp: InterpStar; cmd: char_star; flags: int): int; <*EXTERNAL Tcl_Return *> PROCEDURE Return (interp: InterpStar; string: char_star; status: int); <*EXTERNAL Tcl_SetVar *> PROCEDURE SetVar (interp: InterpStar; varName, newValue: char_star; global: int ); <*EXTERNAL Tcl_SplitList *> PROCEDURE SplitList (interp: InterpStar; list: char_star; VAR argc: int; VAR argv: Argv): int; <*EXTERNAL Tcl_StringMatch *> PROCEDURE StringMatch (string, pattern: char_star): int; <*EXTERNAL Tcl_TildeSubst *> PROCEDURE TildeSubst (interp: InterpStar; name: char_star): char_star; TYPE VarTraceProc = PROCEDURE (clientData: ClientData; interp: InterpStar; varName: char_star; global, flags: int; oldValue, newValue: char_star): char_star; <*EXTERNAL Tcl_TraceVar *> PROCEDURE TraceVar (interp: InterpStar; varName: char_star; global, flags: int; proc: VarTraceProc; clientData: ClientData): int; <*EXTERNAL Tcl_UnTraceVar *> PROCEDURE UnTraceVar (interp: InterpStar; varName: char_star; global: int); <*EXTERNAL Tcl_VarTraceInfo *> PROCEDURE VarTraceInfo (interp: InterpStar; varName: char_star; global: int; VAR proc: VarTraceProc; VAR clientData: ClientData): int; END TclC. (* Copyright (C) 1991, Digital Equipment Corporation *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) UNSAFE MODULE TclCTest EXPORTS Main; IMPORT TclC; IMPORT Rd, Wr, Stdio, Fmt; FROM M3toC IMPORT TtoS, CopyTtoS, CopyStoT; FROM Ctypes IMPORT int, char_star; PROCEDURE FactCmd (<*UNUSED*> clientData: TclC.ClientData; interp: TclC.InterpStar; argc: int; argv: TclC.Argv): int = BEGIN IF argc # 2 THEN interp.result := TtoS ("fact has exactly one argument"); RETURN TclC.TCL_ERROR; ELSE VAR i: INTEGER; BEGIN IF TclC.GetInt (interp, argv[1], i) = TclC.TCL_ERROR THEN RETURN TclC.TCL_ERROR; END; interp.result := CopyTtoS (Fmt.Int (Fact (i))); RETURN TclC.TCL_OK; END; END; END FactCmd; PROCEDURE Fact (i: INTEGER): INTEGER = BEGIN IF i = 1 THEN RETURN 1; ELSE RETURN i * Fact (i - 1); END; END Fact; VAR i: TclC.InterpStar; buf: TclC.CmdBuf; s: char_star; status: int; BEGIN i := TclC.CreateInterp (); TclC.CreateCommand (i, TtoS ("fact"), FactCmd, 0, NIL); buf := TclC.CreateCmdBuf (); TRY LOOP Wr.PutText (Stdio.stdout, "-> "); s := TclC.AssembleCmd (buf, TtoS (Rd.GetLine (Stdio.stdin) & "\n")); IF s # NIL THEN status := TclC.RecordAndEval (i, s, 0); CASE status OF | TclC.TCL_OK => Wr.PutText (Stdio.stdout, CopyStoT (i.result) & "\n"); | TclC.TCL_ERROR => Wr.PutText (Stdio.stderr, "error: " & CopyStoT (i.result) & "\n"); ELSE Wr.PutText (Stdio.stderr, "TclC.Eval returned with code = " & Fmt.Int (status) & "\n"); END; END; END; EXCEPT | Rd.EndOfFile => END; TclC.DeleteCmdBuf (buf); TclC.DeleteInterp (i); END TclCTest. ======================================================================= 48 === Date: Fri, 3 Apr 92 19:12:25 PST From: muller@src.dec.com (Eric Muller) Subject: Re: tcl and Modula-3 In article <1992Apr3.110041.28332@src.dec.com>, muller@src.dec.com (Eric Muller ) writes: > In article <1992Apr1.232619.18244@newross.Princeton.EDU>, nr@elan (Norman Ram sey) writes: > > > > > Has anyone implemented a Modula-3/TCL interface? > > > > A long time back, Eric Muller posted a Modula-3 interface to the C TCL > > library. > > Here it is. It compiles, but I have no idea of the version of TCL > this corresponds to (except that I wrote it in March 91). I'll be > happy to put this or an udpated version in the next release. Here is a version that should work with TCL 6.2. I am working on a nice Modula-3 interface (interpreters are objects, char_star are Text.T, and so on). Enjoy, Eric. #!/bin/sh # This is a shell archive (shar 3.32) # made 04/04/1992 03:06 UTC by muller@procope.pa.dec.com # Source directory /tmp_mnt/flimflam/r/dlusers5/muller/tmp/tclexport # # existing files WILL be overwritten # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 13775 -rw-r--r-- TclC.i3 # 359 -rw-r--r-- TclC.m3 # 2167 -rw-r--r-- TclCTest.m3 # if touch 2>&1 | fgrep 'amc' > /dev/null then TOUCH=touch else TOUCH=true fi # ============= TclC.i3 ============== echo "x - extracting TclC.i3 (Text)" sed 's/^X//' << 'SHAR_EOF' > TclC.i3 && X(* Copyright (C) 1991, Digital Equipment Corporation *) X(* All rights reserved. *) X(* See the file COPYRIGHT for a full description. *) X X(* Last modified on Fri Apr 03 19:09:01 PST 1992 by muller *) X X(* Version 6.2 of TCL *) X X(* This file is derived from tcl.h, covered by the following copyright: X X * Copyright 1987, 1990 Regents of the University of California X * Permission to use, copy, modify, and distribute this X * software and its documentation for any purpose and without X * fee is hereby granted, provided that the above copyright X * notice appear in all copies. The University of California X * makes no representations about the suitability of this X * software for any purpose. It is provided "as is" without X * express or implied warranty. X *) X XUNSAFE INTERFACE TclC; X XFROM Ctypes IMPORT char_star, int_star, int, char, X double_star, int_star_star, long_star; XIMPORT Word; X XCONST X TCL_OK = 0; X TCL_ERROR = 1; X TCL_RETURN = 2; X TCL_BREAK = 3; X TCL_CONTINUE = 4; X X TCL_RESULT_SIZE = 199; X X BRACKET_TERM = 1; X DONT_USE_BRACES = 1; X NO_EVAL = -1; X XVAR (* READONLY *) X volatile, static, dynamic: FreeProc; X XCONST X GLOBAL_ONLY = 1; X APPEND_VALUE = 2; X LIST_ELEMENT = 4; X NO_SPACE = 8; X TRACE_READS = 16_10; X TRACE_WRITES = 16_20; X TRACE_UNSETS = 16_40; X TRACE_DESTROYED = 16_80; X INTERP_DESTROYED = 16_100; X LEAVE_ERR_MSG = 16_200; X X VARIABLE_UNDEFINED = 8; X XTYPE X FreeProc = PROCEDURE (blockPtr: char_star); X X Interp = RECORD X result: char_star; X freeProc: FreeProc; X errorLine: int; END; X X Interp_star = UNTRACED REF Interp; X X ClientData = Word.T; X X Argv = UNTRACED REF ARRAY [0..255] OF char_star; X Argv_star = UNTRACED REF Argv; X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_AddErrorInfo *> XPROCEDURE AddErrorInfo (interp: Interp_star; message: char_star); X X<*EXTERNAL Tcl_SetErrorCode *> XPROCEDURE SetErrorCode (interp: Interp_star; X s1, s2, s3, s4, s5: char_star := NIL); X X<*EXTERNAL Tcl_UnixError *> XPROCEDURE UnixError (interp: Interp_star): char_star; X X(*---------------------------------------------------------------------------* ) X XTYPE X CmdBuf = int_star; X X<*EXTERNAL Tcl_CreateCmdBuf *> XPROCEDURE CreateCmdBuf (): CmdBuf; X X<*EXTERNAL Tcl_DeleteCmdBuf *> XPROCEDURE DeleteCmdBuf (buffer: CmdBuf); X X<*EXTERNAL Tcl_AssembleCmd *> XPROCEDURE AssembleCmd (buffer: CmdBuf; string: char_star): char_star; X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_Backslash *> XPROCEDURE Backslash (src: char_star; count: int_star): char; X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_Concat *> XPROCEDURE Concat (argc: int; argv: Argv): char_star; X X(*---------------------------------------------------------------------------* ) X XTYPE X CmdProc = PROCEDURE (clientData: ClientData; X interp: Interp_star; X argc: int; X argv: Argv): int; X X CmdDeleteProc = PROCEDURE (clientData: ClientData); X X<*EXTERNAL Tcl_CreateCommand *> XPROCEDURE CreateCommand (interp: Interp_star; X cmdName: char_star; X proc: CmdProc; X clientData: ClientData; X deleteProc: CmdDeleteProc); X X<*EXTERNAL Tcl_DeleteCommand *> XPROCEDURE DeleteCommand (interp: Interp_star; X cmdName: char_star); X X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_CreateInterp *> XPROCEDURE CreateInterp (): Interp_star; X X<*EXTERNAL Tcl_DeleteInterp *> XPROCEDURE DeleteInterp (interp: Interp_star); X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_CreatePipeline *> XPROCEDURE CreatePipeline (interp: Interp_star; X argc: int; X argv: Argv; X pidArrayPtr: int_star_star; X inPipePtr: char_star; X outPipePtr: char_star; X errFilePr: char_star): int; X X(*---------------------------------------------------------------------------* ) X XTYPE X CmdTraceProc = PROCEDURE (clientData: ClientData; X interp: Interp_star; X level: int; X command: char_star; X cmdProc: CmdProc; X cmdClientData: ClientData; X argc: int; X argv: Argv); X Trace = int_star; X X<*EXTERNAL Tcl_CreateTrace *> XPROCEDURE CreateTrace (interp: Interp_star; X level: int; X proc: CmdTraceProc; X clientData: ClientData): Trace; X X<*EXTERNAL Tcl_DeleteTrace *> XPROCEDURE DeleteTrace (interp: Interp_star; trace: Trace); X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_Eval *> XPROCEDURE Eval (interp: Interp_star; X cmd: char_star; X flags: int; X termPtr: Argv): int; X X<*EXTERNAL Tcl_VarEval *> XPROCEDURE VarEval (interp: Interp_star; X s1, s2, s3, s4, s5: char_star := NIL): int; X X<*EXTERNAL Tcl_EvalFile *> XPROCEDURE EvalFile (interp: Interp_star; X fileName: char_star); X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_ExprLong *> XPROCEDURE ExprLong (interp: Interp_star; X string: char_star; longPtr: long_star): int; X X<*EXTERNAL Tcl_ExprDouble *> XPROCEDURE ExprDouble (interp: Interp_star; X string: char_star; doublePtr: double_star): int; X X<*EXTERNAL Tcl_ExprBoolean *> XPROCEDURE ExprBoolean (interp: Interp_star; X string: char_star; booleanPtr: int_star): int; X X<*EXTERNAL Tcl_ExprString *> XPROCEDURE ExprString (interp: Interp_star; X string: char_star): int; X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_Fork *> XPROCEDURE Fork (): int; X X<*EXTERNAL Tcl_WaitPids *> XPROCEDURE WaitPids (numPids: int; pidPtr, statusPtr: int_star): int; X X<*EXTERNAL Tcl_DetachPids *> XPROCEDURE DetachPids (numPids: int; pidPtr: int_star): int; X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_GetInt *> XPROCEDURE GetInt (interp: Interp_star; X string: char_star; intPtr: int_star): int; X X<*EXTERNAL Tcl_GetDouble *> XPROCEDURE GetDouble (interp: Interp_star; X string: char_star; doublePtr: double_star): int; X X<*EXTERNAL Tcl_GetBoolean *> XPROCEDURE GetBoolean (interp: Interp_star; X string: char_star; boolPtr: int_star): int; X X(*---------------------------------------------------------------------------* ) X XTYPE X HashEntry = RECORD X nextPtr: HashEntry_star; X tablePtr: HashTable_star; X bucketPtr: HashEntry_star_star; X clientData: ClientData; X key: Word.T; END; X HashEntry_star = UNTRACED REF HashEntry; X HashEntry_star_star = UNTRACED REF HashEntry_star; X X XCONST X SMALL_HASH_TABLE = 4; X XTYPE X HashTable = RECORD X buckets: HashEntry_star_star; X staticBuckets: ARRAY [0..SMALL_HASH_TABLE-1] OF HashEntry_star ; X numBuckets: int; X numEntries: int; X rebuildSize: int; X downShift: int; X mask: int; X keyType: int; X findProc: PROCEDURE (tablePtr: HashTable_star; X key: char_star): HashEntry_star; X createProc: PROCEDURE (tablePtr: HashTable_star; X key: char_star; X newPtr: int_star): HashEntry_star; END; X X HashTable_star = UNTRACED REF HashTable; X X HashSearch = RECORD X tablePtr: HashTable_star; X nextIndex: int; X nextEntryPtr: HashEntry_star; END; X X HashSearch_star = UNTRACED REF HashSearch; X X<*EXTERNAL Tcl_InitHashTable *> XPROCEDURE InitHashTable (tablePtr: HashTable_star; keyType: int); X X<*EXTERNAL Tcl_DeleteHashTable *> XPROCEDURE DeleteHashTable (tablePtr: HashTable_star); X X<*EXTERNAL Tcl_CreateHashEntry *> XPROCEDURE CreateHashEntry (tablePtr: HashTable_star; X key: char_star; newPtr: int_star): HashEntry_star; X X<*EXTERNAL Tcl_DeleteHashEntry *> XPROCEDURE DeleteHashEntry (entryPtr: HashEntry_star); X X<*EXTERNAL Tcl_FindHashEntry *> XPROCEDURE FindHashEntry (tablePtr: HashTable_star; X key: char_star): HashEntry_star; X X<*EXTERNAL Tcl_GetHashValue *> XPROCEDURE GetHashValue (entryPtr: HashEntry_star): ClientData; X X<*EXTERNAL Tcl_SetHashValue *> XPROCEDURE SetHashValue (entryPtr: HashEntry_star; value: ClientData); X X<*EXTERNAL Tcl_GetHashKey *> XPROCEDURE GetHashKey (tablePtr: HashTable_star; X entryPtr: HashEntry_star): char_star; X X<*EXTERNAL Tcl_FirstHashEntry *> XPROCEDURE FirstHashEntry (tablePtr: HashTable_star; X searchPtr: HashSearch_star): HashEntry_star; X X<*EXTERNAL Tcl_NextHashEntry *> XPROCEDURE NextHashEntry (searchPtr: HashSearch_star): HashEntry_star; X X<*EXTERNAL Tcl_HashStats *> XPROCEDURE HashStats (tablePtr: HashTable_star): char_star; X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_InitHistory *> XPROCEDURE InitHistory (interp: Interp_star); X X<*EXTERNAL Tcl_RecordAndEval *> XPROCEDURE RecordAndEval (interp: Interp_star; X cmd: char_star; flags: char): int; X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_SetResult *> XPROCEDURE SetResult (interp: Interp_star; X string: char_star; freeProc: FreeProc); X X<*EXTERNAL Tcl_AppendResult *> XPROCEDURE AppendResult (interp: Interp_star; X s1, s2, s3, s4, s5: char_star := NIL); X X<*EXTERNAL Tcl_AppendElement *> XPROCEDURE AppendElement (interp: Interp_star; string: char_star; noSep: int); X X<*EXTERNAL Tcl_ResetResult *> XPROCEDURE ResetResult (interp: Interp_star); X XPROCEDURE FreeResult (interp: Interp_star); X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_SetVar *> XPROCEDURE SetVar (interp: Interp_star; X varName, newValue: char_star; flags: int); X X<*EXTERNAL Tcl_SetVar2 *> XPROCEDURE SetVar2 (interp: Interp_star; X name1, name2, newValue: char_star; flags: int); X X<*EXTERNAL Tcl_GetVar *> XPROCEDURE GetVar (interp: Interp_star; X varName: char_star; flags: int): char_star; X X<*EXTERNAL Tcl_GetVar2 *> XPROCEDURE GetVar2 (interp: Interp_star; X name1, name2: char_star; flags: int): char_star; X X<*EXTERNAL Tcl_UnsetVar *> XPROCEDURE UnsetVar (interp: Interp_star; X varName: char_star; flags: int): int; X X<*EXTERNAL Tcl_UnsetVar2 *> XPROCEDURE UnsetVar2 (interp: Interp_star; X name1, name2: char_star; flags: int): int; X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_SplitList *> XPROCEDURE SplitList (interp: Interp_star; X list: char_star; X argcPtr: int_star; X argvPtr: Argv_star): int; X X<*EXTERNAL Tcl_Merge *> XPROCEDURE Merge (argc: int; argv: Argv): char_star; X X<*EXTERNAL Tcl_ScanElement *> XPROCEDURE ScanElement (src: char_star; flagsPtr: int_star): int; X X<*EXTERNAL Tcl_ConvertElement *> XPROCEDURE ConvertElement (src, dst: char_star; flags: int): int; X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_StringMatch *> XPROCEDURE StringMatch (string, pattern: char_star): int; X X(*---------------------------------------------------------------------------* ) X X<*EXTERNAL Tcl_TildeSubst *> XPROCEDURE TildeSubst (interp: Interp_star; name: char_star): char_star; X X(*---------------------------------------------------------------------------* ) X XTYPE X VarTraceProc = PROCEDURE (clientData: ClientData; X interp: Interp_star; X varName: char_star; X global, flags: int; X oldValue, newValue: char_star): char_star; X X<*EXTERNAL Tcl_TraceVar *> XPROCEDURE TraceVar (interp: Interp_star; X varName: char_star; X flags: int; X proc: VarTraceProc; X clientData: ClientData): int; X X<*EXTERNAL Tcl_TraceVar2 *> XPROCEDURE TraceVar2 (interp: Interp_star; X name1, name2: char_star; X flags: int; X proc: VarTraceProc; X clientData: ClientData): int; X X<*EXTERNAL Tcl_UnTraceVar *> XPROCEDURE UnTraceVar (interp: Interp_star; X varName: char_star; X flags: int; X proc: VarTraceProc; X clientData: ClientData); X X<*EXTERNAL Tcl_UnTraceVar2 *> XPROCEDURE UnTraceVar2 (interp: Interp_star; X name1, name2: char_star; X flags: int; X proc: VarTraceProc; X clientData: ClientData); X X<*EXTERNAL Tcl_VarTraceInfo *> XPROCEDURE VarTraceInfo (interp: Interp_star; X varName: char_star; X flags: int; X proc: VarTraceProc; X prevClientData: ClientData): int; X X<*EXTERNAL Tcl_VarTraceInfo2 *> XPROCEDURE VarTraceInfo2 (interp: Interp_star; X name1, name2: char_star; X flags: int; X proc: VarTraceProc; X prevClientData: ClientData): int; X X(*---------------------------------------------------------------------------* ) X XEND TclC. SHAR_EOF $TOUCH -am 0403190992 TclC.i3 && chmod 0644 TclC.i3 || echo "restore of TclC.i3 failed" set `wc -c TclC.i3`;Wc_c=$1 if test "$Wc_c" != "13775"; then echo original size 13775, current size $Wc_c fi # ============= TclC.m3 ============== echo "x - extracting TclC.m3 (Text)" sed 's/^X//' << 'SHAR_EOF' > TclC.m3 && XUNSAFE MODULE TclC; X XIMPORT Cstdlib; X XPROCEDURE FreeResult (interp: Interp_star) = X BEGIN X IF interp.freeProc # NIL THEN X interp.freeProc (interp.result); X interp.freeProc := NIL; END; X END FreeResult; X X XBEGIN X volatile := LOOPHOLE (-1, FreeProc); X static := LOOPHOLE (0, FreeProc); X dynamic := LOOPHOLE (Cstdlib.free, FreeProc); XEND TclC. SHAR_EOF $TOUCH -am 0403190992 TclC.m3 && chmod 0644 TclC.m3 || echo "restore of TclC.m3 failed" set `wc -c TclC.m3`;Wc_c=$1 if test "$Wc_c" != "359"; then echo original size 359, current size $Wc_c fi # ============= TclCTest.m3 ============== echo "x - extracting TclCTest.m3 (Text)" sed 's/^X//' << 'SHAR_EOF' > TclCTest.m3 && X(* Copyright (C) 1991, Digital Equipment Corporation *) X(* All rights reserved. *) X(* See the file COPYRIGHT for a full description. *) X X XUNSAFE MODULE TclCTest EXPORTS Main; X XIMPORT TclC; XIMPORT Rd, Wr, Stdio, Fmt; XFROM M3toC IMPORT TtoS, CopyTtoS, CopyStoT; XFROM Ctypes IMPORT int, char_star; X X<*FATAL ANY*> X XPROCEDURE FactCmd (<*UNUSED*> clientData: TclC.ClientData; X interp: TclC.Interp_star; X argc: int; X argv: TclC.Argv): int = X BEGIN X IF argc # 2 THEN X interp.result := TtoS ("fact has exactly one argument"); X RETURN TclC.TCL_ERROR; X ELSE X VAR i: INTEGER; BEGIN X IF TclC.GetInt (interp, argv[1], ADR (i)) = TclC.TCL_ERROR THEN X RETURN TclC.TCL_ERROR; END; X interp.result := CopyTtoS (Fmt.Int (Fact (i))); X RETURN TclC.TCL_OK; END; END; X END FactCmd; X XPROCEDURE Fact (i: INTEGER): INTEGER = X BEGIN X IF i = 1 THEN X RETURN 1; X ELSE X RETURN i * Fact (i - 1); END; X END Fact; X X XVAR X i: TclC.Interp_star; X buf: TclC.CmdBuf; X s: char_star; X status: int; X XBEGIN X i := TclC.CreateInterp (); X TclC.CreateCommand (i, TtoS ("fact"), FactCmd, 0, NIL); X buf := TclC.CreateCmdBuf (); X X TRY X LOOP X Wr.PutText (Stdio.stdout, "-> "); X Wr.Flush (Stdio.stdout); X s := TclC.AssembleCmd (buf, TtoS (Rd.GetLine (Stdio.stdin) & "\n")); X IF s # NIL THEN X status := TclC.RecordAndEval (i, s, 0); X CASE status OF X | TclC.TCL_OK => X Wr.PutText (Stdio.stdout, CopyStoT (i.result) & "\n"); X Wr.Flush (Stdio.stdout); X | TclC.TCL_ERROR => X Wr.PutText (Stdio.stderr, "error: " & CopyStoT (i.result) & "\n"); X Wr.Flush (Stdio.stdout); X ELSE X Wr.PutText (Stdio.stderr, "TclC.Eval returned with code = " X & Fmt.Int (status) & "\n"); X Wr.Flush (Stdio.stdout); X END; END; END; X EXCEPT X | Rd.EndOfFile => END; X X TclC.DeleteCmdBuf (buf); X TclC.DeleteInterp (i); XEND TclCTest. SHAR_EOF $TOUCH -am 0403190992 TclCTest.m3 && chmod 0644 TclCTest.m3 || echo "restore of TclCTest.m3 failed" set `wc -c TclCTest.m3`;Wc_c=$1 if test "$Wc_c" != "2167"; then echo original size 2167, current size $Wc_c fi exit 0 ======================================================================= 49 === Date: 5 Apr 92 06:49:14 GMT From: schwartz@groucho.cs.psu.edu (Scott Schwartz) Subject: Re: why modula3? mjordan@src.dec.com (Mick Jordan) writes: melling@cs.psu.edu (Michael D Mellinger) writes: > chased@rbbb.Eng.Sun.COM (David Chase) writes: > VERBOSE UPPERCASE IDENTIFIERS. > Will this be "fixed"? My fingers bother me enough as it is without > having to reach for the shift key all the time. I suggest you use the gnuemacs modula-3 mode in which case you will not have to type reserved words very often. I suggest that no one make that argument outside this newsgroup. Elsewhere, people will recognize that it explicitly admits that there is a very serious problem with m3, one which requires complex and expensive tools to work around. Many of those people will walk away from m3 forever, never giving it a fair chance, thinking to themselves, 'Upper case identifiers... must be a toy language.' Granted this is what Wirth calls an ephemeral issue, but it is one of those emotional things that can really hurt an up and coming language. Keywords are things you type often: as a practical matter ``proc'' is very much nicer than ``PROCEDURE''. Fortunately, the DEC M3 compiler comes with sources, so we can all fix this little problem before it gets carved in stone. (Sorry to be uptight, but my tendinitis is in upper case today.) ======================================================================= 50 === Date: 3 Apr 92 21:32:57 GMT From: wkh@duke.austin.ibm.com (Ward K Harold) Subject: Re: why modula3? In article <1992Apr2.125203.8319@src.dec.com>, mjordan@src.dec.com (Mick Jordan ) writes: |> I suggest you use the gnuemacs modula-3 mode in which case you will not |> have to type reserved words very often. |> |> Mick Jordan I fear this is a FAQ but just where does the modula-3 mode .el live? I looked on archive.cis.ohio-state.edu but it wasn't there. ... WkH -- Ward K Harold (512) 838-3473 [T/L 678-3473] IBM Personal Systems Programming external: wkh@dce.austin.ibm.com 11400 Burnet Rd., Zip 9541 internal: wkh@duke.austin.ibm.com Austin, TX 78758 vnet: wharrold --ausvmq ======================================================================= 51 === Date: Sun, 5 Apr 92 10:24:01 EDT From: wyant@centerline.com Subject: M3TK for M3 2.05 ? Is there a new version of M3TK forthcoming ? I'm trying build the current version under 2.05, but lib/oli gets a significant number of syntax errors. I thought that before I delved into this, I'd see if there was a version that compiled under M3 2.0 coing out soon. thanks ! Geoff Wyant wyant@centerline.com Centerline Software, Inc. (Formerly Saber Software, Inc) 10 Fawcett Street Cambridge, Ma. 01237 ======================================================================= 52 === Date: 5 Apr 92 21:08:04 GMT From: jhummel@broadway.ics.uci.edu (Joseph Edward Hummel) Subject: real applications where OO did/didn't work well? Hello all. Being a student with (as yet :-) little industrial experience, I'm looking for info on real applications where OOP was used. I'm particularly interested in info about how well you feel the OO paradigm worked in this particular problem -- good or bad. Please respond by email, and I'll post the results since I think others will find this interesting (if it hasn't been done already?). Thanks in advance... - joe hummel (jhummel@ics.uci.edu) -- Joe Hummel ICS Graduate Student, UC Irvine Internet: jhummel@ics.uci.edu ======================================================================= 53 === Date: 6 Apr 92 07:19:12 GMT From: qs101@cl.cam.ac.uk (Quentin Stafford-Fraser) Subject: Gatekeeper Gatekeeper is now giving me 'User anonymous unknown' messages. Should I be getting things from somewhere else now? Quentin ----------------------------------- Quentin Stafford-Fraser Cambridge University Computer Lab qs101@cl.cam.ac.uk Tel +44 223 334645 ----------------------------------- ======================================================================= 54 === Date: 6 Apr 92 09:19:01 GMT From: pfrants@cs.vu.nl (Frants P) Subject: GATEKEEPER!!!!!!!!!!!!!!!!!!!!!!!!!!!! Why does gatekeeper.dec.com not recognize "anonymous"? When will this problem be out of this world??????? ======================================================================= 55 === Date: Mon, 6 Apr 92 09:30:21 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Re: M3TK for M3 2.05 ? In article <9204051424.AA22562@riposte>, wyant@centerline.com writes: > Is there a new version of M3TK forthcoming ? > I'm trying build the current version under > 2.05, but lib/oli gets a significant number > of syntax errors. I thought that before I > delved into this, I'd see if there was a > version that compiled under M3 2.0 coing > out soon. > Yes. I am preparing it for release to gatekeeper as I write. Barring some disas ter it will be available by the end of the week. Mick Jordan ======================================================================= 56 === Date: 6 Apr 92 14:58:54 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Uppercase reserved words (was: Re: why modula3?) Re: the post FROM schwartz@groucho.cs.psu.edu (Scott Schwartz), who RAISES an objection TO upper CASE identifiers. To SET the RECORD straight, WHILE I have some sympathy FOR his point, his EXCEPTION TO upper CASE identifiers is a too NARROW, AND NOT a reason TO go through the CEILING. (What VALUE a language FOR which different compilers could OVERRIDE reserved word spelling? I hope the chance OF anyone using this LOOPHOLE is NIL.) I DO NOT think upper CASE id's have BRANDED Modula-3 a loser. We can DISPOSE OF that argument. It is NOT NEW AND there is no need TO REPEAT it. Let me BEGIN TO ADDRESS this issue: TRUE, I used TO OBJECT TO upper CASE reserved words when I FIRST saw them because they made my code look ugly. That was UNTIL I got more experience. At LAST, I like them. They cut down on on the name space pollution. I like being able TO use ANY lower CASE identifiers (such AS "from" AND "to") IN my code. A close reading OF the book will REVEAL that that Modula-3 has about 100 reserved identifiers (TO use a ROUND NUMBER). This includes predefined identifiers WITH keywords. (It is a CARDINAL rule that you can't use predefined identifiers FOR ANY other purpose IN Modula-3.) IN the END, I think DEC simply had a BOOLEAN choice TO make, AND they made it right. TO avoid an EXTENDED debate AND RETURN TO the REAL issue, let me RAISE a NEW possibility (OF some VALUE) IN the ARRAY OF solutions FOR GNU emacs users. TRY using abbrev mode--it's one OF the better METHODS. IF you TYPE your TEXT IN lower CASE, THEN you will get upper CASE reserved words. I have included the necessary definitions below so you can IMPORT them into your program. Warning: Test before using, ELSE the result may be UNSAFE. I didn't have time FOR a NUMBER OF tests. (Only one.) Sam Harbison Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. ---- PROCEDURE: Change 'global-abbrev-table ' TO 'yourmode-abbrev-table ' IF necessary. Read IN WITH M-x read-abbrev-file$. (define-abbrev-table 'global-abbrev-table '( ("methods" "METHODS" nil 0) ("abs" "ABS" nil 0) ("loop" "LOOP" nil 0) ("raises" "RAISES" nil 0) ("return" "RETURN" nil 0) ("bitsize" "BITSIZE" nil 0) ("max" "MAX" nil 0) ("value" "VALUE" nil 0) ("cardinal" "CARDINAL" nil 0) ("exports" "EXPORTS" nil 0) ("set" "SET" nil 0) ("except" "EXCEPT" nil 0) ("nil" "NIL" nil 0) ("false" "FALSE" nil 0) ("or" "OR" nil 0) ("if" "IF" nil 0) ("eval" "EVAL" nil 0) ("min" "MIN" nil 0) ("narrow" "NARROW" nil 0) ("not" "NOT" nil 0) ("try" "TRY" nil 0) ("typecode" "TYPECODE" nil 0) ("boolean" "BOOLEAN" nil 0) ("text" "TEXT" nil 0) ("loophole" "LOOPHOLE" nil 0) ("unsafe" "UNSAFE" nil 0) ("readonly" "READONLY" nil 0) ("record" "RECORD" nil 0) ("import" "IMPORT" nil 0) ("branded" "BRANDED" nil 0) ("raise" "RAISE" nil 0) ("any" "ANY" nil 0) ("array" "ARRAY" nil 0) ("extended" "EXTENDED" nil 0) ("repeat" "REPEAT" nil 0) ("typecase" "TYPECASE" nil 0) ("end" "END" nil 0) ("of" "OF" nil 0) ("bytesize" "BYTESIZE" nil 0) ("lonreal" "LONREAL" nil 0) ("override" "OVERRIDE" nil 0) ("reveal" "REVEAL" nil 0) ("subarray" "SUBARRAY" nil 0) ("while" "WHILE" nil 0) ("ref" "REF" nil 0) ("var" "VAR" nil 0) ("new" "NEW" nil 0) ("const" "CONST" nil 0) ("procedure" "PROCEDURE" nil 0) ("round" "ROUND" nil 0) ("mutex" "MUTEX" nil 0) ("to" "TO" nil 0) ("ceiling" "CEILING" nil 0) ("mod" "MOD" nil 0) ("until" "UNTIL" nil 0) ("val" "VAL" nil 0) ("object" "OBJECT" nil 0) ("with" "WITH" nil 0) ("module" "MODULE" nil 0) ("integer" "INTEGER" nil 0) ("refany" "REFANY" nil 0) ("bits" "BITS" nil 0) ("char" "CHAR" nil 0) ("float" "FLOAT" nil 0) ("then" "THEN" nil 0) ("last" "LAST" nil 0) ("trunc" "TRUNC" nil 0) ("address" "ADDRESS" nil 0) ("dec" "DEC" nil 0) ("finally" "FINALLY" nil 0) ("null" "NULL" nil 0) ("and" "AND" nil 0) ("do" "DO" nil 0) ("else" "ELSE" nil 0) ("istype" "ISTYPE" nil 0) ("untraced" "UNTRACED" nil 0) ("exception" "EXCEPTION" nil 0) ("begin" "BEGIN" nil 0) ("dispose" "DISPOSE" nil 0) ("floor" "FLOOR" nil 0) ("true" "TRUE" nil 0) ("lock" "LOCK" nil 0) ("by" "BY" nil 0) ("exit" "EXIT" nil 0) ("adr" "ADR" nil 1) ("div" "DIV" nil 0) ("real" "REAL" nil 0) ("type" "TYPE" nil 0) ("elsif" "ELSIF" nil 0) ("for" "FOR" nil 0) ("number" "NUMBER" nil 0) ("from" "FROM" nil 0) ("root" "ROOT" nil 0) ("interface" "INTERFACE" nil 0) ("first" "FIRST" nil 0) ("ord" "ORD" nil 0) ("case" "CASE" nil 0) ("adrsize" "ADRSIZE" nil 0) ("as" "AS" nil 0) ("in" "IN" nil 0) ("inc" "INC" nil 0) )) ======================================================================= 57 === Date: 6 Apr 92 12:46:07 GMT From: weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT]) Subject: Re: GATEKEEPER!!!!!!!!!!!!!!!!!!!!!!!!!!!! pfrants@cs.vu.nl (Frants P) writes: >Why does gatekeeper.dec.com not recognize "anonymous"? >When will this problem be out of this world??????? It's not gatekeeper.dec... they seem to have a problem in one of the top-level-nameservers, so that you don't get dec's gatekeeper. Try the numerical address, that should work. (Taken from a post to comp.protocols-tcpip.domains) Regards Christoph Weber-Fahr -- Christoph Weber-Fahr | E-Mail: weber@rhrk.uni-kl.de Universitaet Kaiserslautern, KIT/IVS | S-Mail: Postfach 3049 Tel. 0631/205-3391 | D-6750 Kaiserslautern -------------------------- My personal opinion only --------------------- ======================================================================= 58 === Date: Mon, 6 Apr 92 16:04:42 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: GATEKEEPER!!!!!!!!!!!!!!!!!!!!!!!!!!!! In article <1992Apr6.124607.20513@rhrk.uni-kl.de>, weber@rhrk.uni-kl.de (Christ oph Weber-Fahr [KIT]) writes: > It's not gatekeeper.dec... they seem to have a problem in one of the > top-level-nameservers, so that you don't get dec's gatekeeper. > Try the numerical address, that should work. Until the fix propagates from NIC, you can use the numerical address 16.1.0.2. -- Eric. ======================================================================= 59 === Date: Mon, 6 Apr 92 13:25:45 PDT From: muller@src.dec.com (Eric Muller) Subject: archive of comp.lang.modula3 for March 1992 The archive of the messages sent to comp.lang.modula3 in March 1992 is now available in: gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3/92-03.Z Achives for the previous months are available in the same directory. ---- Eric. ======================================================================= 60 === Date: Mon, 6 Apr 1992 13:40:55 PDT From: David Goldberg Subject: trestle and SPARC running OpenWindows 3.0 There is a problem with using trestle on SPARCs if you are running Openwindows 3.0 (Openwin 2.0 works fine). The problem is that any trestle application will crash the 3.0 xnews server. There are two possible workarounds: 1. Patch xnews. The Sun bugID for this is 1082200 UngrabKey for a particular keycode after GrabKey for AnyKey crashes xnews Sun has a patch for this. The one I got from Sun was labeled: Patch-ID# 100444-14 Keywords: X11-NeWS, server, patch, xnews Synopsis: Openwindows V3.0 Server Patch 3000-22 Date:04/01/92 2. Patch Trestle replace X.XGrabKey(trsl.dpy, X.AnyKey, X.AnyModifier, ur.w, X.True, X.GrabModeAsync, X.GrabModeAsync); with VAR min, max: INTEGER; BEGIN X.XDisplayKeycodes(trsl.dpy, ADR(min), ADR(max)); FOR i := min TO max DO X.XGrabKey(trsl.dpy, i, X.AnyModifier, ur.w, X.True, X.GrabModeAsync, X.GrabModeAsync); END; END; David Goldberg goldberg@parc.xerox.com ======================================================================= 61 === Date: Mon, 6 Apr 1992 20:05:15 GMT From: twhlai@watdragon.waterloo.edu (Tony Lai) Subject: Re: why modula3? In article <=q9H4j2i6@cs.psu.edu> schwartz@groucho.cs.psu.edu (Scott Schwartz) writes: >Elsewhere, people will recognize that it explicitly admits that there >is a very serious problem with m3, one which requires complex and >expensive tools to work around. Many of those people will walk away >from m3 forever, never giving it a fair chance, thinking to >themselves, 'Upper case identifiers... must be a toy language.' [stuff deleted] Are uppercase keywords really so bad? It is simple to write a program to convert one's favorite lowercase keywords to proper uppercase keywords. ======================================================================= 62 === Date: 6 Apr 92 22:55:43 GMT From: schwartz@roke.cs.psu.edu (Scott Schwartz) Subject: Re: why modula3? twhlai@watdragon.waterloo.edu (Tony Lai) writes: Are uppercase keywords really so bad? It is simple to write a program to convert one's favorite lowercase keywords to proper uppercase keywords. As I said, I was being uptight, but I do think this issue will turn a lot of people off. Yes, it is easy to write an encasing program---maybe pp should be taught to do this as part of its other functions. But this admits that the common case is being penalized. Eiffel, IMHO, does better, with keywords lowercase, and user supplied classes (conventionally) named in uppercase. ======================================================================= 63 === Date: Tue, 7 Apr 1992 11:19:21 PDT From: David Nichols Subject: SunRPC implementation available [I tried posting this from my news reader, but doesn't seem to have made it outside of PARC. My apologies if you see it twice.] Our Modula-3 implementation of Sun RPC is now available for anonymous ftp. It consists of a stub compiler (based on rpcgen) that produces object-oriented Modula-3 stubs and a runtime that is thread-safe (although clients have some synchronization responsibilities). There is no support for authentication yet. It has received some testing and use here, but has not been used extensively. The code is available on parcftp.xerox.com as "pub/m3/m3rpc.tar.Z". For your one-stop shopping convenience, I have also placed in that directory a copy of the Modula-3 tags package David Goldberg announced recently. Please send any bugs, comments, etc. to me (nichols@parc.xerox.com). David ======================================================================= 64 === Date: 7 Apr 92 20:56:53 GMT From: salomon@silver.cs.umanitoba.ca (Daniel J. Salomon) Subject: Re: why modula3? In article <1992Apr6.200515.22885@watdragon.waterloo.edu> twhlai@watdragon.wate rloo.edu (Tony Lai) writes: > Are uppercase keywords really so bad? It is simple to write a program > to convert one's favorite lowercase keywords to proper uppercase keywords. I have written such a program, and included it with this posting. It was not hard to write, but was rather tedious to type and test. I wrote the original version because I had a problem with keywords in Modula-2. Although I prefer the appearance of uppercase keywords I hate typing them in uppercase. My solution was to write a filter that would convert them to upper case. I typically use it directly from vi when editing a program (see below for more details). Using this filter prevents you from using the reserved words in lowercase as variables, but I don't think that that is a very safe practice. FOR for := from TO to DO do END; #---- Remove this line and exerything before it. ---- #!/bin/csh # # This shell script will generate the files: # m3uc.l, m3uc.flex, makefile.lex, and makefile.flex # The files contain both lex and flex source for a filter that # will read a Modula-3 source program and output it with all # the reserved keywords converted to uppercase. # Store this shell script in a file called bundle, # then to unbundle the files type: # sh bundle # # If you have the scanner generator FLEX on your system, then # to compile the filter type the line: # make -f makefile.flex # # If you do not have flex on your system, you can compile it using # lex by typing: # make -f makefile.lex # # The program generated will be called "m3uc". # The program reads a Modula-3 program on standard input and # outputs it on standard output with all the keyword converted # to uppercase. # E.g. m3uc upper_case.m3 # # The easiest way to use the filter is from inside vi. # To do so, move to the top of the file with the command: 1G # then pipe the whole program to the filter by typing: !G m3uc # sed -e s/X// <<==== >m3uc.l X%{ X/* X * m3uc.l X * ====== X * X * A lex script for a filter to convert Modula-3 keywords from X * mixed-case to uppercase. Programs are easier to type if the X * keywords are entered in lowercase, but easier to read if the X * keywords are in uppercase. X * This filter gives you the best of both worlds. X * X * The input is read from standard input, and the output generated X * on standard output. Thus m3uc is easily used as a filter during X * a vi session. X */ X X int comdep = 0; /* Current comment nesting depth. */ X X%} X X%Start CODE COMMENT X%a 5000 X%e 1500 X%k 1500 X%p 4000 X%o 7000 X Xletter [a-zA-Z] Xdigit [0-9] Xa [aA] Xb [bB] Xc [cC] Xd [dD] Xe [eE] Xf [fF] Xg [gG] Xh [hH] Xi [iI] Xj [jJ] Xk [kK] Xl [lL] Xm [mM] Xn [nN] Xo [oO] Xp [pP] Xq [qQ] Xr [rR] Xs [sS] Xt [tT] Xu [uU] Xv [vV] Xw [wW] Xx [xX] Xy [yY] Xz [zZ] X X%% X X BEGIN CODE; /* Enter scanner in CODE state. */ X X"(*" { ECHO; BEGIN COMMENT; comdep++; } X"(*" { ECHO; comdep++; } X"*)" { X ECHO; X comdep--; X if (comdep<1) BEGIN CODE; X } X. ECHO; X\n ECHO; X"*)" { X ECHO; X fprintf (stderr, X "\n(**** Unopened comment. ****)\n"); X } X{a}{b}{s} printf ("ABS"); X{a}{d}{d}{r}{e}{s}{s} printf ("ADDRESS"); X{a}{d}{r} printf ("ADR"); X{a}{d}{r}{s}{i}{z}{e} printf ("ADRSIZE"); X{a}{n}{d} printf ("AND"); X{a}{n}{y} printf ("ANY"); X{a}{r}{r}{a}{y} printf ("ARRAY"); X{a}{s} printf ("AS"); X{b}{e}{g}{i}{n} printf ("BEGIN"); X{b}{i}{t}{s} printf ("BITS"); X{b}{i}{t}{s}{i}{z}{e} printf ("BITSIZE"); X{b}{o}{o}{l}{e}{a}{n} printf ("BOOLEAN"); X{b}{r}{a}{n}{d}{e}{d} printf ("BRANDED"); X{b}{y} printf ("BY"); X{b}{y}{t}{e}{s}{i}{z}{e} printf ("BYTESIZE"); X{c}{a}{r}{d}{i}{n}{a}{l} printf ("CARDINAL"); X{c}{a}{s}{e} printf ("CASE"); X{c}{e}{i}{l}{i}{n}{g} printf ("CEILING"); X{c}{h}{a}{r} printf ("CHAR"); X{c}{o}{n}{s}{t} printf ("CONST"); X{d}{e}{c} printf ("DEC"); X{d}{i}{s}{p}{o}{s}{e} printf ("DISPOSE"); X{d}{i}{v} printf ("DIV"); X{d}{o} printf ("DO"); X{e}{l}{s}{e} printf ("ELSE"); X{e}{l}{s}{i}{f} printf ("ELSIF"); X{e}{n}{d} printf ("END"); X{e}{v}{a}{l} printf ("EVAL"); X{e}{x}{c}{e}{p}{t} printf ("EXCEPT"); X{e}{x}{c}{e}{p}{t}{i}{o}{n} printf ("EXCEPTION"); X{e}{x}{i}{t} printf ("EXIT"); X{e}{x}{p}{o}{r}{t}{s} printf ("EXPORTS"); X{e}{x}{t}{e}{n}{d}{e}{d} printf ("EXTENDED"); X{f}{a}{l}{s}{e} printf ("FALSE"); X{f}{i}{n}{a}{l}{l}{y} printf ("FINALLY"); X{f}{i}{r}{s}{t} printf ("FIRST"); X{f}{l}{o}{a}{t} printf ("FLOAT"); X{f}{l}{o}{o}{r} printf ("FLOOR"); X{f}{o}{r} printf ("FOR"); X{f}{r}{o}{m} printf ("FROM"); X{i}{f} printf ("IF"); X{i}{m}{p}{o}{r}{t} printf ("IMPORT"); X{i}{n} printf ("IN"); X{i}{n}{c} printf ("INC"); X{i}{n}{t}{e}{g}{e}{r} printf ("INTEGER"); X{i}{n}{t}{e}{r}{f}{a}{c}{e} printf ("INTERFACE"); X{i}{s}{t}{y}{p}{e} printf ("ISTYPE"); X{l}{a}{s}{t} printf ("LAST"); X{l}{o}{c}{k} printf ("LOCK"); X{l}{o}{n}{g}{r}{e}{a}{l} printf ("LONGREAL"); X{l}{o}{o}{p} printf ("LOOP"); X{l}{o}{o}{p}{h}{o}{l}{e} printf ("LOOPHOLE"); X{m}{a}{x} printf ("MAX"); X{m}{e}{t}{h}{o}{d}{s} printf ("METHODS"); X{m}{i}{n} printf ("MIN"); X{m}{o}{d} printf ("MOD"); X{m}{o}{d}{u}{l}{e} printf ("MODULE"); X{m}{u}{t}{e}{x} printf ("MUTEX"); X{n}{a}{r}{r}{o}{w} printf ("NARROW"); X{n}{e}{w} printf ("NEW"); X{n}{i}{l} printf ("NIL"); X{n}{o}{t} printf ("NOT"); X{n}{u}{l}{l} printf ("NULL"); X{n}{u}{m}{b}{e}{r} printf ("NUMBER"); X{o}{b}{j}{e}{c}{t} printf ("OBJECT"); X{o}{f} printf ("OF"); X{o}{r} printf ("OR"); X{o}{r}{d} printf ("ORD"); X{o}{v}{e}{r}{r}{i}{d}{e} printf ("OVERRIDE"); X{p}{r}{o}{c}{e}{d}{u}{r}{e} printf ("PROCEDURE"); X{r}{a}{i}{s}{e} printf ("RAISE"); X{r}{a}{i}{s}{e}{s} printf ("RAISES"); X{r}{e}{a}{d}{o}{n}{l}{y} printf ("READONLY"); X{r}{e}{a}{l} printf ("REAL"); X{r}{e}{c}{o}{r}{d} printf ("RECORD"); X{r}{e}{f} printf ("REF"); X{r}{e}{f}{a}{n}{y} printf ("REFANY"); X{r}{e}{p}{e}{a}{t} printf ("REPEAT"); X{r}{e}{t}{u}{r}{n} printf ("RETURN"); X{r}{e}{v}{e}{a}{l} printf ("REVEAL"); X{r}{o}{o}{t} printf ("ROOT"); X{r}{o}{u}{n}{d} printf ("ROUND"); X{s}{e}{t} printf ("SET"); X{s}{u}{b}{a}{r}{r}{a}{y} printf ("SUBARRAY"); X{t}{e}{x}{t} printf ("TEXT"); X{t}{h}{e}{n} printf ("THEN"); X{t}{o} printf ("TO"); X{t}{r}{u}{e} printf ("TRUE"); X{t}{r}{u}{n}{c} printf ("TRUNC"); X{t}{r}{y} printf ("TRY"); X{t}{y}{p}{e} printf ("TYPE"); X{t}{y}{p}{e}{c}{a}{s}{e} printf ("TYPECASE"); X{t}{y}{p}{e}{c}{o}{d}{e} printf ("TYPECODE"); X{u}{n}{s}{a}{f}{e} printf ("UNSAFE"); X{u}{n}{t}{i}{l} printf ("UNTIL"); X{u}{n}{t}{r}{a}{c}{e}{d} printf ("UNTRACED"); X{v}{a}{l} printf ("VAL"); X{v}{a}{l}{u}{e} printf ("VALUE"); X{v}{a}{r} printf ("VAR"); X{w}{h}{i}{l}{e} printf ("WHILE"); X{w}{i}{t}{h} printf ("WITH"); X X{letter}({letter}|{digit}|"_")* ECHO; /* Identifiers. */ X\"([^\"\n])+\" ECHO; /* Quote delimited strings. */ X\n ECHO; X. ECHO; /* All other characters. */ X%% ==== sed -e s/X// <<==== >m3uc.flex X%{ X/* X * m3uc.flex X * ========= X * X * A flex script for a filter to convert Modula-3 keywords from X * mixed-case to uppercase. This version takes advantage of flex's X * special feature for case insensitivity. Programs are easier to X * type if the keywords are entered in lowercase, but easier to X * read if the keywords are in uppercase. X * This filter gives you the best of both worlds. X * X * The input is read from standard input, and the output generated X * on standard output. Thus m3uc is easily used as a filter during X * a vi session. X */ X X int comdep = 0; /* Current comment nesting depth. */ X X%} X X%Start CODE COMMENT X Xletter [a-zA-Z] Xdigit [0-9] X X%% X X BEGIN CODE; /* Enter scanner in CODE state. */ X X"(*" { ECHO; BEGIN COMMENT; comdep++; } X"(*" { ECHO; comdep++; } X"*)" { X ECHO; X comdep--; X if (comdep<1) BEGIN CODE; X } X. ECHO; X\n ECHO; X"*)" { X ECHO; X fprintf (stderr, X "\n(**** Unopened comment. ****)\n"); X } Xabs printf ("ABS"); Xaddress printf ("ADDRESS"); Xadr printf ("ADR"); Xadrsize printf ("ADRSIZE"); Xand printf ("AND"); Xany printf ("ANY"); Xarray printf ("ARRAY"); Xas printf ("AS"); Xbegin printf ("BEGIN"); Xbits printf ("BITS"); Xbitsize printf ("BITSIZE"); Xboolean printf ("BOOLEAN"); Xbranded printf ("BRANDED"); Xby printf ("BY"); Xbytesize printf ("BYTESIZE"); Xcardinal printf ("CARDINAL"); Xcase printf ("CASE"); Xceiling printf ("CEILING"); Xchar printf ("CHAR"); Xconst printf ("CONST"); Xdec printf ("DEC"); Xdispose printf ("DISPOSE"); Xdiv printf ("DIV"); Xdo printf ("DO"); Xelse printf ("ELSE"); Xelsif printf ("ELSIF"); Xend printf ("END"); Xeval printf ("EVAL"); Xexcept printf ("EXCEPT"); Xexception printf ("EXCEPTION"); Xexit printf ("EXIT"); Xexports printf ("EXPORTS"); Xextended printf ("EXTENDED"); Xfalse printf ("FALSE"); Xfinally printf ("FINALLY"); Xfirst printf ("FIRST"); Xfloat printf ("FLOAT"); Xfloor printf ("FLOOR"); Xfor printf ("FOR"); Xfrom printf ("FROM"); Xif printf ("IF"); Ximport printf ("IMPORT"); Xin printf ("IN"); Xinc printf ("INC"); Xinteger printf ("INTEGER"); Xinterface printf ("INTERFACE"); Xistype printf ("ISTYPE"); Xlast printf ("LAST"); Xlock printf ("LOCK"); Xlongreal printf ("LONGREAL"); Xloop printf ("LOOP"); Xloophole printf ("LOOPHOLE"); Xmax printf ("MAX"); Xmethods printf ("METHODS"); Xmin printf ("MIN"); Xmod printf ("MOD"); Xmodule printf ("MODULE"); Xmutex printf ("MUTEX"); Xnarrow printf ("NARROW"); Xnew printf ("NEW"); Xnil printf ("NIL"); Xnot printf ("NOT"); Xnull printf ("NULL"); Xnumber printf ("NUMBER"); Xobject printf ("OBJECT"); Xof printf ("OF"); Xor printf ("OR"); Xord printf ("ORD"); Xoverride printf ("OVERRIDE"); Xprocedure printf ("PROCEDURE"); Xraise printf ("RAISE"); Xraises printf ("RAISES"); Xreadonly printf ("READONLY"); Xreal printf ("REAL"); Xrecord printf ("RECORD"); Xref printf ("REF"); Xrefany printf ("REFANY"); Xrepeat printf ("REPEAT"); Xreturn printf ("RETURN"); Xreveal printf ("REVEAL"); Xroot printf ("ROOT"); Xround printf ("ROUND"); Xset printf ("SET"); Xsubarray printf ("SUBARRAY"); Xtext printf ("TEXT"); Xthen printf ("THEN"); Xto printf ("TO"); Xtrue printf ("TRUE"); Xtrunc printf ("TRUNC"); Xtry printf ("TRY"); Xtype printf ("TYPE"); Xtypecase printf ("TYPECASE"); Xtypecode printf ("TYPECODE"); Xunsafe printf ("UNSAFE"); Xuntil printf ("UNTIL"); Xuntraced printf ("UNTRACED"); Xval printf ("VAL"); Xvalue printf ("VALUE"); Xvar printf ("VAR"); Xwhile printf ("WHILE"); Xwith printf ("WITH"); X X{letter}({letter}|{digit}|"_")* ECHO; /* Identifiers. */ X\"([^\"\n])+\" ECHO; /* Quote delimited strings. */ X\n ECHO; X. ECHO; /* All other characters. */ X%% ==== sed -e s/X// <<==== >makefile.lex X# makefile.lex - LEX version X# ============ X# X# Generate m3uc using LEX. X# X Xm3uc: m3uc.c X cc -O m3uc.c -ll -o m3uc X Xm3uc.c: m3uc.l X lex m3uc.l X mv lex.yy.c m3uc.c ==== sed -e s/X// <<==== >makefile.flex X# makefile.flex - FLEX version X# ============= X# X# Generate m3uc using FLEX. X# X Xm3uc: m3uc.c X cc -O m3uc.c -ll -o m3uc X Xm3uc.c: m3uc.flex X flex -i m3uc.flex X mv lex.yy.c m3uc.c ==== ======================================================================= 65 === Date: 8 Apr 92 15:18:41 GMT From: jjw1@mongoose.gte.com (Jim Walker) Subject: Modula-3 for a Snake... -------- Has anyone attempted or started on a port of the latest SRC Modula-3 stuff (2.04) to an HP 700 series machine? I tried just compiling the boot stuff for an HP300, but that did not get very far. So, I was thinking about making the big leap to do the port. If anyone has already made a start (Piet?), maybe we should talk... ...Walker -------- James Walker GTE Laboratories, Waltham, MA -- -------- James Walker GTE Laboratories, Waltham, MA ======================================================================= 66 === Date: Wed, 8 Apr 1992 12:01:33 PDT From: David Goldberg Subject: upper case keywords Even if you believe that it is poor practice to use the name 'root' as an identifier for the root of a tree (and not everyone does), you can't avoid using keywords as identifiers because the interfaces supplied with the Modula3 distribution have over 100 instances of such use. (A few examples follow). Thus tools which always upcase keywords will not always do the right thing. VBT.i3:PROCEDURE MiscCodeTypeName(type: MiscCodeType): TEXT; VBT.i3:PROCEDURE PutProp(v: T; ref: REFANY); <* LL.sup < v *> Unix.i3:<*EXTERNAL*> PROCEDURE rename (from, to: char_star): int; IntTable.i3:PROCEDURE Get (t: T; key: INTEGER; VAR value: REFANY): BOOLEAN; RTScheduler.i3:PROCEDURE Pause (until: Time.T; alertable := FALSE) RAISES {Thread.Alerted}; Pixmap.i3:PROCEDURE FromBitmap(bits: Raw): T; David Goldberg goldberg@parc.xerox.com ======================================================================= 67 === Date: Wed, 8 Apr 1992 11:32:04 PDT From: David Nichols Subject: new m3rpc I've placed a new copy of our RPC code on parcftp.xerox.com:pub/m3/m3rpc.tar.Z. This version fixes two problems in the stub compiler: 1) strdup should no longer appear as an undef, and 2) a situation where a non-compiling stub was generated has been fixed. This could only happen if there was no program defined in the .x file. The new version looks like this: -rw-r--r-- 1 nichols parc 114065 Apr 8 11:26 m3rpc.tar.Z Bugs, etc. to me at nichols@parc.xerox.com. David ======================================================================= 68 === Date: 9 Apr 92 18:17:12 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Errata, Modula-3 (addendum) Since I posted an errata list for _Modula-3_ on March 24, a number of other comments turned up. Here is a posting of the revised list. For those of you who incorporated the older version, the only significant changes are on pp. 5, 43, 75, and 177. The complete list of changes are pages 5, 35, 43, 75, 90, 155, 177, 178, 180, 191, 212, and 311. Errata: Modula-3 (Prentice Hall, 1992) Samuel P. Harbison April 9, 1992 1. Errata by Page Line number "n" is the n'th line from the top of the page; line number "-n" is the n'th line from the bottom of the page. An "x" in the column labeled "Chg" means that the correction was supplied to the publisher and will appear in a future printing; no entry in that column means the problem was not considered serious enough to correct. Page:Line:Chg:Description 1:-4:x:Change "it easy" to "it is easy". 3:-6:x:Change "MODULE Main" to "MODULE Hello1 EXPORTS Main". 3:-1:x:Change "END Main" to "END Hello1". 5:11:x:The sentence should read, "Therefore, the characters MODULEHello1 would be considered a single identifier rather than the reserved word MODULE followed by the identifier Hello1." This was correct in the first printing, but "MODULEHello1" may appear as "MODULE Hello1" in the second printing. 5:-5:x:Change "MODULE Main" to "MODULE Hello1 EXPORTS Main". 5:-4:x:Change "END Main" to "END Hello1". 8:7:x:Change "Hello, World!" to "Hello, World!\n" 8::x:Swap positions of Example 1-4 and Figure 1-3. 10:-4:x:Rewrite last paragraph; mention left-associativity. 20:-5:x:Mention that loop variable i is declared in FOR statement. 20::x:Swap positions of Box and Example 2-5. 32:1:x:Add space before "By". 32:6:x:Change "n := n" to "n := BITSIZE(n)" 32:7:x:Add "because the result type of BITSIZE is always CARDINAL." 33:-4:x:Add missing ")" at end of declaration. 33:-5:x:Add missing ")" at end of declaration. 33:8:x:Fix typeface in exercise 4d. 35:1::Change "fifteen" to "eighteen." 38:-17::Change "a,pos" to "a, pos". 43:5:x:The box "Variations on Procedure Calls" makes an inaccurate statement about Modula-2. Modula-2 requires "()" in function calls but not in proper procedure calls. 49:8::"Solution" should be boldface. 50:1::In box, keywords should not be boldface. 57:-9:x:Rephrase as: "Which of the three versions is more readable?" 57:-5:x:Change "page 49" to "page 50". 64:-10:x: -8 MOD 3 is 1, not -1. 64:-5:x:x MOD 2 is 1 if x is odd; it cannot be -1. 67:19::Change "volume : [0..10]" to "volume: [0..10]". 74:-4:x:Add: The type of FIRST and LAST is the base type of T. 74:-4:x:Add: The type of NUMBER is CARDINAL. 74:-3:x:Add: "and has type T" to example of FIRST and LAST. 75:15:3:The solution presented in Example 4-14 doesn't work when VolumeLevel is an enumeration or an integer subrange. The problem is that the value of NewVolume may lie outside the range of VolumeLevel and therefore cause a run-time error. Here is the new example and a revised following paragraph Example 4-14 Rewrite procedure ChangeVolume in Example 4-8 on page 67 assuming VolumeLevel is defined as the enumeration type {Off, Soft, Medium, Loud, Ear_splitting}. SOLUTION You cannot compute the tentative value of NewVolume as VAL(ORD(volume)+n, VolumeLevel) without getting a checked run-time error if n is too large or too small. This makes the procedure somewhat more cumbersome. Here is one possibility, in which the range testing is hidden in the functions MIN and MAX: PROCEDURE ChangeVolume(n: INTEGER) = BEGIN WITH biggest = ORD(LAST(VolumeLevel)), smallest = ORD(FIRST(VolumeLevel)), proposed = ORD(volume) + n DO volume := VAL(MAX(MIN(biggest,proposed),smallest),VolumeLevel); END; END ChangeVolume; Now suppose that v has the subrange type [T.A..T.B]. For the assignment v := e to be legal, the type of e must either be T or else it must be a subrange of T that includes at least one value in T.A..T.B. That is, the types of v and e must share at least one value. Even if the assignment is legal, it is a checked run-time error if the actual value of e is not in T.A..T.B. 90:6:3:Change "Ans" to "answer". 111:6:x:Change "Point, the" to "Point (page 107), the". 111:-6:x:Change "SET OF t" to "SET OF T". 112:-5::Change "CARDINALITY" to "Cardinality". 112:-2::Identifiers in italics should be in the program typeface. 113:3:x:Change ":=" to "=". 129:1:x:Remove "[A]". 129:-3:x:Add "(or LAST(CARDINAL) if the array is empty)" before ":". 129:-10:x:Change "the procedure" to "ForAllElements". 134:-18::Change "out.If" to out. If". 136:1::In the box, the keyword ELSE should not be boldface. 141:18:x:Change "in procedure Forever" to "in the procedure". 141:-14:x:Change "ELSE =>" to "ELSE". 141:-9:x:Change "Chapter 12 (Threads)" to "Chapter 12". 155:-2:x:The last sentence should read: "Ordinary clients will import only Basic, while trusted clients will import both Basic and Friendly (Figure 8-5)." 168:1::In box, keyword "END" should not be boldface. 176:-9::Change "P" to "p" (four times) in Ex. 10-1 and following text. 177:-3:x:Change "beta := beta;" to "beta := alpha;" 178:-1:x:Add NEW to the list of builtin functions for reference types. 180:19::Add a semicolon after "theta := Math.Pi / 2.0". 191:-19::Change "IMPORTS Rational" to "IMPORT Rational". 212:-4::Since TL=TR implies TL<:TR, the first entry in the third row of the table is understood to mean TL<:TR AND TL#TR. The table layout already suggests this interpretation. 214::x:Add "RETURN self" to InitPostion and InitRectangle. 214:-19:x:Editorial changes to paragraph "The Rectangle.init method...". 218::x:Add "RETURN self" to InitPosition and InitRectangle. 219::x:Add "RETURN self" to InitCircle. 219:-8:x:Editorial changes were made to the last paragraph. 226:-7::Change typeface of "Child". 227:8:x:Mention that untraced things are discussed in 13.2 on p. 258. 227:-6:x:Change typeface of "name". 234::x:Change "94681" to "94861" (four times). 296:-7::Change "=QualID" to "= QualID". 299:7:x:The answer to D.1.5(c) is 11, not 3. 300:8:x:Change "a := y" to "b := y". 300:-16:x:Change all "A" and "B" to "a" and "b" in answer to exercise 9. 300:-11:x:Delete procedure heading; the solution is a block statement. 305:::Correct typeface of leading entry in letter groups as necessary. 305:::Add "Alerted (Thread)" to the index (cite p. 250) 311:4::Change "Subtypes (see Types)" to "Subtypes (see Type)". 2. Errata History This section lists the errata according to the date they were entered into the list. 2.1 March 24, 1992 Pages 1, 3, 5, 8, 10, 20, 32, 33, 56, 57, 64, 74, 111, 113, 129, 141, 214, 218, 219, 227, 234, 299, 300. These changes should be reflected in the book beginning with the second printing. 2.2 March 31, 1992 Pages 5, 35, 43, 75, 90, 155, 177, 178, 180. These changes should be reflected in the book beginning with the second or third printing. 2.3 April 9, 1992 Pages 191, 212, 311. ======================================================================= 69 === Date: Wed, 8 Apr 1992 12:05:06 GMT From: ian@syacus.acus.oz.au (Ian Joyner) Subject: C++ Critique in comp.lang.c++ I have posted a critique of C++ in comp.lang.c++. This can form a basis of comparison of Modula-3 and C++. -- Ian Joyner ACSNet: ian@syacus.acus.oz ACUS (Australian Centre for Unisys Software) Internet: ian@syacus.acus.oz.au Tel 61-2-390 1328 Fax 61-2-390 1391 UUCP: ...uunet!munnari!syacus.oz ======================================================================= 70 === Date: 10 Apr 92 05:09:02 GMT From: fn00@gte.com (Farshad Nayeri) Subject: Summer Opportunity for Modula-3 Programmer Hi Folks. I would just like to remind our enthusiastic Modula-3 crowd that we happen to have a summer position open for a full-time Modula-3 programmer. The position involves building nice front ends for our Distributed Object Manager prototype using Trestle (most probably FormsVBT when it comes out :-) and of course Modula-3 (and getting paid on top it :-). The full description is available from misc.jobs.offered. I will be happy to send you a copy, in case you don't have access to that newsgroup. --farshad P.S., I hope that the USENET thought police doesn't take away my posting privilages because of this posting. ;-) -- Farshad Nayeri Intelligent Database Systems fn00@gte.com Computer and Intelligent Systems Laboratory (617)466-2473 GTE Laboratories, Waltham, MA ======================================================================= 71 === Date: Sat, 11 Apr 92 09:48:00 PDT From: msm@src.dec.com (Mark S. Manasse) Subject: Re: C++ Critique in comp.lang.c++ Ian's article on C++ is quite intersting. It's a little too pure in its faith in object-orientation for my tastes, but a lot of its critiques are sensible. There are several points of Modula-3 where I suspect that Ian would find too much similarity with C++ for his taste, and a few other places he might be dissatisfied. Here's my attempt to answer his objections in advance. For all those points in Ian's message I don't mention, I think that M3 already solves the problem. VALUE mode parameters ----- ---- ---------- Both C++ and Modula-3 strive to be good systems programming languages, as well as good object-oriented programming languages. Consequently, there are features exposed by these languages that Ian doesn't like, such as VALUE parameter mode. I think that both for compatability with external libraries and operating systems, and for efficiency, VALUE mode is essential. I could believe that a persuasive argument could be made that READONLY should be the default. <* HIDES *> considered necessary ----------- ---------- --------- Ian argues that one shouldn't be able to introduce conflicting names into the scope of an object. While this seems sensible, it conflicts badly with Modula-3's strategy using partially-opaque types for data hiding: I can't be expected (nor can the compiler check if I succeeded) to avoid introducing fields and methods whose names conflict with names I can't see. M3 does avoid one of the most serious pitfalls of C++: the key word OVERRIDES is used to introduce replacement methods, while METHODS is used to name a new method. Two problems remain. First, a subtype might introduce names into scope that visibly in that type conflict with supertype names. Such a conflict should rarely cause a problem: programs that use the subtype presumably want to reference the subtype fields when they name something. However, the addition of a field or method might inadvertantly change the meaning of code that used to reference the supertype field; consequently, the compiler might well issue a warning when it detected name conflicts, unless the pragma <* HIDES *> preceded the declaration. The introduction of a HIDES pragma should be done cautiously, except in very stylized cases, such as init methods. The final problem is that caused by partial revelation. The declaration of a name may appear innocent to the compiler; it may only be later on at a point where the concrete type and a subtype are both visible that the conflict is noticed. A compiler warning would again be appropriate; a variant of HIDES which specifies the type and name in conflict seems appropriate. On ABSTRACT types -- -------- ----- In M3, because of partial revelation, it is very easy to introduce types without values for some of the methods. This error leads to a checked runtime error at the point of method invocation, but that's a little later than might be useful. The compiler could easily provide some help here, with a small amount of assistance from the interface designer. In the absence of partial revelations, the compiler would be able to know which methods were concrete and which abstract, and could warn of any call to NEW an object with abstract methods, unless the programmer guaranteed (say by writing <* ABSTRACT init, incr *>) that he was aware that some methods were abstract. With partial revelations, life is harder; separate compilation won't allow the compiler to know whether a method is abstract or not. If we provide pragmas ABSTRACT and CONCRETE which apply to types which are partially- revealed, and which optionally take a list of method names (with any unnamed methods defaulting the other way), we can check the uses of every type, and we can have the compiler check that the type meets its abstractness specification. It's probably sensible to make CONCRETE the default, since many introductions of partially-revealed types are just done to hide the names of the method values. Default parameters ------- ---------- Ian expressed in no uncertain terms his disdain for default parameters. I think that M3's default paramters are somewhat better than C++'s, and that, in any case, default parameters are too useful in the software engineering process to toss out. M3 default parameters are better, because M3 allows parameters to a call to be named. Thus, unlike C++, I can make a procedure call where all but the last parameter is defaulted, by naming that parameter in the call. This isn't entirely a panacea, but it's as close as we're likely to get. Ian argues that we could just give the procedure a different name when some of the parameters are defaulted, but it's hard enough coming up with one good name for a procedure, let alone two, or four, or thirty-two. It's especially hard to come up with names if you have a procedure that's already using the best name, but which is missing a parameter. You wind up either giving the full procedure some awkward name that reminds you forever after that someone really botched the interface the first time, or you have to modify all the clients so that they pass a new parameter that you could have just as well defaulted, or so that they call the defaulted version of the procedure. Blecch. I further contend that default parameters provide much better documentation for those defaults than you would get through multiple procedure names. Objects as monitors ------- -- -------- Ian suggests that objects can be treated as monitors, and that this paradigm by itself makes objects wonderful for concurrent programming. I'd like to support this, but it's really only the beginning of what you need to do. In Trestle, Greg and I carefully document the locking level of fields and methods of our objects. Most of our objects *do* descend from MUTEX, and that MUTEX frequently does protect the fields and methods of that object. That in itself, however, is inadequate for concurrent programming. To avoid deadlock, it is essential that you have some mechanism for capturing the ordering on your MUTEXes. In order to support asynchronous computation, you must have a mechanism for signalling conditions, so that threads don't have to busy-wait until there's something for them to do. Anyhow, I believe that M3 is in much better shape on this point than most other languages I know. Greg and I are in the process of working on automatic tools to verify that programs that use our locking level pragmas are race and deadlock free. capitalizationShouldBeSignificant --------------------------------- This is basically an unimportant surface feature of a language. At SRC, we've found that using capitalization conventions to distinguish types, constants, and procedures from variables, fields, and methods is helpful. And it avoids the awkwardness of having to come up with good names for both a type and a member of the type. While you can avoid this by suffix conventions (types are always plural, say), it's easier to admit that Pie = (Blueberry, Cherry) is a nice name for the type, and that pie := Pie.Cherry is a sensible way to name a variable. But no one will ever be convinced who doesn't already believe. x.incr() -------- Ian argues that 0-ary procedures shouldn't need parentheses, just as variables don't. Well, maybe, but procedure calls don't have L-values. That is, it's an abuse of mathematical thinking to think of variables as 0-ary functions. Moreover, in the case of a method call, it isn't true that the function is 0-ary; it's 1-ary with an implicit argument of the object itself. Finally, if naming a procedure or method ought to call it, and special syntax is required to treat it as a procedure variable, then you're going to need that special syntax in declaring the values for methods. Blecch. I suppose that I could be persuaded that () should be allowed after a variable or field name to convert it to its value. That is, if x has a field foo, x.foo() is a non-designator whose value is that of x.foo. Procedures versus methods, modules versus objects ---------- ------ -------- ------- ------ ------- Ian complains that in C++, the interface designer must designate which methods are virtual, and which are not. M3 doesn't have that problem: all methods are virtual. But not all procedures that apply to objects are methods. Some are procedures defined at top-level in an interface. Greg and I will plead guilty to the charges of having done this extensively in Trestle. Our defense is that method syntax is only useful for those things where you want the programmer to think of the thing as an object, and where the semantics admit some sensible form of overriding. Thus, painting into a window in Trestle is a procedure call. A client programmer should not think of there being any retained state as a result of this, except the state on the screen. And there isn't any utility to overriding this as a method, except to make it slower. Because, in fact, there is state inside a window, and the painting calls are buffered up and then handed off to a method which gets to deal with them several at a time. The consequence is that the call requires not just the procedure name, but the module name as well (adding some of that redundancy that Ian generally approves of), the system runs faster, and no restrictions have been imposed on the programmer. A similar case is that of readers and writers, which are carefully described in Greg's book on M3. The outer layer exposes only procedures that perform a lot of boiler-plate, resolving eventually to method calls on a data structure tuned for better performance. Call us troglodytes, call us retrograde, call us insensitive to the higher truth that everything is a method call. You would be right. A programming language should facilitate the design of well-crafted interfaces; it can not prohibit the construction of bad ones. Modules and procedures have proven their value in the past. Just because everything I can write with them can be written in pure object notation doesn't make it a good idea to do so. Unless you want us to delete all the boolean operators except NAND, all the arithmetic operators except -, .... Some final issues ---- ----- ------ Ian may find a few more things about M3 that he'll hate. I hope not, but who knows. Here are a few candidates. 1. Wrong number of friends In M3, given partial revelations, the notion of friends doesn't make too much sense. The information hiding is much better than in C++, because you don't even get to notice when things you shouldn't use change. But, if the revelatio n is made in an interface, there are no restrictions to prevent programmers from importing those interfaces. I think this is good: you never know when you'll want to write a module for, say, data-structure browsing that will need to access fields that you had meant to share only with a few of your closest friends. In large part, this is mitigated by the ability to have a module export multiple interfaces, allowing you to reveal things inside an implementation module, if you really don't want anyone else to know about it. 2. Nested scopes, including nested procedures Hey, we think they're useful every now and then. Limited scopes for variables can be very useful; often you can avoid introducing a variable until you also know how to initialize it. 3. Objects as references only This seems to be required by safety, if you have either value mode parameters or structure copy. While Oberon seems to get pretty far without this restriction, I would find it strange to pass an object's data fields in part; the methods of the object might access fields which didn't exist in the restricted object. If you never pass objects by value, and object copy doesn't copy the methods, you might be OK. But then you have to deal with the impact on garbage collection, and that can be a little tricky. At any rate, there are various techniques one might explore that would give you the benefits of having objects as records instead of as references to records. Garret Swart has posted in the past a few restrictions one could make that would make stack allocation safe. On a more interesting note, Henry Baker's recent SIGPLAN paper (Why CONS shouldn't CONS its arguments) argues that you can use the stack to hold the most recent generation of stuff that should be on the heap, copying things off by need. Clearly, a compiler could often work out when you're going to wind up needing to do that copy, and could optimize that case a little for you. Finally, I would list multiple inheritance, but since Ian never mentioned it, I'll omit it too. Mark ======================================================================= 72 === Date: 13 Apr 92 14:57:06 GMT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: RPCVBT imports RPC in Trestle? The interface RPCVBT in Trestle imports RPC in order to have a Trestle application distributed among many processes. We are directly interested in such applications and tried without success to find the RPC interface. Indeed, it probably defines how the processes find themselves and send and receive messages. Is it there somewhere but not installed in the usual place or is it missing? -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 73 === Date: Tue, 14 Apr 92 06:32:27 PDT From: msm@.dec.com (Mark S. Manasse) Subject: Re: RPCVBT imports RPC in Trestle? Regrettably, that interface doesn't currently have a Modula-3 implementation. In addition to the Modula-3 Trestle, Greg, Steve, and I were maintaining a Modula-2+ version, where RPC was real. Even for those parts of the system that we couldn't (yet) build in M3, we did the design in M3. RPCVBT is such a stub. I don't know whether it would be easy to use PARC's port of Sun RPC to do this. Mark ======================================================================= 74 === Date: 15 Apr 92 14:00:12 GMT From: jjw1@mongoose.gte.com (Jim Walker) Subject: Porting Modula-3 I have not received any replies to my query regarding porting Modula-3 to an HP Series 700, aka Snake. (Did that post get out?) So anyway, I am going to, as my time permits, attempt to do the port myself. The most important question that I have (really more of a meta-question) is whether I should ask my porting questions in this forum, or is there somebody there at SRC that I should correspond with via e-mail? That's it for now... ...Walker -------- James Walker GTE Laboratories, Waltham, MA ======================================================================= 75 === Date: Wed, 15 Apr 92 10:32:35 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: Porting Modula-3 In article <16141@bunny.GTE.COM>, jjw1@mongoose.gte.com (Jim Walker) writes: > The most important question that I have (really more of a meta-question) > is whether I should ask my porting questions in this forum, or is there > somebody there at SRC that I should correspond with via e-mail? m3-request@src.dec.com is probably the right place to ask that kind of question. -- Eric. ======================================================================= 76 === Date: Thu, 16 Apr 1992 05:37:50 GMT From: ian@syacus.acus.oz.au (Ian Joyner) Subject: Re: C++ Critique in comp.lang.c++ Mark, My apologies for taking so long to respond, but I have been inundated with mails asking for the Postscript, and many being complementary. Let me answer some of your points. msm@src.dec.com (Mark S. Manasse) writes: >Ian's article on C++ is quite intersting. It's a little too pure in its >faith in object-orientation for my tastes, but a lot of its critiques are >sensible. Let me counter the notion that I am a purist. I am a practitioner, who happens to see that where things are not implemented cleanly in the tools we use, that this often makes life difficult. I believe we should start with a pure base, and evolve from there, adding what is only necessary. >There are several points of Modula-3 where I suspect that Ian would find >too much similarity with C++ for his taste, and a few other places he might >be dissatisfied. Here's my attempt to answer his objections in advance. >For all those points in Ian's message I don't mention, I think that M3 >already solves the problem. You may be jumping the gun a bit. I have not been able to pick up a book on M3 yet, and have not programmed at all in Modula, but have in Pascal and Object Pascal (and Simula). Many of the points in the critique are subtle, and are often fixed in other languages in subtle ways. >VALUE mode parameters >----- ---- ---------- >Both C++ and Modula-3 strive to be good systems programming languages, as >well as good object-oriented programming languages. Consequently, there >are features exposed by these languages that Ian doesn't like, such as >VALUE parameter mode. I think that both for compatability with external >libraries and operating systems, and for efficiency, VALUE mode is >essential. I could believe that a persuasive argument could be made that >READONLY should be the default. I do not believe that systems programming and OOP are at odds. In fact I think they are very well suited. But I do think the way it is done in C++ is wrong. Systems level programming does not require that all structuring and good programming practice needs to be undermined. If so, then we should not be developing for that processor, as it must be a very ill-defined architecture. It is also wrong to think that systems programming means a C style language (or worse assembler). If Modula-3 is a systems programming language then it disproves this. Burroughs has been in the business of writing systems in higher level languages exclusively since the early 1960s, first with Algol, and then with SDL on the B1000. This proves that the concept of minimal extensions to languages can easily support systems programming. But that is now the old style way of doing it. Now the way that OOP implements systems programming is to embed the system level stuff in an object of its own, and the program only accesses the system through this clean interface. In fact portability is then guaranteed, as all you need to do is port the system class. This is not really so different to the C way of modularisation and importing interfaces by #include, but it is much cleaner and more sophisticated. I think you may misunderstand my comments on value mode parameters (if I am not misunderstanding your comments). I am saying that value mode is the only mode necessary in OOP. Call by reference and by name are unnecessary, and error-prone, and I like even less the way C simulates these by passing pointers and function pointers. ><* HIDES *> considered necessary >----------- ---------- --------- I can't really comment on this as I don't know about the M3 constructs you are talking about. However, OVERRIDES is certainly preferable to C++'s scheme, so I think M3 is probably way ahead here. My point though is that where you have an issue of programmer convenience vs safety, safety must override convenience. Since when has programming been convenient anyway. I would find it much more convenient, if they just posted out my pay cheque every week, without me having to come in and program for it! Programmer convenience in the C sense is often only a short term consideration. Nothing is more inconvenient than tracking down some very subtle errors caused by such convenience. >On ABSTRACT types >-- -------- ----- >In M3, because of partial revelation, it is very easy to introduce types >without values for some of the methods.... I'm not really sure what you mean by partial revelation in M3. Sounds rather Biblical though :-) >Default parameters >------- ---------- >Ian expressed in no uncertain terms his disdain for default parameters. I >think that M3's default paramters are somewhat better than C++'s, and that, >in any case, default parameters are too useful in the software engineering >process to toss out. >M3 default parameters are better, because M3 allows parameters to a call to be >named. Thus, unlike C++, I can make a procedure call where all but the last >parameter is defaulted, by naming that parameter in the call. Well I did say that there were other ways to provide this other than the C++ way. Perhaps M3 achieves this. My point is to at least get these points considered, and not just to accept default parameters as a good thing. I do agree that the problem without them is increased name space. But then again, I see this as a matter of programmer convenience vs safety. >Objects as monitors >------- -- -------- >Ian suggests that objects can be treated as monitors, and that this paradigm >by itself makes objects wonderful for concurrent programming. >I'd like to support this, but it's really only the beginning of what you need >to do. Yes, I agree, but I wasn't going to write a book on this. I think there are still many problems for the researchers to solve, and that is why we don't have this with us now. But I think also that what the research is showing is that the objects must be very clean to achieve this. C++ objects are not clean enough. >capitalizationShouldBeSignificant >--------------------------------- Let me retitle this: capitalisation_should_not_be_significant >This is basically an unimportant surface feature of a language. At SRC, we've >found that using capitalization conventions to distinguish types, constants, >and procedures from variables, fields, and methods is helpful. And it avoids >the awkwardness of having to come up with good names for both a type and a >member of the type. While you can avoid this by suffix conventions (types >are always plural, say), it's easier to admit that Pie = (Blueberry, Cherry) >is a nice name for the type, and that pie := Pie.Cherry is a sensible way to >name a variable. >But no one will ever be convinced who doesn't already believe. I agree that this is an unimportant surface feature, but as I showed, it can lead to really obscure errors. The thing is the less likely that something is going to cause an error, the more obscure the error when it does happen. Thus, I err again in terms of safety, rather than programmer convenience, not that this is really at all inconvenient. >x.incr() >-------- >Ian argues that 0-ary procedures shouldn't need parentheses, just as variables >don't. Well, maybe, but procedure calls don't have L-values. That is, it's >an abuse of mathematical thinking to think of variables as 0-ary functions. No, I think the abuse to mathematical thinking is the assignment statement. When you use a variable in an expression, it is equivalent to the notion of mathematical function. It returns a value of a given type. Thinking of variables and value returning procedures as both being mathematical functions is very elegant. Besides in OOP, you should not be assigning to the a variable entity of an object from outside the class anyway. So to the interface user of the class, whether the entity is a variable or a function should be indistinguishable. >I suppose that I could be persuaded that () should be allowed after a variable >or field name to convert it to its value. That is, if x has a field foo, >x.foo() is a non-designator whose value is that of x.foo. Well, if you can be persuaded this way, then that proves that the () syntax is superfluous, and it may as well not be there ;-) >Call us troglodytes, call us retrograde, call us insensitive to the higher >truth that everything is a method call. OK, you troglodytes, you retrogrades, you insensitive.... Well I didn't really mean that but since you asked for it, only trying to be obliging :-) >Some final issues >---- ----- ------ >Ian may find a few more things about M3 that he'll hate. I hope not, but >who knows. Here are a few candidates. >1. Wrong number of friends >In M3, given partial revelations, the notion of friends doesn't make too much >sense. Ah, now I think I see what you mean by partial revelation. I suspect that this is the very reason, why I said friends were not a very general mechanism. Partial revelation would be exactly the mechanism I had in mind as much better and controllable than friend. Is that right? >2. Nested scopes, including nested procedures >Hey, we think they're useful every now and then. Limited scopes for >variables can be very useful; often you can avoid introducing a >variable until you also know how to initialize it. Well I have spent a lot of time writing in languages that provided this, (ALGOL, Pascal), and thinking how much better off we were than C. But in the face of OO, and the new style of scoping that brings, I am not so sure. >3. Objects as references only ... >Finally, I would list multiple inheritance, but since Ian never mentioned it, >I'll omit it too. No, I have no problems with multiple inheritance. But it must be used correctly. This would have to be an instance where I would trust the programmer to play with razor blades, and not ban them, just because a baby might get hold of them. Thanks for the comments, I hope that clarified a few things. -- Ian Joyner ACSNet: ian@syacus.acus.oz ACUS (Australian Centre for Unisys Software) Internet: ian@syacus.acus.oz.au 115-117 Wicks Rd, North Ryde, N.S.W, Australia 2113. Tel 61-2-390 1328 Fax 61-2-390 1391 UUCP: ...uunet!munnari!syacus.oz ======================================================================= 77 === Date: Wed, 15 Apr 92 20:37:09 PDT From: jdd@src.dec.com (John DeTreville) Subject: Modula-3 Users Group Meeting... A few weeks ago here on comp.lang.modula3, Sam Harbison suggested a Modula-3 get-together at this June's SIGPLAN meeting in San Francisco, and Michel Dagenais from l'Ecole PolyTechnique de Montreal seconded the idea of a Modula-3 BOF session. Here at DEC SRC, we've also been thinking of organizing a Modula-3 Users' Group (MUG?) meeting this summer. It looks like it might be a good idea to merge the MUG meeting with the SIGPLAN Modula-3 BOF session, and this message is to ask people whether they agree. We were thinking of an all-day meeting, perhaps the Tuesday before SIGPLAN proper begins. We can line up a number of speakers from SRC, and would like to solicit other potential speakers from outside. We'd especially like to hear about your experiences using the language and the SRC system. In return, we can talk about our own future plans, and together we can sketch out where Modula-3 is going. What we need to know is whether people can make it that Tuesday (June 16), and, if not, when might be better. Our first choice would be to meet at SRC--there's convenient public transit from San Francisco--but let us know whether you'd prefer the conference site. And of course, a shorter meeting might be easier to schedule. If you'd like to give a talk, send a title and a very short abstract. We're also making our own list of people we'd like to hear speak, and we'll be contacting you if you don't contact us first. We'd also like to schedule some time for discussions about the language and system. If you'd like to place a topic on the agenda, please mail it in. And when you send all this in, please send it to me, jdd@src.dec.com. Sooner is better than later. I'll post followups to comp.lang.modula3. Cheers, John ======================================================================= 78 === Date: 16 Apr 92 12:56:44 GMT From: thewalt@canuck.ce.berkeley.edu (C. Thewalt) Subject: Evolution After reading with great interest the recent discussions about number crunching in Modula-3, I never saw any answers to some fairly important questions. In particular, what is the likelihood that any of the following features will find their way (formally) into M3? 1) support for complex types (built-in so that usual operators work) 2) exponentiation operator 3) standard math library (trig etc) It is an elegant language that we'd like to use for large analytical packages (both teaching and research), but it seems that you have to do some unnecessarily ugly things to get the three items listed above. 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... ======================================================================= 79 === Date: Thu, 16 Apr 1992 16:23:57 GMT From: mday@jukebox.lcs.mit.edu (Mark Day) Subject: Re: C++ Critique in comp.lang.c++ ian@syacus.acus.oz.au (Ian Joyner) writes: >msm@src.dec.com (Mark S. Manasse) writes: >Ian argues that 0-ary procedures shouldn't need parentheses, just as >variables don't. Well, maybe, but procedure calls don't have >L-values. That is, it's an abuse of mathematical thinking to think of >variables as 0-ary functions. No, I think the abuse to mathematical thinking is the assignment statement. No, I think the abuse to computational thinking is trying to squeeze it into a framework of mathematical thinking. I think you are both making reasonable points about language design elsewhere in your articles, but I don't think very highly of this implicit assumption that a programming language is better as it comes nearer to mathematical thinking. --Mark Day mday@lcs.mit.edu ======================================================================= 80 === Date: 16 Apr 92 17:14:19 GMT From: ms@cs.brown.edu (Manojit Sarkar) Subject: C++ vs. M3 A very good thing about M3 is the absence of "include" facility... In C++, to me includes are sources of confusion - when you see an "include" statement - you have no idea about what is being really included - because you include a "file" and you have no idea about what it contains in terms of your program components without looking at the file. Consider IMPORT statements in M3, your imports are real program components, INTERFACES there is no additinal level of obscuration through file names - which has no place in the programming concepts in the first place. When one is programming, why should one have to worry about which definition is in which file? You should be able to refer to the definitions by names instead. ======================================================================= 81 === Date: Thu, 16 Apr 1992 05:17:48 GMT From: johnh@wheaton.edu (John (Doc) Hayward) Subject: Possible Modula-3 compiler performace bug? Is there a problem with v2.0 Modula-3 compiler (or is it a problem with the MIPS C compiler? If a large array is passed by value it takes significantly more time to compile than if passed by reference. Below is a script example. The time seems to be taken up in the c compilation when cc creates a process called ugen. We are running version 2.0. Script started on Wed Apr 15 23:28:14 1992 > csh> cat Main.m3 > MODULE Main; > CONST > Size = 10000; > > PROCEDURE Proc(VAR Values:ARRAY [1..Size] OF INTEGER; Lots:INTEGER) : INTEGER = > VAR > I : INTEGER; > Sum : INTEGER := 0; > BEGIN > FOR I:= 1 TO Lots DO > Sum := Sum + Values[I] > END; > RETURN Sum > END Proc; > VAR > Values : ARRAY [1..Size] OF INTEGER; > I : INTEGER; > Sum : INTEGER; > BEGIN > FOR I := 1 TO Size DO Values[I] := I END; > Sum := Proc(Values,Size) > END Main. > csh> time m3make > /usr/local/bin/m3 -w2 -make -why -g -o List Main.m3 > new source -> compile Main.m3 > "Main.m3", line 7: warning: not used (I) > "Main.m3", line 17: warning: not used (I) > 2 warnings encountered > new objects -> link List > 3.5u 2.5s 0:12 47% 552+4600k 321+192io 137pf+0w < ^^^^--- 3.5 user cpu seconds > csh> ed Main.m3 > 425 > 5 > PROCEDURE Proc(VAR Values:ARRAY [1..Size] OF INTEGER; Lots:INTEGER) : INTEGER = > s/VAR // < ^^^^^^^^ Change from pass by value to pass by reference > p > PROCEDURE Proc(Values:ARRAY [1..Size] OF INTEGER; Lots:INTEGER) : INTEGER= > w > 421 > q > csh> !t > time m3make > /usr/local/bin/m3 -w2 -make -why -g -o List Main.m3 > new source -> compile Main.m3 > "Main.m3", line 7: warning: not used (I) > "Main.m3", line 17: warning: not used (I) > 2 warnings encountered > new objects -> link List > 121.4u 4.5s 2:20 90% 290+1525k 326+235io 137pf+0w < ^^^^^^--- 121.4 user cpu seconds > csh> ^D > script done on Wed Apr 15 23:34:37 1992 johnh... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = UUCP: johnh@wheaton.uucp telephone: (708) 752-5871 (office) Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187 Act justly, love mercy and walk humbly with your God. Micah 6:8b ======================================================================= 82 === Date: Fri, 17 Apr 92 14:09:17 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: Possible Modula-3 compiler performace bug? In article <1992Apr16.051748.29331@wheaton.wheaton.edu>, johnh@wheaton.edu (Joh n (Doc) Hayward) writes: > Is there a problem with v2.0 Modula-3 compiler (or is it a problem > with the MIPS C compiler? With the C compiler. ugen is the thing that generate object code from the intermediate representation used in this compiler (ucode). I'll try to see what our compiler people have to say. --- Eric. ======================================================================= 83 === Date: Sat, 18 Apr 1992 09:02:17 GMT From: dmb@usl.edu (David M. Brumley) Subject: Should Params.Get (n), for n >= RTArgs.argc, raise an exception? I got bitten when I accidentally called Params.Get (n) with n = argc. Any sympathy? FYI: m3 ver 2.04, DECstation 5000/200, ULTRIX 4.2 ======================================================================= 84 === Date: 7 Apr 92 20:19:25 GMT From: matthes@dbis1.informatik.uni-hamburg.de (Florian Matthes) Subject: LONGFLOAT(x:REAL) in 2.05? A simple, stupid question: Using m3 version 1.6 one could write longRealVar:= LONGFLOAT(realVal) to convert a single precision real value into a double precision real value. If I try to recompile existing M3 programs with the new 2.05 compiler (SPARC architecture), I get the following error messages: "...", line nn: undefined (LONGFLOAT) "...", line nn: types are not assignable Is there a new mechanism to achieve this conversion? Please reply to matthes@dbis1.informatik.uni-hamburg.de. Thank you for your help Florian Matthes ======================================================================= 85 === Date: Mon, 20 Apr 92 12:53:29 EDT From: wyant@centerline.com Subject: M3 and Epoch Epoch users might want to grab the tek-epoch-stuff package available via anonymous FTP from a variety of sites (gatekeeper.dec.com, ftp.uu.net, ...). It provides rendering of comments in a user-specified font. For M3, I find that it makes well-documented interfaces quite pleasant to read on the screen. You need to make one change to modula-3.el to use it: old (modify-syntax-entry ?\( "()" table) (modify-syntax-entry ?\) ")(" table) new (modify-syntax-entry ?\( "()1" table) (modify-syntax-entry ?\) ")(4" table) Otherwise, comment starter and ender characters get dropped. It shouldn't be to hard to add support for highlighting keywords as well. Geoff Wyant wyant@centerline.com Centerline Software, Inc. (Formerly Saber Software, Inc) 10 Fawcett Street Cambridge, Ma. 01238 ======================================================================= 86 === Date: Mon, 20 Apr 92 14:05:10 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: LONGFLOAT(x:REAL) in 2.05? In article , matthes@dbis1.informatik.uni-hamburg.de ( Florian Matthes) writes: > A simple, stupid question: Using m3 version 1.6 one could write > > longRealVar:= LONGFLOAT(realVal) > > to convert a single precision real value into a double precision real > value. If I try to recompile existing M3 programs with the new 2.05 > compiler (SPARC architecture), I get the following error messages: > > "...", line nn: undefined (LONGFLOAT) > "...", line nn: types are not assignable > > Is there a new mechanism to achieve this conversion? Yes. 2.x implements the latest version of the language, and there is now a single operator for conversions to floating-point types: FLOAT (x: INTEGER; T: Type := REAL) : T; (x: Float; T; T: Type := REAL): T; where Float and T can be any of the floating-point types (REAL, LONGREAL, EXTENDED). So you can write: longRealVar:= FLOAT (realVal, LONGREAL); This change was motivated by the introduction of the EXTENDED floating-point type. It seemed better to have a single generic conversion operator than to introduce a new operator to convert to EXTENDED. -- Eric. ======================================================================= 87 === Date: Wed, 22 Apr 1992 18:28:11 GMT From: dmb@usl.edu (David M. Brumley) Subject: Re: Should Params.Get (n), for n >= RTArgs.argc, raise an exception? moss@cs.umass.edu (Eliot Moss) writes: >Well, I can see Params.Get(n) for n >= argc either raising an exception, or >returning the empty string (or NIL?). AN exception is probably the safeest >since it will tend to prevent unintended infinite loops .... Eliot >-- Well, it returns NIL now in SRC Modula-3. It's simply a matter of being careful about the value of 'n' and double checking the return value. I just thought a range check on the value of 'n' with an appropriate exception raised on failure would make the interface foolproof, for fools like me. ======================================================================= 88 === Date: 22 Apr 1992 14:27:50 -0500 From: eckam@cs.utexas.edu (Daniel James Eckam) Subject: stdout This may be a stupid question, but I'll ask anyway. Why is all interactive output saved until a program finishes execution ? (m3 version 2.04 on Sun 4) In other words, what's wrong with this program: MODULE test2 EXPORTS Main; IMPORT Rd, Wr, Stdio, Text; VAR c: CHAR; BEGIN c:= ' '; WHILE (c # 'y') AND (c # 'n') DO Wr.PutText(Stdio.stdout, "Measure time of execution ? (y/n) "); c:= Text.GetChar(Rd.GetLine(Stdio.stdin), 0); END; END test2. When I run this, I don't get any prompts until I have entered a y or n. ---------- Dan Eckam :w ? :q i ======================================================================= 89 === Date: 22 Apr 92 16:49:40 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Should Params.Get (n), for n >= RTArgs.argc, raise an exception? Well, I can see Params.Get(n) for n >= argc either raising an exception, or returning the empty string (or NIL?). AN exception is probably the safeest since it will tend to prevent unintended infinite loops .... Eliot -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================= 90 === Date: Thu, 23 Apr 1992 12:11:52 GMT From: dmb@usl.edu (David M. Brumley) Subject: Re: stdout laverman@cs.rug.nl (Bert Laverman) writes: >Daniel James Eckam wrote: >> This may be a stupid question, but I'll ask anyway. Why is all >> interactive output saved until a program finishes execution ? >Never fear; the question isn't stupid. FIrst: output is _buffered_, >not saved. That makes a small difference. But should 'Stdio.stdout' be buffered? According to the interface for Stdout, "If the output streams are directed to terminals, they should be unbuffered, so that explicit Wr.Flush calls are unnecessary for interactive programs." ======================================================================= 91 === Date: Thu, 23 Apr 1992 07:58:04 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: Re: stdout Daniel James Eckam wrote: > This may be a stupid question, but I'll ask anyway. Why is all > interactive output saved until a program finishes execution ? Never fear; the question isn't stupid. FIrst: output is _buffered_, not saved. That makes a small difference. > (m3 version 2.04 on Sun 4) In other words, what's wrong with this > program: Ah, that's another questions! > MODULE test2 EXPORTS Main; > > IMPORT Rd, Wr, Stdio, Text; > > VAR c: CHAR; > > BEGIN > c:= ' '; > WHILE (c # 'y') AND (c # 'n') DO > Wr.PutText(Stdio.stdout, "Measure time of execution ? (y/n) "); Insert a "Wr.Flush(Stdio.stdout);" here and all will be well. > c:= Text.GetChar(Rd.GetLine(Stdio.stdin), 0); > END; > END test2. > > When I run this, I don't get any prompts until I have entered a y or n. IO is buffered, and since this is a small program, the flushing of the output buffers doesn't happen until the program finishes. > ---------- > Dan Eckam > :w > ? > :q > i ^X^S^X^C ;-) -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null ======================================================================= 92 === Date: Thu, 23 Apr 92 11:39:32 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: stdout In article , dmb@usl.edu (David M. Brumley) w rites: > laverman@cs.rug.nl (Bert Laverman) writes: > > >Daniel James Eckam wrote: > >> This may be a stupid question, but I'll ask anyway. Why is all > >> interactive output saved until a program finishes execution ? > >Never fear; the question isn't stupid. FIrst: output is _buffered_, > >not saved. That makes a small difference. > > But should 'Stdio.stdout' be buffered? According to the interface for > Stdout, "If the output streams are directed to terminals, they should > be unbuffered, so that explicit Wr.Flush calls are unnecessary for > interactive programs." The trouble is that an unbuffered writer has little choice but to output each character as it is delivered by the class-indenpendent buffering mechanism. This means one write(2) call per character and it seems a bit expensive; when the compiler was invoked under gnuemacs, the error messages would take a very long time to be displayed, for example. The only way to not have one write(2) call per character is to make the writer is buffered. This explains why we changed stdout to be buffered. There are two solutions to have the characters appear on the target before the buffer is full: - insert some Wr.Flush (wr) in your program, - build an AutoFlushWr.T on top of your wr. AutoFlush writers start a thread that comes around every now and then to do a Wr.Flush. I believe it is ok to have near the beginning of your program something like: Stdio.stdout = AutoFlushWr.New (Stdio.stdout); -- Eric. ======================================================================= 93 === Date: Fri, 24 Apr 92 10:27:03 EDT From: wyant@centerline.com Subject: re: AutoFlush stream Having a thread that flushes the stream periodically seems awkward and non-dete rministic. I think most applications want to flush the stream at discrete points, such as when a new line is encountered in the stream. A better interface to an 'AutoFlush' stream would be one that was created with a set of 'break' characters which flushed the stream whenever one was encountered. Another approach would be to attack the problem from the other side. Normally, you want to flush the output stream when a read is posted to the input stream. How 'bout an 'OutputFlushing' reader. This would be created with the writer that was to b e flushed on any inout call. Just some (very) random thoughts... Geoff Wyant wyant@centerline.com Centerline Software, Inc. (Formerly Saber Software, Inc) 10 Fawcett Street Cambridge, Ma. 01238 ======================================================================= 94 === Date: Fri, 24 Apr 1992 07:46:16 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: Re: stdout David M. Brumley writes: > But should 'Stdio.stdout' be buffered? According to the interface for > Stdout, "If the output streams are directed to terminals, they should > be unbuffered, so that explicit Wr.Flush calls are unnecessary for > interactive programs." The problem of whether or not to buffer terminal I/O is debatable. Sometimes buffered tty I/O is a definite advantage, sometimes it isn't. Most *NIX C implemenations leave stderr unbuffered, but not stdout. I guess it's a matter of getting used to it. Both the Stdio.i3 and SPwM3 (page 140) say stdout should be unbuffered. appearently the SRC-m3 implementation doesn't follow suit. However, I don't mind really, since buffering the terminal I/O can sometimes be advantageous, especially to reduce the overhead of one system call per character/string. This sounds silly, but for programs dthat print out a lot of information, it has a definite effect on the user when he/she is watching. Flusing stdout is useful habit anyway, since with sockets and pipes it's not always clear when you're in an interactive environment... Greetings, Bert -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null ======================================================================= 95 === Date: Fri, 24 Apr 1992 15:28:14 GMT From: treese@crl.dec.com (Win Treese) Subject: Re: stdout Since the C stdio library is line-buffered, one has to use an explicit flush for prompting without a newline. It would seem reasonable to do it for Stdio as well. Win Treese Cambridge Research Lab treese@crl.dec.com Digital Equipment Corp. IMPORT Disclaimer; ======================================================================= 96 === Date: Fri, 24 Apr 1992 15:37:27 GMT From: barton@chopin.seas.ucla.edu (Bob Barton System Administrator (403)492 5160) Subject: Modula 3 on an RS/6000 320 Keywords: Has anyone got Modula3 ver 2.04 running on an RS6000? I am working on an RS6000 320 using AIX 3.1.5. When trying to do the m3make build_boot I get an error message from awk indicating syntax errors in source lines 43 and 50 which I think are in the file /usr/local/lib/m3/mklist.awk. I don't know what this file is meant to do so I have not tried changing anything in it. In addition I will soon be moving to AIX 3.2 and wonder if there are any known problems that appear for Modula 3. NOTE: (Modula 3 is available by anonymous ftp from gatekeeper.dec.com) (for IBM Risc 6000 installations ensure that the BSD install is used not the AIX install) Bob Barton (barton@chopin.eche.ualberta.ca) ======================================================================= 97 === Date: Fri, 24 Apr 1992 13:42:31 PDT From: David Nichols Subject: Re: stdout Well, I looked at the code, and WrMove.FastPutString, which is what PutText and PutString call, now only flushes at the end instead of calling Wr.PutChar and flushing on each character. Thus, it would appear that we could make Stdio.stdout unbuffered without a big performance hit as long as clients were calling Wr.PutText or Wr.PutString most of the time. I wrote a test program and traced it, and it did indeed make only one write call for an unbuffered Wr.T. I also tried writing a new writer class that would automatically flush whenever it saw certain characters (like newlines). The problem is that it needs to be unbuffered so it sees everything that's written immediately, but then it can't tell the wr.flush calls that come from the normal writing code (e.g. in WrMove.FastPutChar) from the ones the client makes (from Wr.Flush). Perhaps the flush method could get an extra parameter or something. David ================ MODULE Main; IMPORT Wr, UFileWr; VAR buf, unBuf: Wr.T; BEGIN buf := UFileWr.New(fd := 1, buffered := TRUE); unBuf := UFileWr.New(fd := 1, buffered := FALSE); Wr.PutText( buf, "This is a longish line of buffered output. Wasn't it fast?\n"); Wr.Flush(buf); Wr.PutText(unBuf, "This is a longish line of unBuffered output." & " Can you see the chars?\n"); END Main. ======================================================================= 98 === Date: Fri, 24 Apr 1992 19:52:07 GMT From: schwartz@roke.cs.psu.edu (Scott Schwartz) Subject: Re: AutoFlush stream wyant@centerline.com writes: | Normally, you want to flush the output stream when a read is posted | to the input stream. How 'bout an 'OutputFlushing' reader. This | would be created with the writer that was to be flushed on any inout | call. The FIO library in V10 Unix has a ``tie'' function. You can tie two descriptors together so that whenever one of them does a read, the other is flushed. In this case you would tie stdout to stdin, so that when the program prompts pending output will be visible. That seems like a clever solution to me. ======================================================================= 99 === Date: 25 Apr 92 02:50:21 GMT From: bbc@cs.rice.edu (Benjamin Chase) Subject: Re: AutoFlush stream In article <9204241427.AA24484@riposte> wyant@centerline.com writes: >Another approach would be to attack the problem from the other side. >Normally, you want to flush the output stream when a read is posted to >the input stream. How 'bout an 'OutputFlushing' reader. This would be >created with the writer that was to be flushed on any inout call. That was my reaction to the problem, as well. It should yield an efficient implementation, yet still do what you want. Output streams should also be flushed on (checked) runtime errors. (You can try to flush them on the unchecked runtime errors, if you want. :-) In general, I guess you'd want to be able to indicate that a read on a specified stream caused a flush on another stream or streams (ie. not necessarily the stdin/stdout special case), but the stdin/stdout case is 99% of the problem. -- Ben Chase ======================================================================= 100 === Date: Fri, 24 Apr 1992 18:30:02 GMT From: nr@elan (Norman Ramsey) Subject: Re: stdout Many systems handle the problem of unbuffered writes to standard output by flushing the standard output buffer whenever there is a read from standard input. This is done only when the input is intermittent. I think it would be worth thinking about how to do this automatically in Modula-3. ======================================================================= 101 === Date: 24 Apr 92 18:53:28 From: vixie@pa.dec.com (Paul A Vixie) Subject: Re: AutoFlush stream I disagree. Flushing the output "periodically" would let you write large amounts of data and only pay the system-call overhead of "flush" when the internal buffer filled up or after you stop writing new data. This assumes that the "flush" "timer" will be reset whenever new data is added to the output buffer. This combined with a reader that flushed output to its corresponding writer, would give you completely smooth output in all but one case, with a minimum system call overhead in *all* cases. Seems like a winner. I don't like explicit flushes -- it's a detail I don't think an application ought to have to worry about. Sort of like error checking vs. exceptions. C's "line buffering" is a lose, since you still need explicit flushes for partial-line output, and further, you pay one system call per output line even if you're writing hundreds (or thousands) of output lines back-to-back. -- Paul Vixie, DEC Network Systems Lab Palo Alto, California, USA "Ready, Fire, Aim" decwrl!vixie vixie!paul alt.pink.bunny.boom.boom.boom moderator ======================================================================= 102 === Date: Sat, 25 Apr 1992 12:35:16 GMT From: dmb@usl.edu (David M. Brumley) Subject: Re: stdout laverman@cs.rug.nl (Bert Laverman) writes: >David M. Brumley writes: >> But should 'Stdio.stdout' be buffered? According to the interface for >> Stdout, "If the output streams are directed to terminals, they should >> be unbuffered, so that explicit Wr.Flush calls are unnecessary for >> interactive programs." >The problem of whether or not to buffer terminal I/O is debatable. Sometimes >buffered tty I/O is a definite advantage, sometimes it isn't. Most *NIX C >implemenations leave stderr unbuffered, but not stdout. I guess it's a matter >of getting used to it. I hope it's not a "matter of getting used to it." I suppose that depends on whether or not the people at DEC SRC are aware of the discussions in this group and whether they want to make Modula-3's standard libraries better than C's. > Both the Stdio.i3 and SPwM3 (page 140) say stdout should be unbuffered. >appearently the SRC-m3 implementation doesn't follow suit. However, I don't >mind really, since buffering the terminal I/O can sometimes be advantageous, >especially to reduce the overhead of one system call per character/string. >This sounds silly, but for programs dthat print out a lot of information, >it has a definite effect on the user when he/she is watching. >Flusing stdout is useful habit anyway, since with sockets and pipes it's >not always clear when you're in an interactive environment... I don't think the question is really "To buffer or not to buffer?" but "When to flush?" Why not let the programmer decide when the convenience of automatic flushing becomes too costly? In the current implementation, there is no difference between 'stdout' and 'bufferedStdout' since: stdout := UFileWr.New (fd := 1, buffered := TRUE); bufferedStdout := UFileWr.New (fd := 1, buffered := TRUE); in spite of the interface description. Besides, is "unbuffered" stdout going to be so costly when calls to Wr.PutText() and the rest end up calling WrMove.FastPutString() thus avoiding excessive write(2) calls? What I, and presumably Mr. Eckam, would like is a stdout that we wouldn't have to explicitly flush. Others can always decide to use another interface with more sophisticated buffering and flushing. Or maybe Stdio could determine whether stdout is a pipe or whatever and automatically use a more appropriate buffering scheme. ======================================================================= 103 === Date: Sat, 25 Apr 1992 16:00:22 GMT From: mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) Subject: initializing objects It seems to me that it is a weakness of Modula 3 that there is no easy way to ensure that opaque types are properly initialized. In some cases, default values for fields works, but only if the default values are constants. There are some rather klugey work-arounds, such as having a field that indicates whether the instance has been initialized, and then checking that field every time an unknown instance is encountered. It would be much nicer to make sure that instances have been initialized properly to begin with. It also seems to me that a simple solution is possible. Introduce a pragma that indicates that NEW is not allowed for a particular opaque type. Then the only way to allocate an object of that opaque type would be to invoke a module procedure that returns an instance, already initialized. -mike ======================================================================= 104 === Date: Fri, 24 Apr 1992 00:42:28 GMT From: johnh@wheaton.edu (John (Doc) Hayward) Subject: Re: stdout (and deadlock problem) > >Daniel James Eckam wrote: > >> This may be a stupid question, but I'll ask anyway. Why is all > >> interactive output saved until a program finishes execution ? > >Never fear; the question isn't stupid. FIrst: output is _buffered_, > >not saved. That makes a small difference. > > But should 'Stdio.stdout' be buffered? According to the interface for > Stdout, "If the output streams are directed to terminals, they should > be unbuffered, so that explicit Wr.Flush calls are unnecessary for > interactive programs." We had the same problem. Since my students writes interactive programs I modified Stdio.m3. >From Stdio.m3 in libm3/rw/src line 25 modified to: stdout := UFileWr.New (fd := 1, buffered := FALSE); (* was true now false *) This seems to work ok for terminals however it should really determine if the stdout is connected to a terminal before assigning buffered to FALSE. This may negativly impact performance for redirected stdout programs. The only other problem which this may have caused is that I get a deadlock when joining the only thread forked and the main program is waiting to finishing output from an unbuffered (autoflush). The deadlock seems to be related to the fact that there are no runnable threads at the time it is waiting to finish flushing the buffer. Code looks like: EVAL Thead.Join(...); Wr.PutText(Stdio.stdout,"bla bla \n"); (* deadlock occures while waiting for this output to be auto flushed *) Any hints on this one? (ps. we are running version 2.0) johnh... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = UUCP: johnh@wheaton.uucp telephone: (708) 752-5871 (office) Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187 Act justly, love mercy and walk humbly with your God. Micah 6:8b -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = UUCP: johnh@wheaton.uucp telephone: (708) 752-5871 (office) Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187 Act justly, love mercy and walk humbly with your God. Micah 6:8b ======================================================================= 105 === Date: Sat, 25 Apr 92 18:37:56 -0400 From: Norman Ramsey Subject: Rd.Error is gone Why has the Error exception been removed from the Rd interface? Norman ======================================================================= 106 === Date: Fri, 24 Apr 1992 16:10:17 GMT From: nr@cs.Princeton.EDU () Subject: Questions about installing SRC M3, v 2.0x I built SRC M3 on a DS3100 making as few changes as possible to the `model' distributed with that architecture. I notice that the default, which I used, compiles the compiler without optimization. How much of a hit am I taking compiling my own programs if the compiler isn't optimized? Can someone tell me how to control (independently) a) whether the compiler is compiled with optimization b) for any library, whether that library is compiled with optimization I'm perfectly happy to do this by using flags and switches on the m3make command line if that will do the job. A separate, unrelated question: I want to build M3 for the SPARC using the same source directories. What is the easiest way to do this? Shall I ftp boot.SPARC*.tar.Z? Or is there an easy way to cross-compile? -- Norman Ramsey nr@princeton.edu ======================================================================= 107 === Date: 27 Apr 92 14:04:12 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: AutoFlush stream >>>>> On 24 Apr 92 23:53:28 GMT, vixie@pa.dec.com (Paul A Vixie) said: Paul> C's "line buffering" is a lose, since you still need explicit flushes Paul> for partial-line output, and further, you pay one system call per output Paul> line even if you're writing hundreds (or thousands) of output lines Paul> back-to-back. Umm, wait a minute: one *library* call, e.g., to puts, does NOT equal one *system* call. The stdio package typically buffers until some considerable quantity of output is generated, and then does a system call; that is why one does fflush. Output to terminal devices may be handled differently. -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================= 108 === Date: Mon, 27 Apr 92 16:00:14 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: Questions about installing SRC M3, v 2.0x In article <1992Apr24.161017.9628@newross.Princeton.EDU>, nr@cs.Princeton.EDU ( ) writes: > Can someone tell me how to control > (independently) > a) whether the compiler is compiled with optimization The optimization of the bootstrap compiler and of the bootstrap driver can be set in the config file (BOOTOPT). If you want different options for the compiler and the driver, replaces the instances of BOOTOPT in one of {compiler,driver}/src/m3makefile. > b) for any library, whether that library is compiled with optimization Add a line like M3OPT = -O at the beginning of /src/m3makefile, and cross your fingers so that your make will take the latter of two definitions of a make symbol. > I'm perfectly happy to do this by using flags and switches on the > m3make command line if that will do the job. Unfortunately, there is no universal way of passing arguments through recursive makes, and we would have a hard time without recursive makes. > A separate, unrelated question: I want to build M3 for the SPARC using > the same source directories. What is the easiest way to do this? > Shall I ftp boot.SPARC*.tar.Z? Or is there an easy way to > cross-compile? The easiest it to get the boot.SPARC* archive and to unpack it in the same place as your current installation. All the derived files are built in directories that are architecture specific. m3make figures the architecture for which it should build. -- Eric. ======================================================================= 109 === Date: Mon, 27 Apr 92 15:39:40 PDT From: jdd@src.dec.com (John DeTreville) Subject: Re: Modula-3 Users Group Meeting... Executive summary: June is approaching, as is the Modula-3 Users' Group meeting. Although June 16 doesn't satisfy everyone, nor does holding the meeting in Palo Alto, these still seem the best choices. If there's not a sudden groundswell of complaints, the meeting will be at SRC in Palo Alto on June 16, the day before SIGPLAN in San Francisco. If you haven't already, please send us a message if you think you'd like to attend, so that we can keep a rough head count. You can now send your message to mug-meeting@src.dec.com and it will be directed to the right people. A couple of people have volunteered talks and we're beating the bushes to get others to volunteer. We'd like as many talks from outside SRC as possible: about Modula-3 itself, about what you've done with it, whatever. In addition to full-length talks, we'll have a session for 5-minute talks by anyone with something to say. If you can't give a full-length talk, perhaps you'd like to give a 5-minute talk. Think about it. If you think you might like to give a talk, please send a title and short abstract to mug-meeting@src.dec.com. If you'd like to propose a topic for group discussion, send it in too. I hope to be able to post a initial agenda sometime next week. Cheers, John DeTreville DEC SRC ======================================================================= 110 === Date: Mon, 27 Apr 92 19:44:30 PDT From: msm@.dec.com (Mark S. Manasse) Subject: Re: AutoFlush stream It shouldn't be very hard to create a new reader class which takes a reader and writer as input to its init method, and which flushes the writer whenever a new buffer is needed to satisfy requests to read. This module could even update stdin in its module initialization section, so that just by importing LinkedRdWr into your program you could get the desired behavior. You could check whether the input reader was intermittent, to decide whether to just return the reader passed in. If you suppose that it was, the methods seek and close need to be overridden so that seek: 1) flushes the linked writer. 2) reads as much as it can from the other linked reader, and copies it into its own buffer (using CharsReady and GetSub, for instance, unless it's supposed to block, in which case it can call GetChar to do the blocking). A more efficient implementation could share buff with the underlying reader, just setting the indices into it differently, if you were sure that no one would access the underlying reader directly. Close just needs to flush the writer, and close the linked reader. Mark ======================================================================= 111 === Date: Mon, 27 Apr 92 17:54:27 PDT From: muller@src.dec.com (Eric Muller) Subject: SRC Modula-3 2.06 available from gatekeeper.dec.com:pub/DEC/Modula-3/release. Numerous bug fixes and improvements in the compiler (coverage seems to be in better shape), the runtime (threads, gc, fingerprint - pickles seems to be in better shape), the pretty printer, the U* interfaces in particular for SUN3 and SPARC, showheap, the Modula-3 toolkit. New in this release: seekable text writers, Tcl 6.2 binding interface, modula-3 mode for gnuemacs (both template based and electric), tags for gnuemacs (really a repackaging of the Xerox PARC stuff). -- Eric. ======================================================================= 112 === Date: Tue, 28 Apr 92 15:03:39 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: Modula-3 AST toolkit 2.06 available In article <1992Apr28.132911.8977@src.dec.com>, mjordan@src.dec.com (Mick Jorda n) writes: > It is built in the same manner as other Modula-3 > distributions, e.g. "m3make build_m3tk install_m3tk" Make that "m3make -f m3makefile.m3tk all install". -- Eric. ======================================================================= 113 === Date: 27 Apr 92 18:35:58 GMT From: woolsey@mri.uucp (Jeff Woolsey) Subject: Re: Modula 3 on an RS/6000 320 In article <1992Apr24.153727.18229@kakwa.ucs.ualberta.ca> barton@chopin.seas.uc la.edu (Bob Barton System Administrator (403)492 5160) writes: >Keywords: > >Has anyone got Modula3 ver 2.04 running on an RS6000? >I am working on an RS6000 320 using AIX 3.1.5. > >When trying to do the m3make build_boot I get an error message from awk >indicating syntax errors in source lines 43 and 50 which I think are in the >file /usr/local/lib/m3/mklist.awk. I don't know what this file is meant to do >so I have not tried changing anything in it. > >In addition I will soon be moving to AIX 3.2 and wonder if there are any >known problems that appear for Modula 3. > >NOTE: (Modula 3 is available by anonymous ftp from gatekeeper.dec.com) > (for IBM Risc 6000 installations ensure that the BSD install is > used not the AIX install) > >Bob Barton (barton@chopin.eche.ualberta.ca) Thu Apr 16 13:42:09 CDT 1992 Problems installing boot.IBMR2-2.04.tar.Z 1. This awk, like some others, has different precedence for string concatenation and output redirection. mklist.awk requires () around "." name in two places. 1.5 There's an uncommented #----- line in the top-level m3makefile. 2. I performed the bsdcc installation. 3. /lib/cpp predefines absolutely no symbols! it also converts tabs to spaces in macro expansions. Thus, imake needs to be built with the kludge. But I could find no way to convince it (after adding || defined(aix) ) that it was actually on an aix system other than -Daix in m3make/IBMR2/makefile. 4. The compiler doesn't like volatile return types from functions. I added #define _IMPORT extern just before first offending statement in Thread_i.c, Rd_i.c, Wr_i.c, and others. Fortunately (?) /lib/cpp doesn't complain about multiple #defines. However, changing the _IMPORT define in all affected modules is too tedious [but necessary due to #5 below. I haven't finished doing this yet!]. Changing it more globally in a header then means that I need to eliminate _all_ of the volatiles, because of type conflicts. Of course, this means that multi-threaded code may exhibit peculiarities, but my application is single-threaded, and I'm just benchmarking on a borrowed machine anyway. 5. The resulting compiler looped for an hour trying to build the library. No joy. 6. m3make scratch_IBMR2 doesn't work, either. -- -- Jeff Woolsey 800 950 5554 woolsey@mri.COM Microtec Research, Inc. +1 408 980 1300 woolsey@netcom.COM Nothing like a three-address mailer.... woolsey@folderol.UUCP ======================================================================= 114 === Date: Tue, 28 Apr 92 13:29:11 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Modula-3 AST toolkit 2.06 available Version 2 of the Modula-3 AST toolkit, a development of the otherwise defunct Olivetti Modula-3 implemention, is now available via ftp from gatekeeper.dec.com. There are no substantial changes from version 1, other than the implementation of the "twelve changes" to the language definition. That is, the toolkit supports the language defined in "Systems Programming with Modula-3", and is compatible with the conventions of the SRC Modula-3 implementation. The documentation on the toolkit components has been improved, particularly that for the AST specification. The system is made available under the same licence terms as the SRC compiler. In addition the original Olivetti sources are covered by a separate, non-restrictive, copyright notice. The toolkit is designed to support the creation of Modula-3 program development tools and is structured around a compiler front-end which uses a public Abstract Syntax Tree (AST) to represent program source. A description of the (original) system can be found in: "An Extensible Programming Environment for Modula-3", Mick Jordan, Proceedings of the Fourth ACM SIGSOFT Symposium on Software Development Environments, Software Engineering Notes, 15, 6, Dec 1990. A number of tools are provided with the toolkit, vis: * (m3check) A tool that is a step towards an integrated, incremental program development environment for Modula-3. It includes a compiler front end, a tool to scan the file system for source file changes and recompile changed (and dependent) units, a pre-linker to analyse a program for completeness, and a primitive browser. I have reworked this tool quite a bit in repsonse to user feedback. On a DECstation 5000, if compiled with optimisation, it compiles at about 500 lines a second and, since it caches interfaces and is interactive, can provide a fast turnround syntax/semantic checker, before invoking "m3make". * (m3fe) (Just a) compiler front-end (syntax/semantic analysis), with optional checks for unused variables, uncaught exceptions, etc. The compiler can compile multiple sources in one invocation and compiles each interface once only. * (m3modgen) A tool to generate skeleton modules from interfaces. * (m3seegen) A tool to generate a textual form of a generic instantiation, with optional substitution of the generic formals by the actuals. The toolkit is designed to be extensible, by virtue of the AST and a collection of reusable compiler components. I expect to add more tools over time, and hope that others will be motivated to do so. ** N.B. You must install version 2.06 (or later) of SRC Modula-3 before ** attempting to build the toolkit. The toolkit is stored in the directory /pub/DEC/Modula-3/release in the file m3tk-2.06.tar.Z. It is built in the same manner as other Modula-3 distributions, e.g. "m3make build_m3tk install_m3tk", assuming that you have already installed SRC Modula-3 (2.06 or later). You will get plenty of warning messages, but these are all harmless. Thanks to Geoff Wyant and David Goldberg for being beta-testers. Mick Jordan, Apr 24 1992. ======================================================================= 115 === Date: Tue, 28 Apr 92 15:21:42 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Re: Modula-3 AST toolkit 2.06 available In article <1992Apr28.150339.11060@src.dec.com>, muller@src.dec.com (Eric Mulle r) writes: > Make that "m3make -f m3makefile.m3tk all install". > Right. A big thanks to Eric for doing all the hard work to actually construct t he distribution. Mick Jordan ======================================================================= 116 === Date: Tue, 28 Apr 92 21:19:37 PDT From: muller@src.dec.com (Eric Muller) Subject: performance This message reports some experiments I just made, to assess the performance problems of Modula-3. In all cases, I am running on a DECstation 5000/200, 64Mb of memory, Ultrix 4.2, SRC Modula-3 2.06. The machine was lightly loaded in all cases. cc is the C compiler what comes with the DECstation, gcc is gcc 2.1. I concentrated mostly on the size of the programs (but also looked at the compilation time). I took two test programs: Hello world (hello), and the same program with 1000 calls to Wr.PutText instead of one (hello2). Times are in seconds, sizes in kilobytes. I used various combinations of driver/compilers/libm3: A bootstrap driver compiled with cc -g bootstrap compiler compiled with cc -g cc -g libm3 compiled with cc -g B bootstrap driver compiled with gcc -O2 bootstrap compiler compiled with gcc -O2 gcc -g libm3 compiled with cc -g C bootstrap driver compiled with gcc -O2 bootstrap compiler compiled with gcc -O2 gcc -g libm3 compiled with gcc -O2 D bootstrap driver compiled with gcc -O2 bootstrap compiler compiled with gcc -O2 gcc -O2 libm3 compiled with gcc -O2 I could not try cc -O2; the m3compiler obtained with cc -O2 does not run properly. I am not sure about the problem yet (it's delicate to debug optimized code). Here are the quantities I measured: a.out data segment --------------------------------------------------- a.out text segment ---------------------------------------------- | Hello{,2}.mo data segment ------------------------------ | | Hello{,2}.mo text segment ------------------------- | | | stripped a.out size ---------------------- | | | | a.out size -------------------------- | | | | | user time, in seconds ------ | | | | | | | | | | | | | A hello 4.3 853 332 0 0 228 104 hello2 11.0 875 352 20 0 250 104 B hello 2.8 880 340 0 0 232 108 hello2 13.2 920 368 27 0 260 108 C hello 2.9 408 260 0 0 152 108 hello2 13.2 448 288 27 0 180 108 D hello 2.7 402 260 0 0 152 108 hello2 521.8 419 276 16 0 168 108 "a.out text/data segment" are the results of "size" on the executable. "Hello{,2}.mo text/data segment" are the result of "size" on the object produced by the compilation of Hello{,2}.m3. "a.out size" is the size of the executable file; "stripped a.out" is the size of the executable file after it has been stripped. "user time" is the user time reported by the csh time on the full compilation/link of Hello{,2}.m3. I considered elapsed time too volatile to be meaningful (I wanted to take only one measurement for each program). So let's try to see how we get a 920 k executable (B, hello2). I got these number by comparisons of the different cases; these number are very approximate. - 143 of symbol information 15% | - 18 of debugging information for Hello2 2% | 60% - 391 of debugging information for libm3 42% | - 27 of text for Hello2 3% - 233 of text for libm3 25% - 108 of data for libm3 12% Oviously, debugging cost a lot in the a.out size. The situation could be better if there was no debugging information for the C variables that do not correspond to Modula-3 variables (temporaries generated by the compiler), but I don't know by how much. The program itself looks reasonnable. We made no attempts to have a "shrinking" runtime; you get the full allocator/collector, full thread implementation, full fingerprint implementation (for pickles), runtime type information, as well as other pieces, even if your program doesn't need that. So far, the programs we have been building here at SRC typically use most of the runtime, and there was little value in making pieces optional (for example, replacing the real thread procedures by empty ones if there is no call to Thread.Fork). Given that, the runtime does not look too bad. Of course, if we start to have many programs that don't use the full runtime, it may be worth investigating that area. Clearly shared libraries can be a big win. The text segment and a good part of the data segment (constant tables for fingerprints) can be shared. In earlier experiments with OSF/1 shared libraries, I have measured the text segment for Hello world going from 295k to 12k and the data segment going from 100k to 4k. For solitaire (which uses trestle), the differences are even more important: 1452k to 128k and 408k to 48k. On the time side, this is the elapsed time for the various phases of C/Hello (these values seem typical): seconds #times operation 1.36 2 inhaling library link info 1.54 1 compiling Modula-3 -> C 0.11 1 merging new link info 4.98 2 compiling C -> object 0.05 1 checking global consistency 0.11 1 generating _m3main.c 2.96 1 linking 0.04 3 removing temporary files 0.02 1 renaming files 0.08 other --------------------------------------------------- 11.26 TOTAL Shared libraries can be a big win on that front too. In my earlier experiments, the link time went from 13s to 1s for Hello world, and from 77s to 7s for solitaire. I am looking right now into supporting the shared libraries for SunOS. -- Eric. ======================================================================= 117 === Date: Tue, 28 Apr 92 21:33:43 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: performance In article <1992Apr28.211937.17186@src.dec.com>, I write: > hello2 521.8 419 276 16 0 168 108 This 521 seconds is not a typo. I reproduced it a few times. This sounds like a bug in gcc, I will investigate. -- Eric. ======================================================================= 118 === Date: 28 Apr 92 18:59:58 GMT From: mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) Subject: Re: initializing objects In article <1992Apr28.153157.17037@newross.Princeton.EDU> nr@algorithms (Norman Ramsey) writes: > If you declare > TYPE T <: REFANY; > then NEW(T) is illegal... Yes, but what about objects? I want to put an object type (perhaps partially opaque) in an interface and make sure that clients initialize the object properly. Is there a way to do this without making the type completely opaque? -mike ======================================================================= 119 === Date: Tue, 28 Apr 92 13:29:11 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Modula-3 AST toolkit 2.06 available Version 2 of the Modula-3 AST toolkit, a development of the otherwise defunct Olivetti Modula-3 implemention, is now available via ftp from gatekeeper.dec.com. There are no substantial changes from version 1, other than the implementation of the "twelve changes" to the language definition. That is, the toolkit supports the language defined in "Systems Programming with Modula-3", and is compatible with the conventions of the SRC Modula-3 implementation. The documentation on the toolkit components has been improved, particularly that for the AST specification. The system is made available under the same licence terms as the SRC compiler. In addition the original Olivetti sources are covered by a separate, non-restrictive, copyright notice. The toolkit is designed to support the creation of Modula-3 program development tools and is structured around a compiler front-end which uses a public Abstract Syntax Tree (AST) to represent program source. A description of the (original) system can be found in: "An Extensible Programming Environment for Modula-3", Mick Jordan, Proceedings of the Fourth ACM SIGSOFT Symposium on Software Development Environments, Software Engineering Notes, 15, 6, Dec 1990. A number of tools are provided with the toolkit, vis: * (m3check) A tool that is a step towards an integrated, incremental program development environment for Modula-3. It includes a compiler front end, a tool to scan the file system for source file changes and recompile changed (and dependent) units, a pre-linker to analyse a program for completeness, and a primitive browser. I have reworked this tool quite a bit in repsonse to user feedback. On a DECstation 5000, if compiled with optimisation, it compiles at about 500 lines a second and, since it caches interfaces and is interactive, can provide a fast turnround syntax/semantic checker, before invoking "m3make". * (m3fe) (Just a) compiler front-end (syntax/semantic analysis), with optional checks for unused variables, uncaught exceptions, etc. The compiler can compile multiple sources in one invocation and compiles each interface once only. * (m3modgen) A tool to generate skeleton modules from interfaces. * (m3seegen) A tool to generate a textual form of a generic instantiation, with optional substitution of the generic formals by the actuals. The toolkit is designed to be extensible, by virtue of the AST and a collection of reusable compiler components. I expect to add more tools over time, and hope that others will be motivated to do so. ** N.B. You must install version 2.06 (or later) of SRC Modula-3 before ** attempting to build the toolkit. The toolkit is stored in the directory /pub/DEC/Modula-3/release in the file m3tk-2.06.tar.Z. It is built in the same manner as other Modula-3 distributions, e.g. "m3make build_m3tk install_m3tk", assuming that you have already installed SRC Modula-3 (2.06 or later). You will get plenty of warning messages, but these are all harmless. Thanks to Geoff Wyant and David Goldberg for being beta-testers. Mick Jordan, Apr 24 1992. ======================================================================= 120 === Date: Tue, 28 Apr 92 21:33:43 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: performance In article <1992Apr28.211937.17186@src.dec.com>, I write: > hello2 521.8 419 276 16 0 168 108 This 521 seconds is not a typo. I reproduced it a few times. This sounds like a bug in gcc, I will investigate. -- Eric. ======================================================================= 121 === Date: Mon, 27 Apr 92 17:54:27 PDT From: muller@src.dec.com (Eric Muller) Subject: SRC Modula-3 2.06 available from gatekeeper.dec.com:pub/DEC/Modula-3/release. Numerous bug fixes and improvements in the compiler (coverage seems to be in better shape), the runtime (threads, gc, fingerprint - pickles seems to be in better shape), the pretty printer, the U* interfaces in particular for SUN3 and SPARC, showheap, the Modula-3 toolkit. New in this release: seekable text writers, Tcl 6.2 binding interface, modula-3 mode for gnuemacs (both template based and electric), tags for gnuemacs (really a repackaging of the Xerox PARC stuff). -- Eric. ======================================================================= 122 === Date: 27 Apr 92 14:04:12 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: AutoFlush stream >>>>> On 24 Apr 92 23:53:28 GMT, vixie@pa.dec.com (Paul A Vixie) said: Paul> C's "line buffering" is a lose, since you still need explicit flushes Paul> for partial-line output, and further, you pay one system call per output Paul> line even if you're writing hundreds (or thousands) of output lines Paul> back-to-back. Umm, wait a minute: one *library* call, e.g., to puts, does NOT equal one *system* call. The stdio package typically buffers until some considerable quantity of output is generated, and then does a system call; that is why one does fflush. Output to terminal devices may be handled differently. -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================= 123 === Date: 27 Apr 92 18:35:58 GMT From: woolsey@mri.uucp (Jeff Woolsey) Subject: Re: Modula 3 on an RS/6000 320 In article <1992Apr24.153727.18229@kakwa.ucs.ualberta.ca> barton@chopin.seas.uc la.edu (Bob Barton System Administrator (403)492 5160) writes: >Keywords: > >Has anyone got Modula3 ver 2.04 running on an RS6000? >I am working on an RS6000 320 using AIX 3.1.5. > >When trying to do the m3make build_boot I get an error message from awk >indicating syntax errors in source lines 43 and 50 which I think are in the >file /usr/local/lib/m3/mklist.awk. I don't know what this file is meant to do >so I have not tried changing anything in it. > >In addition I will soon be moving to AIX 3.2 and wonder if there are any >known problems that appear for Modula 3. > >NOTE: (Modula 3 is available by anonymous ftp from gatekeeper.dec.com) > (for IBM Risc 6000 installations ensure that the BSD install is > used not the AIX install) > >Bob Barton (barton@chopin.eche.ualberta.ca) Thu Apr 16 13:42:09 CDT 1992 Problems installing boot.IBMR2-2.04.tar.Z 1. This awk, like some others, has different precedence for string concatenation and output redirection. mklist.awk requires () around "." name in two places. 1.5 There's an uncommented #----- line in the top-level m3makefile. 2. I performed the bsdcc installation. 3. /lib/cpp predefines absolutely no symbols! it also converts tabs to spaces in macro expansions. Thus, imake needs to be built with the kludge. But I could find no way to convince it (after adding || defined(aix) ) that it was actually on an aix system other than -Daix in m3make/IBMR2/makefile. 4. The compiler doesn't like volatile return types from functions. I added #define _IMPORT extern just before first offending statement in Thread_i.c, Rd_i.c, Wr_i.c, and others. Fortunately (?) /lib/cpp doesn't complain about multiple #defines. However, changing the _IMPORT define in all affected modules is too tedious [but necessary due to #5 below. I haven't finished doing this yet!]. Changing it more globally in a header then means that I need to eliminate _all_ of the volatiles, because of type conflicts. Of course, this means that multi-threaded code may exhibit peculiarities, but my application is single-threaded, and I'm just benchmarking on a borrowed machine anyway. 5. The resulting compiler looped for an hour trying to build the library. No joy. 6. m3make scratch_IBMR2 doesn't work, either. -- -- Jeff Woolsey 800 950 5554 woolsey@mri.COM Microtec Research, Inc. +1 408 980 1300 woolsey@netcom.COM Nothing like a three-address mailer.... woolsey@folderol.UUCP ======================================================================= 124 === Date: Tue, 28 Apr 92 15:21:42 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Re: Modula-3 AST toolkit 2.06 available In article <1992Apr28.150339.11060@src.dec.com>, muller@src.dec.com (Eric Mulle r) writes: > Make that "m3make -f m3makefile.m3tk all install". > Right. A big thanks to Eric for doing all the hard work to actually construct t he distribution. Mick Jordan ======================================================================= 125 === Date: Mon, 27 Apr 92 15:39:40 PDT From: jdd@src.dec.com (John DeTreville) Subject: Re: Modula-3 Users Group Meeting... Executive summary: June is approaching, as is the Modula-3 Users' Group meeting. Although June 16 doesn't satisfy everyone, nor does holding the meeting in Palo Alto, these still seem the best choices. If there's not a sudden groundswell of complaints, the meeting will be at SRC in Palo Alto on June 16, the day before SIGPLAN in San Francisco. If you haven't already, please send us a message if you think you'd like to attend, so that we can keep a rough head count. You can now send your message to mug-meeting@src.dec.com and it will be directed to the right people. A couple of people have volunteered talks and we're beating the bushes to get others to volunteer. We'd like as many talks from outside SRC as possible: about Modula-3 itself, about what you've done with it, whatever. In addition to full-length talks, we'll have a session for 5-minute talks by anyone with something to say. If you can't give a full-length talk, perhaps you'd like to give a 5-minute talk. Think about it. If you think you might like to give a talk, please send a title and short abstract to mug-meeting@src.dec.com. If you'd like to propose a topic for group discussion, send it in too. I hope to be able to post a initial agenda sometime next week. Cheers, John DeTreville DEC SRC ======================================================================= 126 === Date: Mon, 27 Apr 92 16:00:14 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: Questions about installing SRC M3, v 2.0x In article <1992Apr24.161017.9628@newross.Princeton.EDU>, nr@cs.Princeton.EDU ( ) writes: > Can someone tell me how to control > (independently) > a) whether the compiler is compiled with optimization The optimization of the bootstrap compiler and of the bootstrap driver can be set in the config file (BOOTOPT). If you want different options for the compiler and the driver, replaces the instances of BOOTOPT in one of {compiler,driver}/src/m3makefile. > b) for any library, whether that library is compiled with optimization Add a line like M3OPT = -O at the beginning of /src/m3makefile, and cross your fingers so that your make will take the latter of two definitions of a make symbol. > I'm perfectly happy to do this by using flags and switches on the > m3make command line if that will do the job. Unfortunately, there is no universal way of passing arguments through recursive makes, and we would have a hard time without recursive makes. > A separate, unrelated question: I want to build M3 for the SPARC using > the same source directories. What is the easiest way to do this? > Shall I ftp boot.SPARC*.tar.Z? Or is there an easy way to > cross-compile? The easiest it to get the boot.SPARC* archive and to unpack it in the same place as your current installation. All the derived files are built in directories that are architecture specific. m3make figures the architecture for which it should build. -- Eric. ======================================================================= 127 === Date: Tue, 28 Apr 92 21:19:37 PDT From: muller@src.dec.com (Eric Muller) Subject: performance This message reports some experiments I just made, to assess the performance problems of Modula-3. In all cases, I am running on a DECstation 5000/200, 64Mb of memory, Ultrix 4.2, SRC Modula-3 2.06. The machine was lightly loaded in all cases. cc is the C compiler what comes with the DECstation, gcc is gcc 2.1. I concentrated mostly on the size of the programs (but also looked at the compilation time). I took two test programs: Hello world (hello), and the same program with 1000 calls to Wr.PutText instead of one (hello2). Times are in seconds, sizes in kilobytes. I used various combinations of driver/compilers/libm3: A bootstrap driver compiled with cc -g bootstrap compiler compiled with cc -g cc -g libm3 compiled with cc -g B bootstrap driver compiled with gcc -O2 bootstrap compiler compiled with gcc -O2 gcc -g libm3 compiled with cc -g C bootstrap driver compiled with gcc -O2 bootstrap compiler compiled with gcc -O2 gcc -g libm3 compiled with gcc -O2 D bootstrap driver compiled with gcc -O2 bootstrap compiler compiled with gcc -O2 gcc -O2 libm3 compiled with gcc -O2 I could not try cc -O2; the m3compiler obtained with cc -O2 does not run properly. I am not sure about the problem yet (it's delicate to debug optimized code). Here are the quantities I measured: a.out data segment --------------------------------------------------- a.out text segment ---------------------------------------------- | Hello{,2}.mo data segment ------------------------------ | | Hello{,2}.mo text segment ------------------------- | | | stripped a.out size ---------------------- | | | | a.out size -------------------------- | | | | | user time, in seconds ------ | | | | | | | | | | | | | A hello 4.3 853 332 0 0 228 104 hello2 11.0 875 352 20 0 250 104 B hello 2.8 880 340 0 0 232 108 hello2 13.2 920 368 27 0 260 108 C hello 2.9 408 260 0 0 152 108 hello2 13.2 448 288 27 0 180 108 D hello 2.7 402 260 0 0 152 108 hello2 521.8 419 276 16 0 168 108 "a.out text/data segment" are the results of "size" on the executable. "Hello{,2}.mo text/data segment" are the result of "size" on the object produced by the compilation of Hello{,2}.m3. "a.out size" is the size of the executable file; "stripped a.out" is the size of the executable file after it has been stripped. "user time" is the user time reported by the csh time on the full compilation/link of Hello{,2}.m3. I considered elapsed time too volatile to be meaningful (I wanted to take only one measurement for each program). So let's try to see how we get a 920 k executable (B, hello2). I got these number by comparisons of the different cases; these number are very approximate. - 143 of symbol information 15% | - 18 of debugging information for Hello2 2% | 60% - 391 of debugging information for libm3 42% | - 27 of text for Hello2 3% - 233 of text for libm3 25% - 108 of data for libm3 12% Oviously, debugging cost a lot in the a.out size. The situation could be better if there was no debugging information for the C variables that do not correspond to Modula-3 variables (temporaries generated by the compiler), but I don't know by how much. The program itself looks reasonnable. We made no attempts to have a "shrinking" runtime; you get the full allocator/collector, full thread implementation, full fingerprint implementation (for pickles), runtime type information, as well as other pieces, even if your program doesn't need that. So far, the programs we have been building here at SRC typically use most of the runtime, and there was little value in making pieces optional (for example, replacing the real thread procedures by empty ones if there is no call to Thread.Fork). Given that, the runtime does not look too bad. Of course, if we start to have many programs that don't use the full runtime, it may be worth investigating that area. Clearly shared libraries can be a big win. The text segment and a good part of the data segment (constant tables for fingerprints) can be shared. In earlier experiments with OSF/1 shared libraries, I have measured the text segment for Hello world going from 295k to 12k and the data segment going from 100k to 4k. For solitaire (which uses trestle), the differences are even more important: 1452k to 128k and 408k to 48k. On the time side, this is the elapsed time for the various phases of C/Hello (these values seem typical): seconds #times operation 1.36 2 inhaling library link info 1.54 1 compiling Modula-3 -> C 0.11 1 merging new link info 4.98 2 compiling C -> object 0.05 1 checking global consistency 0.11 1 generating _m3main.c 2.96 1 linking 0.04 3 removing temporary files 0.02 1 renaming files 0.08 other --------------------------------------------------- 11.26 TOTAL Shared libraries can be a big win on that front too. In my earlier experiments, the link time went from 13s to 1s for Hello world, and from 77s to 7s for solitaire. I am looking right now into supporting the shared libraries for SunOS. -- Eric. ======================================================================= 128 === Date: Tue, 28 Apr 92 15:03:39 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: Modula-3 AST toolkit 2.06 available In article <1992Apr28.132911.8977@src.dec.com>, mjordan@src.dec.com (Mick Jorda n) writes: > It is built in the same manner as other Modula-3 > distributions, e.g. "m3make build_m3tk install_m3tk" Make that "m3make -f m3makefile.m3tk all install". -- Eric. ======================================================================= 129 === Date: 28 Apr 92 15:31:57 GMT From: nr@algorithms (Norman Ramsey) Subject: Re: initializing objects In article mhcoffin@tolstoy.uwate rloo.ca (Michael Coffin) writes: >It seems to me that it is a weakness of Modula 3 that there is no easy >way to ensure that opaque types are properly initialized... >Introduce a >pragma that indicates that NEW is not allowed for a particular opaque >type. If you declare TYPE T <: REFANY; then NEW(T) is illegal... ======================================================================= 130 === Date: Mon, 27 Apr 92 19:44:30 PDT From: msm@.dec.com (Mark S. Manasse) Subject: Re: AutoFlush stream It shouldn't be very hard to create a new reader class which takes a reader and writer as input to its init method, and which flushes the writer whenever a new buffer is needed to satisfy requests to read. This module could even update stdin in its module initialization section, so that just by importing LinkedRdWr into your program you could get the desired behavior. You could check whether the input reader was intermittent, to decide whether to just return the reader passed in. If you suppose that it was, the methods seek and close need to be overridden so that seek: 1) flushes the linked writer. 2) reads as much as it can from the other linked reader, and copies it into its own buffer (using CharsReady and GetSub, for instance, unless it's supposed to block, in which case it can call GetChar to do the blocking). A more efficient implementation could share buff with the underlying reader, just setting the indices into it differently, if you were sure that no one would access the underlying reader directly. Close just needs to flush the writer, and close the linked reader. Mark ======================================================================= 131 === Date: 28 Apr 92 15:31:57 GMT From: nr@algorithms (Norman Ramsey) Subject: Re: initializing objects In article mhcoffin@tolstoy.uwate rloo.ca (Michael Coffin) writes: >It seems to me that it is a weakness of Modula 3 that there is no easy >way to ensure that opaque types are properly initialized... >Introduce a >pragma that indicates that NEW is not allowed for a particular opaque >type. If you declare TYPE T <: REFANY; then NEW(T) is illegal... ======================================================================= 132 === Date: Wed, 29 Apr 92 12:09:43 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Re: performance In article <1992Apr28.211937.17186@src.dec.com>, muller@src.dec.com (Eric Mulle r) writes: > ... Of course, if we start to have many programs that don't use the > full runtime, it may be worth investigating that area. > I am investigating that area as part of the global optimiser, in which unused p rocedures and static data are removed. (Before you ask, yes it does handle procedures bou nd to methods). Currently I am operating in a source->source mode which causes som e problems in handling the guts of the runtime, so right now I cant give measurem ents that correspond directly to Eric's for "Hello". However, I can report the size of the resulting source that results from optimising "Hello". The "Hello" program simply coalesced into a single module is 1175 lines long an d contains 75 procedure bodies. The "Hello" program with unused procedures removed is 460 lines long and contains 24 procedure bodies. I have also applied the optimiser to some Trestle applications, e.g "BadBricks" , which is 30,000 lines containing 1268 procedures, and reduces to 22,800 lines and 848 procedures. The optimiser is based around the AST toolkit, and I expect to release a version later this year, once I have implemented a basic inline procedure expansion capability. Mick Jordan ======================================================================= 133 === Date: Wed, 29 Apr 92 15:20:40 PDT From: jdd@src.dec.com (John DeTreville) Subject: Re: Modula-3 Users Group Meeting... Well, the mug-meeting@src.dec.com mail alias isn't working at all! Apologies to everyone who's had their mail bounce. For right now, please RSVP to me personally, jdd@src.dec.com. Also, I forgot to mention that in addition to inviting talks, we invite any demos you might like to give. Our meeting room has a wall-sized video screen, so Trestle-based demos would look especially stunning. If you'd like to give a demo, please contact me as soon as possible. It will probably entail bringing up your system at SRC prior to the meeting. Cheers, John ======================================================================= 134 === Date: Wed, 29 Apr 92 12:09:43 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Re: performance In article <1992Apr28.211937.17186@src.dec.com>, muller@src.dec.com (Eric Mulle r) writes: > ... Of course, if we start to have many programs that don't use the > full runtime, it may be worth investigating that area. > I am investigating that area as part of the global optimiser, in which unused p rocedures and static data are removed. (Before you ask, yes it does handle procedures bou nd to methods). Currently I am operating in a source->source mode which causes som e problems in handling the guts of the runtime, so right now I cant give measurem ents that correspond directly to Eric's for "Hello". However, I can report the size of the resulting source that results from optimising "Hello". The "Hello" program simply coalesced into a single module is 1175 lines long an d contains 75 procedure bodies. The "Hello" program with unused procedures removed is 460 lines long and contains 24 procedure bodies. I have also applied the optimiser to some Trestle applications, e.g "BadBricks" , which is 30,000 lines containing 1268 procedures, and reduces to 22,800 lines and 848 procedures. The optimiser is based around the AST toolkit, and I expect to release a version later this year, once I have implemented a basic inline procedure expansion capability. Mick Jordan ======================================================================= 135 === Date: 28 Apr 92 18:59:58 GMT From: mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) Subject: Re: initializing objects In article <1992Apr28.153157.17037@newross.Princeton.EDU> nr@algorithms (Norman Ramsey) writes: > If you declare > TYPE T <: REFANY; > then NEW(T) is illegal... Yes, but what about objects? I want to put an object type (perhaps partially opaque) in an interface and make sure that clients initialize the object properly. Is there a way to do this without making the type completely opaque? -mike ======================================================================= 136 === Date: Thu, 30 Apr 92 01:35:29 GMT From: vixie@pa.dec.com (Paul Vixie) Subject: Re: AutoFlush stream Paul> C's "line buffering" is a lose, since you still need explicit flushes Paul> for partial-line output, and further, you pay one system call per output Paul> line even if you're writing hundreds (or thousands) of output lines Paul> back-to-back. [Eliot Moss] >> Umm, wait a minute: one *library* call, e.g., to puts, does NOT equal one >> *system* call. The stdio package typically buffers until some considerable >> quantity of output is generated, and then does a system call; that is why >> one does fflush. Output to terminal devices may be handled differently. If you want "line buffering", you get a system call every time there is a newline in the output stream. That's what "line buffering" means. And it is a compromise design, suitable only for simple languages like C where you just can't do any better without adding (more and more) warts to the runtime. -- Paul Vixie, DEC Network Systems Lab Palo Alto, California, USA "Ready, Fire, Aim" decwrl!vixie vixie!paul alt.pink.bunny.boom.boom.boom moderator ======================================================================= 137 === Date: 29 Apr 92 18:23:39 From: vixie@pa.dec.com (Paul A Vixie) Subject: Re: AutoFlush stream Paul> C's "line buffering" is a lose, since you still need explicit flushes Paul> for partial-line output, and further, you pay one system call per output Paul> line even if you're writing hundreds (or thousands) of output lines Paul> back-to-back. [Eliot Moss] >> Umm, wait a minute: one *library* call, e.g., to puts, does NOT equal one >> *system* call. The stdio package typically buffers until some considerable >> quantity of output is generated, and then does a system call; that is why >> one does fflush. Output to terminal devices may be handled differently. If you want "line buffering", you get a system call every time there is a newline in the output stream. That's what "line buffering" means. And it is a compromise design, suitable only for simple languages like C where you just can't do any better without adding (more and more) warts to the runtime. -- Paul Vixie, DEC Network Systems Lab Palo Alto, California, USA "Ready, Fire, Aim" decwrl!vixie vixie!paul alt.pink.bunny.boom.boom.boom moderator ======================================================================= 138 === Date: Thu, 30 Apr 92 01:35:29 GMT From: vixie@pa.dec.com (Paul Vixie) Subject: Re: AutoFlush stream Paul> C's "line buffering" is a lose, since you still need explicit flushes Paul> for partial-line output, and further, you pay one system call per output Paul> line even if you're writing hundreds (or thousands) of output lines Paul> back-to-back. [Eliot Moss] >> Umm, wait a minute: one *library* call, e.g., to puts, does NOT equal one >> *system* call. The stdio package typically buffers until some considerable >> quantity of output is generated, and then does a system call; that is why >> one does fflush. Output to terminal devices may be handled differently. If you want "line buffering", you get a system call every time there is a newline in the output stream. That's what "line buffering" means. And it is a compromise design, suitable only for simple languages like C where you just can't do any better without adding (more and more) warts to the runtime. -- Paul Vixie, DEC Network Systems Lab Palo Alto, California, USA "Ready, Fire, Aim" decwrl!vixie vixie!paul alt.pink.bunny.boom.boom.boom moderator ======================================================================= 139 === Date: 29 Apr 92 09:35:13 GMT From: ljp@sm.luth.se (Johan Persson) Subject: Embedded formatting in comments Hi, Sorry if this is a FAQ; I'm new to M3 and just beginning my tour through the libraries. I've seen some comment's which looks like LaTeX. Is there some way to print the interfaces and use the embedded formatting (some script or something)? Thanks, Johan ---------------------------------------------------------------------- That Is The Question: Co-existence or no existence. Piet Hein ---------------------------------------------------------------------- Johan Persson E-mail: Voice: Dept. of Computer Science ljp@sm.luth.se +46 (0)920 912 00 University of Lule{\aa} Fax: S-951 87 Lule{\aa},Sweden +46 (0)920 988 94 ----------------------------------------------------------------------- ======================================================================= 140 === Date: Wed, 29 Apr 92 20:39:06 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: Questions about installing SRC M3, v 2.0x In article , vixie@pa.dec.com (Paul A Vixie) writes: > Has anyone tried M3 with GCC? Yes, m3 2.06 works with gcc 2.1 -O2 on a DECstation. Sometime the compile time seems weird (see my message about performance). -- Eric. ======================================================================= 141 === Date: 29 Apr 92 16:20:37 From: vixie@pa.dec.com (Paul A Vixie) Subject: Re: Questions about installing SRC M3, v 2.0x When I caused M3 2.04's bootstrap compiler to build the real compiler with optimization on an Ultrix/RISC 4.2 system, the resulting compiler failed to work (died with assert errors). My theory right now is that the C code generated by M3 is too baroque for the Ultrix/RISC CC in 4.2. For my next trick, I'm going to try M3 2.06 with GCC 2.1, which has a slightly more reliable optimizer than the Ultrix/RISC CC -- and GCC lets you use "-g -O" so you can have optimization and still have debugging symbols that mostly point to the right places. Has anyone tried M3 with GCC? -- Paul Vixie, DEC Network Systems Lab Palo Alto, California, USA "Ready, Fire, Aim" decwrl!vixie vixie!paul alt.pink.bunny.boom.boom.boom moderator ======================================================================= 142 === Date: 29 Apr 92 09:35:13 GMT From: ljp@sm.luth.se (Johan Persson) Subject: Embedded formatting in comments Hi, Sorry if this is a FAQ; I'm new to M3 and just beginning my tour through the libraries. I've seen some comment's which looks like LaTeX. Is there some way to print the interfaces and use the embedded formatting (some script or something)? Thanks, Johan ---------------------------------------------------------------------- That Is The Question: Co-existence or no existence. Piet Hein ---------------------------------------------------------------------- Johan Persson E-mail: Voice: Dept. of Computer Science ljp@sm.luth.se +46 (0)920 912 00 University of Lule{\aa} Fax: S-951 87 Lule{\aa},Sweden +46 (0)920 988 94 ----------------------------------------------------------------------- ======================================================================= 143 === Date: 29 Apr 92 16:20:37 From: vixie@pa.dec.com (Paul A Vixie) Subject: Re: Questions about installing SRC M3, v 2.0x When I caused M3 2.04's bootstrap compiler to build the real compiler with optimization on an Ultrix/RISC 4.2 system, the resulting compiler failed to work (died with assert errors). My theory right now is that the C code generated by M3 is too baroque for the Ultrix/RISC CC in 4.2. For my next trick, I'm going to try M3 2.06 with GCC 2.1, which has a slightly more reliable optimizer than the Ultrix/RISC CC -- and GCC lets you use "-g -O" so you can have optimization and still have debugging symbols that mostly point to the right places. Has anyone tried M3 with GCC? -- Paul Vixie, DEC Network Systems Lab Palo Alto, California, USA "Ready, Fire, Aim" decwrl!vixie vixie!paul alt.pink.bunny.boom.boom.boom moderator ======================================================================= 144 === Date: 29 Apr 92 18:23:39 From: vixie@pa.dec.com (Paul A Vixie) Subject: Re: AutoFlush stream Paul> C's "line buffering" is a lose, since you still need explicit flushes Paul> for partial-line output, and further, you pay one system call per output Paul> line even if you're writing hundreds (or thousands) of output lines Paul> back-to-back. [Eliot Moss] >> Umm, wait a minute: one *library* call, e.g., to puts, does NOT equal one >> *system* call. The stdio package typically buffers until some considerable >> quantity of output is generated, and then does a system call; that is why >> one does fflush. Output to terminal devices may be handled differently. If you want "line buffering", you get a system call every time there is a newline in the output stream. That's what "line buffering" means. And it is a compromise design, suitable only for simple languages like C where you just can't do any better without adding (more and more) warts to the runtime. -- Paul Vixie, DEC Network Systems Lab Palo Alto, California, USA "Ready, Fire, Aim" decwrl!vixie vixie!paul alt.pink.bunny.boom.boom.boom moderator ======================================================================= 145 === Date: Wed, 29 Apr 92 20:39:06 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: Questions about installing SRC M3, v 2.0x In article , vixie@pa.dec.com (Paul A Vixie) writes: > Has anyone tried M3 with GCC? Yes, m3 2.06 works with gcc 2.1 -O2 on a DECstation. Sometime the compile time seems weird (see my message about performance). -- Eric. ======================================================================= 146 === Date: Wed, 29 Apr 92 15:20:40 PDT From: jdd@src.dec.com (John DeTreville) Subject: Re: Modula-3 Users Group Meeting... Well, the mug-meeting@src.dec.com mail alias isn't working at all! Apologies to everyone who's had their mail bounce. For right now, please RSVP to me personally, jdd@src.dec.com. Also, I forgot to mention that in addition to inviting talks, we invite any demos you might like to give. Our meeting room has a wall-sized video screen, so Trestle-based demos would look especially stunning. If you'd like to give a demo, please contact me as soon as possible. It will probably entail bringing up your system at SRC prior to the meeting. Cheers, John ======================================================================= 147 === Date: Thu, 30 Apr 92 10:35:17 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: performance In article <1992Apr29.120943.2681@src.dec.com>, mjordan@src.dec.com (Mick Jorda n) writes: > > The "Hello" program simply coalesced into a single module is 1175 lines long and > contains 75 procedure bodies. > > The "Hello" program with unused procedures removed is 460 lines long and > contains 24 procedure bodies. This numbers are somewhat misleading. The resulting Modula-3 code contains LOCK statements and NEW expressions, which are implemented by the runtime, but the corresponding procedures do not appear in the expanded code. -- Eric. ======================================================================= 148 === Date: 30 Apr 92 15:01:40 GMT From: ljp@sm.luth.se (Johan Persson) Subject: A proposal for a new construction Hi, I thought I should share some ideas that were floating around here at the department some years ago and perhaps get some reactions from experienced M3 programmers on what an extension to the M3 language, described below, would impose for problems. First som background; Some year ago a group here at the department designed and implemented an enhanced version of Modula-2 called Modula-2000. (This project is now abandoned mainly because of time and shortage of people, although it resulted in some interesting experience.) Some of the more significant changes was in the type system which was designed to have a more uniform treatment of types. Much in the same spirit as M3, for example structural equality. Some of the restrictions that exists in M2 was removed, for example the following: - the type of the return value of a function procedure must be simple - an opaque type must be of a fixed size known to the compiler - constructor expression forms are provided only for simple types - if the return value of a function is a pointer type, an application may not be immediately dereferenced There was also an extension of the basic types to include a STRING type. Furthermore, the module system was enhanced to support generic modules. There were also some other changes which tried to clerify the fundamental confusion between object and value in imperative languages. For example, value parameters are considered as values and therefore cannot be assigned to. The FOR-statement was modified to stress the fact that the controlling "variable" is not a variable but a value which takes on successive values. However, the main innovation as compared to M2, as I see it, was the introduction of the disjoint-union. It was designed with the possibility of pattern matching, ala ML or HASKELL, in mind. It's often the case that one want to define a type whose element have a number of different forms, In M2 this is expressed using variant records. Consider an example with arithmetic expressions. In M2 you would probably code something like TYPE Operator = (plus,minus,times,div); ExprForm = (const,var.opexp); Expr = POINTER TO ExprNode; ExprNode = RECORD CASE form:ExprForm OF const: val:INTEGER | var: id:STRING | opexp: op:Operator; left,right:Expr END (* CASE *) END (* RECORD *) The interesting type here is Expr. The form of the actual value at run time can be determined by looking at the tag field form. However, access to the correct field is entirely dependent on the discipline of the programmer and as we all know, if you have a choice you will probably end up making a mistake. To remedy this problem the variant record construction was replaced by the (cleaner) UNION construct. The previous example would become TYPE Operator = (plus,minus,times,div); Expr = UNION const : INTEGER | var : STRING | opexp : POINTER TO RECORD op: Operator; left,right : Expr END END; An Expr takes one of three possible forms indicated by the tag const, var or opexp. The tag, however, is not a variable and can be neither assigned to nor tested. Values of type Expr are built using the tag as a constructor. The only way to access the contents of a variable e:Expr is with the use of the VARIANT statement introduced precisely for this purpose. Note the POINTER construction, this is necessary as the type system in M-2000 doesn't allow true recursive types. A function to evaluate an expression with respect to an environment which binds integer values to variable names might look like PROCEDURE eval(e:Expr; env:Environment.T):INTEGER VAR lval,rval:INTEGER; BEGIN VARIANT e OF const(c): RETURN c | var(v) : VARIANT lookup(x,env) OF notfound: error( ... ); | found(y): RETURN y END (* VARIANT *) | opexp(f): lval = eval(f^.left,env); rval = eval(f^.right,env); CASE f^.op OF plus : RETURN lval + rval; (* The rest omitted *) END (* CASE *) END (* VARIANT *) END eval; The code deserves some explanation. First e is examined and its form found, (const,var,opexp), then the value is bound to the constructor variable (c,v,f). Those of you familiar with ML or HASKELL will recognize this as the imperative version of pattern matching, admittedly in a very crude form. It should be noted that the identifier used as argument to the tags in these variant denotes a value; it is not a variable and consequently can not be assigned to. This is a consequence from the fact that 'e' is a value parameter. The assignment of 'e' has the form e:=const(5), for example. The lookup function returns a value of a union type. The signature could be stated as PROCEDURE lookup(x:STRING,env:Environment.T): UNION notfound: | found:INTEGER END; The idea in lookup to use unions as range types for partial functions should ne noted. This is often an elegant method in such cases partly replacing the use of exceptions. This method also forces the user to be explicetly aware of the possiblity of failure, sometimes considered a disadvantage by lazy people but of course necessary for serious programming. Now, after this somewhat lengthy introduction, I'll try to make a point. I was thinking of implementing UNIONS for M3, but I would like to get a second (and a third) opinion on what you people experinced with M3 think of this. There might be some serious pitfalls which I tend to overlook since I haven't any real experience (yet) with M3. Thanks in advance, Johan ---------------------------------------------------------------------- That Is The Question: Co-existence or no existence. Piet Hein ---------------------------------------------------------------------- Johan Persson E-mail: Voice: Dept. of Computer Science ljp@sm.luth.se +46 (0)920 912 00 University of Lule{\aa} Fax: S-951 87 Lule{\aa},Sweden +46 (0)920 988 94 ----------------------------------------------------------------------- ======================================================================= 149 === Date: Thu, 30 Apr 92 12:11:05 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Re: performance In article <1992Apr30.103517.28231@src.dec.com>, muller@src.dec.com (Eric Mulle r) writes: > In article <1992Apr29.120943.2681@src.dec.com>, mjordan@src.dec.com (Mick Jor dan) writes: > > > > The "Hello" program simply coalesced into a single module is 1175 lines lon g and > > contains 75 procedure bodies. > > > > The "Hello" program with unused procedures removed is 460 lines long and > > contains 24 procedure bodies. > > This numbers are somewhat misleading. The resulting Modula-3 code > contains LOCK statements and NEW expressions, which are implemented by > the runtime, but the corresponding procedures do not appear in the > expanded code. > Eric is quite correct. He knows the runtime a lot better than I do! I ran the wrong version of the optimiser which considers much of the runtime as a hardwir ed" black box. So both figures are an underestimate. I redid the analysis, this tim e including all the runtime, with the following results. The "Hello" program simply coalesced into a single module is 9194 lines long an d contains 393 procedure bodies. The "Hello" program with unused procedures removed is 3212 lines long and contains 126 procedure bodies. Since I cant currently compile and run these programs I cant be sure that the optimised version is correct, but it looks ok. Mick ======================================================================= 150 === Date: 1 May 92 03:10:15 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: A proposal for a new construction I have two kinds of responses to the proposal for a UNION type: 1) OBJECT types essentially subsume UNIONS with added functionality, though they do not have quite as concise a notation, etc. My understanding was that UNIONs (or their earlier version, variant records) were not included in M3 precisely because of the overlap with OBJECT types. 2) CLU oneof and variant types did all this before. I don't think there's necessarily all that much issue about how to do it well. The issue is whether, given OBJECT types, it should be done in M3 at all. Since there are other ways to achieve the functionality, albeit more verbose ones, I favor considering first extensions that give new functionality. Of course this tends to run afoul of the original goal of a language that can be described in 50 pages or less, which I find laudable. Maybe we should agree to change the limit to 60 or 75 pages :-). There is always a tricky question of where to stop adding features to a language .... -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================= 151 === Date: Thu, 30 Apr 92 21:27:22 -0400 From: Norman Ramsey Subject: Re: A proposal for a new construction I believe current wisdom is that the subtyping mechanism should be used for union types, using TYPECASE for discrimination. I'm doing this in my code. I find it somewhat unsatisfactory since I have to allocate an object to do it, and since there could always be subtypes I don't know about, but it works tolerably well. Norman Ramsey ======================================================================= 152 === Date: Thu, 30 Apr 92 10:35:17 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: performance In article <1992Apr29.120943.2681@src.dec.com>, mjordan@src.dec.com (Mick Jorda n) writes: > > The "Hello" program simply coalesced into a single module is 1175 lines long and > contains 75 procedure bodies. > > The "Hello" program with unused procedures removed is 460 lines long and > contains 24 procedure bodies. This numbers are somewhat misleading. The resulting Modula-3 code contains LOCK statements and NEW expressions, which are implemented by the runtime, but the corresponding procedures do not appear in the expanded code. -- Eric. ======================================================================= 153 === Date: Thu, 30 Apr 92 12:11:05 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Re: performance In article <1992Apr30.103517.28231@src.dec.com>, muller@src.dec.com (Eric Mulle r) writes: > In article <1992Apr29.120943.2681@src.dec.com>, mjordan@src.dec.com (Mick Jor dan) writes: > > > > The "Hello" program simply coalesced into a single module is 1175 lines lon g and > > contains 75 procedure bodies. > > > > The "Hello" program with unused procedures removed is 460 lines long and > > contains 24 procedure bodies. > > This numbers are somewhat misleading. The resulting Modula-3 code > contains LOCK statements and NEW expressions, which are implemented by > the runtime, but the corresponding procedures do not appear in the > expanded code. > Eric is quite correct. He knows the runtime a lot better than I do! I ran the wrong version of the optimiser which considers much of the runtime as a hardwir ed" black box. So both figures are an underestimate. I redid the analysis, this tim e including all the runtime, with the following results. The "Hello" program simply coalesced into a single module is 9194 lines long an d contains 393 procedure bodies. The "Hello" program with unused procedures removed is 3212 lines long and contains 126 procedure bodies. Since I cant currently compile and run these programs I cant be sure that the optimised version is correct, but it looks ok. Mick ======================================================================= 154 === Date: 30 Apr 92 15:01:40 GMT From: ljp@sm.luth.se (Johan Persson) Subject: A proposal for a new construction Hi, I thought I should share some ideas that were floating around here at the department some years ago and perhaps get some reactions from experienced M3 programmers on what an extension to the M3 language, described below, would impose for problems. First som background; Some year ago a group here at the department designed and implemented an enhanced version of Modula-2 called Modula-2000. (This project is now abandoned mainly because of time and shortage of people, although it resulted in some interesting experience.) Some of the more significant changes was in the type system which was designed to have a more uniform treatment of types. Much in the same spirit as M3, for example structural equality. Some of the restrictions that exists in M2 was removed, for example the following: - the type of the return value of a function procedure must be simple - an opaque type must be of a fixed size known to the compiler - constructor expression forms are provided only for simple types - if the return value of a function is a pointer type, an application may not be immediately dereferenced There was also an extension of the basic types to include a STRING type. Furthermore, the module system was enhanced to support generic modules. There were also some other changes which tried to clerify the fundamental confusion between object and value in imperative languages. For example, value parameters are considered as values and therefore cannot be assigned to. The FOR-statement was modified to stress the fact that the controlling "variable" is not a variable but a value which takes on successive values. However, the main innovation as compared to M2, as I see it, was the introduction of the disjoint-union. It was designed with the possibility of pattern matching, ala ML or HASKELL, in mind. It's often the case that one want to define a type whose element have a number of different forms, In M2 this is expressed using variant records. Consider an example with arithmetic expressions. In M2 you would probably code something like TYPE Operator = (plus,minus,times,div); ExprForm = (const,var.opexp); Expr = POINTER TO ExprNode; ExprNode = RECORD CASE form:ExprForm OF const: val:INTEGER | var: id:STRING | opexp: op:Operator; left,right:Expr END (* CASE *) END (* RECORD *) The interesting type here is Expr. The form of the actual value at run time can be determined by looking at the tag field form. However, access to the correct field is entirely dependent on the discipline of the programmer and as we all know, if you have a choice you will probably end up making a mistake. To remedy this problem the variant record construction was replaced by the (cleaner) UNION construct. The previous example would become TYPE Operator = (plus,minus,times,div); Expr = UNION const : INTEGER | var : STRING | opexp : POINTER TO RECORD op: Operator; left,right : Expr END END; An Expr takes one of three possible forms indicated by the tag const, var or opexp. The tag, however, is not a variable and can be neither assigned to nor tested. Values of type Expr are built using the tag as a constructor. The only way to access the contents of a variable e:Expr is with the use of the VARIANT statement introduced precisely for this purpose. Note the POINTER construction, this is necessary as the type system in M-2000 doesn't allow true recursive types. A function to evaluate an expression with respect to an environment which binds integer values to variable names might look like PROCEDURE eval(e:Expr; env:Environment.T):INTEGER VAR lval,rval:INTEGER; BEGIN VARIANT e OF const(c): RETURN c | var(v) : VARIANT lookup(x,env) OF notfound: error( ... ); | found(y): RETURN y END (* VARIANT *) | opexp(f): lval = eval(f^.left,env); rval = eval(f^.right,env); CASE f^.op OF plus : RETURN lval + rval; (* The rest omitted *) END (* CASE *) END (* VARIANT *) END eval; The code deserves some explanation. First e is examined and its form found, (const,var,opexp), then the value is bound to the constructor variable (c,v,f). Those of you familiar with ML or HASKELL will recognize this as the imperative version of pattern matching, admittedly in a very crude form. It should be noted that the identifier used as argument to the tags in these variant denotes a value; it is not a variable and consequently can not be assigned to. This is a consequence from the fact that 'e' is a value parameter. The assignment of 'e' has the form e:=const(5), for example. The lookup function returns a value of a union type. The signature could be stated as PROCEDURE lookup(x:STRING,env:Environment.T): UNION notfound: | found:INTEGER END; The idea in lookup to use unions as range types for partial functions should ne noted. This is often an elegant method in such cases partly replacing the use of exceptions. This method also forces the user to be explicetly aware of the possiblity of failure, sometimes considered a disadvantage by lazy people but of course necessary for serious programming. Now, after this somewhat lengthy introduction, I'll try to make a point. I was thinking of implementing UNIONS for M3, but I would like to get a second (and a third) opinion on what you people experinced with M3 think of this. There might be some serious pitfalls which I tend to overlook since I haven't any real experience (yet) with M3. Thanks in advance, Johan ---------------------------------------------------------------------- That Is The Question: Co-existence or no existence. Piet Hein ---------------------------------------------------------------------- Johan Persson E-mail: Voice: Dept. of Computer Science ljp@sm.luth.se +46 (0)920 912 00 University of Lule{\aa} Fax: S-951 87 Lule{\aa},Sweden +46 (0)920 988 94 ----------------------------------------------------------------------- ======================================================================= 155 === Date: Thu, 30 Apr 92 21:27:22 -0400 From: Norman Ramsey Subject: Re: A proposal for a new construction I believe current wisdom is that the subtyping mechanism should be used for union types, using TYPECASE for discrimination. I'm doing this in my code. I find it somewhat unsatisfactory since I have to allocate an object to do it, and since there could always be subtypes I don't know about, but it works tolerably well. Norman Ramsey ======================================================================= 156 === Date: Fri, 1 May 92 04:11:14 PDT From: msm@src.dec.com (Mark S. Manasse) Subject: Re: Embedded formatting in comments If you're reading the Trestle interfaces, the answer is a qualified "yes". The easy way to view the results of typesetting the interfaces is to get a copy of SRC Research Report #68, the Trestle Reference Manual. You can send mail to src-report@src.dec.com to request that a copy be mailed to you. Incidentally, the Trestle Tutorial (SRC 69) is on its way to the printer, so that should be available in a couple of weeks. If you want to print it yourself, the answer is "not yet". The programs we have that build the reference manual from the sources are a bit fragile at this point. We hope to improve this soon. For those of you interested in the technology, read on. Every else should probably stop reading now, before they lose their lunch all over their keyboard. For the curious, our formatting conventions are pretty simple. Except for comments, the program is typeset in a typewriter font, with narrow margins and no filling or justification. Most comments are just treated as Latex text, and can contain arbitrary commands. Except that double quotes in a comment are used to surround things that should appear in the same font as the program, like identifiers. Now we're almost ready to typeset. One exception is that a comment immediately following a procedure declaration gets typeset indented in a slanted font, sort of like a theorem in mathematics. And we toss in automatic index entries for every declaration in an interface. And we've always had our pretty-printer handle comments that have vertical bars in the first column to mean that the pretty-printer should keep its hands off that line, because it's part of a table, or a piece of sample code, so we automatically switch to typewriter font. Except sometimes you want to put some text in the middle of a program example to indicate that some string is a meta- variable, and not an identifier, so you put those in backquotes, but only on lines in comments that started with a vertical bar. Hey, you were warned. Anyhow, we've found it useful in producing a document that actually reflected the truth about our interfaces, and we don't find very much of the typesetting commands too ugly while we're editing. In particular, the quoting convention seems quite tolerable. The main things I don't like are when we start getting into TeX commands that aren't in the standard working set of most prgrammers, or aren't obvious. I consider something like {\it foo} to be relatively transparent (it means to put "foo" into italics), and the Latex section header macros aren't too bad. The ones I don't much like are the ones for typesetting bulleted lists, mostly because you get a choice of having it look like a bulleted list in the typeset version or in the typewritten version but not both. We still need to invent a couple more conventions, and then we'll be done. Mark ======================================================================= 157 === Date: 1 May 92 03:10:15 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: A proposal for a new construction I have two kinds of responses to the proposal for a UNION type: 1) OBJECT types essentially subsume UNIONS with added functionality, though they do not have quite as concise a notation, etc. My understanding was that UNIONs (or their earlier version, variant records) were not included in M3 precisely because of the overlap with OBJECT types. 2) CLU oneof and variant types did all this before. I don't think there's necessarily all that much issue about how to do it well. The issue is whether, given OBJECT types, it should be done in M3 at all. Since there are other ways to achieve the functionality, albeit more verbose ones, I favor considering first extensions that give new functionality. Of course this tends to run afoul of the original goal of a language that can be described in 50 pages or less, which I find laudable. Maybe we should agree to change the limit to 60 or 75 pages :-). There is always a tricky question of where to stop adding features to a language .... -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu