======================================================================= 1 === Date: Thu, 1 Sep 1994 05:30:09 GMT From: mat@mole-end.matawan.nj.us Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <340dcc$qn8@larry.rice.edu>, amitp@owlnet.rice.edu (Amit Jayant Pate l) writes: > I have often heard that "most" C++ programs use casts. However, I > haven't found any place where I needed them, other than const-casts, > which are no longer needed with the 'mutable' keyword. > > Can someone give examples of where casts are necessary in C++? I have > not worked on medium or large programs yet, so I may just be lacking > experience. I suspect that the author was accustomed to using C++ as though it were Smalltalk and downcasting to get at a `universal' base class. (Of course, I could be entirely wrong.) There _are_ some places where you end up writing _conversions_ (which get expressed as casts); these typically are places where you need more conversions than C++ will insert automatically, or where you need to disambiguate. Such casts are dangerous not because they violate the type system, but because they might violate it someday when declarations are changed. It is for this reason that ANSI/ISO C++ will (almost certainly) contain the `static_cast< T >( .. .. .. )' which will convert its parameter to the type T _iff_ it can be done by a legal, legitimate conversion (e.g. if the compiler could insert the conversion itself, if it knew your intentions). If such a conversion attempts to contravene the type system, it is illegal and will be diagnosed. -- (This man's opinions are his own.) From mole-end Mark Terribile mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ (Training and consulting in C, C++, UNIX, etc.) ======================================================================= 2 === Date: Thu, 1 Sep 1994 03:28:59 GMT From: ian@syacus.acus.oz.au (Ian Joyner) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? Aug29141346@samsun.us.oracle.com> speters@samsun.us.oracle.com (Stephen Peters) writes: >In article <1994Aug29.022054.4589@rcmcon.com> rmartin@rcmcon.com (Robert Marti n) writes: >> goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7151) writes: >> >> [responding as to why he enjoys dynamic typed languages] >> >> >Actually, I think it's because I'm essentially a freedom junkie. >> >I find that I'm much more comfortable (and productive) in an >> >environment that lets me do pretty much whatever I want within >> >the programming paradigm, and doesn't throw non-essential >> >constraints at me in the interest of "forcing" me to write >> >"better" programs. >> >> I notice that you do not exercise your freedom with respect to the >> spelling of the words in your posting. Is this because you feel that >> a certain amount of rigidity in the spelling and grammar of your >> writings aids in communictaions? ^^ Fairy vunny ;-) >If I might respond to this rather silly analogy, I'm sure that he >finds spelling "freely" rather obnoxious, considering that USENET as a >whole tends to pop up "syntax errors" in the form of spelling flames. >He's merely trying to get his words to compile cleanly. No, Robert has an excellent analogy. I read into it that all languages are made up of tokens, but only certain combinations are valid. In the written word, a spell checker can to the tedious work of detecting spelling errors (where the error does not result in another valid word of the language). Grammar checkers have been less successful, as natural grammar is much more complex. However, with computer languages, the grammars are deliberately invented so that mechanical checks can be made. This has to do with helping the programmer, NOT limiting her freedom. A type system within a language is a language of it's own that the programmer is inventing, and this again can be checked. It helps detect inconsistencies that we might be introducing, because of something purely mechanical that our thought processes did not think of at the time. And it is good programmers that know their own thought processes that admit we need this kind of mechanical aid. This has got nothing to do with limiting freedom or creativity. In fact it enhances it. Further more it is not just syntax errors we are trying to catch, it is semantic errors. If you get flamed on the net for spelling errors, then the error has already propogated too far. When building software, if this sort of error propogates to our customer, it costs us money, to fix it and in lost faith. Even more so, if semantic errors get through. >Surely you don't think he wants to be *completely* free in his >programming, do you? I'd hate to see him then...writing gorgeous >poems instead of C code and then ranting about the restrictions of the >compiler! :-) Well if programmers put as much thought, love and care into programming, as a poet puts into crafting fine words, perhaps the industry would be a better place. But then I would certainly rather be reading poetry than C programs ;-{. -- Ian Joyner |"for when lenity and cruelty play |All opinions are Unisys (ACUS) | for a kingdom, the gentler gamester|personal and are not ian@syacus.acus.oz.au| is the soonest winner" W.S. Henry V|Unisys official comm ent ======================================================================= 3 === Date: Thu, 1 Sep 1994 05:12:06 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? amitp@owlnet.rice.edu (Amit Jayant Patel) writes: >I have often heard that "most" C++ programs use casts. However, I >haven't found any place where I needed them, other than const-casts, >which are no longer needed with the 'mutable' keyword. >Can someone give examples of where casts are necessary in C++? I have >not worked on medium or large programs yet, so I may just be lacking >experience. Casts in C++ are not almost always unecessary and unwanted. There are times when dynamic_cast is useful, but this is more a test and less a cast. If we ignore novices, Casts are most often used in C++ by people who are used to programming in dynamically typed languages (like Smalltalk). They have difficulty with the type system and are not used to the restrictions it imposes. Thus they use casts to do the same things that they would have done in their dynamically typed language. What they need to do instead, is change their style. The style needed for programming in a statically typed language is quite different from that needed for a dynamically typed language. Once this transition is made, the casts in C++ disappear. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ ======================================================================= 4 === Date: 1 Sep 1994 08:00:49 GMT From: nebbe@lglsun.epfl.ch (Robb Nebbe) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article , derway@ndc.com (D. Erway) wri tes: |> |> >>>>> "Amit" == Amit Jayant Patel writes: |> |> Amit> I have not used Eiffel, so I am not speaking from experience here, bu t |> Amit> it seems like I have to anticipate what classes my users might want m y |> Amit> class to be derived from (like Sortable) for them to use my class, |> Amit> while I am less likely to have to do so in C++. |> |> Eiffel offers both unconstrained and constrained generics. Use whichever is |> appropriate. |> Amit is correct in stating that in Eiffel you usually need to anticipate the use of constrained genericity. In Eiffel unconstrained genericity isn't the equivalent of templates in C++. In Eiffel as well as Ada the generic contract is clearly documented which in my opinion should ease reuse and maintenance. In C++ I would expect you would need a tool to figure out the contract or depend on comments in the code. - Robb Nebbe ======================================================================= 5 === Date: Thu, 1 Sep 1994 04:57:34 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? bunbury@vienna.eiffel.com (Richard Bunbury) writes: >As a contribution to the recent discussions on static versus dynamic >typing on these newsgroups, ISE has prepared a short position >paper on the Eiffel approach to typing. I wish this were more a position paper, and less a "Eiffel is better than C++" paper.... > Static typing is for dynamic programmers: > On the Eiffel approach to typing. > C++ offers some of the typing mechanisms described below. But >static typing a la C++ is too constraining for realistic software >development. Gee, all those programs that we've all been developing in C++ just aren't realistic. This is pure hype and has no place in a position paper. >This is evidenced by the observation that most C++ >programs use casts, that is to say, cheat with the type system. Most "good" programs in C++ *don't* use casts. [...] >Multiple inheritance >==================== >This is used routinely in Eiffel (as opposed to C++ where it is >viewed with suspicion; MI in C++ may be viewed with suspicion by novices and people who are used to SI languages. Most consumate C++ programmers use MI freely, and without suspicion. [...] -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ ======================================================================= 6 === Date: Thu, 01 Sep 94 08:55:00 EDT From: gwyant@cloyd.East.Sun.COM Subject: can we kill the "dynamic vs. static typing" discussion ? I don't see what the discussion has to do Modula-3 anymore. In fact, it seems to have degenerated into a defense of the C++ type system, with the occasional advertisement for Eiffel and why it is better than C++. I find this to be just so much noise at this point. If you insist on continuing this war of opinions, please do so on the Eiffel, C++, or comp.object mailing lists. Just one person's grumpy request. --geoff ======================================================================= 7 === Date: Thu, 1 Sep 1994 17:06:51 GMT From: freeman@coolidge.coolidge.grenoble.xerox.fr (Steve Freeman) Subject: Re: [Q] Description of Modula-3? In article bcrwhims@undergrad.math.uwa terloo.ca (Carsten Whimster) writes: > > In article <341b1e$qrh@rs18.hrz.th-darmstadt.de>, > Michael Bonetsmueller wrote: > | > | Hello M3ers, > | > | I'm a bloody beginner even in OOP. Does anybody know where to find a good > | Manual/Tutorial an M3? I don't need a compiler description, i want to get > | taught how to program in M3. Is there anything the like on the Net? > | > | I browsed already the FAQ, but there are only big, expensive books. :-( > > I suppose it is probably what you would call a big expensive book, but > I would recommend "Modula-3", Sam Harbison. > -- Apologies to Sam Harbison, but you could also get hold of the technical report which describes the language from SRC (or ftp it from gatekeeper.dec.com) and pull over some of the libraries to see how they do it. It may take a while to get your head around some of the concepts, but it's worth it. steve -- - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Steve Freeman, Research Scientist, Rank Xerox France. Surface: Rank Xerox Research Centre, 6, chemin de Maupertuis, 38240 Meylan, France. Internet: steve.freeman@xerox.fr Phone: +33 76 61 50 21 Fax: +33 76 61 50 99 but wotthehel wotthehel toujours gai -- mehitabel the cat ======================================================================= 8 === Date: Thu, 1 Sep 1994 09:42:23 -0500 (CDT) From: "William D. Gooch" Subject: Re: Static vs Dynamic Typing: Effects on Productivity? On Thu, 1 Sep 1994, Ian Joyner wrote: > Aug29141346@samsun.us.oracle.com> > > speters@samsun.us.oracle.com (Stephen Peters) writes: > > >If I might respond to this rather silly analogy, I'm sure that he > >finds spelling "freely" rather obnoxious, considering that USENET as a > >whole tends to pop up "syntax errors" in the form of spelling flames. > >He's merely trying to get his words to compile cleanly. > .... > However, with computer languages, the grammars are deliberately invented > so that mechanical checks can be made. This has to do with helping > the programmer, NOT limiting her freedom. A type system within a > language is a language of it's own that the programmer is inventing, > and this again can be checked. It helps detect inconsistencies that > we might be introducing, because of something purely mechanical that > our thought processes did not think of at the time. And it is good > programmers that know their own thought processes that admit we need > this kind of mechanical aid. So your assertion is that in order to be a "good programmer" one is required to "admit that we need this ... aid." I think not. > This has got nothing to do with limiting > freedom or creativity. In fact it enhances it. Depends on your point of view and the kind of freedom you want to have, I suppose. In an email discussion that spun off from this thread, I elaborated: ... as in the freedom to not worry about static typing and other such constraints when I am doing development. This freedom allows me to concentrate on dealing with the complexities of the problem at hand, rather than being concerned about extraneous issues that have more to do with the quality of the implementation than the quality of the solution. I find that I am much better off if I have the choice of deferring those issues until I am on the downhill run toward finishing. And I simply cannot agree with you when you say that static typing "enhances" creativity. What exactly do you mean, that you could make such a claim? Creativity, in my experience, is limited whenever there are extraneous distractions from uninhibited ideation. Dealing with static type specification is one such distraction. This isn't an issue if dynamic typing is also available, but I still don't see how static typing can possibly _enhance_ creativity. ======================================================================= 9 === Date: 1 Sep 1994 17:45:52 GMT From: heinze@i41s5.ira.uka.de (Ernst A. Heinz) Subject: Modula-3 for Solaris 2.3 alias SunOS 5.3 Is the SOLsun port of Modula-3 release 3.3 or 3.4 up and running? If so, is there also a comprehensive file somewhere with all necessary patches? My question relates to the following installation problem that I am experiencing right now when executing ``m3boot'' with release 3.3 from gatekeep er. Undefined first referenced symbol in file ieee_handler ../../libm3/SOLsun/libm3.a(FloatMode_m.o) sigfpe ../../libm3/SOLsun/libm3.a(FloatMode_m.o) ieee_flags ../../libm3/SOLsun/libm3.a(FloatMode_m.o) ld: fatal: Symbol referencing errors. No output written to m3c *** error code 1 "/a/senilix/files/senilix10/labs/pelab/Modula-3/release-3.3/boot-SOLsun/m3build /templates/COMMON.BOOT", line 52: command execute failed *** call stack *** "/a/senilix/files/senilix10/labs/pelab/Modula-3/release-3.3/boot-SOLsun/m3build /templates/COMMON.BOOT", line 52: call to built-in exec "./make.boot", line 367: call to procedure boot_prog Please answer by email to ernhe@ida.liu.se or heinze@ira.uka.de --- thanks. =Ernst= -- +--------------------------------------------------------+-------------------+ | Ernst A. Heinz (email: heinze@ira.uka.de) | | | Institut fuer Programmstrukturen und Datenorganisation | Make it as simple | | Fakultaet fuer Informatik, Universitaet Karlsruhe | as possible, but | | Postfach 6980, D-76128 Karlsruhe, F.R. Germany | not simpler. | | (Voice: ++49/(0)721/6084386, FAX: ++49/(0)721/694092) | | +--------------------------------------------------------+-------------------+ "It has recently been found out that research causes cancer in rats!" ======================================================================= 10 === Date: 1 Sep 94 08:57:29 From: doug@monet.ads.com (Doug Morgan) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <340dcc$qn8@larry.rice.edu> amitp@owlnet.rice.edu (Amit Jayant Patel ) writes: >I have often heard that "most" C++ programs use casts. However, I >haven't found any place where I needed them, other than const-casts, >which are no longer needed with the 'mutable' keyword. > >Can someone give examples of where casts are necessary in C++? I have >not worked on medium or large programs yet, so I may just be lacking >experience. Some (many, all?) C++ compiler/linker environments are incapable of recognizing *all* cases of template functions (member or not) that never deference, overload, dispatch, etc. on objects of pointer type declared as template arguments. Such functions could have just one implementation that works for pointers to all types of objects. Therefore, to prevent code bloat, programmers sometimes "must" use templates with (inlined) casts of pointers to/from void* with actual operations carried out by a single implementation in terms of void*. Similarly, in order to get reasonable behavior from virtual functions, programmers sometimes have to cast pointers returned by virtual functions (to pointers to more derived classes). The need for this has been removed by some ANSI committee decisions, but that doesn't help everybody today. (Reflects the issue of what you mean by "C++".) I find casts to be helpful in rapidly coding/decoding/reformating binary data. Maybe there are better ways, but I've never bothered thinking about it. Doug ======================================================================= 11 === Date: Thu, 1 Sep 1994 18:39:21 GMT From: stef1638@mach1.wlu.ca (stefanovich boris) Subject: AUSTIN PARK AUSTIN PARK MANAGEMENT - The Number One UNIX Recruiters in Canada We are currently recruiting candidates with 2+ years of work experience in sofware development, technical support, MAC, and Q.A. Testing. If you have OOP, RDBMS (Sybase or Oracle), LAN/WAN, or Internet implementation experience, we'd like to talk to you about opportunities with our client companies. Call us at (416) 488-9565, Fax us at (416) 488-9601 or Snail us at: AUSTIN PARK MANAGEMENT 40 Eglinton Avenue West Suite #207 Toronto, Ontario M4P 3A2 *************************call us before we call you!!************************ ======================================================================= 12 === Date: 1 Sep 94 14:04:21 From: emery@goldfinger.mitre.org (David Emery) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? > This isn't an issue if dynamic typing is also available, but I still >don't see how static typing can possibly _enhance_ creativity. Do you believe in abstraction? Do you believe in automating the details and bookkeeping? Static type checking (whether in the language, such as Ada, or in some related tool, such as lint for C) helps creativity by allowing the programmer to concentrate on the big issues, and using the tools to automate checking of the small issues. dave -- --The preceeding opinions do not necessarily reflect the opinions of --The MITRE Corporation or its sponsors. -- "A good plan violently executed -NOW- is better than a perfect plan -- next week" George Patton -- "Any damn fool can write a plan. It's the execution that gets you -- all screwed up" James Hollingsworth ------------------------------------------------------------------------- ======================================================================= 13 === Date: Thu, 1 Sep 1994 16:20:02 GMT From: heyman@acad.stedwards.edu (Jerry Heyman) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? Richard Bielak (richieb@bony1.bony.com) wrote: > In article richieb@bony1.bony.com (Richard Bielak ) writes: > > > >Recall this sentiment of an old programmer: > > > > "Testing only proves the existence of errors, not their absense." > ^^^^^^^ > > > >On the other hand, a type checker proves the _absense_ of type errors. Well, I guess this is true - but what if the programmer casts a variable? The type might be correct (because they cast it to the type they need), but is the data valid? > ...richie > -- > * Richie Bielak (212)-635-4835 | jerry -- Jerry Heyman by day : IBM AIX Development, RISC System/6000 Div Internet: jerry@austin.ibm.com heyman@acad.stedwards.edu by nite : Adjunct Lecturer, St. Edward's Univ. *All comments are my own and should not be construed to represent any one else ======================================================================= 14 === Date: 2 Sep 94 06:18:12 GMT From: priest@fraser.sfu.ca (David Priest) Subject: Logitech M2 v4.0 Student Pak I can get Logitech's Modula-2 v4.0 student package. Is it worth it? I currently use FST's Modula, and have had a great time with it: I think I should be buying a package. My choices seem to be FST and Logitech (or, I suppose, move on to Modula-3)... So the question boils down to: is the Logitech student package ag any good? Bugs? How's the development environment? And does it have object extensions like FST does? Thanks for any help, david_priest@fraser.sfu.ca ======================================================================= 15 === Date: Sat, 03 Sep 1994 02:03:21 From: j_mcarthur@BIX.com (Jeffrey McArthur) Subject: Re: Logitech M2 v4.0 Student Pak David Priest asks > I can get Logitech's Modula-2 v4.0 student package. Is it worth it? I >currently use FST's Modula, and have had a great time with it: I think >I should be buying a package. My choices seem to be FST and Logitech >(or, I suppose, move on to Modula-3)... > > So the question boils down to: is the Logitech student package ag >any good? Bugs? How's the development environment? And does it >have object extensions like FST does? I don't have any experience with the student package. I have the "normal" package. The Logitech 4.0 package is a very good development platform. There are only two problems with it. First it is not very flashy. Personally I prefer this. I run from the command line. Second, and much more serious, the product is orphaned. Symantech purchased Multiscope a while ago. Symantech decreed that ALL development would be done in C++. So this killed all support for the very good Modula 2 product. Actually the Logtech 4.0 package uses a slighly modified version of the Stonybrook compiler. Stonybrook is still around. So you can buy the compiler directly from them. The newest release of the Stonybrook compiler is STILL in beta test (how long has it been?). The only bugs I have found in the Logitech 4.0 package relate to LONGCARD. I have found 4 separate bugs in the way the compiler handles arithmatic with LONGCARD. LONGINT works, but LONGCARD is broken. The other option is Clarion's TopSpeed compiler. Again it is not flashy. It does have object oriented extensions. There is a student version of the compiler that gets very good reviews (it is based on version 1.17 while the current release is 3.10). In my opinion, Modula-3 is not quite ready for "prime time". I am spoiled. I got used to reasonably fast compiles and links with Modula-2. Modula-3 generates C code which then must be compiled and linked. This is a VERY SLOW process. So until someone has a native code Modula-3 I will not use it (I just don't have the time to wait around for the slow compiler and linker). The other option is to go to Oberon-2. Oberon is the successor to Modula-2. Oberon-2 is the sucessor to Oberon. There are several very interresting packages available for Oberon. One of the more interresting is the OM2 compiler. It comes with a full Modula-2 and Oberon-2 compiler. The compiler generates 32 bit code. It looks very good. Unfortunately you cannot link in forign modules. I need the ability to link in forign modules (e.g. the Paradox Engine or CodeBase). There is also the Window's based POW. This looks very good also. ---- Jeffrey M\kern-.05em\raise.5ex\hbox{\b c}\kern-.05emArthur a.k.a. Jeffrey McArthur email: j_mcarthur@bix.com phone: (301) 210-6655 fax: (301) 210-4999 home: (410) 290-6935 The opinions express are mine. They do not reflect the opinions of my employer. My access to the Internet is not paid for by my employer. ======================================================================= 16 === Date: 2 Sep 1994 20:18:44 -0700 From: bunbury@vienna.eiffel.com (Richard Bunbury) Subject: Real C++ programmers don't use casts [was Re: Static vs Dynamic Typing ] >From Robert Martin : >Casts in C++ are [] almost always unecessary and unwanted. There are >times when dynamic_cast is useful, but this is more a test and less a >cast. >If we ignore novices, Casts are most often used in C++ by people who >are used to programming in dynamically typed languages (like >Smalltalk). [The place marked [] contained the word "not" but I assume this is a typo.] Well, this is not what we hear from the field - i.e. from disgruntled C++ programmers, an ever fresh source of new Eiffel fans. Or from the literature either. Just today we received the September 1994 issue (volume 12, number 9) of "The C/C++ Users Journal"). And sure enough, the longest article in the issue is entitled "Code Capsules: Conversions and Casts", by Chuck Allison (perhaps a "Novice"?). Here is a quote from that article: -------- Begin quotation -------------------------------------- A cast is your way of telling the compiler to allow you to do something potentially dangerous, because you think you know what you're doing. Too often, though, you don't know what you're doing (no offense!), and you spend days tracking down an insidious pointer conversion error or similar bug . [Note by RB: No, this is NOT Eiffel propaganda literature. It does come from the C/C++ Users Journal, September 1994.] It's interesting that programmers use a single cast notation for so many different purposes: + to reinterpret the bit pattern of an object + to widen or narrow a value + to traverse a class hierarchy + to cast-away `const' or `volatile' + to do some implementation-dependent magic -------- End quotation -------------------------------------- Frankly, to an Eiffel programmer, this all sounds pretty repulsive. In particular we do not think that object-oriented software construction should be about "magic". But even if you find nothing wrong with this, the scope of things for which the author cites a need to use casts in C++ seems rather broad, supporting the obvious observation of my earlier message that practical C++ programming requires casting. In fact, the same article by Mr. Allison tells us that "C++ defines four new cast mechanisms". Now if casts are not needed, how come there are four more kinds? To repeat comments made in an earlier message: in Eiffel, you can do everything WITHOUT casts, in a type-safe manner. The key is a flexible enough type system. By the way, the lead article in the same issue of the C/C++ Users Journal is entitled "Using Windows Memory Management", by David Singleton. It comes with a program listing. Here are a few pretty typical lines from that listing: FP_FHB current_block_pointer = (FP_FHB) p_fhb ; ... _segment cur_seg = (_segment) SELECTOROF (this) ... (WORD) (this_block -> in_use_list) Looks like some casting is going on. But perhaps the author is a novice, or a freshly retrained Smalltalk programmer? -- Richard Bunbury ISE Eiffel Customer Support Reply to: ======================================================================= 17 === Date: Fri, 2 Sep 1994 20:14:32 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? "William D. Gooch" writes: >And I simply cannot agree with you when you say that static typing >"enhances" creativity. What exactly do you mean, that you could make >such a claim? Creativity, in my experience, is limited whenever there >are extraneous distractions from uninhibited ideation. Dealing with >static type specification is one such distraction. This isn't an issue >if dynamic typing is also available, but I still don't see how static >typing can possibly _enhance_ creativity. Creativity is the art of solving problems in the face of limitations. One person says it is impossible, another gets creative and solves the problem. It is not the absence of limitations that enhances creativity, it is creativity that conquers limitations. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ ======================================================================= 18 === Date: Fri, 2 Sep 1994 18:39:05 GMT From: dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: TCP Module strangeness. Intended? > - The strace showed a call to connect like: > connect(4, {sin_family=AF_INET, sin_port=htons(57616), ... The previous post does not mention the conclusion. The htons function included for LINUX was for big endian instead of for little endian. This has been fixed (libm3/src/unix/linux/Uin.m3) and will show up in the next SRC release and LINUX binaries, as usual. -- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 19 === Date: 3 Sep 1994 17:37:20 GMT From: satish@sun.mcs.clarkson.edu (Satish Thatte) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] >From bunbury@vienna.eiffel.com (Richard Bunbury): > From Robert Martin : > >>If we ignore novices, Casts are most often used in C++ by people who >>are used to programming in dynamically typed languages (like >>Smalltalk). > > Well, this is not what we hear from the field - i.e. from disgruntled C++ > programmers, an ever fresh source of new Eiffel fans. [extract from C/C++ Journal and comments by RB eleted] Richard, perhaps you can post some examples where a C++ program *requires* casting that a corresponding Eiffel program avoids by some mechanism *other than* assignment attempt or covariance in subclasses (which in a way are the same thing). I am not saying such examples don't exist, but having heard this argument going on for a long time, I still haven't seen any examples that pinpoint the superiority of Eiffel typing over C++ in a way that is not subsumed by RTTI features in forthcoming versions of C++. Satish ======================================================================= 20 === Date: Fri, 02 Sep 1994 21:20:00 +0100 From: geert@dialis.hacktic.nl (Geert Bosch) Subject: DEC's Modula 3 I just ftp-ed Modula-3 from gatekeeper.dec.com and I am wondering if anybody has tips about setting it up. My ultimate wish would be to compile Modula-3 from within an OS/2 environment. Does anybody have experience in doing this? Thanks in advance for your reply, Greetings, Geert ======================================================================= 21 === Date: Sat, 03 Sep 94 20:59:55 GMT+0100 From: atverm@ecp541.ecn.nl Subject: Re: DEC's Modula 3 In <778611866.AA07139@dialis.hacktic.nl> geert@dialis.hacktic.nl (Geert Bosch ) writes: | I just ftp-ed Modula-3 from gatekeeper.dec.com and I am wondering if anybody | has tips about setting it up. My ultimate wish would be to compile Modula-3 | from within an OS/2 environment. Does anybody have experience in doing this? | | Thanks in advance for your reply, | | Greetings, Geert I wish you good luck, you'd be the first to succeed. If you're serious I advise you to use the EMX 0.8h GCC environment to compile the beast. You'll need a fair amount of Unix and C knowledge. I gather you've taken the Linux port as a starting point? I once had the same plans as you, but I really don't have the time to do it. I remember reading some message of another brave person about two months ago who reported he got quake to work and he posted the diffs needed for it. I didn't hear from it any more. If you make progress, I am very much interested and would like to be kept informed, and I'm sure much others are because there have been quite some requests for an OS/2 port in the recent year! ====================================================================== A.T. Vermeulen (Internet: a.vermeulen@ecn.nl; Phone: (+31)22464194) Energy Research Foundation, PO Box 1, 1755 ZG Petten, The Netherlands ======================================================================= 22 === Date: 03 Sep 1994 22:41:01 GMT From: tmb@arolla.idiap.ch (Thomas M. Breuel) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <1994Sep1.094653@lglsun.epfl.ch> nebbe@lglsun.epfl.ch (Robb Nebbe) w rites: |Amit is correct in stating that in Eiffel you usually need to anticipate |the use of constrained genericity. In Eiffel unconstrained genericity |isn't the equivalent of templates in C++. In Eiffel as well as Ada the |generic contract is clearly documented which in my opinion should ease |reuse and maintenance. In C++ I would expect you would need a tool to |figure out the contract or depend on comments in the code. You can make the contract explicit in C++ by defining a dummy function that mentions all the facilities and properties you would like to put in the contract. You can (for example) specify the presence of member functions, data members, and inheritance relations that way. Thomas. ======================================================================= 23 === Date: Sun, 4 Sep 1994 03:47:16 GMT From: mikec@metronet.com (Mike Christiansen) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >From: bunbury@vienna.eiffel.com (Richard Bunbury) >Multiple inheritance >==================== > Multiple inheritance makes it possible to view an object from >two or more viewpoints. For example an E_MAIL_MESSAGE can be both >an ASCII_DOCUMENT and a NETWORK_EXCHANGEABLE (capitalizing the name >of the corresponding classes: the first will inherit from both of >the next two). One of the main unvoiced reasons for the hostility >to static typing in Smalltalk is that Smalltalk has only single >inheritance; so in a case like this you would have to choose only >one of the two viewpoints, making static typing unacceptably >constraining. Sorry, But I missed this one altogether. What does MI have to do with dynamic typing. Yes, Smalltalk supports only linear inheritance and I have found it to be constraining in some cases. But with some though, and the application of other patterns of composition (such as wrappers and deligation) I have been able to work arround my problems. But these problems would be there reguardless of the typing system. BTW. I would be interested in a discussion of the problems which would be introduced by supporting MI in Smalltalk. Tools, existing class libraries, legasy applications, etc. (although like this thread, it has probably been beat to death in the past :-) ********************************************* Mike Christiansen mikec@metronet.com ********************************************* ======================================================================= 24 === Date: 4 Sep 1994 06:50:09 GMT From: mbk@inls1.ucsd.edu (Matt Kennel) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] Richard Bunbury (bunbury@vienna.eiffel.com) wrote: : To repeat comments made in an earlier message: in Eiffel, you can : do everything WITHOUT casts, in a type-safe manner. The key is a : flexible enough type system. : By the way, the lead article in the same issue of the C/C++ Users Journal : is entitled "Using Windows Memory Management", by David Singleton. : It comes with a program listing. Here are a few pretty typical lines : from that listing: : FP_FHB current_block_pointer = (FP_FHB) p_fhb ; : ... : _segment cur_seg = (_segment) SELECTOROF (this) : ... : (WORD) (this_block -> in_use_list) : Looks like some casting is going on. But perhaps the author is a : novice, or a freshly retrained Smalltalk programmer? This is the fault of Windows no doubt. And the fact that the native Windows API is C. (yeah right language doesn't matter) : -- : Richard Bunbury : ISE Eiffel Customer Support : Reply to: -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego -*** AD: Archive for nonlinear dynamics papers & programs: FTP to -*** lyapunov.ucsd.edu, username "anonymous". ======================================================================= 25 === Date: Sun, 4 Sep 1994 12:32:14 GMT From: robsch@robkaos.ping.de (Robert Schien) Subject: Re: DEC's Modula 3 atverm@ecp541.ecn.nl wrote: : In <778611866.AA07139@dialis.hacktic.nl> geert@dialis.hacktic.nl (Geert Bos ch) writes: : | I just ftp-ed Modula-3 from gatekeeper.dec.com and I am wondering if anybod y : | has tips about setting it up. My ultimate wish would be to compile Modula-3 : | from within an OS/2 environment. Does anybody have experience in doing this ? : | : | Thanks in advance for your reply, : | : | Greetings, Geert : I wish you good luck, you'd be the first to succeed. If you're serious : I advise you to use the EMX 0.8h GCC environment to compile the beast. : You'll need a fair amount of Unix and C knowledge. I gather you've : taken the Linux port as a starting point? I would be interested in porting "the beast" to SVR4/386 and FreeBSD/NetBSD. When I take the Linux port as a starting point, what is necessary to port? I've looked at the various files in BOOT-Linux.tar and found lots of assembler code. What is necessary to do the port? BTW, in which way vary gcc and m3gcc? Robert ======================================================================= 26 === Date: Sun, 4 Sep 1994 03:55:18 +0000 From: rob@brewster.demon.co.uk (Rob Heyes) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <1994Sep1.162002.24832@acad.stedwards.edu> heyman@acad.stedwards.edu (Jerry Heyman) writes: > Well, I guess this is true - but what if the programmer casts a variable? > The type might be correct (because they cast it to the type they need), but > is the data valid? Proper languages (e.g. Eiffel) don't provide casts (not strictly true, but you have to jump through hoops to do it). Assignment attempt is the safe alternative in Eiffel. Rob -- It's going to be fun to see how long the meek can keep the earth when they inherit it. Rob Heyes (B3/5 w- dc g k s- r- p) rob@brewster.demon.co.uk ======================================================================= 27 === Date: Sun, 4 Sep 1994 14:35:55 +0000 From: rob@brewster.demon.co.uk (Rob Heyes) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <341sem$82e@galileo.polito.it> amund@galileo.polito.it (A.Aarsten) w rites: > Also, derway@ndc.com (D. Erway) writes: > > > C++ offers Unconstrained Genericity. So you cannot write a template, > > and limit the types that can be used to instantiate it. Therefor you > > cannot write code in EXCHANGE_LIST that uses the fact that the type is > > known, so you can call a method. You would have to first do a cast, > > which throws away the type safety... > > The types of the parameters are limited _implicitly_ by the features > your generic class accesses. You just call the methods that you need, > no casting. You can then use any class that provides those features, > regardless of where it is located in the class hierarchy. In other words, you can quite easily write a generic class in C++ that can never be instantiated because no classes provide all the methods that are used by that class. And the designer of the generic class will never know. Apart from anything else this seems to blow type safety completely out of the water. The absence of pre and post-conditions in C++ means that you have no idea whether the features that you are using are appropriate. > > Also, Eiffel allows you to inherit from a generic class to make a > > specialized version, that is still generic. C++ does not allow this. > > Wrong! C++ does allow this. Could you illustrate this? > > Assignment attempt is an operation of the form > > > > x ?= y > > > > Assignment attempt x ?= y (...) looks at the actual > > object type, performs the assignment if that type is compatible with > > that of x, and otherwise assigns to x a void value (which you can > > then test for). > > What is the difference between this and the C++ dynamic_cast? They > seem exactly the same to me. I thought that dynamic_cast threw an exception rather than assigning a void value. Rob -- It's going to be fun to see how long the meek can keep the earth when they inherit it. Rob Heyes (B3/5 w- dc g k s- r- p) rob@brewster.demon.co.uk ======================================================================= 28 === Date: Sun, 4 Sep 1994 03:55:14 +0000 From: rob@brewster.demon.co.uk (Rob Heyes) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <342ib1$gpm@larry.rice.edu> amitp@owlnet.rice.edu (Amit Jayant Patel ) writes: > If I want a sorted list, in C++'s templates, I can write a template > class that uses the "operator <" on the class for sorting. I can use > ints or strings or any class that has an operator < defined on it. > [Note: operator < is not a method here; it is a "global" function.] And as such has absolutely no semantics - all you can say about it is that it is a binary operator and that its 'name' is "<". In Eiffel you can specify more properties of a given feature by means of the pre and post conditions. IMHO Eiffel's support for design by contract by the use of assertions is its most important feature. > However, ints, strings, and all my other classes are not all derived > from some Sortable class. I can't specify "derived from Sortable" in > my template. > > I have not used Eiffel, so I am not speaking from experience here, but > it seems like I have to anticipate what classes my users might want my > class to be derived from (like Sortable) for them to use my class, > while I am less likely to have to do so in C++. This is IMHO a point in Eiffel's favour. You only need to specify enough of the behaviour that is required to implement your class. Eiffel's version of multiple inheritance will generally let you do whatever you want. Some people will probably complain that this may make it difficult to store integers, reals and strings in a container class with a strange ordering. But then how often do you only store integers, reals or strings by themselves in a container? Rob -- It's going to be fun to see how long the meek can keep the earth when they inherit it. Rob Heyes (B3/5 w- dc g k s- r- p) rob@brewster.demon.co.uk ======================================================================= 29 === Date: 05 Sep 1994 02:37:12 GMT From: tmb@arolla.idiap.ch (Thomas M. Breuel) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] In article <348puk$3o0@vienna.eiffel.com> bunbury@vienna.eiffel.com (Richard Bu nbury) writes: |[citing an article from the C/C++ journal:] |> A cast is your way of telling the compiler to allow you to do something |> potentially dangerous, because you think you know what you're doing. Well, this is simply wrong. Most casts are conversions between types that are as typesafe as the same operations are in other languages, including Eiffel. |> It's interesting that programmers |> use a single cast notation for so many different purposes: |> |> + to reinterpret the bit pattern of an object |> + to widen or narrow a value |> + to traverse a class hierarchy |> + to cast-away `const' or `volatile' |> + to do some implementation-dependent magic |[...] |But even if you find nothing wrong with this, the scope of things for |which the author cites a need to use casts in C++ seems rather broad, |supporting the obvious observation of my earlier message that practical C++ |programming requires casting. | |In fact, the same article by Mr. Allison tells us that "C++ defines four |new cast mechanisms". Now if casts are not needed, how come there are |four more kinds? Casts in C++ fulfill a number of functions and are used in a number of contexts. Here are some examples: (1) typesafe conversions (e.g. int to float) (2) interfacing to code written for different versions of the C/C++ type system (e.g., pre-const and const) (3) interfacing to code written in a language with a different type system (e.g., to CommonLisp or assembly language) (4) writing user-defined memory allocators (5) accessing I/O registers and absolute memory locations (6) accessing machine-dependent disk files These are all things that real-world programs have to do every now and then. Casts have in the past provided a single, convenient notation for doing these things. However, over the last 20 years, software engineering has changed, and programmers now prefer to be able to document better the different uses of a cast. That's why C++ now has four different casts, each of which only covers part of the functionality of the original notation, which has now been deprecated. The new notation also makes it easier to locate places in the code where unsafe casts are being used. Unfortunately, cast notation looks so harmless that inexperienced programmers will also use them to hack around design flaws. The newer notation will hopefully make it clearer that this is a bad idea. |To repeat comments made in an earlier message: in Eiffel, you can |do everything WITHOUT casts, in a type-safe manner. The key is a |flexible enough type system. You seem to be saying that Eiffel doesn't have to provide the functionality of a cast because Eiffel's type system is more flexible than that of C++. Could you be more specific in what way it is more flexible? |By the way, the lead article in the same issue of the C/C++ Users Journal |is entitled "Using Windows Memory Management", by David Singleton. |It comes with a program listing. Here are a few pretty typical lines |from that listing: [...] |Looks like some casting is going on. But perhaps the author is a |novice, or a freshly retrained Smalltalk programmer? I'm not surprised that Windows memory management code requires casts. How would you carry out the same operations in Eiffel? Thomas. ======================================================================= 30 === Date: 4 Sep 1994 23:29:18 -0700 From: bunbury@vienna.eiffel.com (Richard Bunbury) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >From Mike Christiansen: >Sorry, But I missed this one altogether. What does MI have to do with dynamic >typing. Yes, Smalltalk supports only linear inheritance and I have found it to >be constraining in some cases. But with some though, and the application of >other patterns of composition (such as wrappers and deligation) I have been >able to work arround my problems. But these problems would be there >reguardless of the typing system. The argument of the original message was this: - (A) Proponents of Smalltalk and other dynamically typed languages claim that static typing is too constraining. - (B) Smalltalk does not (in general) support multiple inheritance. - (C) It is indeed true that without multiple inheritance static typing would be unacceptably constraining (claim A). - (D) But examination of the typical examples used to support claim A show, in our opinion, that the unacceptable restrictions are due to the absence of multiple inheritance, and that with MI static typing is in fact not a limitation. Sorry if the reasoning was not clear enough. -- Richard Bunbury ISE Eiffel Customer Support Reply to: ======================================================================= 31 === Date: 5 Sep 1994 11:18:22 GMT From: glyn@midland.co.nz (Glyn Webster) Subject: Re: [Q] Description of Modula-3? >Apologies to Sam Harbison, but you could also get hold of the technical >report which describes the language from SRC >(or ftp it from gatekeeper.dec.com) ...... >- - - - - - - - - - - - - - - - - - - - - - - - - - >Dr. Steve Freeman, Research Scientist, Rank Xerox France. I've been lurking on Michael Bonetsmueller's message. I tryed FTPing gatekeeper.dec.com for the report last night but didn't know where to look: could you tell me where in gatekeeper.dec.com the report is stored? ======================================================================= 32 === Date: 5 Sep 1994 01:38:08 +0100 From: tom@smart.bo.open.de (Thomas Neumann) Subject: Success - 3.3 on NeXT I've just succeeded in bootstrapping release-3.3 on a NeXT/m68k running NeXTSTEP 3.2. Things look pretty good; it just finished compiling libm3 [the real thing, not the libm3 from the boot compiler] and I compiled "m3pp" with the fresh libm3 for a test. Everything looks ok, so I assume the compiler is working. I have not heard of anyone else who succeeded in bootstrapping a 3.x release on NeXTSTEP so far, and it was quite tricky in some places, so this may indeed be the first port (?!) To the SRC folks: Are you interested in my modifications ? Maybe it would be a good idea to upload a pre-compiled, ready to execute NeXT version somewhere ? bye -- Thomas ======================================================================= 33 === Date: 6 Sep 1994 08:09:28 GMT From: fabre@osf.org (Christian Fabre) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] In article <34ac8g$rlc@library.erc.clarkson.edu>, satish@sun.mcs.clarkson.edu (Satish Thatte) writes: |> From bunbury@vienna.eiffel.com (Richard Bunbury): [deleted] |> Richard, perhaps you can post some examples where a C++ program |> *requires* casting that a corresponding Eiffel program avoids |> by some mechanism *other than* assignment attempt or covariance in |> subclasses (which in a way are the same thing). Too bad that you remove covariance from the argument. In my project, covariance is the perfect technique: 99.9% of the casts in my C++ code would disapear in Eiffel. |> Satish Christian. ======================================================================= 34 === Date: 6 Sep 94 04:41:17 GMT From: dls@gwd.dsto.gov.au (David Silver) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] bunbury@vienna.eiffel.com (Richard Bunbury) writes: >From Robert Martin : >>Casts in C++ are [] almost always unecessary and unwanted. There are >>times when dynamic_cast is useful, but this is more a test and less a >>cast. >>If we ignore novices, Casts are most often used in C++ by people who >>are used to programming in dynamically typed languages (like >>Smalltalk). > [The place marked [] contained the word "not" but > I assume this is a typo.] >Well, this is not what we hear from the field - i.e. from disgruntled C++ >programmers, an ever fresh source of new Eiffel fans. Or from the >literature either. Just today we received the September 1994 issue >(volume 12, number 9) of "The C/C++ Users Journal"). And sure enough, >the longest article in the issue is entitled "Code Capsules: Conversions >and Casts", by Chuck Allison (perhaps a "Novice"?). Here is a quote from >that article: >-------- Begin quotation -------------------------------------- > A cast is your way of telling the compiler to allow you to do something > potentially dangerous, because you think you know what you're doing. Too > often, though, you don't know what you're doing (no offense!), and you > spend days tracking down an insidious pointer conversion error or similar bu g. >In fact, the same article by Mr. Allison tells us that "C++ defines four >new cast mechanisms". Now if casts are not needed, how come there are >four more kinds? Preferred methods of moving around a class hierarchy with pointers that take into account the type info that gets carried around with objects these days. They just make it more explicit exactly why you are doing a cast to the human reader, and also dynamic_cast<> casts from a base class down to a derived class in a hierarchy involving virtual bases, where the pointer value must be modified, and type info is required to do this correctly. >To repeat comments made in an earlier message: in Eiffel, you can >do everything WITHOUT casts, in a type-safe manner. The key is a >flexible enough type system. >By the way, the lead article in the same issue of the C/C++ Users Journal >is entitled "Using Windows Memory Management", by David Singleton. >It comes with a program listing. Here are a few pretty typical lines >from that listing: > FP_FHB current_block_pointer = (FP_FHB) p_fhb ; Turning the default pointer type into a "far" (32-bit segment:offset) pointer. *NOT NEEDED* > _segment cur_seg = (_segment) SELECTOROF (this) Probably not needed, depends what the SELECTOROF() macro returns and what _segment really is. Ideally it makes sense that a "selector" would be an _segment. > (WORD) (this_block -> in_use_list) Interpreting something as an unsigned 16-bit integer. Depends on the context but it is probably not needed. >Looks like some casting is going on. But perhaps the author is a >novice, or a freshly retrained Smalltalk programmer? Looks like you were picking on the code of a confirmed "cast-a-holic". The only other reason I can think of for these casts is that he was making the conversions explicit to do away with annoying compiler warning messages. I use C++ extensively, and the only times I use casts are where I have a collection class or iterator that returns a const pointer/reference and I need a non-const one. Does Eiffel have const? -- David ======================================================================= 35 === Date: 06 Sep 1994 09:38:14 GMT From: devernay@sophia.inria.fr (Frederic Devernay) Subject: Re: Modula-3 for Solaris 2.3 alias SunOS 5.3 This is because the sparc compiler takes /usr/lib/libm.so instead of its own libm.so, which contains sigfpe et al. BUT WHY THE HELL DIDN'T THEY INCLUDE THESE FUCTIONS IN /usr/lib/libm.so ? The cure is to add a -L flag corresponding to where the sparccompiler libraries are. I did a configuration file that allows dynamic libraries among other things for Solaris 2.3. I still have the old sparccompiler (2.0.1), though, so that you may have to modify some of the configuration parameters (especially the -z2 option). The pkg/m3build/templates/SOLsun file is included after this message. Fred ---8<---snip-snip---- % Copyright (C) 1989, 1992 Digital Equipment Corporation % All rights reserved. % See the file COPYRIGHT for a full description. % % Last Modified On Thu Jun 2 11:21:38 PDT 1994 By kalsow % % Standard configuration file for SOLsun (Solaris 2.x w/Sun C) % %-------------------------------------------------- compilation environment --- readonly TARGET = "SOLsun" readonly DEFAULT_BUILD_DIR = TARGET include ("PLATFORMS") % get the target-dependent mappings include (OS_TYPE) % get the OS-dependent functions readonly NAMING_CONVENTIONS = "0" % object files libraries % 0=Unix => .o .io .mo libXX.a % 1=Unix with a grumpy C compiler => .o _i.o _m.o libXX.a % 2=Windows/NT => .obj _i.obj _m.obj XX.lib % %------------------------------------------------------------- export paths --- % During the installation, destination directories that do not exist % will be created. You need the necessary permissions to do so; otherwise, % the installation will fail, but can be restarted after you have % fixed the permissions. BIN_INSTALL = "/u/corse/0/devernay/modula3/bin" % executables LIB_INSTALL = "/u/corse/0/devernay/modula3/" & TARGET % libraries DOC_INSTALL = "/u/corse/0/devernay/modula3/doc" % documents PKG_INSTALL = "/u/corse/0/devernay/modula3/pkg" % packages EMACS_INSTALL = "/u/corse/0/devernay/modula3/elisp" % emacs lisp code MAN_INSTALL = "/u/corse/0/devernay/modula3/man" % man pages HTML_INSTALL = "/u/corse/0/devernay/modula3/www" % public hypertext % The manual pages normally go in subdirectories man{1,...8} of % the MAN_INSTALL directory. If you prefer to have them all in % a single section, define MAN_SECTION to be that section's name. % MAN_SECTION = "l" % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. BIN_USE = BIN_INSTALL LIB_USE = LIB_INSTALL PKG_USE = PKG_INSTALL readonly INSTALL_IMPLS = "TRUE" % "TRUE" % => save all source files during the install % => makes debugging easier and browsing more fruitful % "" (i.e. FALSE) % => save only the exported interfaces and templates % => makes the installed system slightly smaller. readonly NEED_OBJECTS = "TRUE" % "TRUE" % => accumulate a list of derived objects in COMPILE_OBJECTS % => for building shared libraries in the library_hooks function below % "" % => don't bother %---------------------------------------------------------------------- X11 --- % If you have X11R4 installed and would like the X11R4 binding interfaces % to be built, define the procedure "import_X11R4" to import the libraries % that are needed. Otherwise, define "import_X11R4" to be an empty procedure. % % If you use the MIT server with DECnet support, you need X11 and dnet, % otherwise X11 should be enough. % % Since X11R5 is an extension of X11R4, you can use the X11R5 libraries % instead of X11R4. However, the Modula-3 binding interfaces have not % yet been upgraded to X11R5. % readonly proc import_X11R4() is import_lib("Xaw", "/usr/openwin/lib") import_lib("Xmu", "/usr/openwin/lib") import_lib("Xext", "/usr/openwin/lib") import_lib("Xt", "/usr/openwin/lib") import_lib("X11", "/usr/openwin/lib") end %---------------------------------------------------------------------- TeX --- % If you have TeX, define "DVIPS" to convert DVI files to PostScript (or % whatever your printer accepts). Otherwise, define "DVIPS" to be an % empty procedure % % If you have TeX, the implementation notes can be recompiled at your % site with whatever local modifications you make. % readonly proc DVIPS(f) is exec("dvips", f & ".dvi >", f & ".ps") end %-------------------------------------------------------------------- emacs --- % If you have emacs and want to compile ".el" files to ".elc" files, % fill in the function below. Otherwise, define it to be a no-op. readonly proc emacs_compile (el) is exec ("emacs -batch -f batch-byte-compile", el) end %-------------------------------------------------------- Modula-3 compiler --- % The syntax for the values passed to most of the M3_CONFIG options is % "@pgm@arg1@...@argn@" where "@" is an arbitrary character. The % separator character must begin and end the value. % Where is the driver? M3 = LIB_USE & "/m3" % What are the standard flags? M3OPTIONS = [ "-w1", "-why", "-g" ] M3_CONFIG = [ "-Y0@" & LIB_USE & "/m3c@-t" & TARGET & "@", % --- the Modula-3 to IL compiler "-Y1@/usr/ucb/cc@-pic@", % --- the C compiler, with options to compile Modula-3 code "-Y2@/usr/ucb/cc@-R/usr/ucblib:/usr/openwin/lib:" & LIB_USE & "@", % --- the C compiler, with options to link Modula-3 code "-Y3@/usr/ccs/bin/ar@cr@", % --- program to build library archives "-Y4@/bin/touch@", % --- program to create the table of contents in archives "-Y6@" & LIB_USE & "/m3cgc1@-quiet@-fpic@", % --- the Modula-3 IL to assembly language pass "-Y7@/usr/ccs/bin/as@-s@-K@PIC@", % --- the assembler "-z2@-L/opt/SUNWspro/SC2.0.1@-lm@", % --- libraries systematically linked w ith all programs "-z3" & LIB_USE & SL & "report_coverage.o", % --- library linked in programs compiled with "-Z" coverage option "-z5" & NAMING_CONVENTIONS, % Set the local naming conventions. "-z60", % Set the value of "-z6" to "0" if you want the m3 driver to split % library names and pass -L/-l arguments to the linker; otherwise ("-z61"), % the m3 driver will pass libraries with full path names. "-zA0", % The "-zA" option specifies the maximum size (in megabytes) that Pass0 % is allowed to reach as a persistent server before the driver kills it. % Setting it to zero disables server mode. % NOTE: the current compiler is buggy, leave "-zA" alone! "-zB@-O@", % --- pass 1 options implied by "-O" "-zC@-O@", % --- pass 6 options implied by "-O" "-zD@@", % --- pass 7 options implied by "-O" "-zE@-g@", % --- pass 1 options implied by "-g" "-zF@-g@", % --- pass 6 options implied by "-g" "-zG@@" % --- pass 7 options implied by "-g" ] proc build_standalone() is % --- reset the linker to avoid shared libraries. M3_CONFIG += "-Y2@/usr/ucb/cc@" M3_CONFIG += "-Y6@" & LIB_USE & "/m3cgc1@-quiet@" M3_CONFIG += "-Y7@/usr/ccs/bin/as@-s@" M3_CONFIG += "-z61" end proc build_shared() is % --- reset the linker to use shared libraries. end %-------------------------------------------------------------------- hooks --- % These are the "last chance" hooks that are called each time a library % or program is built. They might build shared libraries or strip % executables... proc library_hooks(x) is local lib_a = format ("lib%s.a", x) local lib_so = format ("lib%s.so", x) % version number is optional if defined ("_all") if stale (lib_a, lib_a) write ("missing ", lib_a, ": not building ", lib_so, CR) else if stale (lib_so, lib_a) exec ("/usr/ucb/ld -dy -G -z text -o", lib_so, COMPILE_OBJECTS) end %% _install_file (lib_so, LIB_INSTALL, "0644", "T") install_derived (lib_so) end end deriveds (lib_so, no_extension) end proc program_hooks(x) is end %---------------------------------------------------------------- bootstrap --- % These functions are used during the bootstrap process % if defined("_bootstrap") BOOT_CC = "/usr/ucb/cc" BOOT_ASM = "/usr/ccs/bin/as" BOOT_AR = "/usr/ccs/bin/ar cru" BOOT_RAN = "touch" BOOT_LINK = "/usr/ucb/cc" include("COMMON.BOOT") end %------------------------------------------------------------- installation --- % "install_file" is called during an "m3build install" for % each file that neededs to be externally exported. readonly proc install_file (src, dest, mode) is % exec ("install -c -m", mode, src, dest) exec ("cp -p", src, dest) end %---------------------------------------------- the rest of the environment --- include ("COMMON") -- * Frederic.Devernay@sophia.inria.fr * * Projet ROBOTVIS -- INRIA Sophia Antipolis -- FRANCE * ======================================================================= 36 === Date: 06 Sep 1994 08:59:20 GMT From: baechler@lia.di.epfl.ch (Emmanuel Baechler) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? There is another aspect of this question which hasn't been discussed yet: the e ffect on modelization. Most of the object systems, either with compile-time or run-time checks, create objects which are static in their properties throughout their all life. They will have the same (according to the lisp vocabulary) instance variables, methods ancestors and so on. Some systems, like CLOS, enable some runtime modification of part these properties. Most, especially the ones with static typing, don't. Now, if you consider the modelling of the real world, there are however many cases where this where this limitation is real troublesome. Consider the very simple (and really not new) example of the modellization of people status throughout their whole life: A youg child has a name, a first name a birthdate and can do a few things. When (s)he starts school, he may student a student number, go to a given school, and follow several given courses teached by given professors. He may take exams, get promoted and so on. When (s)he starts the university he will probably lose its previous student number and get a new one, attend a given faculty, have the choice between many options and so on. Of course if (s)he doesn't go to thje university, he'll follow a totally different path with totally different properties and actions. And this will continue for his (her) whole life. Some of these changes will superpose with other properties (for example, being both a doctor and having a Phd), while other will cancel previously valid propreties (for example leaving the universtiy after graduating and get a job). I have difficulties to see how an object system, either statically or dynamically typed can model this in a quite natural and managable way. Of course there are kludges. On can for example, create instances containing all the possible porperties right at the start, but checking that only the relevant ones (at a given time) are used will be problematic. Such instances will probably be huge while they'll contain much less information at a given time. I can also imagine specialized functions for each possible transition creating a new instance of the appropriate class, transfering the relevant information and destroying the previous one. I fear however that the number of these functions will be so high that the system will soon become unmanagable. It's however true that a meta-object protocol, as the one of CLOS, may help a lot in this domain. The most natural tool that I can imagine is a frame system, which is even more dynamic than dynamically type object systems. I am however not sure that this is the only (and even the best) solution. Any other idea, comment? -- Emmanuel Baechler. | Tel.: ++41-21-314-29-06 Etat de Vaud | Fax: ++41-21-314-45-55 Service des Hospices Cantonaux | e-mail: baechler@lia.di.epfl.ch Office Informatique | or: baechler@liasun6.epfl.ch Les Allieres | Standard Disclaimer CH-1011 Lausanne Switzerland Political correctness = the replacement of historical biasses in the language by new ones that are more suitable for the speaker's purposes Gun control laws don't die, people do. Ban the bomb. Save the world for conventional warfare. ======================================================================= 37 === Date: Tue, 6 Sep 1994 07:31:28 GMT From: skj@oasis.icl.co.uk (Simon Johnston) Subject: Re: DEC's Modula 3 atverm@ecp541.ecn.nl wrote: : In <778611866.AA07139@dialis.hacktic.nl> geert@dialis.hacktic.nl (Geert Bos ch) writes: : | I just ftp-ed Modula-3 from gatekeeper.dec.com and I am wondering if anybod y : | has tips about setting it up. My ultimate wish would be to compile Modula-3 : | from within an OS/2 environment. Does anybody have experience in doing this ? : | : I wish you good luck, you'd be the first to succeed. If you're serious : I advise you to use the EMX 0.8h GCC environment to compile the beast. : You'll need a fair amount of Unix and C knowledge. I gather you've : taken the Linux port as a starting point? : I once had the same plans as you, but I really don't have the time to : do it. I remember reading some message of another brave person about : two months ago who reported he got quake to work and he posted the I am that 'brave' person, I got quake working, and produced some OS2 template files which appear to work with the EMX 0.8hpl9 environment. The main problem with this was that the OS2 command line cannot take all those file names on the link/lib command name. The answer was to produce a response file for the librarian and pass it on the command line, for the link phase produce a lib first and then link the lib. : diffs needed for it. I didn't hear from it any more. If you make progress, : I am very much interested and would like to be kept informed, and I'm sure I have had to stop work on this as my *real* work demanded the time and disk space I was using. If I get back to it I will of course let the group know. : much others are because there have been quite some requests for an OS/2 : port in the recent year! Thanks for remembering the post, noone else seemed to have noticed the post go by, I thought I was all alone out here! MODULE Sig; FROM ICL IMPORT StdDisclaimer; FROM Interests IMPORT Modula2, Modula3, Linux, OS2; BEGIN (* ------------------------------------------------------------------------. |Simon K. Johnston - Development Engineer |ICL Retail Systems | |------------------------------------------------------|3/4 Willoughby Road| |Unix Mail : S.K.Johnston.bra0801@oasis.icl.co.uk |Bracknell, Berks | |Telephone : +44 (0)344 476320 Fax: +44 (0)344 476084|United Kingdom | |Internal : 7261 6320 OP Mail: S.K.Johnston@BRA0801|RG12 8TJ | `------------------------------------------------------------------------ *) END Sig. ======================================================================= 38 === Date: 6 Sep 1994 07:40:01 GMT From: mbk@inls1.ucsd.edu (Matt Kennel) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? Richard Bunbury (bunbury@vienna.eiffel.com) wrote: : - (A) Proponents of Smalltalk and other dynamically typed languages : claim that static typing is too constraining. : - (B) Smalltalk does not (in general) support multiple inheritance. : - (C) It is indeed true that without multiple inheritance static : typing would be unacceptably constraining (claim A). : - (D) But examination of the typical examples used to support claim : A show, in our opinion, that the unacceptable restrictions are due : to the absence of multiple inheritance, and that with MI static : typing is in fact not a limitation. Where does this leave Modula-3? -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego -*** AD: Archive for nonlinear dynamics papers & programs: FTP to -*** lyapunov.ucsd.edu, username "anonymous". ======================================================================= 39 === Date: 6 Sep 1994 10:50:47 GMT From: hanssgen@iraul1.ira.uka.de (Stefan Haenssgen) Subject: Q: Modula-3 / GCC Backend for KSR-1? Hello world, I'm looking for an implementation of Modula-3 for the KSR-1 parallel computer. Since Modula-3 directly uses the GNU cc's backend, a gcc backend description for the KSR-1 would be equally helpful. Modula-3's threads should map well to the KSR's thread library, and since Modula-3 is freely available, a version for the KSR-1 would make an excellent parallel program / compiler experimentation environment (which is exactly what I'm planning to do ;-) Please send all replies by Email to haenssgen@ira.uka.de - I'll post a summary if there is enough interest. Thanks a lot in advance Stefan PS: I want to use the latest version of Modula-3, so taking version 2.x and compiling the resulting C code on the KSR is just a last resort. PPS: Followup to comp.lang.modula3 -- ,-----,------,--,--, Stefan Haenssgen, Comp Sci, Uni Karlsruhe, Germany / / / / / Email: haenssgen@ira.uka.de or haenssgen@acm.org / ---/-, ,-/ / / IRC: sth Phone: +49/721/593910 Fax: hoo nose / / / / / / Snail: Nuitsstr. 2c, D-76185 Karlsruhe, Germany /--- / / / / / / / / / / / / / "Use the SOURCE, Luke!" (Return of the RedEye Nights) '-----' '--' '--'--' "I feel a great disturbance in the SOURCE" ======================================================================= 40 === Date: Mon, 5 Sep 1994 23:10:08 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? "William D. Gooch" writes: >On Thu, 1 Sep 1994, Ian Joyner wrote: >> And it is good >> programmers that know their own thought processes that admit we need >> this kind of mechanical aid. >So your assertion is that in order to be a "good programmer" one is >required to "admit that we need this ... aid." I think not. Actually, I find that the best programmers know they need help, and look for any they can get. When discussing one's skills at programming, the best tack is humility. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ ======================================================================= 41 === Date: Tue, 6 Sep 1994 13:33:10 GMT From: grp@dmu.ac.uk (Graham Perkins) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] In article <34ac8g$rlc@library.erc.clarkson.edu> satish@sun.mcs.clarkson.edu (S atish Thatte) writes: > >Richard, perhaps you can post some examples where a C++ program >*requires* casting that a corresponding Eiffel program avoids >by some mechanism *other than* assignment attempt or covariance in >subclasses (which in a way are the same thing). > >I am not saying such examples don't exist, but having heard this >argument going on for a long time, I still haven't seen any examples >that pinpoint the superiority of Eiffel typing over C++ in a way that >is not subsumed by RTTI features in forthcoming versions of C++. > class LIST[T] feature head : T tail : like Current put( x:T ) is do tail := clone( Current ) head := x end empty : BOOLEAN is do Result := void( tail ) end end class ORDERED_LIST[ T->COMPARABLE ] inherit LIST[T] rename put as cons end LIST[T] redefine put end feature put( x:T ) is do if empty then cons( x ) elsif x < head then cons( x ) else tail.put( x ) end end end Here, the use of type anchoring allows me to define a recursive data type (list = head:T plus tail:like Current) which I can also derive more recursive data types from. You try writing the above scheme in C++ without using any casts. I'll let you off with a non-generic solution, since using templates AND inheritance in the same C++ data structure leads to a horrible, unreadable mess. ======================================================================= 42 === Date: Tue, 6 Sep 1994 01:18:30 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] bunbury@vienna.eiffel.com (Richard Bunbury) writes: >From Robert Martin : >>Casts in C++ are [] almost always unecessary and unwanted. There are >>times when dynamic_cast is useful, but this is more a test and less a >>cast. >>If we ignore novices, Casts are most often used in C++ by people who >>are used to programming in dynamically typed languages (like >>Smalltalk). > [The place marked [] contained the word "not" but > I assume this is a typo.] That is correct. >Well, this is not what we hear from the field - i.e. from disgruntled C++ >programmers, an ever fresh source of new Eiffel fans. That some people are disgruntled with C++ does not surprise me. It will surprise me, however, if a large portion of them do not become disgruntled over Eiffel as well. This has nothing to do with the quality of either language. Any C++ programmer becomming disgruntled about casts did not take the time to learn the language as well as he should. And so, will likely not take the time to learn Eiffel as well as necessary... This is just my opinion. >Or from the >literature either. Just today we received the September 1994 issue >(volume 12, number 9) of "The C/C++ Users Journal"). And sure enough, >the longest article in the issue is entitled "Code Capsules: Conversions >and Casts", by Chuck Allison (perhaps a "Novice"?). Here is a quote from >that article: I know not whether Chuck Allison is a novice. >-------- Begin quotation -------------------------------------- > A cast is your way of telling the compiler to allow you to do something > potentially dangerous, because you think you know what you're doing. Too > often, though, you don't know what you're doing (no offense!), and you > spend days tracking down an insidious pointer conversion error or similar bug. Translation: don't use casts. It seems Chuck is not a novice. > It's interesting that programmers > use a single cast notation for so many different purposes: > + to reinterpret the bit pattern of an object > + to widen or narrow a value > + to traverse a class hierarchy > + to cast-away `const' or `volatile' > + to do some implementation-dependent magic >-------- End quotation -------------------------------------- Does he quote figures here? How many C++ programmers are actually using these techniques? I'll tell you that I think it is quite a few, and I believe that they are novices. It seems very unlikely to me that a seasoned C++ programmer would make rampant use of casts. >Frankly, to an Eiffel programmer, this all sounds pretty repulsive. I assume you meant to say: "To this Eiffel programmer". Lets not cast people into molds based upon the computer languages they use. The rule about casts applies in human relations as well as in C++. >In >particular we do not think that object-oriented software construction >should be about "magic". Nor do I. Nor do a great many of the C++ programmers that I deal with regularily. In fact, I know of no programmer who thinks that sofware should be about magic. So, this is not an exclusive virtue of "the Eiffel programmer." >But even if you find nothing wrong with this, the scope of things for >which the author cites a need to use casts in C++ seems rather broad, >supporting the obvious observation of my earlier message that practical C++ >programming requires casting. No. As I read your quote (I did not read the article) the author was saying that casts were "used" for these things. Not that they must be, or should be. In fact, they needn't and shouldn't be. >In fact, the same article by Mr. Allison tells us that "C++ defines four >new cast mechanisms". Now if casts are not needed, how come there are >four more kinds? The four new kinds are to be used instead of the old more general kind. Specifically they are: "dynamic_cast" which is equivalent to "?=" in Eiffel. (so if you call this a cast, then Eiffel has a cast too!). "const_cast" which may only change the 'const' attribute of a type. "static_cast" which is used to make "legal" type changes such as int -> long, and 'reinterpret_cast' which is like the old very general C cast. Of these 4, dynamic_cast and static_cast are completely type safe. Invalid conversions cannot be made. I do not recommend that the others be used in most cases. These new casts were added so that the kinds of casts which are 'safe' could be seperated from those that weren't. i.e. you can use a static_cast as follows: double half = 1/static_cast(2); So. These are not 4 new kinds of casts. They are 4 divisions of the old kind of cast. At least one division of which is present in Eiffel. >To repeat comments made in an earlier message: in Eiffel, you can >do everything WITHOUT casts, in a type-safe manner. The key is a >flexible enough type system. And to repeat my own statement. You can do everything in C++ without casts. Casts should be avoided. It is only relatively inexperienced C++ programmers who rely on them with any regularity. >By the way, the lead article in the same issue of the C/C++ Users Journal >is entitled "Using Windows Memory Management", by David Singleton. >It comes with a program listing. Here are a few pretty typical lines >from that listing: > FP_FHB current_block_pointer = (FP_FHB) p_fhb ; > ... > _segment cur_seg = (_segment) SELECTOROF (this) > ... > (WORD) (this_block -> in_use_list) >Looks like some casting is going on. But perhaps the author is a >novice, or a freshly retrained Smalltalk programmer? First of all, this looks like C code, and we were dicsussing C++. Casts are much more prevalent in C than in C++ because C is not a strongly typed language. Thus casts are performed to convert types. (generally to make sure that they fit in the right size integer) In fact, many C programmers get into the habbit of using casts, even when they aren't necessary. I have even seen C coding standards that dictate that "all function arguments and return types will be cast". I have always thought this practice to be very silly. Some old C programmers carry this practice into C++ when they first start using it. However, they should stop using the casts before long. C++ is strongly typed, and the casts are not necessary. Now, let me quote Stroustrup from "The design and evolution of C++": "I consider most casts in C++ progarms signs of poor design. Some casts are essential, but most aren't" -- pg 170 -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ ======================================================================= 43 === Date: Tue, 6 Sep 1994 13:59:07 GMT From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: DEC's Modula 3 I would be interested in porting "the beast" to SVR4/386 and FreeBSD/NetBSD. When I take the Linux port as a starting point, what is necessary to port? I've looked at the various files in BOOT-Linux.tar and found lots of assembler code. What is necessary to do the port? BTW, in which way vary gcc and m3gcc? The assembly code is simply the Modula-3 compiler code cross-compiled from another platform. You first need to setup the compiler on one of the existing platforms (LINUX, SPARC, DEC, HPPA...). Then you have to modify the source files in order to get it working for your new platform. This includes setting up gcc as a cross-compiler for the new platform, adapting the OS interface for a different UNIX flavor and finally the small system dependent portion of the run time library. -- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 44 === Date: 06 Sep 1994 23:00:56 GMT From: tmb@arolla.idiap.ch (Thomas M. Breuel) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] In article <1994Sep6.133310.16406@dmu.ac.uk> grp@dmu.ac.uk (Graham Perkins) wri tes: |class LIST[T] |feature |head : T |tail : like Current |put( x:T ) is | do tail := clone( Current ) | head := x | end |empty : BOOLEAN is | do Result := void( tail ) | end |end | | |class ORDERED_LIST[ T->COMPARABLE ] |inherit LIST[T] rename put as cons | end | LIST[T] redefine put | end |feature | |put( x:T ) is | do if empty then cons( x ) | elsif x < head | then cons( x ) | else tail.put( x ) | end | end |end | |Here, the use of type anchoring allows me to define a recursive |data type (list = head:T plus tail:like Current) which I can |also derive more recursive data types from. You try writing |the above scheme in C++ without using any casts. I'll let |you off with a non-generic solution, since using templates |AND inheritance in the same C++ data structure leads to a |horrible, unreadable mess. This code seems to have several serious problems. In terms of semantics, we have two major problems. First, it treats ORDERED_LIST as a kind of LIST, but ORDERED_LIST is _not_ a kind of list, in the sense that it is often incorrect to substitute an ORDERED_LIST for a LIST. Second, it associates the type of list with each cons cell, while being ordered is a property of the whole list. In terms of performance, we also have several important problems. First, the list contains a hidden variable of type T. If T is associated with scarce resources (memory, file descriptors, etc.), this may be a problem. Second, each cons cell contains a pointer to a virtual function table, which wastes space (in the worst case, 50% per list element), and, as we saw above, this space isn't even put to good use. Third, the use of "clone" and "like" seems to essentially preclude a non-pointer implementation of type LIST. In any case, the crucial point you seem to be driving at is that it may be difficult to express the notion of "like Current" in C++ without casts. Well, a typesafe C++ solution without casts is given below; for the purposes of illustration, it lets OrderedList inherit from List, even though I think that that's actually wrong for these specific datatypes. It also assumes a C++ implementation with garbage collection. The C++ version is longer than the Eiffel version for several reasons. First, the C++ implementation is considerably better, in that it doesn't allocate memory for an empty list, carries around no hidden variable of type T, and doesn't have any additional overhead associated with the individual cons cells due to method tables. No doubt, some of these improvements could also be incoporated into the Eiffel version. Second, C++ forces you to be more explicit about what "like Current" means; in this case, it means that List and OrderedList have a common underlying representation, which is interchangeable. That fact is expressed through the introduction of the common Cons class for the representation and the two additional construction/assignment operations in class OrderedList. Neverhteless, inheritance is used in exactly the same way as in the Eiffel version: all operations on List are inherited by OrderedList. Third, C++ requires the programmer to be more explicit about what assignment and construction means, and that leads to some additional code. Thomas. template struct Cons { T head; Cons *tail; Cons(T head,Cons *tail):head(head),tail(tail) {} }; template struct List { Cons *data; List():data(0) {} List(Cons *data):data(data) {} void insert(T x) {data = new Cons(x,data);} bool empty() {return data==0;} T head() {assert(data); return data->head;} List tail() {assert(data); return List(data->tail);} }; template struct OrderedList:List { OrderedList() {} OrderedList(Cons *data):List(data) {} OrderedList &operator=(OrderedList &list) {data = list.data; return *thi s;} OrderedList(List list):List(list.data) {} OrderedList &operator=(List &list) {data = list.data; return *this;} void insert(T x) { if(!data || data->head >= x) { data = new Cons(x,data); return; } Cons *p = data; while(p->tail) { if(p->tail->head >= x) { p->tail = new Cons(x,p->tail); return; } p = p->tail; } p->tail = new Cons(x,p->tail); } }; ======================================================================= 45 === Date: 6 Sep 1994 21:25:35 GMT From: madon@didec22.epfl.ch (Dominik Madon) Subject: Re: Success - 3.3 on NeXT Thomas Neumann (tom@smart.bo.open.de) wrote: : I've just succeeded in bootstrapping release-3.3 on a NeXT/m68k : running NeXTSTEP 3.2. Great ! : To the SRC folks: Are you interested in my modifications ? : Maybe it would be a good idea to upload a pre-compiled, ready to : execute NeXT version somewhere ? Good idea. Is it difficult to compile an intel version ? I have NS/I 3.2. Dominik ======================================================================= 46 === Date: Tue, 6 Sep 1994 21:52:08 GMT From: haensgen@i43fs1.ira.uka.de (Stefan Haenssgen) Subject: Q: Modula-3 / GCC Backend for KSR-1? Hello world, I'm looking for an implementation of Modula-3 for the KSR-1 parallel computer. Since Modula-3 directly uses the GNU cc's backend, a gcc backend description for the KSR-1 would be equally helpful. Modula-3's threads should map well to the KSR's thread library, and since Modula-3 is freely available, a version for the KSR-1 would make an excellent parallel program / compiler experimentation environment (which is exactly what I'm planning to do ;-) Please send all replies by Email to haenssgen@ira.uka.de - I'll post a summary if there is enough interest. Thanks a lot in advance Stefan PS: I want to use the latest version of Modula-3, so taking version 2.x and compiling the resulting C code on the KSR is just a last resort. PPS: Followup to comp.lang.modula3 -- Stefan U. Haenssgen, IPD, Fakultaet fuer Informatik, Email: haenssgen@ira.uka.d e Universitaet Karlsruhe, Postfach 6980 Phone: +49/721/608-3972 D-76128 Karlsruhe, Germany Fax: +49/721/694092 ======================================================================= 47 === Date: 7 Sep 1994 10:01:02 GMT From: vogler@rzddec1.informatik.uni-hamburg.de (Jens Vogler) Subject: Re: DEC's Modula 3 Robert Schien wrote: [ ... ] >I would be interested in porting "the beast" to SVR4/386 and FreeBSD/NetBSD. >When I take the Linux port as a starting point, what is necessary >to port? I've looked at the various files in BOOT-Linux.tar and found >lots of assembler code. What is necessary to do the port? >BTW, in which way vary gcc and m3gcc? >Robert One NetBSD port? Sounds interesting ;-) !!! Please tell me more! Yours etc. Jens "ABert" Vogler P.S.: Sorry, I cannot help you. I just try to install NetBSD on my PC -- as you can see, I cannot be an advanced coder. -- V V TTTTT CCCC Jens Vogler -- vogler@informatik.uni-hamburg.de V V T C Universitaet Hamburg (BR Deutschland) V V T C VirusTestCenter V T CCCC Amiga-Gruppe ======================================================================= 48 === Date: Wed, 07 Sep 94 02:28:45 EST From: viper@cml.com Subject: HELP! I am writing a report on careers in the programming field and would like your help. If you could answer some or all of these questions it would be of great help. Thank you in advance. 1. What kind of education do you need to get into the programming field? 2. What are the languages to learn? 3. Who are the companies to work for? 4. What do you think are the coming things in programming? 5. In what order do you think a person should learn the different languages? 6. What is the best software in each language? 7. Which school is the most respected in the Industry? 8. In your opinion, what is the best way to get into the Industry? 9. Do you still try to learn different languages, or learn more about the one that you use? 10. Do you see a single language becoming the standard or do you see another language coming in to the field? E-Mail viper@cml.com * SLMR 2.1a * It's not the money I want, it's the stuff!! ComputerLink 'the easy way to bbs' (416) 233 - 7150 ======================================================================= 49 === Date: 7 Sep 1994 02:07:48 GMT From: cal@hk.super.net (Lindon Parker) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] Graham Perkins (grp@dmu.ac.uk) wrote: [discussion deleted] : > : class LIST[T] : feature : head : T : tail : like Current : put( x:T ) is : do tail := clone( Current ) : head := x : end : empty : BOOLEAN is : do Result := void( tail ) : end : end : class ORDERED_LIST[ T->COMPARABLE ] : inherit LIST[T] rename put as cons : end : LIST[T] redefine put : end : feature : put( x:T ) is : do if empty then cons( x ) : elsif x < head : then cons( x ) : else tail.put( x ) : end : end : end : Here, the use of type anchoring allows me to define a recursive : data type (list = head:T plus tail:like Current) which I can : also derive more recursive data types from. You try writing : the above scheme in C++ without using any casts. I'll let : you off with a non-generic solution, since using templates : AND inheritance in the same C++ data structure leads to a : horrible, unreadable mess. Gentlepersons, All this is, I am sure, very interesting. But before responding further to this thread please note that in many peoples opinions it may now seem to be a discussion about C++, with some reference to Eiffel. Please also note the cross-posting going on. Its been a long time in this thread since I've seen Smalltalk, Objective-C or Modula-3 mentioned, thus I suggest you carefully consider deleting those news-groups you no longer consider relevant. I am sure those in c.l.smalltalk etc. can move to c.l.c++ to follow if they require.... regards, Lindon Parker. ======================================================================= 50 === Date: Wed, 7 Sep 1994 16:53:51 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] grp@dmu.ac.uk (Graham Perkins) writes: >[...] since using templates >AND inheritance in the same C++ data structure leads to a >horrible, unreadable mess. It does? Graham. Perhaps, for the benefit of those of us who do not read Eiffel, you can post your example in C++ with casts, and then we can try to remove the casts.... -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ ======================================================================= 51 === Date: Wed, 7 Sep 1994 17:02:47 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] >grp@dmu.ac.uk (Graham Perkins) writes: [presents a challenge, Translate this Eiffel code into C++ without Casts] >|class LIST[T] [code elided] tmb@arolla.idiap.ch (Thomas M. Breuel) writes: >Well, a typesafe C++ solution without casts is given >below; [code elided] I think this particular bit of language war has illustrated the salient principle of all language wars: "The only valid critic of a language, is an expert in that language." Corrollary: "If you don't code in it *alot*, then don't complain about it." -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ ======================================================================= 52 === Date: Wed, 7 Sep 1994 16:51:00 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] fabre@osf.org (Christian Fabre) writes: >In article <34ac8g$rlc@library.erc.clarkson.edu>, > satish@sun.mcs.clarkson.edu (Satish Thatte) writes: >|> From bunbury@vienna.eiffel.com (Richard Bunbury): >[deleted] >|> Richard, perhaps you can post some examples where a C++ program >|> *requires* casting that a corresponding Eiffel program avoids >|> by some mechanism *other than* assignment attempt or covariance in >|> subclasses (which in a way are the same thing). >Too bad that you remove covariance from the argument. In my project, >covariance is the perfect technique: 99.9% of the casts in my C++ code >would disapear in Eiffel. But these cast ought to be dynamic_casts since, in C++, you are downcasting a base argument to a specific derived class. This amounts to an assignment attempt (?=) in Eiffel. Thus, 99.9% of the casts in your C++ programs are using a structure that Eiffel admits as necessary. However, this 99.9% must be a pretty small absolute number. In my experience with C++ the need for covariance (of argument types) is pretty rare. I use it specifically for comparison operators, and probably nowhere else. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ ======================================================================= 53 === Date: Wed, 7 Sep 1994 16:44:34 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? baechler@lia.di.epfl.ch (Emmanuel Baechler) writes: >There is another aspect of this question which hasn't been discussed yet: the effect >on modelization. >Most of the object systems, either with compile-time or run-time >checks, create objects which are static in their properties throughout >their all life. >Now, if you consider the modelling of the real world, there are however >many cases where this where this limitation is real troublesome. >A youg child has a name, a first name a birthdate and can do a few things. >When (s)he starts school, he may student a student number, go to a given >school, and follow several given courses teached by given professors. He may >take exams, get promoted and so on. >When (s)he starts the university he will probably lose its previous student >number and get a new one, attend a given faculty, have the choice between many >options and so on. Of course if (s)he doesn't go to thje university, he'll >follow a totally different path with totally different properties and actions. >And this will continue for his (her) whole life. This is one of the difficulties intrinsic with the notion of "real world modeling". In fact, our models must be limited because we cannot fully incorporate the real world into them. We can "model the real world", but only if we realize that those models, no matter how complex they are, will always fail to capture the "real world" at some level or another. Now, the fact that objects change characteristics over their lifetime is a common problem. And there are dozens of ways to deal with it. Many methodologies are based upon the notion of the "state" of an object. e.g. these methodologies model objects as presenting only certain interfaces depending upon their current state. Other mechanisms try to capture the changing attributes into classes which the primary class can contain. e.g. A person class may contain a student class. There may be many derivatives of the student class, one for each grade level. The person class delegates certain of its interfaces to its contained student class... Yet all of these are weak models of the true real world. There is, after all, a significant mismatch between the cybernetic world, and the real world. The models within the computer must be quantized in ways that are absurd in the real world. So the models are always inadequate in the general case. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ ======================================================================= 54 === Date: Tue, 6 Sep 1994 13:09:43 GMT From: jcm@hgc.edu (James McKim) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] In article <34ac8g$rlc@library.erc.clarkson.edu> satish@sun.mcs.clarkson.edu (S atish Thatte) writes: >From bunbury@vienna.eiffel.com (Richard Bunbury): >> From Robert Martin : >> >>>If we ignore novices, Casts are most often used in C++ by people who >>>are used to programming in dynamically typed languages (like >>>Smalltalk). >> >> Well, this is not what we hear from the field - i.e. from disgruntled C++ >> programmers, an ever fresh source of new Eiffel fans. >[extract from C/C++ Journal and comments by RB eleted] > >Richard, perhaps you can post some examples where a C++ program >*requires* casting that a corresponding Eiffel program avoids >by some mechanism *other than* assignment attempt or covariance in >subclasses (which in a way are the same thing). Hmmm... If we travel back in time a few years we might find the following analagous request. "Please show me an example in language X that "requires" a "go to" which the corresponding code in language Y avoids by some mechanism other than an "if..then" or "while..do" (which in a way are the same thing). People who use Eiffel are willing to trade off a certain amount of potentially dangerous low level flexibility for safety and high level expressibility. > >I am not saying such examples don't exist, but having heard this >argument going on for a long time, I still haven't seen any examples >that pinpoint the superiority of Eiffel typing over C++ in a way that >is not subsumed by RTTI features in forthcoming versions of C++. > >Satish Regards, -- Jim -- *------------------------------------------------------------------------------ * Jim McKim (203)-548-2458 In exactly 3.2 seconds it will be a few Internet: jcm@hgc.edu minutes to 5:00. ======================================================================= 55 === Date: Mon, 05 Sep 94 22:52:22 GMT From: michely@deliah.nemeter.dinoco.DE (Joachim Michely) Subject: Re: Logitech M2 v4.0 Student Pak In article <3499ib$iko@news.delphi.com> j_mcarthur@BIX.com writes: > >David Priest asks >> I can get Logitech's Modula-2 v4.0 student package. Is it worth it? I >>currently use FST's Modula, and have had a great time with it: I think >>I should be buying a package. My choices seem to be FST and Logitech >>(or, I suppose, move on to Modula-3)... >> >> So the question boils down to: is the Logitech student package ag >>any good? Bugs? How's the development environment? And does it >>have object extensions like FST does? > >I don't have any experience with the student package. I have the "normal" >package. The Logitech 4.0 package is a very good development platform. >There are only two problems with it. First it is not very flashy. >Personally I prefer this. I run from the command line. Second, and much >more serious, the product is orphaned. I think the Student edition is the "normal" edition maybe without the library source ( you don't need them ). >Symantech purchased Multiscope a while ago. Symantech decreed that ALL >development would be done in C++. So this killed all support for the very >good Modula 2 product. > >Actually the Logtech 4.0 package uses a slighly modified version of the >Stonybrook compiler. Stonybrook is still around. So you can buy the >compiler directly from them. The newest release of the Stonybrook compiler >is STILL in beta test (how long has it been?). Logitech V4.0 has the Stonybrook compiler engine, but has a differnet set of libraries. The libraries are Logitech conform, so that a Logitech 3.x user can switch to V4.0 without great pain. >The only bugs I have found in the Logitech 4.0 package relate to LONGCARD. >I have found 4 separate bugs in the way the compiler handles arithmatic >with LONGCARD. LONGINT works, but LONGCARD is broken. All bugs are now well defined and described ( also with workarounds ). The Version 4.0 will be suported by : Terra Datentechnik, Zurich, Switzerland and they fixed nearly all bugs ( LONGCARD too ). They have a good team of developers and will support ( and bug fix ) the compiler in the future. You can also buy the Logitech Version 3.4 which is bug FREE ( from Terra ). >The other option is Clarion's TopSpeed compiler. Again it is not flashy. >It does have object oriented extensions. There is a student version of the >compiler that gets very good reviews (it is based on version 1.17 while the >current release is 3.10). > >In my opinion, Modula-3 is not quite ready for "prime time". I am spoiled. > I got used to reasonably fast compiles and links with Modula-2. Modula-3 >generates C code which then must be compiled and linked. This is a VERY >SLOW process. So until someone has a native code Modula-3 I will not use >it (I just don't have the time to wait around for the slow compiler and >linker). > >The other option is to go to Oberon-2. Oberon is the successor to >Modula-2. Oberon-2 is the sucessor to Oberon. There are several very >interresting packages available for Oberon. One of the more interresting >is the OM2 compiler. It comes with a full Modula-2 and Oberon-2 compiler. >The compiler generates 32 bit code. It looks very good. Unfortunately you >cannot link in forign modules. I need the ability to link in forign >modules (e.g. the Paradox Engine or CodeBase). There is also the Window's >based POW. This looks very good also. >---- > Jeffrey M\kern-.05em\raise.5ex\hbox{\b c}\kern-.05emArthur > a.k.a. Jeffrey McArthur email: j_mcarthur@bix.com > phone: (301) 210-6655 > fax: (301) 210-4999 > home: (410) 290-6935 > >The opinions express are mine. They do not reflect the opinions >of my employer. My access to the Internet is not paid for by my >employer. > -- Joachim Michely Voice/Fax : ++49 (0)2241 337938 Internet : michely@nemeter.dinoco.DE CompuServe : 100024,2476 ======================================================================= 56 === Date: 8 Sep 1994 00:50:28 GMT From: vbidarko@classic4.cs.ttu.edu (Vinod Bidarkoppa) Subject: QUESTIONNAIRE ON OOAD NOTE : This is for people who are involved directly or indirectly with Object oriented software development. Please fill up the required information and mail it to vbidarko@cs.ttu.edu. Students and faculty are also welcome to reply. Thanks in advance. *************************************************************************** Questionnaire on requirements of Object Oriented Analysis and Design Methodo logy INTRODUCTION This survey is to obtain information from the real world regarding the requirements of OOAD methodology. This is a part of masters thesis research in the Computer Science department at the Texas Tech University. All the information will remain anonymous. The information from the questionnaires will be used to specify a set of practical requirements for an OOAD and also to evaluate the existing methodologies based on this. Completed questionnaires may be sent by post or e-mail to: Vinod Bidarkoppa Department of Computer Science Texas Tech University Mail Stop 3104 Lubbock, TX 79409 E-mail : vbidarko@cs.ttu.edu bed85@ttacs1.ttu.edu ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- ----------------------- 1. GENERAL INFORMATION 1.1 Organization a) Name : b) Address : c) City : d) State : 1.2 Area(s) of Company business ( Mention areas which use OO ) 1.3 Personal Information a) Name : b) Your role in the organization : 1.4 OO Methodologies used at present in your organization ( e.g. Booch, Coad and Yourdon, Shlaer and Mellor,OMT, Wirfs-Brock) an d in which projects / applications. e.g. G. Booch (1994 ed.) Realtime Process Control 2. METHODOLOGY REQUIREMENTS ( Please rate one of the categories from A to E. ( A= Extremely Important, B= Important, C= Not so important, D= Unimportant, E= No comment) 2.1 Structural Concepts 2.1.1 Degree of OO support 1. The methodology should support the usual meaning of the terms object (instance) and class. ( ) 2. The class should be described in terms of its distinct parts: an interface and body. ( ) 3. Encapsulation and information hiding should be supported by the methodology ( ) 4. The methodology should support metaclasses ( ) 2.1.2 Relationships 1. The methodology should support : i) Single inheritance ( ) ii) Multiple inheritance ( ) iii) Aggregation (container ) ( ) iv) Associative ( ) v) The associative relationships should include cardinalities ( ) 2. The methodology should include / distinguish subclassing ( inheritance implementation with redefinition and / or restriction as well as addition ) and subtyping ( just addition). ( ) 2.2 Behavioral Concepts 2.2.1 Instances 1. The methodology should provide facility for dynamically creating and destroying objects. ( ) 2. The methodology should support i) Notion of object state. ( ) ii) Export Control / Visibility e.g. Private, Protected, Public ( ) iii) Persistent Objects ( ) iv) Concurrent objects ( ) v) Embedded Objects ( ) vi) Active ( instances executing in parallel) and passive (executing in serial with others) instances ( ) 2.2.2 Messages or events 1. The methodology should facilitate message passing that involve : i) Static Binding ( ) ii) Dynamic Binding ( ) 2. The methodology should support the following kinds of polymorphism : i) Inclusion ( ) ii) Operational ( ) iii) Parametric ( ) 3. The methodology should include the following modes of communication i) Synchronous ( ) ii) Asynchronous ( ) note : Synchronous is where the sender suspends execution till the receiver processes the message and asynchronous is where the sender continues processing. 2.3 Process 1. The methodology should prescribe steps / guidelines for identifying : i) Semantic (Abstract) classes ( ) ii) Attributes ( ) iii) Methods ( ) iv) Allocating attributes and methods to classes ( ) 2. The methodology should specify guidelines for identifying the following relationships : i) Generalization ( ) ii) Aggregation ( ) iii) Association ( ) iv) Cardinalities ( ) 3). The methodology should be able to specify dynamic behaviors through the following : i) Message connection ( ) ii) Instance connection ( ) iii) Object interaction diagrams ( ) iv) State machine ( ) v) Event and state generalization ( ) vi) Interactions within the state ( ) vii) Timing diagrams ( ) viii) Formalization of abnormal behavior ( ) 4). The methodology should prescribe guidelines to identify and decomp ose : i) Structural complexity ( ) ii) Dynamic complexity ( ) 2.4 Design features 1. The methodology should prescribe guidelines for the following : i) Specifying system architecture ( ) ii) Specifying and integrating interface classes for human interaction ( ) iii) Specifying and allocating tasks / processes to processors ( ) iv) Specifying and integrating classes for database management ( ) v) Data structures and pseudo code for the application classes ( ) vi) Refinement of overall analysis and design in scope of all the new classes added ( ) 2. The methodology should prescribe OOSE features regarding : i) Release planning ( ) ii) Work products ( deliverables) review ( ) iii) Incremental development ( ) 2.5 Representation 2.5.1 Static Views 1. Class and Object ( ) 2. Attributes ( ) 3. Methods ( ) 4. Generalization ( ) 5. Aggregation ( ) 6. Cardinalities ( ) 2.5.2 Dynamic views 1. Instance connection ( ) 2. Visibility ( ) 3. Message connection ( ) 4. Control / timing ( ) 5. Concurrency ( ) 6. Object interaction diagrams ( ) 7. State charts ( ) 8. Nested states ( ) 2.5.3 Constraints 1. On structure ( ) 2. On behavior ( ) 2.5.4 Complexity 1. Static structure ( ) 2. Dynamic behavior ( ) 2.6 Miscellaneous The methodology should : 1. Be Scaleable ( ) 2. Have semantic and syntactic definitions for all notations ( ) 3. Use same notations for analysis and design ( ) 4. Provide deliverables at every stage ( ) 5. Have case tool support for graphical layout ( ) 6. Have case tool support for simulation / code generation ( ) 7. Check for extensibility ( ) 8. Check degree of coupling and cohesion ( ) 9. Check for consistency ( ) 10. Checks for completeness ( ) 11. Prescribe performance evaluation ( ) 12. Prescribe non-graphical specifications for entities discovered at all stages ( ) 3.0 Comments and suggestions ======================================================================= 57 === Date: 8 Sep 94 07:09:24 GMT From: dls@gwd.dsto.gov.au (David Silver) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] grp@dmu.ac.uk (Graham Perkins) writes: >In article <34ac8g$rlc@library.erc.clarkson.edu> satish@sun.mcs.clarkson.edu ( Satish Thatte) writes: >> >>Richard, perhaps you can post some examples where a C++ program >>*requires* casting that a corresponding Eiffel program avoids >>by some mechanism *other than* assignment attempt or covariance in >>subclasses (which in a way are the same thing). >>I am not saying such examples don't exist, but having heard this >>argument going on for a long time, I still haven't seen any examples >>that pinpoint the superiority of Eiffel typing over C++ in a way that >>is not subsumed by RTTI features in forthcoming versions of C++. >> >class LIST[T] >feature >head : T >tail : like Current >put( x:T ) is > do tail := clone( Current ) > head := x > end >empty : BOOLEAN is > do Result := void( tail ) > end >end >class ORDERED_LIST[ T->COMPARABLE ] >inherit LIST[T] rename put as cons > end > LIST[T] redefine put > end >feature >put( x:T ) is > do if empty then cons( x ) > elsif x < head > then cons( x ) > else tail.put( x ) > end > end >end >Here, the use of type anchoring allows me to define a recursive >data type (list = head:T plus tail:like Current) which I can >also derive more recursive data types from. You try writing >the above scheme in C++ without using any casts. I'll let >you off with a non-generic solution, since using templates >AND inheritance in the same C++ data structure leads to a >horrible, unreadable mess. OK, I'll bite. #ifndef LIST_H #define LIST_H #include // C++ standard includes a "bool" type (finally) coming soon! typedef int bool; template class LIST { protected: T *item; LIST *tail; virtual LIST *clone() const { return new LIST(item,tail); } LIST( T* it, LIST *next ) { tail = next; item = it; } public: LIST() { tail = NULL; item = NULL; } virtual void put( T& it ) { tail = clone(); item = ⁢ } bool empty() const { return tail == NULL; } T *getItem() const { return item; } LIST *getTail() const { return tail; } }; template class ORDERED_LIST : public LIST { protected: LIST *clone() const { return new ORDERED_LIST(item,tail); } ORDERED_LIST( X* it, LIST *next ) { item = it; tail = next; } public: ORDERED_LIST() : LIST() {} virtual void put( X& it ); }; template void ORDERED_LIST::put( X& it ) { if (empty() || it < *item) LIST::put( it ); else tail->put( it ); } #endif I've tested it. It works. It's longer than the eiffel version, because eiffel does a few extra things for you that C++ doesn't, and you'll notice that I have cheated, subtly. The ORDERED_LIST<> is still chained together with LIST<> pointers, which means that it would be necessary to use a cast in derived classes to call methods of derived classes on elements in the tail of the list. Now, just because I managed to meet your challenge this time doesn't mean that eiffel isn't a "better" language. I have a feeling it is, although I haven't had much incentive (or time) to switch yet. Probably it is better than C++ more for different reasons than this, though. -- David ======================================================================= 58 === Date: 8 Sep 1994 00:37:04 GMT From: satish@sun.mcs.clarkson.edu (Satish Thatte) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] >From article <1994Sep6.130943.19162@merlin.hgc.edu>, by jcm@hgc.edu (James McK im): > In article <34ac8g$rlc@library.erc.clarkson.edu> satish@sun.mcs.clarkson.edu (Satish Thatte) writes: >> >>Richard, perhaps you can post some examples where a C++ program >>*requires* casting that a corresponding Eiffel program avoids >>by some mechanism *other than* assignment attempt or covariance in >>subclasses (which in a way are the same thing). > > Hmmm... If we travel back in time a few years we might find the following > analagous request. > > "Please show me an example in language X that "requires" a "go to" > which the corresponding code in language Y avoids by some mechanism > other than an "if..then" or "while..do" (which in a way are the same > thing). Not fair! See below. > People who use Eiffel are willing to trade off a certain amount of potentiall y > dangerous low level flexibility for safety and high level expressibility. There is no more safety in assignment attempt and covariance than in dynamic casting using RTTI. High level expressibility, maybe, but the extent to which these features are profitably used (especially covariance) does not seem to warrant the additional headache of global checking, etc., which Eiffel is forced to do. Any comments on the *fragility* of a type system that requires global flow analysis, anyone? Especially if you have used this a lot? Satish ======================================================================= 59 === Date: 8 Sep 1994 16:53:07 +0100 From: tom@smart.bo.open.de (Thomas Neumann) Subject: SRC 3.3 for NeXT now available Precompiled binaries of SRC Modula-3 release-3.3 are now available for NeXTSTEP 3.2 on m68k machines. You may get them by anonymous ftp from ftp.vlsi.polymtl.ca:/pub/m3/next/ The directory holds the following files: next-m68k.boot.tar.gz - This is boot-NEXT.tar.gz from release-3.3, modified so that it actually works. next-m68k.libm3.tar.gz - This is libm3.tar.gz from release-3.3, modified so that it works on NeXT machines. next-m68k.diffs.tar.gz - This are the patches relative to the stock release-3.3 distribution from DEC. It includes a step-by-step description how to apply the patches and boot the compiler. next-m68k.bin.tar.gz - Executables and compiled libm3. Unpack and you are ready to go. (Installs under /usr/local/...) Thanks to Michel Dagenais for providing me the necessary disk space on his ftp server, and to DEC SRC for a wonderful software product. bye -- Thomas ======================================================================= 60 === Date: 08 Sep 1994 20:34:11 GMT From: connolly@ulua.hal.com (Dan Connolly) Subject: Performance of M3 on Intell boxes (Linux, Chicago) I have wondered about the "weight" of the M3 runtime, and after some experience with it, I'm a little concerned. When I start an M3 application on my linux box, the machine whirrs and spins for a bit -- swapping in the shard libs, I guess. And then once the application is running, it pauses every once-in-a-while to show me the star-trek cursor and garbage collect. I noticed a couple things in the Linux release notes: * the exception handling code is based on setjmp/longjmp, rather than the more optimal stack-walking strategy. -- is this likely to impact performance noticeably? -- is the Intel stack sufficiently "self-describing" to allow for the more optimal solution? Would someone with experience in this area make a WAGuess at how much work it would be to implement the stack-walking stuff on the intell platform? If it's a reasonable chunk of work, I'm willing to give it a go. * the garbage collection isn't synchronized with the virtual memory system. Same two questions: -- is this likely to impact performance noticeably? -- Would someone with experience guestimate the amount of work to make the appropriate enhancements? Finally, for some serious speculating: Is anybody working on targeting M3 applications on Chicago-class boxes? Say 486/66mhz 8mb ram, SVGA video... regular "Computer City" boxes by the time next summer comes around? My guess is that Tresle and VBTkit would be a very time consuming port, but the stuff apart from the GUI libraries, while it might be tricky, should be doable by then. Dan -- Daniel W. Connolly "We believe in the interconnectedness of all things" Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010 http://www.hal.com/%7Econnolly/index.html ======================================================================= 61 === Date: 8 Sep 94 09:39:41 From: doug@monet.ads.com (Doug Morgan) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] In article <1994Sep7.170247.21058@rcmcon.com> rmartin@rcmcon.com (Robert Martin ) writes: >>grp@dmu.ac.uk (Graham Perkins) writes: >[presents a challenge, Translate this Eiffel code into C++ without Casts] >>|class LIST[T] >[code elided] >tmb@arolla.idiap.ch (Thomas M. Breuel) writes: >>Well, a typesafe C++ solution without casts is given >>below; >[code elided] >I think this particular bit of language war has illustrated the >salient principle of all language wars: > "The only valid critic of a language, > is an expert in that language." >Corrollary: > "If you don't code in it *alot*, then don't complain about it." Interesting principles, but, in this instance, of questionable appropriateness. Although Thomas Breuel asserted that his code is a "typesafe C++ solution", it actually sidesteps the main point of the original challenge and therefore fails to be a "solution" in any sense. (As it is a major anomaly for Thomas to miss hitting any point dead-on and correctly, invoking the above principles probably seemed justified.) The core of Graham's challenge is the compiler-typechecked member datum (attribute feature) called tail. tail is of class LIST for LIST objects and of class ORDERED_LIST for ORDERED_LIST objects. Eiffel compilers don't use casts and are supposed to do conservative system-validity checks for potential violations of the invariants of the tail object engendered by use of features provided by a correctly written class. (Thomas already essentially noted that the invariants for this LIST cannot be those normally associated with lists, but that is irrelevant to the anchoring issue.) The C++ version (reasonably) replaces the tail attribute in the List with a member function: List tail() However, the main point is sidestepped in neglecting to define the corresponding: OrderedList tail() in the OrderedList class. Defining OrderedList::tail() requires using and possibly introducing a typeunsafe construct: either the OrderedList(List) constructor (which can easily be used to construct an invariants-violating unordered OrderedList), a cast, or some other combination of constructors and casts that equally well may be "type checked" by the compiler, but won't guarantee that a resulting OrderedList is indeed ordered. The point is that Eiffel compilers/environments allow explicit covariance and catch errors that C++ compilers are not required to catch (when C++ users implicitly invoke covariance). However, someone could probably write a C++ lint that found the existence and maximum depth down the class lattice of implicit covariance and then did a system-level validity check at that depth, it's just not in the spec. Also, Eiffel could stop a perfectly valid program from executing because its checking is conservative. Although, Graham Perkins' original challenge/critique of C++ is logically valid (well, "cast" should really be replaced with "typeunsafe construct"), its significance to C++ users is less clear. I don't recall having ever made a strictly system-level validity error and I'd guess the odds of misusing OrderedList tail() and its associated typeunsafe implementations would usually be small. OK, maybe the principles aren't so strange. Doug -------------------------------------------------------------------- Doug Morgan, doug@ads.com, (415) 960-7444 Advanced Decision Systems (a division of Booz-Allen & Hamilton Inc.) 1500 Plymouth St., Mountain View, CA 94043-1230 -------------------------------------------------------------------- ======================================================================= 62 === Date: 8 Sep 1994 15:57:39 -0400 From: hendrik@CAM.ORG (Hendrik Boom) Subject: Re: DEC's Modula 3 Simon Johnston (skj@oasis.icl.co.uk) wrote: : atverm@ecp541.ecn.nl wrote: : : In <778611866.AA07139@dialis.hacktic.nl> geert@dialis.hacktic.nl (Geert B osch) writes: : : | I just ftp-ed Modula-3 from gatekeeper.dec.com and I am wondering if anyb ody : : | has tips about setting it up. My ultimate wish would be to compile Modula -3 : : | from within an OS/2 environment. Does anybody have experience in doing th is? : : | : : I wish you good luck, you'd be the first to succeed. If you're serious : : I advise you to use the EMX 0.8h GCC environment to compile the beast. : : You'll need a fair amount of Unix and C knowledge. I gather you've : : taken the Linux port as a starting point? : : I once had the same plans as you, but I really don't have the time to : : do it. I remember reading some message of another brave person about : : two months ago who reported he got quake to work and he posted the : I am that 'brave' person, I got quake working, and produced some OS2 template : files which appear to work with the EMX 0.8hpl9 environment. The main problem : with this was that the OS2 command line cannot take all those file names on : the link/lib command name. The answer was to produce a response file for the : librarian and pass it on the command line, for the link phase produce a lib : first and then link the lib. : : diffs needed for it. I didn't hear from it any more. If you make progress, : : I am very much interested and would like to be kept informed, and I'm sure : I have had to stop work on this as my *real* work demanded the time and disk : space I was using. If I get back to it I will of course let the group know. : : much others are because there have been quite some requests for an OS/2 : : port in the recent year! : Thanks for remembering the post, noone else seemed to have noticed the post : go by, I thought I was all alone out here! I'm another brave person attempting it, planning a cross-port from Linux. I'm on the verge of installing Linux as third OS on my OS/2 machine; i.e., my machine is currently having a much larger hard disk installed... hendrik@cam.org ======================================================================= 63 === Date: 9 Sep 1994 18:01:47 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Performance of M3 on Intell boxes (Linux, Chicago) In article , connolly@ulua.hal.com (Dan Con nolly) writes: > I noticed a couple things in the Linux release notes: > * the exception handling code is based on setjmp/longjmp, > rather than the more optimal stack-walking strategy. > -- is this likely to impact performance noticeably? It's probably not terrible on an x86 box. Every entry to a TRY-EXCEPT statement (and a few bizarre TRY-FINALLY stmts) will call setjmp. Since the jmp buffer is only 8 words, it can't(?) take too long to fill it. > -- is the Intel stack sufficiently "self-describing" > to allow for the more optimal solution? I don't know. > * the garbage collection isn't synchronized with the virtual > memory system. Same two questions: > -- is this likely to impact performance noticeably? Yes. The star-trek cursor appears during the stop-and-copy collections. With the VM synchronization you get incremental and generational collections. The pauses would be invisible. > -- Would someone with experience guestimate the amount > of work to make the appropriate enhancements? It's not much work: - It must be possible to protect and unprotect data pages, and the signal handler for memory access violations must be able to determine the offending address and resume from the signal. See runtime/src/{DS3100,SPARC}/RTHeapDep.[im]3. - The system calls need wrappers that validate their arguments before making the call. See runtime/src/{DS3100,SPARC}/RTHeapDepC.c. > Finally, for some serious speculating: Is anybody working on targeting > M3 applications on Chicago-class boxes? Yes, we're working a port of the system to Chicago. No, I don't know when it will be ready for release. - Bill Kalsow ======================================================================= 64 === Date: 09 Sep 1994 22:47:56 GMT From: connolly@ulua.hal.com (Dan Connolly) Subject: mprotect() support in Linux kernel? I'm interested in enhancing the Linux port of Modula 3 to use incremental/generational garbage collection. This requires support for the mprotect() library routine, or its equivalent. However, it appears that mprotect() is not supported under Linux: In linux/mm/mmap.c, I see: 230 asmlinkage int sys_mprotect(unsigned long addr, size_t len, unsigned long prot) 231 { 232 return -EINVAL; /* Not implemented yet */ 233 } mprotect() is in /usr/include/sys/mman.h, but there's no linux man page (that I can find) for mprotect. In the Kernel Hackers guide at http://sunsite.unc.edu/mdw/LDP/khg/section2.7.1.html I see: Minor alterations are needed in some places (tests for process memory limits comes to mind) to provide support for programmer defined segments. So I guess for now, I'm out of luck. I'm willing to hack the modula-3 runtime, but it would take me a while to ramp up on the Linux kernel memory management. Have I found the most recent info? Is there a more recent version of the kernel that supports mprotect()? Is anyone working on support for this? Is there a different library function that would serve my needs? Thanks. Dan In article <34q7ub$6k4@src-news.pa.dec.com> kalsow@src.dec.com (Bill Kalsow) wr ites: From: kalsow@src.dec.com (Bill Kalsow) Newsgroups: comp.lang.modula3 Date: 9 Sep 1994 18:01:47 GMT Organization: DEC Systems Research Center In article , connolly@ulua.hal.com (Dan Connolly) writes: > * the garbage collection isn't synchronized with the virtual > memory system. Same two questions: > -- is this likely to impact performance noticeably? Yes. The star-trek cursor appears during the stop-and-copy collections. With the VM synchronization you get incremental and generational collections. The pauses would be invisible. > -- Would someone with experience guestimate the amount > of work to make the appropriate enhancements? It's not much work: - It must be possible to protect and unprotect data pages, and the signal handler for memory access violations must be able to determine the offending address and resume from the signal. See runtime/src/{DS3100,SPARC}/RTHeapDep.[im]3. - The system calls need wrappers that validate their arguments before making the call. See runtime/src/{DS3100,SPARC}/RTHeapDepC.c. The source code he refers to is available at: http://www.research.digital.com/SRC/m3sources/html/runtime/src/SPARC/RT HeapDep.m3 -- Daniel W. Connolly "We believe in the interconnectedness of all things" Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010 http://www.hal.com/%7Econnolly/index.html ======================================================================= 65 === Date: Fri, 9 Sep 1994 17:28:39 GMT From: jjb@watson.ibm.com (John Barton) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] In article , doug@monet.ads.com (Doug Morgan) writes: |> In article <1994Sep7.170247.21058@rcmcon.com> rmartin@rcmcon.com (Robert Mar tin) writes: |> >>grp@dmu.ac.uk (Graham Perkins) writes: |> >[presents a challenge, Translate this Eiffel code into C++ without Casts] |> >>|class LIST[T] |> >[code elided] |> >tmb@arolla.idiap.ch (Thomas M. Breuel) writes: |> |> >>Well, a typesafe C++ solution without casts is given |> >>below; [...stuff deleted] |> |> Interesting principles, but, in this instance, of questionable |> appropriateness. Although Thomas Breuel asserted that his code is a |> "typesafe C++ solution", it actually sidesteps the main point of the |> original challenge and therefore fails to be a "solution" in any |> sense. (As it is a major anomaly for Thomas to miss hitting any point |> dead-on and correctly, invoking the above principles probably seemed |> justified.) |> |> The core of Graham's challenge is the compiler-typechecked member |> datum (attribute feature) called tail. tail is of class LIST for LIST |> objects and of class ORDERED_LIST for ORDERED_LIST objects. Eiffel |> compilers don't use casts and are supposed to do conservative |> system-validity checks for potential violations of the invariants of |> the tail object engendered by use of features provided by a correctly |> written class. (Thomas already essentially noted that the invariants |> for this LIST cannot be those normally associated with lists, but that |> is irrelevant to the anchoring issue.) The C++ version (reasonably) |> replaces the tail attribute in the List with a member function: |> |> List tail() |> |> However, the main point is sidestepped in neglecting to define the |> corresponding: |> |> OrderedList tail() |> |> in the OrderedList class. Defining OrderedList::tail() requires using |> and possibly introducing a typeunsafe construct: either the |> OrderedList(List) constructor (which can easily be used to construct |> an invariants-violating unordered OrderedList), a cast, or some other |> combination of constructors and casts that equally well may be "type |> checked" by the compiler, but won't guarantee that a resulting |> OrderedList is indeed ordered. Below I modified the C++ version to introduce a ListCategory that defines a tail() member returning an object of type List. This construct is exactly covariant because each ListCategory class derives from the template and substitutes itself for "List", eg ListCategory< OrderedList, T> and the return types in the ListCategory are of the self type, eg OrderedList in this case. We call this construct a "function-structure category" because it expresses the relation between functions in a category of classes. In the example below I left "data" as member data, but I would look for a design that used a function call here instead. |> |> The point is that Eiffel compilers/environments allow explicit |> covariance and catch errors that C++ compilers are not required to |> catch (when C++ users implicitly invoke covariance). However, someone |> could probably write a C++ lint ... Not necessary; I find that you can put as much---or as little---type checking into C++ as you like. Doesn't make it better or worse, its just that way. [...stuff deleted ] -- John. John J. Barton jjb@watson.ibm.com (914)784-6645 H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598 typedef int bool; void assert(void*); template struct Cons { T head; Cons *tail; Cons(T head,Cons *tail):head(head),tail(tail) {} }; template struct ListCategory { Cons* data; EltT head() { assert(data); return data->head;} List tail() { assert(data); return List(data->tail); } bool empty() {return data==0;} }; template List ListCategory::tail() { assert(data); return List(data->tail); } template struct List : ListCategory< List, T> { List(){ data=0; } List(Cons *dataN) { data = dataN;} void insert(T x) {data = new Cons(x,data);} }; template struct OrderedList : ListCategory< OrderedList, T> { OrderedList() {} OrderedList(Cons *dataN) { data = dataN;} OrderedList& operator=(OrderedList & list) {data = list.data; return *this;} OrderedList(List list){ data = list.data; } OrderedList& operator=(List &list) {data = list.data; return *this;} void insert(T x) { if(!data || data->head >= x) { data = new Cons(x,data); return; } Cons *p = data; while(p->tail) { if(p->tail->head >= x) { p->tail = new Cons(x,p->tail); return; } p = p->tail; } p->tail = new Cons(x,p->tail); } }; int main() { OrderedList ol; return 0; } ======================================================================= 66 === Date: Fri, 9 Sep 1994 19:17:36 GMT From: bcrwhims@undergrad.math.uwaterloo.ca (Carsten) Subject: Re: Performance of M3 on Intell boxes (Linux, Chicago) In article <34q7ub$6k4@src-news.pa.dec.com>, Bill Kalsow wrote: | In article , connolly@ulua.hal.com (Dan Connolly) writes: | > I noticed a couple things in the Linux release notes: | > * the exception handling code is based on setjmp/longjmp, | > rather than the more optimal stack-walking strategy. | > -- is this likely to impact performance noticeably? | | It's probably not terrible on an x86 box. Every entry to a TRY-EXCEPT | statement (and a few bizarre TRY-FINALLY stmts) will call setjmp. | Since the jmp buffer is only 8 words, it can't(?) take too long to | fill it. | | > -- is the Intel stack sufficiently "self-describing" | > to allow for the more optimal solution? | | I don't know. | | > * the garbage collection isn't synchronized with the virtual | > memory system. Same two questions: | > -- is this likely to impact performance noticeably? | | Yes. The star-trek cursor appears during the stop-and-copy collections. | With the VM synchronization you get incremental and generational | collections. The pauses would be invisible. | | > -- Would someone with experience guestimate the amount | > of work to make the appropriate enhancements? | | It's not much work: | - It must be possible to protect and unprotect data pages, | and the signal handler for memory access violations must be able | to determine the offending address and resume from the | signal. See runtime/src/{DS3100,SPARC}/RTHeapDep.[im]3. | | - The system calls need wrappers that validate their arguments | before making the call. See runtime/src/{DS3100,SPARC}/RTHeapDepC.c. | | > Finally, for some serious speculating: Is anybody working on targeting | > M3 applications on Chicago-class boxes? | | Yes, we're working a port of the system to Chicago. No, I don't know | when it will be ready for release. | | - Bill Kalsow Well, considering the number of OS/2 installations out there (5mil+), and the number of Chicago installations (o, <200,000 beta), why not do OS/2 first? -- ------------------------------------------------------------------- Carsten Whimster EDM/2 Associate Editor bcrwhims@cayley.uwaterloo.ca EDM/2 Book Review columnist ---- Author of POVPanel ------ SRX600 ------- TEAM OS/2 ----------- ======================================================================= 67 === Date: Thu, 8 Sep 1994 17:46:00 GMT From: franka@parcplace.com (Frank Adrian) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article emery@goldfinger.mitre.org (David Emery) writes: >> This isn't an issue if dynamic typing is also available, but I still >>don't see how static typing can possibly _enhance_ creativity. > >Do you believe in abstraction? Do you believe in automating the >details and bookkeeping? > >Static type checking (whether in the language, such as Ada, or in some >related tool, such as lint for C) helps creativity by allowing the >programmer to concentrate on the big issues, and using the tools to >automate checking of the small issues. Excuse me? I fail to see the connection with static typing and abstraction. I have seen many fine abstractions presented in dynamically-typed languages - see Ableson and Sussman's "Structure and Interpretation of Computer Programs", for some simple examples. The only thing abstraction means is to present a common interface to a capability without regards how this capability is carried out. This says ABSOLUTELY NOTHING about how references to this interface are checked - statically, dynamically, or at all. In fact, most static type systems I am familiar with lull programmers into a false sense of security because their type system depends on a lexicographic signature rather than a well-defined LOGICAL set of inariant attributes that all members of a different class share. Although Eiffel's pre- and post- conditions are a step in the right direction, most languages that call them- selves "strongly typed" are not. Most studies show that dynamically-typed programming systems still allow a much more productive programmer. I think you overestimate both the amount of help a statically-typed system actually provides in producing a correct program (especially when the check is just on the language's shallow syntactic structur e and not on the deeper logical structure) AND the amount of help a programmer actually NEEDS. If you want to show me a language that allows me to write first-order predicate logic statements as invariants that are used to check types I will be happily disuaded from my points above. To put it in a simpler perspective (for the linguistically challenged out there who only know C++ :-), as soon as you show me that I cannot overload the + operator to perform a - operation, I will know that your type system IS actually strong. Until then, you are living in a fool's paradise. -- Frank A. Adrian /|\ "A Mbit here, a Gbit there franka@parcplace.com / | \ and pretty soon you're talking ParcPlace Systems, Inc. / | \ about real bandwidth..." Portland / | \ -- me ======================================================================= 68 === Date: 10 Sep 1994 02:19:12 GMT From: tmb@arolla.idiap.ch (Thomas M. Breuel) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] In article doug@monet.ads.com (Doug Morgan) w rites: |Although Thomas Breuel asserted that his code is a |"typesafe C++ solution", it actually sidesteps the main point of the |original challenge and therefore fails to be a "solution" in any |sense. I don't think it does miss the point (see below). |The core of Graham's challenge is the compiler-typechecked member |datum (attribute feature) called tail. tail is of class LIST for LIST |objects and of class ORDERED_LIST for ORDERED_LIST objects. There are (at least) four different semantics that you may want to use for the relationship between LIST and ORDERED_LIST, and all four can be implemented easily and without casts in C++: (1) allow List and OrderedList to be used interchangeably, enforcing class invariants Solution: provide conversion functions that ensure the class invariants; in particular, replace the constructor for OrderedList by: OrderedList::OrderedList(List &source) { data = sort(source.data); } (2) allow List and OrderedList to be used interchangeably, guaranteeing class invariants through dynamic typing Solution: use RTTI or a manual implementation OrderedList::OrderedList(List &source) { if(!source.is_ordered()) RUNTIME_TYPE_ERROR; data = copy(source.data); } (3) allow List and OrderedList to be used interchangeably without guaranteeing class invariants: Solution: use the code as given; that is, the constructor doesn't do any checking: OrderedList::OrderedList(List &source) { data = source.data; } (4) don't allow List and OrderedList to be used interchangeably; just reuse part of the implementation of List Solution: there are many possible approaches, including: (a) manual message forwarding (b) message forwarding with operator-> (c) templates (d) inheritance with redefinition of the return type in the derived class (I believe the draft ANSI C++ standard allows this; this is most closely analogous to the Eiffel solution, but I think it's the least desirable solution) None of these possibilities require unsafe casts for their implementation in C++ (or any casts, for that matter). All of them allow full reuse of the functionality defined with the List type. Now, my initial thought was that Graham's Eiffel code implemented (3), since ORDERED_LIST inherits from LIST in his code. That's why I gave the implementation that I did, pointing out clearly that I considered this a flaw. On re-reading the section on system-validity in the Eiffel book, I'm actually not quite sure what his code does (my only reference on Eiffel; unfortunately, Graham didn't tell us in words what he wanted his code to do); it seems like it is either reduces to case (4), or it reduces to case (3), or it requires runtime type checking, or it is useless (because system validity checks would never let you invoke method "tail" on an object of type LIST). Does anyone care to explain? |Although, Graham Perkins' original challenge/critique of C++ is |logically valid (well, "cast" should really be replaced with |"typeunsafe construct"), its significance to C++ users is less clear. Whichever of the four behaviors he wants, he can get without casts or unsafe constructs. If the Eiffel code does something different from these four possibilities, please let me know and I'll try to cook up a C++ version of it. |I don't recall having ever made a strictly system-level validity error |and I'd guess the odds of misusing OrderedList tail() and its |associated typeunsafe implementations would usually be small. OK, |maybe the principles aren't so strange. I don't think you can make a system-level validity error in C++ without explicitly using an unsafe operation (*). System validity checking in Eiffel seems to be necessary because of the possibility of incompatible redefinitions in subclasses (types or hiding). Case (3) above doesn't qualify as a "system level validity error", since the dangerous conversion behavior is explicitly implemented by user code; something analogous can be done in any language, including Eiffel. In any case, I think the reason why you haven't come across this "problem" in C++ is that, as we have seen above, there are numerous other ways of achieving the same kind of polymorphism and reuse that do not involve inheritance and the use of "like" and "clone". You probably have always simply designed your C++ libraries and classes accordingly. Thomas. (*) You can make virtual functions "private" in derived classes and still access them through the base class in C++; however, this is simply a different definition of what "hiding" means. Compilers should probably warn about such cases, though. The original Eiffel code (Graham's challenge): |class LIST[T] |feature |head : T |tail : like Current |put( x:T ) is | do tail := clone( Current ) | head := x | end |empty : BOOLEAN is | do Result := void( tail ) | end |end | |class ORDERED_LIST[ T->COMPARABLE ] |inherit LIST[T] rename put as cons | end | LIST[T] redefine put | end |feature | |put( x:T ) is | do if empty then cons( x ) | elsif x < head | then cons( x ) | else tail.put( x ) | end | end |end | My original solution: |template |struct Cons { | T head; | Cons *tail; | Cons(T head,Cons *tail):head(head),tail(tail) {} |}; | |template |struct List { | Cons *data; | | List():data(0) {} | List(Cons *data):data(data) {} | | void insert(T x) {data = new Cons(x,data);} | bool empty() {return data==0;} | T head() {assert(data); return data->head;} | List tail() {assert(data); return List(data->tail);} |}; | |template |struct OrderedList:List { | OrderedList() {} | OrderedList(Cons *data):List(data) {} | OrderedList &operator=(OrderedList &list) {data = list.data; return *th is;} | | OrderedList(List list):List(list.data) {} | OrderedList &operator=(List &list) {data = list.data; return *this;} | | void insert(T x) { | if(!data || data->head >= x) { | data = new Cons(x,data); | return; | } | Cons *p = data; | while(p->tail) { | if(p->tail->head >= x) { | p->tail = new Cons(x,p->tail); | return; | } | p = p->tail; | } | p->tail = new Cons(x,p->tail); | } |}; ======================================================================= 69 === Date: 10 Sep 1994 02:00:15 GMT From: goldt@math.tu-berlin.de (Sven Goldt) Subject: Re: mprotect() support in Linux kernel? Dan Connolly (connolly@ulua.hal.com) wrote: : I'm interested in enhancing the Linux port of Modula 3 to use : incremental/generational garbage collection. This requires support for : the mprotect() library routine, or its equivalent. : However, it appears that mprotect() is not supported under Linux: It is implemented in newer kernels. Look at the Linux Programmer's Guide. -- ***************************************************************************** * # THE MOST IMPORTANT FINANCIAL QUESTION IS: Where is the money ? # * ***************************************************************************** ======================================================================= 70 === Date: 10 Sep 1994 13:18:19 GMT From: agulbra@nvg.unit.no (Arnt Gulbrandsen) Subject: Re: mprotect() support in Linux kernel? In article <34r3vf$3g9@brachio.zrz.tu-berlin.de>, Sven Goldt wrote: >Dan Connolly (connolly@ulua.hal.com) wrote: > >: I'm interested in enhancing the Linux port of Modula 3 to use >: incremental/generational garbage collection. This requires support for >: the mprotect() library routine, or its equivalent. > >: However, it appears that mprotect() is not supported under Linux: > >It is implemented in newer kernels. Look at the Linux Programmer's Guide. Partly implemented, according to Linus. He added it about 1.1.36-8. --Arnt ======================================================================= 71 === Date: 10 Sep 1994 11:59:29 GMT From: brister@jolt.mpx.com.au (James Brister) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] Richard Bunbury (bunbury@vienna.eiffel.com) wrote: [ a whole pile of crap about C++'s new 'casts' (really type-saftey mechanisms) ] Here we go again. "My language is better than yours." And from a vendor no less. Sounds to me like a little panic setting in. C++ is putting in the type-safety machanisms to make it more appealing and the fringe languages will become even more so. James (Modula-3 rules, but language wars suck). ======================================================================= 72 === Date: Sat, 10 Sep 1994 21:27:26 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? franka@parcplace.com (Frank Adrian) writes: >Most studies show that dynamically-typed programming systems still >allow a much more productive programmer. Which studies are these? Are they controlled experiments? Who sponsors them? Can you give us some citings? >I think you overestimate >both the amount of help a statically-typed system actually provides >in producing a correct program (especially when the check is just on >the language's shallow syntactic structure and not on the deeper >logical structure) AND the amount of help a programmer actually >NEEDS. That programmers need an awful lot of help is not in dispute. They do. If we could all write our programs correctly the first time, then maybe we wouldn't need any help. The cost of a bug increases geometrically with time. Early in analysis and design, bugs are cheap to fix. During testing they are more expensive by a factor of K. During beta by K^2 and after release K^3, if not more. Static typed language find certain kinds of bugs in very early phases. The cost of saving those bugs is significant. >If you want to show me a language that allows me to write first-order >predicate logic statements as invariants that are used to check types >I will be happily disuaded from my points above. To put it in a >simpler perspective (for the linguistically challenged out there who >only know C++ :-), as soon as you show me that I cannot overload the >+ operator to perform a - operation, I will know that your type >system IS actually strong. Until then, you are living in a fool's >paradise. I find it difficult to believe that any serious C++ programmer would consider his language to be fully type safe. I find it difficult to believe that any C++ programmer considers himself to be living in any kind of paradise at all. The most compelling reason for choosing C++ is the aknowledgement that software engineering is closer to Hell than Paradise and that C++ is pragmatic enough to deal with "hellish" problems. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ ======================================================================= 73 === Date: 12 Sep 1994 12:01:28 GMT From: anderse@dna.lth.se (Anders Edenbrandt) Subject: Problems with SRC Modula-3 v. 3.3 I have installed SRC Modula-3 version 3.3, on SunOS 4.1 as well as on Solaris, and I have installed the fixes mentioned in "bugs and patches", but I still have some questions/problems: 1. On SunOS 4.1, nothing works unless I run with @M3novm. Is this what I should expect? (I thought that the VM problem had been fixed ...) 2. M3gdb, the debugger, has lots of problems, most of which I have seen reported here a long time ago. Is anybody working on fixing this? At SRC or anywhere else? 3. What about the VM protection parts for Solaris? Has this been done somewhere? Anders Edenbrandt Dept. of Comp. Sci. Lund University Lund, Sweden ======================================================================= 74 === Date: 12 Sep 1994 14:29:41 GMT From: preece@urbana.mcd.mot.com (Scott E. Preece) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? n-reply-to: rmartin@rcmcon.com's message of Sat, 10 Sep 1994 21:27:26 GMT Xref: courier.urbana.mcd.mot.com comp.software-eng:22141 comp.object:19259 comp .lang.eiffel:5808 comp.lang.smalltalk:14298 comp.lang.modula3:2813 comp.lang.ob jective-c:2964 In article <1994Sep10.212726.2087@rcmcon.com> rmartin@rcmcon.com (Robert Martin ) writes: | The cost of a bug increases geometrically with time. Early in | analysis and design, bugs are cheap to fix. During testing they are | more expensive by a factor of K. During beta by K^2 and after release | K^3, if not more. | | Static typed language find certain kinds of bugs in very early phases. | The cost of saving those bugs is significant. --- Yes, static typing allows you to find a specific class of defects early in the process. However, most dynamic type checking would find most of those same problems equally earely in the process. In my experience, the enormous bulk of the type errors I hit are trivia - typos and mistakes in changing a variable from one type to another in some places but not in others. Virtually all of them would have been caught by run-time checks the first time I tried to run the program (the equivalent of their being caught at the first compile). Virtually all of them could have been caught by a code analyzer with a practical level of effort. The "hard" type errors I've encountered have mostly been in places where static type checking wouldn't have helped - in places where externally provided memory images had to be turned into internally usable types or where other explicit conversions had to be done and were botched. Frankly, I find the "this interface will reliably signal an error if called with the wrong type" promise of dynamic typing more believable than the "the language makes it impossible to pass the wrong type to an interface" promise of static typing... scott -- scott preece motorola/mcg urbana design center 1101 e. university, urbana, il 61801 phone: 217-384-8589 fax: 217-384-8550 internet mail: preece@urbana.mcd.mot.com ======================================================================= 75 === Date: 12 Sep 94 09:12:22 From: doug@monet.ads.com (Doug Morgan) Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty ping] In article tmb@arolla.idiap.ch (Thomas M. B reuel) writes: |In article doug@monet.ads.com (Doug Morgan) writes: ||Although Thomas Breuel asserted that his code is a ||"typesafe C++ solution", it actually sidesteps the main point of the ||original challenge and therefore fails to be a "solution" in any ||sense. | |I don't think it does miss the point (see below). | ||The core of Graham's challenge is the compiler-typechecked member ||datum (attribute feature) called tail. tail is of class LIST for LIST ||objects and of class ORDERED_LIST for ORDERED_LIST objects. | |There are (at least) four different semantics that you may want to |use for the relationship between LIST and ORDERED_LIST, and all |four can be implemented easily and without casts in C++: | |(1) allow List and OrderedList to be used interchangeably, enforcing | class invariants | | Solution: provide conversion functions that ensure the | class invariants; in particular, replace the constructor | for OrderedList by: | | OrderedList::OrderedList(List &source) { | data = sort(source.data); | } No. If you also have a ReverseOrderedList, they will swap orderings of the data out from underneath each other. Further, perhaps LIST required that only put() could modify its current ordering? |(2) allow List and OrderedList to be used interchangeably, guaranteeing | class invariants through dynamic typing | | Solution: use RTTI or a manual implementation | | OrderedList::OrderedList(List &source) { | if(!source.is_ordered()) RUNTIME_TYPE_ERROR; | data = copy(source.data); | } No. Run-time, not compile-time, checked. |(3) allow List and OrderedList to be used interchangeably without | guaranteeing class invariants: | | Solution: use the code as given; that is, the constructor | doesn't do any checking: | | OrderedList::OrderedList(List &source) { | data = source.data; | } No. OrderedLists then aren't necessarily ordered. |(4) don't allow List and OrderedList to be used interchangeably; | just reuse part of the implementation of List | | Solution: there are many possible approaches, including: | | (a) manual message forwarding | | (b) message forwarding with operator-> | | (c) templates | | (d) inheritance with redefinition of the return type | in the derived class (I believe the draft ANSI C++ | standard allows this; this is most closely | analogous to the Eiffel solution, but I think | it's the least desirable solution) No. The Eiffel solution does allow an ORDERED_LIST to be used in some places where a LIST is declared. |None of these possibilities require unsafe casts for their |implementation in C++ (or any casts, for that matter). Yes, but as none of these possibilities actually does or allows what the Eiffel implementation does, they still don't address what I think is the core issue. Actually, I think that most applications could do better to not use covariance and instead improve the structure of a class lattice (like Barton did). However, I also think that sometimes that restructuring can be difficult to retrofit or can introduce new classes that sometimes seem to do little more than add unnecessary bulk. Eiffel give a capability for safely getting around a "proper" restructuring. The capability certainly seems interesting, whether it is good, I'm not so sure. | All of them |allow full reuse of the functionality defined with the List type. Well, they do allow *some* reuse. |Now, my initial thought was that Graham's Eiffel code implemented (3), |since ORDERED_LIST inherits from LIST in his code. That's why I gave |the implementation that I did, pointing out clearly that I considered |this a flaw. I agree that if LIST means what everyone usually thinks "list" means, then having ORDERED_LIST inherit from LIST was a flaw (and would have been detected the first time the example was run with invariant checking added to the implementation). However, if LIST is something a bit less structured (more like a bag, but just called "LIST"), the classes are logically consistent. Maybe I shouldn't be so lenient, but since "good" examples could easily be generated (just rename LIST to be UNSPECIFIED_ORDER_LISTY_THING_WITH_SUBCLASSES_THAT_COULD_SPECIFY_ORDER), I don't think this flaw is significant. |On re-reading the section on system-validity in the Eiffel book, I'm |actually not quite sure what his code does (my only reference on |Eiffel; unfortunately, Graham didn't tell us in words what he wanted |his code to do); it seems like it is either reduces to case (4), or it |reduces to case (3), or it requires runtime type checking, or it is |useless (because system validity checks would never let you invoke |method "tail" on an object of type LIST). Does anyone care to |explain? See other messages. Essentially, redefine the reader and writer to a tail variable with refined return type and argument type and do it with compiler-checked typesafety. |... ||I don't recall having ever made a strictly system-level validity error ||and I'd guess the odds of misusing OrderedList tail() and its ||associated typeunsafe implementations would usually be small. OK, ||maybe the principles aren't so strange. | |I don't think you can make a system-level validity error in C++ |without explicitly using an unsafe operation (*). Right. I have made such unsafe operations (casts!, heavens) and didn't screw up (maybe). |System validity |checking in Eiffel seems to be necessary because of the possibility of |incompatible redefinitions in subclasses (types or hiding). Redefinition of non-virtual member functions gives exactly the same possibilities to C++. No wonder there are some strong suggestions, to never redefine an inherited nonvirtual function (Item 37 in Meyer's excellent book). BTW, this rule was just made to be broken and sometimes should be for the "best" design. |... |In any case, I think the reason why you haven't come across this |"problem" in C++ is that, as we have seen above, there are numerous |other ways of achieving the same kind of polymorphism and reuse that |do not involve inheritance and the use of "like" and "clone". You |probably have always simply designed your C++ libraries and classes |accordingly. That's mostly it. When I do use covariance, I am extra careful. Doug ======================================================================= 76 === Date: 12 Sep 1994 13:21:20 GMT From: haible@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible) Subject: Re: mprotect() support in Linux kernel? Sven Goldt wrote: > >: However, it appears that mprotect() is not supported under Linux: > > It is implemented in newer kernels. mprotect() still needs the following three patches to work properly. The first one ensures that the reference count of an mmap'ed file is decremented when adjacent vm_areas are merged (because it is incremented when a vm_area is splitted). The second and third one provide proper management of the vm_area_struct list. Bruno Haible haible@ma2s2.mathematik.uni-karlsruhe.de diff -r -c3 linux-1.1.48/mm/mmap.c linux/mm/mmap.c *** linux-1.1.48/mm/mmap.c Sun Aug 14 15:40:56 1994 --- linux/mm/mmap.c Tue Aug 23 11:11:52 1994 *************** *** 424,429 **** --- 432,444 ---- */ prev->vm_end = mpnt->vm_end; prev->vm_next = mpnt->vm_next; + if (mpnt->vm_ops && mpnt->vm_ops->close) { + mpnt->vm_offset += mpnt->vm_end - mpnt->vm_start; + mpnt->vm_start = mpnt->vm_end; + mpnt->vm_ops->close(mpnt); + } + if (mpnt->vm_inode) + mpnt->vm_inode->i_count--; kfree_s(mpnt, sizeof(*mpnt)); mpnt = prev; } diff -r -c3 linux-1.1.48/mm/mprotect.c linux/mm/mprotect.c *** linux-1.1.48/mm/mprotect.c Sun Aug 14 15:40:56 1994 --- linux/mm/mprotect.c Sun Aug 14 02:24:34 1994 *************** *** 107,123 **** unsigned long start, unsigned long end, int newflags, int prot) { ! int error; ! unsigned long tmpflags, tmpprot; ! tmpflags = vma->vm_flags; ! tmpprot = vma->vm_page_prot; vma->vm_flags = newflags; vma->vm_page_prot = prot; ! error = mprotect_fixup_end(vma, end, tmpflags, tmpprot); ! if (!error) ! error = mprotect_fixup_start(vma, start, tmpflags, tmpprot); ! return error; } static int mprotect_fixup(struct vm_area_struct * vma, --- 111,146 ---- unsigned long start, unsigned long end, int newflags, int prot) { ! struct vm_area_struct * left, * right; ! left = (struct vm_area_struct *) kmalloc(sizeof(struct vm_area_struct), GFP_KERNEL); ! if (!left) ! return -ENOMEM; ! right = (struct vm_area_struct *) kmalloc(sizeof(struct vm_area_struct) , GFP_KERNEL); ! if (!right) { ! kfree(left); ! return -ENOMEM; ! } ! *left = *vma; ! *right = *vma; ! left->vm_end = start; ! vma->vm_start = start; ! vma->vm_end = end; ! right->vm_start = end; ! vma->vm_offset += vma->vm_start - left->vm_start; ! right->vm_offset += right->vm_start - left->vm_start; vma->vm_flags = newflags; vma->vm_page_prot = prot; ! if (vma->vm_inode) ! vma->vm_inode->i_count += 2; ! if (vma->vm_ops && vma->vm_ops->dup) { ! vma->vm_ops->dup(left); ! vma->vm_ops->dup(right); ! } ! insert_vm_struct(current, left); ! insert_vm_struct(current, right); ! merge_segments(current->mm->mmap); ! return 0; } static int mprotect_fixup(struct vm_area_struct * vma, *************** *** 155,161 **** asmlinkage int sys_mprotect(unsigned long start, size_t len, unsigned long pr ot) { ! unsigned long end; struct vm_area_struct * vma; if (start & ~PAGE_MASK) --- 178,184 ---- asmlinkage int sys_mprotect(unsigned long start, size_t len, unsigned long pr ot) { ! unsigned long end, tmp; struct vm_area_struct * vma; if (start & ~PAGE_MASK) *************** *** 188,199 **** if (vma->vm_end >= end) return mprotect_fixup(vma, start, end, newflags); ! error = mprotect_fixup(vma, start, vma->vm_end, newflags); if (error) return error; ! start = vma->vm_end; ! vma = vma->vm_next; ! if (!vma || vma->vm_start != start) ! return -EFAULT; } } --- 211,225 ---- if (vma->vm_end >= end) return mprotect_fixup(vma, start, end, newflags); ! tmp = vma->vm_end; ! error = mprotect_fixup(vma, start, tmp, newflags); if (error) return error; ! start = tmp; ! if (vma->vm_end <= start) { ! vma = vma->vm_next; ! if (!vma || vma->vm_start != start) ! return -EFAULT; ! } } } ======================================================================= 77 === Date: Mon, 12 Sep 1994 22:26:11 GMT From: charles.herrick@amd.com Subject: Crossposting ButtHeads, keep this thread out of c.l.smalltalk (was: Re al C++ programmers don't use casts [was Re: Static vs Dynamic Typing] In article doug@monet.ads.com (Doug Morgan) writes: > In article tmb@arolla.idiap.ch (Thomas M. Breuel) writes: > |In article doug@monet.ads.com (Doug Morgan) writes: bunch of stuff about C++ Lorena-Bobbitized mercilessly. Kindly think to yourself, if I were a Smalltalk programmer, would I want to read this stuff? Hint: no. -- personal opinions ======================================================================= 78 === Date: 13 Sep 1994 03:38:50 GMT From: rwh@cs.cmu.edu (Robert Harper) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? I'd like to point out a fallacy that appears to pervade this discussion: it is simply not the case that dynamic and static typing are of equivalent expressive power. The discussants appear to be arguing whether one or the other catches errors earlier or more effectively or is more efficient or whatever, losing track of the fact that static typing is strictly more expressive than dynamic typing in that with a decent type system you can enforce invariants statically that are in no way checkable at run time. For example, one cannot tell by the bit pattern whether the value in a variable represents a "set" or a "time of day" or a "favorite color of the author of the program". Nor can one check at run-time properties of, say, functions that can be enforced by a static type discipline. To stave off the obvious flames, it is of course obvious that the static discipline, if it is to be decidable, must provide only sufficient conditions to ensure that properties such as those discussed are true, and consequently rule out cases where the properties obtain but the proof cannot be expressed in the type system to hand. Bear in mind, however, that the possibility exists, at least in principle, for bringing to bear arbitrary mechanical checking procedures for proving that invariants hold, limited only by the willingness of the programmer to instruct the compiler why an invariant must hold. No such option is open in the dynamic case. Bob Harper ======================================================================= 79 === Date: Tue, 13 Sep 1994 06:43:43 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? preece@urbana.mcd.mot.com (Scott E. Preece) writes: >n-reply-to: rmartin@rcmcon.com's message of Sat, 10 Sep 1994 21:27:26 GMT >Xref: courier.urbana.mcd.mot.com comp.software-eng:22141 comp.object:19259 com p.lang.eiffel:5808 comp.lang.smalltalk:14298 comp.lang.modula3:2813 comp.lang.o bjective-c:2964 >Yes, static typing allows you to find a specific class of defects early >in the process. However, most dynamic type checking would find most of >those same problems equally earely in the process. This is quite contrary to my experience. >Frankly, I find the "this interface will reliably signal an error if >called with the wrong type" promise of dynamic typing more believable than >the "the language makes it impossible to pass the wrong type to an >interface" promise of static typing... I don't. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ ======================================================================= 80 === Date: 13 Sep 1994 11:38:20 GMT From: borchert@thales.mathematik.uni-ulm.de (Andreas Borchert) Subject: Joint Modular Languages Conference ============================================================================= Joint Modular Languages Conference "Modula-2, Oberon & Friends" September 28th-30th, 1994 University of Ulm Ulm, Germany ============================================================================= Conference Sessions September 28th-30th, 1994: ================================================ ->>Keynote: The History of Modula-2, Prof. N. Wirth, ETH Zuerich - Application & Education - Large Software Systems - Realtime Programming - Distributed Systems - From Modula-2 to Oberon - Object-oriented Development using BETA & Eiffel - Development Tools and Techniques - Implementation and Porting Projects - Language Design - Compiler Issues - Programming Models - Formal Methods and Theory Tutorials September 26th-27th, 1994: ====================================== - C++ Tutorial, Sean Smith, University of Southampton - Oberon Tutorial, Hanspeter Moessenboeck, University of Linz ************************** Information & Registration ************************** JMLC Conference Secretary Verteilte Systeme, Informatik Universitaet Ulm Oberer Eselsberg O-27 D-89069 ULM, Germany Telephone: ++49 (731) 502-41 40 Telefax: ++49 (731) 502-41 42 E-mail: vsoffice@informatik.uni-ulm.de For accomodation in a hotel please contact the tourist information in Ulm. Tourist Information Telephone: ++49 (0) 731/161-2830 Im Stadthaus Telefax: ++49 (0) 731/161-1641 Muensterplatz D-89073 Ulm, Germany You can also get some informations via ftp or WWW. For information about Ulm: If you have access to WWW try the URLs: http://www.informatik.uni-ulm.de/index.eng.html http://www.informatik.uni-ulm.de/uni-ulm/uni-lageplan.eng.html or FTP to: hermes.informatik.uni-ulm.de:/pub/jmlc/Way-to-Ulm.[gif,jpeg,ps] URL: ftp://hermes.informatik.uni-ulm.de/pub/jmlc For hotel booking: If you have access to WWW try the URL: http://www.informatik.uni-ulm.de/fakultaet/abteilungen/vs/jmlc/HotelBooking.ps or FTP to: hermes.informatik.uni-ulm.de:/pub/jmlc/HotelBooking.ps **************** Conference Theme **************** The decisions on programming languages, tools and environments are of crucial importance for the success of most scientific and commercial data processing organisations. These decisions must take into account local tradition but must also be based on broad and thoroughly researched perspectives of current programming languages. Modular and object-oriented languages will typically speed-up the process of program development, stimulate reuse of existing code and simplify maintenance or documentation of software systems. In practice, however, commercially viable languages differ substantially with respect to their implementation volume, programming performance and fields of application. The Joint Modular Languages Conference 1994 in Ulm provides an opportunity for data processing professionals, programmers, teachers and researchers to become aware of alternative and more recent developments in the field of modular and object-oriented languages. Relevant topics will be presented from both theoretical and practical perspectives and adequate time is allocated for discussions. We cordially invite professional programmers from all language communities together with Pascal, Modula-2 and Oberon programmers to join the conference and to share our and their experiences. *********************** Preconference Tutorials *********************** Three tutorials will introduce software engineers from one programming community to at least one alternative language environment (C++, and Oberon). Each tutorial is a self contained course and discusses key concepts such as modularity, type consistency, classes, inheritance, and dynamic binding from a language specific point of view. The tutorials comprise 4 to 6 lecture hours and are augmented by laboratory exercises. We reserve the right to limit the number of participants for each course. All lecturers are experienced university teachers and language implementors, guaranteeing a high level of expertise and teaching efficiency. They will be available for in depth questions throughout the conference. The conference secretariat will gladly send you a detailed description of all three courses. ------------------------------------------------------------------ C++ Tutorial Monday, September 26, 1994 9.00 a.m. ------------------------------------------------------------------ Lecturer: Sean Smith, University of Southampton History and rationale of C++ Inheritance in C++ Polymorphism Classes in C++ C++ and the future Worked examples ------------------------------------------------------------------ Oberon Tutorial Tuesday, September 27, 1994 8.30 a.m. ------------------------------------------------------------------ Lecturer: Hanspeter Moessenboeck, University of Linz The Oberon language The Oberon environment Common techniques Oberon-2 amendments Object-oriented programming in Oberon-2 Writing extensible software Examples, case studies Extensive laboratory exercises ******************** Conference Programme ******************** *************** Wednesday, September 28, 1994 ***************** ------------------------------------------------------------------ 09:00 - 10:15 From Modula-2 to Oberon, P. Schulthess ------------------------------------------------------------------ Welcome Address ->> Keynote: The History of Modula-2 N. Wirth, ETH Zuerich Process Visualisation with Oberon System 3 and Gadgets E. Templ, A. Stritzinger, G. Pomberger ------------------------------------------------------------------ 10:45 - 12:15 Programming Language Design, H. Moessenboeck ------------------------------------------------------------------ Restricted Multiple Inheritance A.E. Nedorya, E.V. Tarasov, A.D. Hapugin Sequential and Parallel Exception Handling in Modula-3*: A Unifying Semantics Specification E.A. Heinz A Class Mechanism Supporting Subtype-check L. Xuedong, Z. Guoliang Afternoon track 1: ------------------------------------------------------------------ 13:30 - 15:00 Formal Methods and Theory, J. Farre ------------------------------------------------------------------ Object Design with Formal Classes P. Andre, D. Chiorean, J.C. Royer A Semantic Framework for Understanding the Behavior of Modules and Classes in Programming Languages M.H. Dodani, K.S. Gan Teaching a Systematic Method of Program Development C. Pronk, P.G. Kluit ------------------------------------------------------------------ 15:30 - 17:00 Compiler Issues, A. Borchert ------------------------------------------------------------------ Dynamic Polymorphism: An Ada-Based Approach J. Shen, G. Cormack, D. Duggan Compiler Optimizations Should Pay for Themselves M. Franz Building an Optimizing Compiler for Oberon: Implications on Programming Language Design M.M. Brandis Afternoon track 2: ------------------------------------------------------------------ 13:30 - 15:00 Development Tools and Techniques, A. Corradi ------------------------------------------------------------------ Post Mortem Debugger for Oberon M. Hof Using Oberon to Design a Hierachy of Extensible Device Drivers P.J. Muller STUDIO: A Modular, Compiled, Actor-Oriented Language, Based upon a Multitask Runtime System A. Hadjadji, L. Frecon ------------------------------------------------------------------ 15:30 - 17:00 Distributed Systems, P. Moylan ------------------------------------------------------------------ Object-Oriented Distributed Programming in the Oberon-PVM Environment E. Bugnion, M. Gitsels, B.A. Sanders Design of a Distributed Oberon System S. Traub Adding Parallel and Persistent Sets to Modula-3 L. Boeszoermenyi ------------------------------------------------------------------ 17:05 - 18:00 Modula-2 Standardisation Panel, H. Klaeren ------------------------------------------------------------------ M. Woodman (Convenor WG 13) and Panel Members ------------------------------------------------------------------ 19:00 - 20:30 Welcome Reception ------------------------------------------------------------------ *************** Thursday, September 29, 1994 ***************** ------------------------------------------------------------------ 09:00 - 10:15 O-O Development using BETA & Eiffel, J. Gutknecht ------------------------------------------------------------------ Part Objects in the BETA Programming Language B. Moller-Pedersen Model-View-Controller Classes in Eiffel M. Skipper ------------------------------------------------------------------ 10:45 - 12:15 Programming Models, G. Pomberger ------------------------------------------------------------------ An Object-Oriented Functional Logic Language for the Oberon System P. Dykstra Modular Inheritance of Objects through Mixin-Methods C. Lucas, P. Steyaert Combining Different Implementations of Types in a Program X. Franch ------------------------------------------------------------------ 13:30 - 15:00 Application and Education, F. Schweiggert ------------------------------------------------------------------ Modelling and Developing DSP Algorithms in C++ J. Middleton, M. Al-Akaidi, P. Urwin An Oberon-Based Implementation Tool J. Lampe Making the Transition from ADTs to Objects in Undergraduate Software Engineering: A CASE-Based Approach A.J. Peralta ------------------------------------------------------------------ 15:30 - 17:00 Realtime Programming, J. Cooling ------------------------------------------------------------------ A Distributed Real-Time Architecture in Oberon-2 B. Kirk, L. Nigro Writing Real-Time Applications in Modula-2 P.J. Moylan Timing as a Programming-In-The-Large Issue L. Nigro, F. Tisato ------------------------------------------------------------------ 17:05 - 18:00 Oberon Standardisation Panel, B. Kirk ------------------------------------------------------------------ ------------------------------------------------------------------ 20:00 - 23:00 Conference Banquet ------------------------------------------------------------------ *************** Friday, September 30, 1994 ***************** ------------------------------------------------------------------ 09:00 - 10:15 Oberon and beyond, M. Al-Akaidi ------------------------------------------------------------------ Oberon -- Perspectives of Evolution J. Gutknecht Towards End-User Objects: The Gadgets User Interface System J.L. Marais ------------------------------------------------------------------ 10:45 - 12:15 Large Software Systems, L. Nigro ------------------------------------------------------------------ A New Approach to Modularization of Large Object-Oriented Systems A. Belkhelladi, B. Lazzerini, F. Marcelloni How to Structure Parallel Applications: Nested Local Aggregates A. Corradi, L. Leonardi, F. Zambonelli Capability Based Protection in a Persistent Object-Based Programming Language M. Hollins, J. Rosenberg, M. Hitchens ------------------------------------------------------------------ 13:30 - 15:00 Implementation and Porting Projects, St. Collins ------------------------------------------------------------------ Native Oberon on the PC Compatible (ISA) Platform F. Arickx, J. Broeckhove, T. Van den Eede, L. Vinck Alpha AXP/Open VMS (Modula|Oberon)-2 Compiler Project G. Dotzel Bringing the Oberon Language to the Macintosh J. Gesswein, R. Ondrus, O. Schirpf ****************** Product Exhibition ****************** Tools for application development, software systems and books will be demonstrated during the conference. ******************* Companion Programme ******************* Ulm is a city with a rich history and many resources. First mentioned in 854, it has attractions such as the gothic Cathedral with the world's highest spire, the historic Fishermen's Quarter, the picturesque Town Hall, and the Danube river where it is still blue. Other facets of Ulm include the giant federal fortress built around 1850, truck and bus factories, industrial research centers, and the University with a world famous medical faculty. You will be able to discover the treasures of Ulm on a guided tour. We will show you the place where the flight of Albrecht Berblinger, one of the first aviators, failed in 1811. Another tour will take you to a romantic little town and the natural beauties surrounding Ulm, above all the Blautopf, end point and climax of a system of underground rivers, hundreds of kilometers long. Another highlight will be the boat tour on the Danube river with striking views of the medieval city. We will try to share with you the beauty and culture of Ulm and make your time in Ulm worth remembering. ------------------------------------------------------------------ Wednesday, September 28, 1994 ------------------------------------------------------------------ 10:00 - 12:30 Tour of Ulm -- historical city and Gothic cathedral 14:30 - 16:00 Visit of baroque style library hall and Wiblingen Monastery ------------------------------------------------------------------ Thursday, September 29, 1994 ------------------------------------------------------------------ 09:00 - 15:00 Daytour to the Blautopf spring, prehistoric museum and sites ------------------------------------------------------------------ Friday, September 30, 1994 ------------------------------------------------------------------ 10:00 - 12:00 Boat tour on the Danube 14:00 - 16:00 Visiting the modern art sculptures on campus, tour of the science park and research institutes ******************* Programme Committee ******************* Andreas Borchert University of Ulm, Germany Antonio Corradi University of Bologna, Italy Brian Kirk Robinson Associates, UK Franz Schweiggert University of Ulm, Germany Gregor Snelting University of Braunschweig, Germany Guenther Dotzel ModulaWare, Germany Gustav Pomberger University of Linz, Austria Hanspeter Moessenboeck University of Linz, Austria Herbert Klaeren University of Tuebingen, Germany Jacques Farre University of Nice, France Jim Cooling University of Loughborough, UK John Gough Queensland University of Technology, Australia Juerg Gutknecht ETH Zuerich, Switzerland Juergen Uhl IBM, Germany Libero Nigro University of Calabria, Italy Marjan Spegel Stefan Institute, Slovenia Marwan M. Al-Akaidi De Montfort University, UK Peter Schulthess University of Ulm, Germany Peter Moylan University of Newcastle, Australia Randy Bush PSG, USA Steven Collins Real Time Associates, UK Wolfgang Hanika Daimler Benz, Germany Wolfram Lippe University of Muenster, Germany ******************** Organizing Committee ******************** Peter Schulthess Chairman, University of Ulm, Germany Alfred Lupper OC Director, University of Ulm, Germany Franz Schweiggert University of Ulm, Germany Marwan Al-Akaidi De Montfort University, UK Andreas Borchert University of Ulm, Germany Jim Cooling University of Loughboruough, UK ******************** In Co-operation with ******************** Gesellschaft fuer Informatik e.V., Fachgruppe 2.1.3, 2.1.4 Schweizer Informatiker Gesellschaft, Fachgruppe Oberon British Computer Society, Modular Languages SIG Daimler Benz AG, Forschungszentrum Ulm NC-Gesellschaft fuer neue Technologien Forschungsinstitut fuer angewandte Wissensverarbeitung, Ulm IBM Deutschland, Entwicklungs GmbH ----------------------------------- Cut here --------------------------------- ****************************************************************************** Registration Form ****************************************************************************** Yes, I want to join the Joint Modular Languages Conference in Ulm. Name: Name on Badge: Affiliation: Mailing Address: Postal Code: City: Country: Daytime Phone Number: Fax Number: E-mail Address: [ ] Do not include my mailing address on meeting attendee lists. Please mark [X] the sessions you want to attend and calculate the total amount. ================================================================== | Tutorials | Regular | Authors and | Students** | | | | SIG Members* | | ------------------------------------------------------------------ | C++ | [ ] DM 220 | [ ] DM 220 | [ ] DM 220 | ------------------------------------------------------------------ | Oberon | [ ] DM 220 | [ ] DM 220 | [ ] DM 220 | ================================================================== | Conference | [ ] DM 360 | [ ] DM 320 | [ ] DM 50 | ================================================================== | Banquet | [ ] DM 60 | [ ] DM 60 | [ ] DM 60 | ================================================================== | Total | DM | DM | DM | ================================================================== *) Members of involved GI, SI, and BCS SIGs should indicate their affiliation number. **) Full time students are asked to present their original student card with picture at the conference registration desk. Student price does not include conference proceedings. ================================================================== | Companion Programme | all persons | ================================================================== | Wednesday | [ ] DM 20 | ------------------------------------------------------------------ | Thursday | [ ] DM 40 | ------------------------------------------------------------------ | Friday | [ ] DM 20 | ================================================================== | Total | DM | ================================================================== ------------------------------------------------------------------ | Total Conference, Tutorials, | DM | | Banquet | | ------------------------------------------------------------------ | Total Companion Programme | DM | ================================================================== | Total Amount | DM | ================================================================== Method of Payment: Payable to: JMLC Conference 1994, University of Ulm [ ] Transfer to: ULMV DE 66002 Illertisser Bank Sorting Code of Bank (BLZ): 731 915 00 Account No.: 702 505 005 [ ] Cheque enclosed [ ] Visa [ ] Diners Club [ ] American Express [ ] MasterCard/EuroCard Card Number: Expiration Date: Cardholder Name Signature: ----------------------------------- Cut here --------------------------------- Please send registration via surface mail to JMLC Conference Secretary Verteilte Systeme, Informatik Universitaet Ulm Oberer Eselsberg O-27 D-89069 ULM, Germany or by fax to: ++49 (731) 502-41 42 --------------------------------------------------------- Alfred Lupper, Computer Science Dept., ------- University of Ulm, D-89069 Ulm, Germany - o - Phone: ++49 731 502 4139 FAX: ++49 731 502 4142 --- E-Mail: lupper@informatik.uni-ulm.de - ---------------------------------------------------- Note: Visit the Joint Modular Languages Conference Date: 28th-30th September 94 Location: University of Ulm, Germany ---------------------------------------------------- -- _______________________________________________________________________________ Andreas Borchert, University of Ulm, SAI, D-89069 Ulm, Germany Internet: borchert@mathematik.uni-ulm.de ======================================================================= 81 === Date: 13 Sep 1994 17:56:10 GMT From: rlk@rational.com (Bob Kitzberger) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? Scott E. Preece (preece@urbana.mcd.mot.com) wrote: : Yes, static typing allows you to find a specific class of defects early : in the process. However, most dynamic type checking would find most of : those same problems equally earely in the process. In my experience, : the enormous bulk of the type errors I hit are trivia - typos and : mistakes in changing a variable from one type to another in some places : but not in others. Virtually all of them would have been caught by : run-time checks the first time I tried to run the program (the : equivalent of their being caught at the first compile). So, how about those bugs that static typing would have caught yet were not exercised at run time, and therefore not caught? Are they lying in wait for 100% coverage testing? .Bob. -- Bob Kitzberger Rational Software Corporation "Though the boys throw stones at frogs in sport, yet the frogs do not die in sport but in earnest." - Plutarch ======================================================================= 82 === Date: 13 Sep 1994 19:50:49 GMT From: ram+@cs.cmu.edu (Rob MacLachlan) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <3536sa$5se@cantaloupe.srv.cs.cmu.edu>, Robert Harper wrote: >I'd like to point out a fallacy that appears to pervade this >discussion: it is simply not the case that dynamic and static typing >are of equivalent expressive power. Actually, the falsity of this equivalence seems to be the only thing that everyone agrees on. >losing track of the fact that static typing is strictly more expressive than >dynamic typing [...] can enforce invariants statically that are in no way >checkable at run time. This may be true, but it is also true (as you obliquely say later on) that dynamic type systems can signal the violation of invariants that are in no way checkable at compile time, for example in Common Lisp: (the nil (do-I-halt?)) This expression asserts that this call to the do-I-halt? function never returns (NIL is Common Lisp's bottom type.) It is easy to construct type systems for which static checking is not computable. The question is what advantages (if any) derive from the use of "dynamic" type systems which guarantee to detect errors during execution. I think that a great deal of the disagreement over type systems stems from differing meanings of the term "type". I get the impression that for some people "dynamic type" is an oxymoron, since for them the whole point of types is to enable static analysis. >For example, one cannot tell by the bit pattern whether the value in a >variable represents a "set" or a "time of day" or a "favorite color of the >author of the program". This is the reason that dynamic type systems always add extra bits to each object. This results in a potential efficiency penalty, but no loss of power. >[...] the static discipline, if it is to be decidable, must provide only >sufficient conditions [... cannot] rule out cases where the properties obtain >but the proof cannot be expressed in the type system to hand. [...] however, >that the possibility exists, at least in principle, for bringing to bear >arbitrary mechanical checking procedures for proving that invariants hold, >limited only by the willingness of the programmer to instruct the compiler why >an invariant must hold. No such option is open in the dynamic case. This touches on my favorite fallacy in this discussion, which is that dynamic and static typing are mutually exclusive. Static systems can be augmented with dynamic rules without giving up their ability to prove that statically typed program portions contain no static type errors. I very much approve of the idea of the language implementation and programmer engaging in a dialog about the type-correctness of the program, but I don't believe that programmers must be forced to prove type-correctness before executing the first line of code. This is not an argument from "principle": real widely used dynamic language implementations such CMU Common Lisp do static type checking. The key difference between the normal "static checking" and the approach taken in CMU CL is that: 1] Compile-time type warnings are not fatal; the program can still be executed until the erroneous portion is reached, and 2] Compile-time type warnings are only given then the compiler can prove that a particular portion of the program can *never* be executed without a type error. In the "static typing" approach, any compile-time type error is fatal, and type errors are signalled whenever the compiler can't prove that type errors will *always* be avoided. Obviously, the "static" always-safe rule can make stronger runtime guarantees than the no-proven-error rule, but the pragmatic concerns of other contributors to this thread are significantly helped by static checking for provable errors. For example, if interfaces are typed as strongly as possible, then static interface-mismatch errors will generally be caught. Rob MacLachlan ======================================================================= 83 === Date: 13 Sep 1994 20:48:35 GMT From: connolly@ulua.hal.com (Dan Connolly) Subject: efficient M3 runtime for LINUX: RTHeapDepC.c? I'm working on enhancing the modula-3 port of LINUX to synchronize the garbage collector heap with the virtual memory subsystem. I started with linux 1.0.9 and the M3 binary distribution for LINUX by Michel Dagenais at: ftp://ftp.vlsi.polymtl.ca/pub/m3/linux/ I upgraded from linux 1.0.9 to 1.1.18 without incident -- for unrelated reasons. But even simple M3 programs like 'plaid' would stop to garbage collect. I asked if this had something to do with the fact that VM = FALSE in LINUX/RTHeapDep.i3, and Bill Kaslow said yes, that's exactly the problem. He said that nobody has yet done the work to get the memory protection stuff to work with the garbage collector under LINUX. So I'm going to give it a try. The first obstacle was that mprotect() is not included in the 1.1.18 version of the linux kernel. So I have upgraded to 1.1.45. The patches supplied by Bruno Haible in <351kkg$g5n@nz12.rz.uni-karlsruhe.de>, when applied to the 1.1.45 source, would not build. So I assume that they are patches to an earlier version of the kernel, and that the issue has been resolved by the 1.1.45 kernel. *** How can I test that mprotect() actually works? *** I doubt that little 20-line C test programs will test it sufficiently. Anyway... Now I'm deep in the bowels of libm3/src/runtime/LINUX, trying to make it look more like libm3/src/runtime/SPARC and/or libm3/src/runtime/DS3100. I thought the tricky part was going to be in RTHeapDep.m3, but I discovered a whole new ball of wax in RTHeapDepC.c . The comments there [thank god for the comments in the M3 code. How do the linux guys get by without comments? Some form of telepathy that I'm not aware of?] say: /* This file implements wrappers for almost all LINUX 1.1.45 system calls that take pointers as arguments. These wrappers allow the system calls to take arguments that might point to the traced heap, which may be VM-protected in the LINUX implementation of the collector. The wrappers read and write the referents of all pointers about to passed to the system call, which ensures that the pages are not protected when the call is made. Each wrapper is a critical section, with RTou__inCritical non-zero, so that another thread cannot cause the pages to become reprotected before the system call is performed. A few system calls are not handled here, or are handled only partially. This restricts the system calls that can be made from Modula-3, or from libraries that are passed pointers into the Modula-3 traced heap. These system calls are: .... */ The SPARC version of RTHeapDepC.c yields zillions of compile errors on LINUX. gcc is picky, and you have to get this stuff right, I guess. How did you come up with the list of syscalls that need wrappers? How did you distinguish them from the ones like wait, wait3, ...? (Some calls in Section 2, including wait, wait3, sigvec, sigprocmask, and sigsuspend, are already wrappers for other system calls; it is not necessary to reimplement them here.) Anyway... I suppose I can plot through most of this eventually, but it looks tedous and error-prone. I'm making slow progress, but any help would be appreciated. Dan -- Daniel W. Connolly "We believe in the interconnectedness of all things" Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010 http://www.hal.com/%7Econnolly/index.html ======================================================================= 84 === Date: 14 Sep 94 13:07:54 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: Pickles and Libraries Amer brings up a good point that it would be nice if one could pickle references to all reasonable data types, especially ones in the library. I think there is a problem with branding in presence of generics. Specifically, how do you brand the generic type Table.Default? Two fixes are needed: - change the language to support not only literal brands but constant brands. This was mentioned on this forum a while ago and happens to be the it is the way the SRC compiler works. - get a constant TEXT representation for the name of the type of the instantiation of the generic, so that you can brand it in the generated code. In general, you want to parameterize the brand by all the parameters of the generic module. One workaround that you can do right now is to expect each parameter to the generic modules to include CONST name: TEXT, so that the generic module can use this name to generate the tag for the instantiated type. Enforcing this for Table.ig means adding extra requirements on all parameters of Table. By the way, at least some non-generic parts of libm3 do use explicit brands. See for example, TextF.m3. For now, you can register picklers to write out and read in the table correctly. It is a pain, but it should work. -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 85 === Date: 14 Sep 1994 14:42:25 GMT From: diwan@cs.umass.edu (Amer Diwan) Subject: Pickles and Libraries I have found Pickles to be a great tool. And I think the libraries distributed with SRC Modula-3 3.x are also great. But I do have one complaint. Pickles may not work correctly if implicitly branded types are being pickled. The exported data structures in the libraries (e.g., sorted tables) are revealed with implicit brands. Thus, if my "graph" has references to library data structures, then I may not be able to pickle the graph. Is there any reason against doing explicitly branding in the libraries? Perhaps a prefix should be reserved at least for the standard libraries so that their brands don't conflict with user defined types. Amer -- ------------------------------------------------------------------------------ Amer Diwan Department of Computer Science Object Systems Lab University of Massachusetts diwan@cs.umass.edu Amherst, MA 01003 (413) 545-0256 ======================================================================= 86 === Date: Thu, 15 Sep 1994 00:45:36 GMT From: kers@hplb.hpl.hp.com (Chris Dollin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? rwh@cs.cmu.edu (Robert Harper) writes: Adding extra tag bits does not preclude "spoofing", ie creation of an object that appears to be a value of an abstract type, but for which the key invariants fail to hold. eg, marking 23 as a SET. You can check that the value is tagged SET but it doesn't mean anything. A rather weak argument; that an implementation of Set in a statically typed language passes all the static type checks doesn't mean that it actually implements Set (eg I might simply have forgotten to eliminate duplicates). If there's a difference here it needs amplifying. [Also, the dynamically typed languages I have used provide no operations to let users mark objects with types as they please, eg, marking 23 as a Set. (Well, actually they *do*, with flashing red warnings that This Is Dangerous And Can Break Your Code. I'd need convincing that statically typed languages don't also have such loopholes provided.)] -- Regards, | ``"I can't suit myself," said Weinbaum, a little petulantly. Kers. | "I work for the Government".'' - Blish, "The Quincunx of Time". ======================================================================= 87 === Date: 14 Sep 1994 15:17:34 GMT From: werner@cs.sun.ac.za (Werner Fouche ) Subject: M3 for embedded systems programming! Has anyone concidered the pros and cons of using M3 for programming embedded systems? Better still, does anybody have experience in programming embedded systems in M3. The only downside I can think of is the fairly large run-time (garbage collecter, thread manager, exception handling code) that must be supported. I have written a micro-kernel in Modula-2 and found its non-existent run-time environment to be a blessing. Using Modula-3 for the same purpose would of course require that one get its run-time environment to work on the bare hardware, before you can start writing kernel code! How much of an effort would that be? Does embedded systems not require a stripped-down version of the Modula-3 run-time, say a simple garbage collecter (supporting only reference counting), no support for threads (a kernel usually creates its own abstraction for threads), exception handling will be useful so I think one should leave that in. What do YOU think?? Werner ======================================================================= 88 === Date: 14 Sep 1994 14:28:12 GMT From: rwh@cs.cmu.edu (Robert Harper) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? > This may be true, but it is also true (as you obliquely say later on) that > dynamic type systems can signal the violation of invariants that are in no > way checkable at compile time, for example in Common Lisp: > > (the nil (do-I-halt?)) > This does not constitute a _check_ for halting (obviously) because it does no always return. Adding extra tag bits does not preclude "spoofing", ie creation of an object that appears to be a value of an abstract type, but for which the key invariants fail to hold. eg, marking 23 as a SET. You can check that the value is tagged SET but it doesn't mean anything. Static type systems cannot be "augmented with dynamic checks" because you cannot check the properties of interest dynamically. Moreover, so-called dynamic typing compromises run-time representations and precludes important optimizations that cannot be performed unless you have a global program analyzer. (Hence no separate compilation.) And, of course, the analyzer is a form of static type system. Bob Harper ======================================================================= 89 === Date: 14 Sep 1994 16:39:28 GMT From: klon@wildsau.idv.uni-linz.ac.at (Oliver Hable) Subject: GRAPHICAL LIBRARY FOR MODULA ALL WHO WANNA HAVE A GRAPHICAL LIBRARY FOR TS MODULA 2.x / 3.x SHOULD TRY XVGA_V1 ITS ON GARBO.UWASA.FI OR MAIL TO: KLON@WILDSAU.IDV.UNI-LINZ.AC.AT ======================================================================= 90 === Date: 14 Sep 1994 20:12:29 GMT From: ram+@cs.cmu.edu (Rob MacLachlan) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <35719s$7tv@cantaloupe.srv.cs.cmu.edu>, Robert Harper wrote: >> (the nil (do-I-halt?)) > >This does not constitute a _check_ for halting (obviously) because it >does no always return. Well, if "checking" by your definition only applies to decidable problems, then I can see how you can argue that by definition static type checking is the only possibility. Language implementors often refer to "array bounds checks" and other automatic run-time assertions as "checks". >Adding extra tag bits does not preclude "spoofing", [...] eg, marking 23 as a >SET. You can check that the value is tagged SET but it doesn't mean >anything. As others have noted, this is simply not true. In type-safe dynamic languages such as Lisp and Smalltalk, the type tags are meta-information which can be examined but never arbitrarily modified. >Static type systems cannot be "augmented with dynamic checks" because >you cannot check the properties of interest dynamically. I don't deny that there may be non-local "properties of interest" which can't be checked dynamically. I claim that neither dynamic nor static typing is formally more powerful than the other. Which is "better" rests on real-world considerations such as human factors, development processes and market demand. In some situations, a combination of the two may be "best". >Moreover, SO-CALLED DYNAMIC TYPING[caps RAM] compromises run-time >representations I gather you are in the camp who considers "dynamic typing" an oxymoron. You are correct that the size, complexity and restrictive invariants of run-time representations cause real efficiency problems in completely dynamically typed languages (such as Lisp.) A major part of this thread discusses hybrid languages such as Objective-C where dynamic typing doesn't affect crucial primitives such as arithmetic. >and precludes important optimizations that cannot be performed unless >you have a global program analyzer. (Hence no separate compilation.) I'm guessing that you are referring to not being able to choose good representations for values based on their types. But this ignores three crucial concepts which have been exploited in real dynamic language implementations: 1] Dynamic languages such as Common Lisp have type declarations which allow program fragments to be statically typed. 2] Statistical observations about types can be nearly as good as guarantees about types. For example, the strictly dynamic language Self uses heuristics and profiling information to pick off the probable cases and generate good code for them. 3] Separate compilation is a very fuzzy concept primarily defined by the historical interface to file-based linkers. Lisp, Smalltalk, Self, and other fully dynamic languages don't use conventional linkers. Because of this, these languages do a much better job of achieving the primary goal of separate compilation, namely quick recompilation of incremental changes. >And, of course, the analyzer is a form of static type system. Yes, that's pretty obvious. That's why I as a dynamic language implementor am interested in static type systems. The difference between using a static type system and having a "static language" is that in a static language programs can't be run until they have been written in a way which allows the compiler to prove type-correctness. During early and ill-defined stages of development, many programmers have found dynamic languages very useful because they don't force the programmer to worry about rare boundary conditions. Dynamic languages usually allow programs to be run when they contain references to procedures that haven't even been written yet, allowing the functional backbone of a program to be tested and refined without filling in peripheral details. Rob MacLachlan ======================================================================= 91 === Date: 15 Sep 94 07:35:14 From: fn00@gte.com (Farshad Nayeri) Subject: Re: Threads and heavyweight forks I suspect it is the alarm. I think you have two choices: 1. Disable alarms by hand. 2. Use the Process interface from the OS package of Libm3, which takes care of everything for you, I think. This would also make your program more portable, but it would mean taking the plunge and upgrading to 3.x. Here is a message that Bill Kalsow sent a summer student of ours when he was getting a similar problem with Unix.System (Thanks Bill!). The code may be a little stale to work with version 2.11 but you get the idea. I believe this is a subset of what os/POSIX/PosixProcess.m3 does, so you may want to look at the Modula-3 3.x archives or the Interface Police document for more information. (Michel, can we add this question to the FAQ?) Incidently, how is it going with using Motif 1.2 with Modula-3? Have you converted the .h files? Just wondering... -- Farshad --- cut here ---- From: kalsow@src.dec.com To: s9205@gte.com (Rohit Gupta) Cc: m3-request@Pa.dec.com, rgupta@gte.com, fn00@gte.com, kalsow@Pa.dec.com Subject: Re: System commands from within Modula-3 programs Date: Thu, 16 Jul 92 09:51:12 -0700 When your first thread is forked, the thread runtime starts the virtual timer signal to trigger thread preemption. Trestle forks threads so the timer is started. Cstdlib.system does a Unix fork of your shell. That new shell inherits the active virtual timer, but is unprepared to handle it. The fix is to disable the virtual timer before calling Cstdlib.system and then re-enable it when it returns. Note that your trestle application will be unresponsive during the time that the timer (and hence thread preemption) is disabled. Here's some prototype code: (* Disable the timer BEFORE forking. *) VAR nit := Utime.struct_itimerval { it_interval := Utime.struct_timeval {0, 0}, it_value := Utime.struct_timeval {0, 0}}; BEGIN IF Utime.setitimer (Utime.ITIMER_VIRTUAL, nit, oit) = -1 THEN Gripe (-1, "Couldn't disable virtual timer."); END; END; TRY ...... call Cstdlib.system .... FINALLY VAR nit: Utime.struct_itimerval; BEGIN IF Utime.setitimer (Utime.ITIMER_VIRTUAL, oit, nit) # 0 THEN Gripe (-1, "Couldn't re-enable virtual timer."); END; END; END - Bill Kalsow -- Farshad Nayeri nayeri@gte.com ======================================================================= 92 === Date: Wed, 14 Sep 94 18:46:31 PDT From: frode@toaster.SFSU.EDU (Frode Odegard) Subject: Re: M3 for embedded systems programming! I am trying to get a client in Europe to consider Modula-3 for embedded systems. Their main problem is actually the lack of commercial support for Modula-3; I'm trying to do something about this, but it's a catch-22: they won't be entierly comfortable unlesss other people are also paying us to do a commercially supported system, and nobody wants to be first. :-) [Currently the client does all their sw development in Modula-2.] What processors are you interested in? Frode Odegard Odegard Labs, Inc. (usually frode@odegard.com) ======================================================================= 93 === Date: Wed, 14 Sep 1994 22:00:59 GMT From: george@bcstec.ca.boeing.com (Harry G. George) Subject: Threads and heavyweight forks I am stuck on a thread problem. This application works when I do not use threads, but with threads I get (apparently) a spurious timer alarm. ---background--- I am running Modula-3 2.11 on sun0s 4.1.3. I have an X11R5/Motif 1.2 application in which I run two threads: Xthread does X stuff GAthread runs a genetic algorithm At one point, Xthread is waiting for a Signal from GAthread. In GAthread, I am trying to kick off another application (which will eventually talk to my app via an EditRes-like protocol). I try to start the app using a normal (heavyweight) Unix.fork and Unix.execv. The "other" app starts to run for a while, and then dies. The precise timing seems random. By doing a Unix.system("trace otherapp"), I found that the last line was recfrom(3, sh: 883 Virtual time alarm [NOTICE: no closing paren or = ] Then I get kicked back to the parent process. I am guessing that this alarm is an artefact of the thread scheduler still running in the parent process. I would like to clean it up in the child process before doing the exec (just as one closes file descriptors). I don't see how. ---questions--- 1. Anyone already doing this (doing a process fork from inside a thread)? From an X app, to run another X app? 2. Is the alarm the culprit? 3. Is there a way to clean up the alarm so my "other app" can proceed normally? 4. Any other hints??? ------------- Thanks in advance, -- Disclaimer: Any opinions expressed herein are my own and not those of The Boeing Company. Contact: Harry George, BCAG Advanced Software Technology Phone: (206) 237-6915 Org: 6-6541 M-S: 6H-WT ======================================================================= 94 === Date: 14 Sep 94 23:24:40 From: reddy@cs.uiuc.edu (Uday S. Reddy) Subject: Final CFP: State in Programming Languages Call for Papers The Second ACM SIGPLAN Workshop on STATE in Programming Languages (SIPL) Jan 22, 1995 San Francisco Held in conjunction with POPL '95 Programming languages have been state-based since their inception. After a period of relative unpopularity, when research focused on declarative languages, interest in the treatment of state has been renewed. Research is increasingly devoted to finding a symbiotic relationship between the semantic foundations of declarative languages and the pragmatic handling of state in more conventional languages. This workshop brings together researchers from various areas, interested in the common issues of state manipulation in high-level programming languages. The first workshop in this series (SIPL '93) was held in Copenhagen in conjunction with FPCA '93. The proceedings are available as a Yale technical report YALEU/DCS/RR-968. A special issue of the Journal of Lisp and Symbolic Computation is being published as a follow-up to SIPL '93. Submissions are invited for the second workshop to be held in conjunction with POPL '95 in San Francisco. The workshop addresses the fundamental issues of expressing, manipulating, and reasoning about state in high-level programming languages. The range of topics includes operational and denotational models of state, assignment and references, semantics of object- oriented programming, calculi of state and methods to reason about state. Novel methods for expressing and controlling state- manipulation such as linear type systems, effect systems, and monads are also of interest. Formal presentations of results, research in progress, tutorials, and topical discussions are among the possible venues for interaction. Program Committee: Stephen Brookes, Carnegie-Mellon University Kim Bruce, Williams College John Launchbury, Glasgow University and Oregon Graduate Institute Ian Mason, Stanford University Peter O'Hearn, Syracuse University Andrew Pitts, Cambridge University Uday Reddy, University of Illinois (Chair) Mads Tofte, University of Copenhagen POPL General Chair: Ron Cytron, Washington University Submission: We solicit submissions on original research not submitted or published elsewhere. Authors should submit 8 copies of a detailed summary not to exceed 5000 words (approximately 10 pages) to the program chair by Sep 30, 1994. The cover page should include a return postal address and an electronic mail address (if possible). Please follow the same guidelines as for writing summaries for the POPL conference. These are available by anonymous FTP from directories ftp.cs.cmu.edu:/user/petel/popl95 and cs.uiuc.edu:/pub/reddy/sipl This information may also be accessed via Mosaic/WWW at http://vesuvius.cs.uiuc.edu:8080/sipl/index.html Authors will be notified of acceptance of their paper by Nov 15, 1994. Final versions of accepted papers are due on Dec 22, 1995. Accepted papers will appear in a technical report to be distributed at the workshop. Correspondence should be sent to: Prof. Uday Reddy SIPL '95 Department of Computer Science University of Illinois 1304 W. Springfield Avenue Urbana, IL 61801 U.S.A. E-mail: sipl@cs.uiuc.edu -- Uday Reddy Department of Computer Science University of Illinois 1304 West Springfield Avenue Urbana, IL 61801. tel: (217) 333-3412 fax: (217) 333-3501 email: reddy@cs.uiuc.edu ======================================================================= 95 === Date: 15 Sep 1994 15:42:10 GMT From: adiwan@cs.cmu.edu (Amer Diwan) Subject: M3build and recompilation I have 4 modules such that they are linearly related such that each module has a concrete revelation for a type that is a subtype of a type in the previous module. M1.T <: M2.T <: M3.T <: M4.T The problem is that when I change one of the modules, m3build recompiles the other modules as well and says "new opaque info: recompiling". This is just a performance consideration and is thus inacceptable in the quick modify-compile-test cycle that I am operating under. Is there a way to disable this recompilation? ======================================================================= 96 === Date: 16 Sep 1994 14:59:24 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: M3build and recompilation In article <359q0i$2dv@cantaloupe.srv.cs.cmu.edu>, adiwan@cs.cmu.edu (Amer Diwa n) writes: > The problem is that when I change one of the modules, m3build > recompiles the other modules as well and says "new opaque info: recompiling". > This is just a performance consideration and is thus inacceptable in the quic k > modify-compile-test cycle that I am operating under. Is there a way > to disable this recompilation? Yes, add m3_option ("-once") to your m3makefile. - Bill Kalsow ======================================================================= 97 === Date: Fri, 16 Sep 1994 20:48:40 GMT From: ckingsto@undergrad.math.uwaterloo.ca (Craig Andrew Kingston) Subject: Re: SOLICITATION: Call for organized M3 port to OS/2 In article , wrote: >Submitted by: Craig Kingston (ckingsto@undergrad.math.uwaterloo.ca) >Source: Craig Kingston (ckingsto@undergrad.math.uwaterloo.ca) >Date received: 1994 September 15 >Date posted: 1994 September 15 >------------------------------------------------------------------------------ - >I have seen plenty of people saying they tried to / are / or hope >to port M3 to OS/2, but there doesn't seem to be any results as of >yet. > >So I am calling for people who > - are already attempting a port > - have attempted a port and have advice/code to share with us > - are experienced in porting software to offer advice > - people who feel they have special skills to contribute > (i.e. documenting, testing, low level coding, etc) > - has some interest and wishes to see if they can help. > >Send Mail to myself > CRAIG KINGSTON > ckingsto@undergrad.math.uwaterloo.ca > >Don't worry about how much time you have available until a schedule >is set, if you are short of time we may just use you for consultation >of you can help out when you get extra time - I suspect this could take >some time - not sure what is involved as of yet! > >Please include in your letter your skills, experience (even if none), >and the amount of time you have available (so I can get an idea of how >many human/hours per skill are available). Also please include any other\ >important information (like how/when to contact you). > >and from there we shall orgainize a plan of attack on the compiler. reposted (not sure if first post was successful) ======================================================================= 98 === Date: Fri, 16 Sep 1994 16:45:16 GMT From: Bob Hathaway Subject: Comp.Object FAQ Version 1.0.6 (9-15) Announcement [The comp.object FAQ is now at zaphod.uchicago.edu:/pub/CompObj6.faq[.Z]. The automated server should post to comp.object and the answers newsgroups soon.] Archive-name: object-faq/announce Last-Modified: 9/15/94 Version: 1.0.6 This announces the September version 1.0.6 of the Comp.Object FAQ - just in time for my birthday! It has many updates and corrections and has several very up-to-date appendices on object-oriented methodologies and systems. While a new section on miscellaneous commercial systems and libraries is still in the works for completeness, this document may very well comprise the latest and most up-to-date collection of object-oriented systems and terms in the world today! There is also a potential upcoming merge with the new C++ Libraries FAQ. I will try to update the FAQ monthly with system entries and information from the net. I have a new TQM system in place which should proceed from the old Level 1 to Level 5 in no time - not hard for a one man job. *Many* thanks to the patience of those sending system updates and corrections, my new system should provide fast acknowledgement, inclusion (within a few weeks) and tracking, and 6 sigma quality should provide essentially defect free performance for the FAQ. Sending comments, suggestions, additions, updates, corrections, and new system and site entries is strongly encouraged and should be directed to the author at rjh@geodesic.com. The FAQ is posted to the comp.object, comp.answers and news.answers newsgroups and is available via anonymous ftp from zaphod.uchicago.edu and rtfm.mit.edu, although new versions may take a short period of time to be installed. Anonymous FTP Sites and Hypertext Server: anonymous@zaphod.uchicago.edu:/pub/CompObj6.faq(.Z) (128.135.72.61) anonymous@rtfm.mit.edu:/pub/usenet/comp.object/*_Part_* http://cui_www.unige.ch/OSG/FAQ/OO-FAQ/index.html Mail Server: (See also section 1.24) mail mail-server@rtfm.mit.edu Subject: send usenet/comp.object/* Zaphod is preferred over rtfm for anonymous ftp retrieval, as it provides a single file. Rtfm contains the FAQ as posted. To use the hypertext system, see APPENDIX E, entries 27. Again, a short period of time may be required to retrieve the latest version from anonymous ftp, allowing the posted version to propagate and get out as quickly as possible. Thank you to the many people who have contributed their time and effort to help this document spread the word about object-oriented technology and available systems! It is hoped it will be most useful in that endeavor. Best Regards! bob ======================================================================= 99 === Date: 19 Sep 1994 00:02:16 GMT From: vbidarko@tatung3.cs.ttu.edu (Vinod Bidarkoppa) Subject: OBJECT ANALYSIS AND DESIGN NOTE : This is for people who are involved directly or indirectly with Object oriented software development. Please fill up the required information and mail it to vbidarko@cs.ttu.edu. Students and faculty are also welcome to reply. Thanks in advance. *************************************************************************** Questionnaire on requirements of Object Oriented Analysis and Design Methodo logy INTRODUCTION This survey is to obtain information from the real world regarding the requirements of OOAD methodology. This is a part of masters thesis research in the Computer Science department at the Texas Tech University. All the information will remain anonymous. The information from the questionnaires will be used to specify a set of practical requirements for an OOAD and also to evaluate the existing methodologies based on this. Completed questionnaires may be sent by post or e-mail to: Vinod Bidarkoppa Department of Computer Science Texas Tech University Mail Stop 3104 Lubbock, TX 79409 E-mail : vbidarko@cs.ttu.edu bed85@ttacs1.ttu.edu ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- ----------------------- 1. GENERAL INFORMATION 1.1 Organization a) Name : b) Address : c) City : d) State : 1.2 Area(s) of Company business ( Mention areas which use OO ) 1.3 Personal Information a) Name : b) Your role in the organization : 1.4 OO Methodologies used at present in your organization ( e.g. Booch, Coad and Yourdon, Shlaer and Mellor,OMT, Wirfs-Brock) an d in which projects / applications. e.g. G. Booch (1994 ed.) Realtime Process Control 2. METHODOLOGY REQUIREMENTS ( Please rate one of the categories from A to E. ( A= Extremely Important, B= Important, C= Not so important, D= Unimportant, E= No comment) 2.1 Structural Concepts 2.1.1 Degree of OO support 1. The methodology should support the usual meaning of the terms object (instance) and class. ( ) 2. The class should be described in terms of its distinct parts: an interface and body. ( ) 3. Encapsulation and information hiding should be supported by the methodology ( ) 4. The methodology should support metaclasses ( ) 2.1.2 Relationships 1. The methodology should support : i) Single inheritance ( ) ii) Multiple inheritance ( ) iii) Aggregation (container ) ( ) iv) Associative ( ) v) The associative relationships should include cardinalities ( ) 2. The methodology should include / distinguish subclassing ( inheritance implementation with redefinition and / or restriction as well as addition ) and subtyping ( just addition). ( ) 2.2 Behavioral Concepts 2.2.1 Instances 1. The methodology should provide facility for dynamically creating and destroying objects. ( ) 2. The methodology should support i) Notion of object state. ( ) ii) Export Control / Visibility e.g. Private, Protected, Public ( ) iii) Persistent Objects ( ) iv) Concurrent objects ( ) v) Embedded Objects ( ) vi) Active ( instances executing in parallel) and passive (executing in serial with others) instances ( ) 2.2.2 Messages or events 1. The methodology should facilitate message passing that involve : i) Static Binding ( ) ii) Dynamic Binding ( ) 2. The methodology should support the following kinds of polymorphism : i) Inclusion ( ) ii) Operational ( ) iii) Parametric ( ) 3. The methodology should include the following modes of communication i) Synchronous ( ) ii) Asynchronous ( ) note : Synchronous is where the sender suspends execution till the receiver processes the message and asynchronous is where the sender continues processing. 2.3 Process 1. The methodology should prescribe steps / guidelines for identifying : i) Semantic (Abstract) classes ( ) ii) Attributes ( ) iii) Methods ( ) iv) Allocating attributes and methods to classes ( ) 2. The methodology should specify guidelines for identifying the following relationships : i) Generalization ( ) ii) Aggregation ( ) iii) Association ( ) iv) Cardinalities ( ) 3). The methodology should be able to specify dynamic behaviors through the following : i) Message connection ( ) ii) Instance connection ( ) iii) Object interaction diagrams ( ) iv) State machine ( ) v) Event and state generalization ( ) vi) Interactions within the state ( ) vii) Timing diagrams ( ) viii) Formalization of abnormal behavior ( ) 4). The methodology should prescribe guidelines to identify and decomp ose : i) Structural complexity ( ) ii) Dynamic complexity ( ) 2.4 Design features 1. The methodology should prescribe guidelines for the following : i) Specifying system architecture ( ) ii) Specifying and integrating interface classes for human interaction ( ) iii) Specifying and allocating tasks / processes to processors ( ) iv) Specifying and integrating classes for database management ( ) v) Data structures and pseudo code for the application classes ( ) vi) Refinement of overall analysis and design in scope of all the new classes added ( ) 2. The methodology should prescribe OOSE features regarding : i) Release planning ( ) ii) Work products ( deliverables) review ( ) iii) Incremental development ( ) 2.5 Representation 2.5.1 Static Views 1. Class and Object ( ) 2. Attributes ( ) 3. Methods ( ) 4. Generalization ( ) 5. Aggregation ( ) 6. Cardinalities ( ) 2.5.2 Dynamic views 1. Instance connection ( ) 2. Visibility ( ) 3. Message connection ( ) 4. Control / timing ( ) 5. Concurrency ( ) 6. Object interaction diagrams ( ) 7. State charts ( ) 8. Nested states ( ) 2.5.3 Constraints 1. On structure ( ) 2. On behavior ( ) 2.5.4 Complexity 1. Static structure ( ) 2. Dynamic behavior ( ) 2.6 Miscellaneous The methodology should : 1. Be Scaleable ( ) 2. Have semantic and syntactic definitions for all notations ( ) 3. Use same notations for analysis and design ( ) 4. Provide deliverables at every stage ( ) 5. Have case tool support for graphical layout ( ) 6. Have case tool support for simulation / code generation ( ) 7. Check for extensibility ( ) 8. Check degree of coupling and cohesion ( ) 9. Check for consistency ( ) 10. Checks for completeness ( ) 11. Prescribe performance evaluation ( ) 12. Prescribe non-graphical specifications for entities discovered at all stages ( ) 3.0 Comments and suggestions ======================================================================= 100 === Date: Mon, 19 Sep 1994 18:19:46 GMT From: "Steven D. Majewski" Subject: SRC Modula-3 BOOT builds on AIX, but not libm3 I was able to build the BOOT-IBMR2 on AIX 3.2.4, but when I unpacked libm3 and tried to build it, ( 'cd m3lib; m3build -v -V' ) I get this error: [ ... lots of quake lines deleted ... ] | quake: reading "/lv1/users/sdm7g/m3/boot-IBMR2/libm3/src/perftool/POSIX/m3ma kefile" | quake: reading "/lv1/users/sdm7g/m3/boot-IBMR2/libm3/src/pqueue/m3makefile" | quake: reading "/lv1/users/sdm7g/m3/boot-IBMR2/libm3/src/pqueue/pqueue.tmpl" | m3 -w1 -why -g -times -a libm3.a -F/tmp/qkFNDWIF1AAA | | | *** | *** runtime error: | *** Segmentation violation - possible attempt to dereference NIL | *** | | | seconds #times operation | NaN other | --------------------------------------------------- | NaN TOTAL | | bsh: 31253 Abort - core dumped | *** error code 134 (ignored) Any clues ? Has anyone built SRC Modula-3 on AIX lately ? Because of the rather peculiar way the compiler installs, it's pretty hard to get a clue when something goes wrong. Once you've bootstrapped the compiler, your out of the familiar world of 'make' and 'cc', and into 'm3build' and 'quake' and 'm3'. I can't even tell if _in_fact_, the compiler build was successful: no error messages, but I can't even build the simple HelloWorld program until the library is built! - clueless in Modula-3 land, - Steve Majewski (804-982-0831) - UVA Department of Molecular Physiology and Biological Physics ======================================================================= 101 === Date: Wed, 21 Sep 1994 20:01:02 GMT From: 003495h@dragon.acadiau.ca (Mohamed Ali Hussien) Subject: Niklaus Wirth I have to write something about Niklaus Wirth(creator/inventor of Pascal/Modula2) for one of my computer courses. Could anyone out there e-mail me an autobiography of him or anything about him? Or maybe point out to me a gopher/ftp site where I can get hold of such info. Any help will be greatly appreciated ! Thanks in advance .... -- Mohamed Ali Hussien 003495h@dragon.acadiau.ca "If all else fail, read the instructions ..." --- Cann's Axiom. MURPHY'S COMPUTER LAW ======================================================================= 102 === Date: 22 Sep 1994 20:02:33 GMT From: rolf@gundog.lbl.gov (rolf ebert) Subject: Re: M3 for embedded systems programming! If you consider M3 for embedded systems, how about Ada? It has the expressive power of m3 and also the syntax is very close. Both languages have Pascal as an ancestor. You don't have automatic garbage collection in Ada, though. With Ada94, the new standard, you get hooks where you can easily add your own memory manager. There are quite a few compiler vendors out there with specially targeted compilers for embedded systems. In some critical application areas you can also get a customized run-time (e.g. without tasks (aka threads)) mail me if you need more information. Rolf P.S. Please this message was not intended to start another firework over languages. ======================================================================= 103 === Date: 27 Sep 1994 16:18:12 GMT From: adiwan@cs.cmu.edu (Amer Diwan) Subject: Debugging on DECStations It seems that conditional breakpoints do not work while debugging M3 with m3gdb on DECStations. When a conditional breakpoint is reached, the debugger stops regardless of the condition being satisfied and in the info to the breakpoint, the condition is "Invalid expression". Are there any tricks to setting conditional breakpoints? Since news has been very unreliable on the machines I normally use, I would appreciate an email response to this. Thanks. Amer ======================================================================= 104 === Date: 29 Sep 1994 14:41:04 GMT From: kendall@pot.East.Sun.COM (Sam Kendall - Sun Microsystems Labs BOS) Subject: Re: MODULA-3 being used spencer@ERA.COM (Spencer Allain) writes: > I'm hoping that the lack of bandwidth going through this newsgroup isn't due > to little or no use, but that there aren't as many obscure problems that have > to be addressed to the net for a solution. Mostly the latter, I think. The language and its libraries are simple enough to preclude the sort of endless "what are the semantics of this syntax?" questions one gets with C++. Certainly those of us porting the M3 system have questions, but we generally take them up directly with the authors of the code. ---- Sam Kendall Sun Microsystems Laboratories BOS ======================================================================= 105 === Date: Thu, 29 Sep 1994 12:56:24 GMT From: dkenny@actrix.gen.nz (Des Kenny) Subject: Re: Information on teaching OO and Reuse (redux) In article <36b346$50p@uqcspe.cs.uq.oz.au>, Teaching OO Group wrote: > > The following is a rough summary of the responses to my request for informati on > on teaching OO and Reuse. The list is undoubtedly not exhaustive, but it's al l > of the relevant responses I received. > > The list is categorised by languages used in no particular order. > > If anyone would like any more information, please let me know. > > Regards, > > Tim Mansfield > > Teaching Object Orientation Group Dept of Computer Scienc e > University of Queenslan d > Ph: +61 (0)7 365 2956 St Lucia 4072 > email: too@cs.uq.oz.au Australia > > ------------------------------------ > > Smalltalk > --------- > Carleton (first years) > Uni of Colorado > Monash, Caulfield (postgrad) > > Eiffel > ------ > QUT (third year) > UTS (first year) > Monash, Peninsula > Rochester Inst of Tech (moved to C++ at the end of first year) University of Auckland, New Zealand Central Institute of Technology, New Zealand Victoria University, New Zealand ( evaluating Eiffel for teaching OOT ) Canterbury University, New Zealand ( evaluating Eiffel for teaching OOT ) Otago University, New Zealand ( evaluating Eiffel for teaching OOT ) > > C++ > --- > Hamilton College, NY (whole course) > > Ada-83 > ------ > SUNY Plattsburgh (whole course) > Swinburne ? > > Beta > ---- > Uni of Dortmund (first year, first semester) > > > ML > -- > Uni of Dortmund (first year, 2nd semester after Beta) > > Mod3 > ---- > ecole polytechnique de montreal (final year) > > Turbo Pascal > ------------ > Brown University, Rhode Island (first year) > > ======================================================================= 106 === Date: 29 Sep 1994 17:11:11 GMT From: fn00@gte.com (Farshad Nayeri) Subject: Re: MODULA-3 being used In article kendall@pot.East.Sun.COM (S am Kendall - Sun Microsystems Labs BOS) writes: spencer@ERA.COM (Spencer Allain) writes: > I'm hoping that the lack of bandwidth going through this newsgroup isn't d ue > to little or no use, but that there aren't as many obscure problems that h ave > to be addressed to the net for a solution. > Mostly the latter, I think. The language and its libraries are > simple enough to preclude the sort of endless "what are the > semantics of this syntax?" questions one gets with C++. I generally agree with Sam here. We have been using SRC Modula-3 for more than two years now and we are very happy with it. Also, I find that there are fewer religious wars here. I imagine if Modula-3 were more popular, this newsgroup would also get its share of religious wars. However, I agree with Spencer that it would be nice to see a post or two in a week... (Bill, can you please add some obscure features to the next M3 release, so that we have something to discuss? :-) If you are going to be at OOPSLA'94, I recommend that you look into attending either the Modula-3 Tutorial, or the Modula-3 users group meeting (to be announced here shortly). Also, Modula-3 FAQ and the Mosaic Home page should give a good introduction of what is available currently. See http://www.research.digital.com/SRC/modula-3/html/home.html. Please do let us know what you intend to do with Modula-3: commercial software development, prototyping or research software, etc. -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 107 === Date: Thu, 29 Sep 1994 13:21:04 GMT From: spencer@ERA.COM (Spencer Allain) Subject: MODULA-3 being used I have just recently been following this newsgroup because, we weren't subscribed to it before I requested its addition, and was hoping that there would be more discussions going on. I'm not even sure if anyone is using MODULA-3 for any serious large products. I'm currently using C++ for my projects, simply because that is what I have to use. I was weened on MODULA-2 (actually BASIC->FORTRAN->MODULA-2) and still miss it. I was hoping that there would be some discussion on how MODULA-3's style of Object Oriented design compared to C++ or Eiffel, and why some things were better and/or worse. I'm a strong advocate for garbage collection, and was wondering how good it is for MODULA-3. A bulk of my time is spent tracing down memory leaks that cause obscure problems in other (sometimes unrelated) parts of the code, usually stuff that I didn't write but seemed to work fine, until all of its functionality was attempted to be used. I'm hoping that the lack of bandwidth going through this newsgroup isn't due to little or no use, but that there aren't as many obscure problems that have to be addressed to the net for a solution. -Spencer Allain Engineering Research Associates ======================================================================= 108 === Date: 29 Sep 1994 16:03:25 GMT From: gall@infosys.tuwien.ac.at (Harald Gall) Subject: Installation problems on SPARC Dear M3-Experts! I have some problems with installing m3 on a SPARC (SunOS 4.1.3). After having configured the necessary files I start m3boot and get the following: <...> ar: filename RTTypeRecSort_i.o truncated to RTTypeRecSort_i ar: ... <...> ld: Undefined symbol __lib_version *** error code 2 <...> What am I doing wrong? I changed the make to the gnumake, but still things go wrong. Any comments or hints are welcome! Thanks in advance, Harald Gall ------------------------------------------------------------------------------ ___ ______________ Harald Gall, Inst.f. Informationssysteme 184-1 /_| | \ \ \ \ Vienna University of Technology |_ _|__\___\____\____\ A-1040 Wien, Argentinierstr. 8/184-1, Austria ()-----() ()()() email: gall@infosys.tuwien.ac.at Harald.Gall@infosys.tuwien.ac.at H.Gall@infosys.tuwien.ac.at Phone: +43 1 58801 4412 (Fax: +43 1 505 84 53) ------------------------------------------------------------------------------ ======================================================================= 109 === Date: 29 Sep 1994 14:51:40 GMT From: hoodt@postoffice.manassas.ibm.com (Thomas Hood 913-4501) Subject: Re: Information on teaching OO and Reuse (redux) In article <36b346$50p@uqcspe.cs.uq.oz.au>, too@cs.uq.oz.au ( Teaching OO Group ) writes: |> |> Ada-83 |> ------ |> SUNY Plattsburgh (whole course) |> Swinburne ? |> You can add Briar Cliff College in Sioux City IA. I passed the baton in 1992, but we were teaching two years of SE and OO (such as it is :-) with Ada 83. -- Thomas Hood hoodt@lfs.loral.com -- Ada grunt since 1985 -- Member Team Ada since 1994 -- Member Team Human since 1965 -- -- My opinions are not those of my employers, and if they were I'd probably -- reject them out of hand and form new ones. ======================================================================= 110 === Date: 30 Sep 1994 13:55:12 GMT From: fraser@hare.EuroPARC.Xerox.COM (Quentin Stafford-Fraser) Subject: Sun RPC interface I have hacked a version of Marvin Theimer & David Nichols' m3rpc package which now builds under M3 3.3. For those who don't know, this provides an M3 interface to Sun RPC and an appropriate stub generator. My changes have been limited to updating calls which changed in the v2 - v3 transition and writing some m3makefiles. If anyone would like a copy, let me know. I have done only the most basic testing on it so far. -- ---------------------------------------------------------------------- Quentin Stafford-Fraser http://pelican.cl.cam.ac.uk/people/qs101/me.html Cambridge University Computer Lab Rank Xerox Cambridge EuroPARC qs101@cl.cam.ac.uk fraser@europarc.xerox.com Tel: +44 223 334411 Tel: +44 223 341521 Fax: +44 223 334679 Fax: +44 223 341510 ---------------------------------------------------------------------- ======================================================================= 111 === Date: Fri, 30 Sep 1994 09:44:19 GMT From: freeman@coolidge.coolidge.grenoble.xerox.fr (Steve Freeman) Subject: Re: MODULA-3 being used In article spencer@ERA.COM (Spencer Allain) writes: > I'm currently using C++ for my projects, simply because that is what I have > to use. I was weened on MODULA-2 (actually BASIC->FORTRAN->MODULA-2) and > still miss it. I was hoping that there would be some discussion on how > MODULA-3's style of Object Oriented design compared to C++ or Eiffel, and > why some things were better and/or worse. > > I'm a strong advocate for garbage collection, and was wondering how good > it is for MODULA-3. A bulk of my time is spent tracing down memory leaks > that cause obscure problems in other (sometimes unrelated) parts of the > code, usually stuff that I didn't write but seemed to work fine, until all > of its functionality was attempted to be used. > I've recently been exiled to C++ (for external reasons) from M3 and miss it dreadfully. I now have to spend lots of time doing things like tracking news and deletes and writing run-time type stuff, etc, etc, which I used to rely on the language for. One excellent example is the issue of module initialisation; it simply isn't hard in M3 because you IMPORT, rather than include interfaces, so the compiler/linker can figure out an initialisation sequence, and each implementation file has an initial block which you can rely on to set things up. One of the more depressing aspects of C++ is that most of the books include long lists of "gotchas" of which you have to be aware to survive. You might miss is multiple inheritance which, if I remember rightly, exercised this newsgroup a while ago, but either it's not as necessary as some people think or the M3 type system is so nice (or both) that I never really needed it. The other thing you might miss is the preprocessor; the M3 style is more to use different implementation files and link according to your needs. The M3 libraries are pretty substantial and seem to manage quite well with this scheme. If you have the chance, I'd strongly recommend getting away from C++. steve -- - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Steve Freeman, Research Scientist, Rank Xerox France. Surface: Rank Xerox Research Centre, 6, chemin de Maupertuis, 38240 Meylan, France. Internet: steve.freeman@xerox.fr Phone: +33 76 61 50 21 Fax: +33 76 61 50 99 but wotthehel wotthehel toujours gai -- mehitabel the cat ======================================================================= 112 === Date: 30 Sep 1994 03:18:29 GMT From: norman@flaubert.bellcore.com (Norman Ramsey) Subject: Re: MODULA-3 being used In article , Spencer Allain wrote: >I have just recently been following this newsgroup because, we weren't >subscribed to it before I requested its addition, and was hoping that there >would be more discussions going on. I'm not even sure if anyone is using >MODULA-3 for any serious large products. There are a number of serious efforts going on. I believe Michel Dagenais makes some effort to list them in the FAQ. > I was hoping that there would be some discussion on how >MODULA-3's style of Object Oriented design compared to C++ or Eiffel, and >why some things were better and/or worse. We seem to stay relatively free of that sort of religious war. M3 has safety, garbage collection, exceptions, and threads. There's a good UI toolkit with builder and a good implementation of network objects. I (and others) find those things more important than the details of the particular object model. >I'm a strong advocate for garbage collection, and was wondering how good >it is for MODULA-3. There's a reasonable stop-and-copy collector on all platforms. Some platforms support a more incremental collector that synchronizes with the mutator by using VM protection primitives. >I'm hoping that the lack of bandwidth going through this newsgroup isn't due >to little or no use, but that there aren't as many obscure problems that have >to be addressed to the net for a solution. Most problems arise when a new version of the SRC copmiler becomes available and people have difficulty porting it to different platforms. The rest of the time we're all busy getting work done :-) Norman ======================================================================= 113 === Date: Fri, 30 Sep 1994 21:27:03 GMT From: bwbecker@dragon.uwaterloo.ca (Byron Weber Becker) Subject: m3build orientation needed I'm trying to orient myself to v. 3.3 (m3build in particular) after using v. 2.11 for a while. 1. Are there non-trivial examples of m3makefiles that are easy to access. The person who installed m3 on my machine didn't leave the compiler source as a possible set of examples. 2. How does m3build/quake interact with: a. a source code control system like RCS b. building non-M3 parts of the system (compiling lex and yacc, for instance) 3. I often including targets to test code in the same makefile that builds the program. How do the rest of you handle testing? Do you have a separate makefile, or do it with m3build? I guess the big question behind 2 and 3 is whether m3build is viewed as a general purpose tool similar to make or whether it is just for building the M3 portion of the program. 4. I need coaching on appropriate/recommended directory structures. For instance, I have 2 programs that use a common set of modules. I have set up the directories: software/ program_a/ src/ m3makefile -- uses an override to find the common_code library program_b/ src/ m3makefile common_code/ src/ m3makefile -- creates a library Are there better ways to do this? 5. How do I use the variable WDROOT to set "conventional location of the user's personal package library"? Any pointers and advice would be very appreciated. ===== Byron Weber Becker (519) 888-4567 x4661 Computer Science Lecturer/Advisor bwbecker@dragon.uwaterloo.ca University of Waterloo ======================================================================= 114 === Date: 30 Sep 94 15:45:39 From: dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: MODULA-3 being used In article kendall@pot.East.Sun.COM (S am Kendall - Sun Microsystems Labs BOS) writes: spencer@ERA.COM (Spencer Allain) writes: > I'm hoping that the lack of bandwidth going through this newsgroup isn't d ue > to little or no use, but that there aren't as many obscure problems that h ave > to be addressed to the net for a solution. Mostly the latter, I think. The language and its libraries are simple enough to preclude the sort of endless "what are the semantics of this syntax?" questions one gets with C++. Certainly those of us porting the M3 system have questions, but we generally take them up directly with the authors of the code. The language was kept simple by design, there are several well designed and documented libraries and there are no differences practically from one platform to the other. Furthermore you will not get stuck with dangling pointers, corrupted memory and core dumps. This probably tends to keep traffic down. Perhaps the FAQ helps a bit too :-). Of course when a new release will come out, traffic will increase for a while. -- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029