======================================================================= 4 === Date: Tue, 2 Aug 1994 10:53:19 -0400 From: Dick Orgass Subject: Nit bug in LINUX vv. 3.3 binary distribution It appears that the fuction set_member is undefined in libm3.so.3 in binary distribution of version 3.3 for LINUX. I certainly don't need an immediate fix. The output from an ld attempt is below. The three offending locations are exactly the locations where IN appears in the program containing the module. Replacing the IN operations produces a successful completion of ld. This problem does not occur in the version of libm3 that I built for OSF/1 on a DEC Alpha. Dick --------------------------------error log---------------------------------- % cd ../test % m3build --- building in LINUX --- m3 -w1 -why -g -O -o tpd -F/usr/tmp/qk00205aaa -> linking tpd Preferences.m3:103 (/usr/local/soft/modula3-3.3/lib/m3/pkg/support/LINUX/libsupport.a(Prefer ences.mo)): Undefined symbol _set_member referenced from text segment Preferences.m3:106 (/usr/local/soft/modula3-3.3/lib/m3/pkg/support/LINUX/libsupport.a(Prefer ences.mo)): Undefined symbol _set_member referenced from text segment Preferences.m3:118 (/usr/local/soft/modula3-3.3/lib/m3/pkg/support/LINUX/libsupport.a(Prefer ences.mo)): Undefined symbol _set_member referenced from text segment Fatal Error: program "gcc" failed, exit status = 256 *** error code 1 (ignored) % ---------------------------------End------------------------------------ ======================================================================= 5 === Date: 02 Aug 1994 22:35:17 GMT From: akk@argon.prosign.fi (Ari Kautonen) Subject: How to use TextRefTbl -interface? How are you supposed to use the TextRefTbl -interface? I have here a simple example, which I can't compile without errors. Please explain what is wrong with the EVAL g.get(..) -statement. Why are the types incompatible? Compiler is SRC Modula-3 3.3 and LINUX is the operating system. test.m3: MODULE test EXPORTS Main; IMPORT TextRefTbl; VAR g: TextRefTbl.T; vv: REF INTEGER; BEGIN vv := NEW(REF INTEGER); vv^ := 1; EVAL g.put("first", vv); EVAL g.get("first", vv); (* <- this one *) END test. m3makefile: import(libm3) implementation(test) program(test) And this is the error message: % m3build --- building in LINUX --- m3 -w1 -why -g -O -o test -F/usr/tmp/qk00369aaa new source -> compiling ../src/test.m3 "../src/test.m3", line 13: incompatible types (v) 1 error encountered compilation failed => not building program "test" *** error code 1 (ignored) --- Thanks in advance, Ari -- --- Ari Kautonen -------------------------------------+---------------------------------------- Work address: | Home address: | Genera Prosign Oy | Sirkantie 1 Kanslerinkatu 8 E | FIN-36420 SAHALAHTI FIN-33720 TAMPERE | FINLAND FINLAND | | Tel : +358-31-3165280 | Tel : +358-31-3763734 Tel. direct : +358-31-3165284 | FAX : +358-31-3763734 (by request) FAX : +358-31-3165289 | NMT : 9400-830975 -------------------------------------+---------------------------------------- Email : akk@prosign.fi or Ari.Kautonen@prosign.fi X.400 : /S=akk/O=prosign/ADMD=fumail/C=fi/@elisa.fi WWW : http://www.prosign.fi ------------------------------------------------------------------------------ ======================================================================= 6 === Date: 2 Aug 1994 23:31:48 GMT From: najork@src.dec.com (Marc Najork) Subject: Re: How to use TextRefTbl -interface? In article , akk@argon.prosign.fi (Ari Kauto nen) writes: |> |> How are you supposed to use the TextRefTbl -interface? I have here |> a simple example, which I can't compile without errors. Please |> explain what is wrong with the EVAL g.get(..) -statement. Why are |> the types incompatible? |> ... |> MODULE test EXPORTS Main; |> |> IMPORT TextRefTbl; |> |> VAR |> g: TextRefTbl.T; |> vv: REF INTEGER; |> |> BEGIN |> vv := NEW(REF INTEGER); |> vv^ := 1; |> EVAL g.put("first", vv); |> EVAL g.get("first", vv); (* <- this one *) |> END test. The problem here is that vv is of type REF INTEGER as opposed to REFANY. As you see in the definition of the table interface (Table.ig), the get method is defined as follows: TYPE T = OBJECT METHODS get(READONLY k: Key.T; VAR v: Value.T): BOOLEAN; ... END; So, in the TextRefTbl instantiation of the generic Table type, the get method has the type get(READONLY k: Text.T; VAR v: Refany.T): BOOLEAN; which is the same as get(READONLY k: TEXT; VAR v: REFANY): BOOLEAN; According to the language definition, (cf. SPwM3 p. 28, or SIGPLAN 27(8):23) "For a VAR parameter, the actual must be a writable designator whose type is the same as that of the formal." So, the second argument to get must be *exactly* a REFANY, not just a subtype of REFANY. The following modified version of your program will compile: MODULE test EXPORTS Main; IMPORT TextRefTbl; VAR g: TextRefTbl.T; vv: REFANY; BEGIN vv := NEW(REF INTEGER); NARROW (vv, REF INTEGER)^ := 1; EVAL g.put("first", vv); EVAL g.get("first", vv); (* <- this one *) END test. Of course, you will still crash at runtime, because g is not set to any value. You might want to define g as follows: VAR g := NEW(TextRefTbl.Default).init(); As far as *why* VAR parameters are restricted in such a way, my first guess would be because they can occur both on the left-hand-side and the right-hand-side of an assignment, i.e. in an antimonotonic and in a monotonic context. But this would not explain why the rule for VALUE parameters is less stringent -- after all, VALUE parameters can occur in the same positions as VAR parameters ... -- Marc ======================================================================= 7 === Date: Tue, 02 Aug 94 16:40:18 -0700 From: heydon@src.dec.com Subject: Re: How to use TextRefTbl -interface? Ari Kautonen wonders why the call to "g.get" in the following code is producing a compilation error: > VAR > g: TextRefTbl.T; > vv: REF INTEGER; > > BEGIN > vv := NEW(REF INTEGER); > vv^ := 1; > EVAL g.put("first", vv); > EVAL g.get("first", vv); (* <- this one *) > END test. The problem is that a "TextRefTbl.T" is a generic table parameterized by the "Text" and "Refany" interfaces. This means that the instantiation of the TextRefTbl.T's "get" method has the signature: get(READONLY k: Text.T; VAR (*OUT*) v: Refany.T): BOOLEAN Since the "v" parameter has mode "VAR", the second argument to the "get" method in your code must have type "Refany.T", or "REFANY". Instead, you are passing a variable of type "REF INTEGER", which is too narrow. The error makes sense, since the table may contain references to objects of arbitrary type. You can't expect all elements of the table to be "REF INTEGER"'s. The following code should work. Notice that this code also initializes the table "g" (even if the above code had compiled, it would have crashed at the run-time call of the "put" method because "g" wasn't initialized). VAR g: TextRefTbl.T := NEW(TextRefTbl.Default).init(); vv := NEW(REF INTEGER); ref: REFANY; BEGIN vv^ := 1; EVAL g.put("first", vv); EVAL g.get("first", ref); vv := NARROW(ref, REF INTEGER); <* ASSERT vv^ = 1 *> END test. If you are only storing integers in your table, then you should use a "TextIntTbl.T" and save yourself the cost of the NARROW: VAR g: TextIntTbl.T := NEW(TextIntTbl.Default).init(); i: INTEGER; BEGIN EVAL g.put("first", 1); EVAL g.get("first", i); <* ASSERT i = 1 *> END test. - Allan -------------------------------------------------------------------- Allan Heydon heydon@src.dec.com DEC Systems Research Center (415) 853-2142 130 Lytton Ave. (415) 853-2104 (FAX) Palo Alto, CA 94301 ======================================================================= 8 === Date: Wed, 3 Aug 1994 04:25:46 GMT From: shjauda@descartes.uwaterloo.ca (Samir Jauda) Subject: Need help with binary distr. of SRC m3 for linux Recently I obtained binary distribution of SRC M3 for linux from ftp.vlsi.polymtl.ca I picked files src-m3-3.3l0.strip.tar.gz, install.sh and tools-2.11.patch.tar.g z and I ran install script; My problem is that I cannot compile anything, I try to do the following: m3build -S in the source directory m3makefile contains: import (libm3) implementation("Test") program("Test") and these are the errors that I get: "/root/m3test/src/m3makefile", line 1: unable to read ".M3EXPORTS" from directory "src" of package "libm3" (/usr/local/soft/modula3-3.3/lib/m3/ pkg/libm3) *** call stack *** "/root/m3test/src/m3makefile", line 1: call to built-in error "/root/m3test/src/m3makefile", line 539: call to procedure M3include "/usr/local/soft/modula3-3.3/lib/m3/pkg/m3build/templates/COMMON", line 531: ca ll to procedure import_version "/root/m3test/src/m3makefile", line 1: call to procedure import my test program compiles and runs on university machine (SUN). I have hard time understanding what to do with these errors. I was able to run successfully M3 compiler without shared libraries, but I am eager to set it up to work with shared libraries. Could anyone give me some help. Thanks in advance. I apologize if I am missing something obvious. -- Samir Jauda University of Waterloo, Ontario, Canada shjauda@descartes.uwaterloo.ca Department of Computer Science ======================================================================= 9 === Date: 3 Aug 1994 15:01:43 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Need help with binary distr. of SRC m3 for linux In article , shjauda@descartes.uwaterlo o.ca (Samir Jauda) writes: > My problem is that I cannot compile anything, I try to do the following: > > m3build -S in the source directory You need to use "m3build -S -b LINUX", othewise m3build doesn't know which configuration to use. Better yet, don't build in the source directory! In the parent directory type "m3build". It will create the necessary derived directory and put everything it builds there. Keeping source and derived files separate is good. - Bill Kalsow ======================================================================= 10 === Date: Wed, 3 Aug 1994 13:56:21 GMT From: dagenais@freia.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Nit bug in LINUX vv. 3.3 binary distribution This bug probably arises due to ld on LINUX which wants the libraries in a specific order, indeed "nm libm3.a" produces: ... hand.o: ... 000003e0 T _set_lt 00000120 T _set_member 000002a0 T _set_ne ... Thus, set_member is there. I have some quake "goo" to get the libraries in the right order, it should be on ftp.vlsi.polymtl.ca:pub/m3/linux by tonight. I will also include a newer version of m3gdb which benefits from patches produced by Peter Klein. -- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 11 === Date: 05 Aug 1994 16:56:53 GMT From: kendall@pot.East.Sun.COM (Sam Kendall - Sun Microsystems Labs BOS) Subject: Surprise--no unbuffered file writers I was just surprised to find that there are no unbuffered FileWr.T's. You can say stderr := NEW(FileWr.T).init(FS.OpenFile("logfile"), buffered := FALSE); but it doesn't do what I expected, because init silently ignores the value of `buffered' for regular file handles--the file writer for a regular file handle is always buffered. Can someone suggest a workaround? I don't want to insert lots of calls to Wr.Flush in the program, but I want to see the very latest output. ---- Sam Kendall Sun Microsystems Laboratories Boston ======================================================================= 12 === Date: Fri, 5 Aug 1994 12:22:53 GMT From: skj@oasis.icl.co.uk (Simon Johnston) Subject: Re: Linux-Oberon: thank you Bill Hogan (bhogan@crl.com) wrote: : I wish to express my gratitude to Markus Datwyler, to Marc Sperisen, : and everyone else involved in conceiving and realizing Oberon, for making : this elegant and powerful system available to Linux users like me. I agree, I have used the old DOS Oberon and Windows one and I like it, and the language is so tight !! : As enthusiastic about Linux as I am, Linux is still Unix and, in my : experience, Unix has always been closely correlated with the attitude : that "C" is necessarily the best way to program everything. : I believe that view to be mistaken and misleading. here here ! : Although I was happy to discover that Linux people are, generally : speaking, much more cosmopolitan in outlook, I still see too much of the : other attitude expressed. yes I think this is due to the wide background and skill level involved in the community as a whole. [deleted rest] I think we must also point out the extremely nice implementation of Modula-2 (mocka) which I have used to move my OS/2 Topspeed Modula-2 programs to Linux and now to the people at DEC SRC for the Linux implementation of Modula-3. I don't believe there is any argument now which says any future Linux application development must be done in C/C++. I am in the process of moving a program I started writing in C++ to Modula-3 for Linux, I only use C now for very fast and *dirty* hacks. I have a 25Mhz 486 Tower at work next to my work machine and a 486 portable at home both running Linux, I will not give up either now I have a really good development environment. 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. ======================================================================= 13 === Date: 05 Aug 1994 21:04:21 GMT From: kendall@pot.East.Sun.COM (Sam Kendall - Sun Microsystems Labs BOS) Subject: Re: Surprise--no unbuffered file writers Thanks to Scott Schwartz and Farshad Nayeri for pointing me to AutoFlushWr, writers that periodically (say, every second) flush their output. Multithreading is pretty useful. ---- Sam Kendall Sun Microsystems Laboratories Boston ======================================================================= 14 === Date: Sat, 06 Aug 1994 11:51:24 GMT From: myoung@farad.elee.calpoly.edu (May T. Young) Subject: Ordering DEC SRC TEtech reports? This may be a FAQ, but I looked through the FAQ list and didn't find the answer. I was wondering if it is still possible to order hardcopies of DEC SRC technical reports. If so, what is their e-mail address? Thank you, M ======================================================================= 15 === Date: Sat, 06 Aug 94 12:48:29 -0700 From: mhb@src.dec.com ("Marc H. Brown") Subject: Re: Ordering DEC SRC TEtech reports? SRC Research Reports can be (viewed and) ordered online through the WWW. The URL is http://www.research.digital.com/SRC/publications/src-rr.html The home page for SRC is http://www.research.digital.com/SRC/home.html >From there, you'll also find a link to the Modula-3 documentation. ======================================================================= 16 === Date: 7 Aug 1994 12:44:18 GMT From: torki@file01.mpfpi-muenchen.mpg.de (Torsten R. Kirschner) Subject: small patch to "mentor-3.3.tar.gz" Hello, for those who haven't --as I myself-- realized the small changes which have to be made to two m3makefiles in the mentor package, well, here they are: --------------------------- cut here ----------------------------- *** mentor/src/m3makefile.orig Sun Aug 7 13:41:29 1994 --- mentor/src/m3makefile Sun Aug 7 13:40:14 1994 *************** *** 33,35 **** include_dir (pktroute) ! include_dir (pqueue) include_dir (searchtree) --- 33,35 ---- include_dir (pktroute) ! include_dir ("pqueue") include_dir (searchtree) *** mentor/src/sorting/m3makefile.orig Sun Aug 7 13:58:59 1994 --- mentor/src/sorting/m3makefile Sun Aug 7 13:59:03 1994 *************** *** 25,27 **** is a MIDI device accessible through the EtherNet. */ ! include_dir (mentor-audio) --- 25,27 ---- is a MIDI device accessible through the EtherNet. */ ! /* include_dir (mentor-audio) */ --------------------------- cut here ----------------------------- ad 1. "pqueque" has to be quoted, since this name is already used within quake. This can be found out by reading the pqueque/ src/m3makefile. ad 2. Unfortunately, we don't have the midi-boxes around here, so... The patch works best when applied in the directory where you typed "gtar zxf mentor.tar.gz" or something the like. I hope it works for you as it did for me. Yours Torsten -- Torsten R. Kirschner (EDV) Kirschner@mpipf-muenchen.mpg.de MPI f. Psychologische Forschung tel: ++49 89 38602258 Leopoldstr. 24 fax: ++49 89 342473 80802 Muenchen, Germany X.400: no longer available ======================================================================= 17 === Date: 08 Aug 1994 07:21:31 GMT From: connolly@hal.com (Dan Connolly) Subject: How much hardware for Modula-3 on Linux? I am interested in developing distributed hypermedia applications -- WWW clients, servers; experimenting with data formats, protocols, and user interfaces. After a casual but fairly thorough search of the available/unavailable development tools and platforms, (DCE, X windows, tk/tcl, python, perl, wafe, X11R6, C++, fresco, Windows 4, Windows NT, NeXTStep, OLE2.0, OpenDoc, Corba, Bento, Dylan, schem48, Common Lisp, CLOS, Motif) I have decided that Modula-3 and Linux will best suit my purposes. I think. Over the last week, I managed to get a hodge-podge Linux installation going on my hodge-podge PC. I just managed to get the X server running, but none too quick. I am seeking information about how various hardware upgrades will affect the performance of this box for this purpose. I am also seeking bids from folks with hardware to sell me (particularly folks in Austin with disk drives, CD rom drives, and tape backup systems -- perhaps even a motherboard). I'm almost ready to send $2.5 grand to the guys in california who sell packaged linux workstations, but I've decided that "getting there is half the fun," and I'd rather put the thing together myself. After all, ever since I gave up OS/9 on my Radio Shack color computer for a Macintosh, I miss OS hacking! (why didn't Apple use OS/9 68k? I bet they're regretting ever letting apps run in supervisor mode these days!) Success stories from M3-on-linux users are also welcome. I have a an AST Cupid motherboard 486DX with 16MB RAM, 80MB (!) of disk, and a VGA display of unknown origin. See below for gory details. A recent article in Computer Shopper summarized PC performance issues nicely: the three subsystems are CPU/memory, Disk, and Video. I guess he left out networking. Along those lines, my theory is: CPU/memory: I'm OK here. Perhaps I could use some cache memory (anybody know how to find out if I've already got some? I have this funky Cupid motherboard, where the CPU and memory are on an ISA card...) I'll eventually want more RAM and a higher clock speed, but who doesn't? DISK: Critical need here. I think a 540MB IDE disk would suffice for a while, though I wonder if I should get a SCSI disk. I am still very unclear about the stability of SCSI devices on linux. How much disk does a full-blown M3 installation use? I want everything, including visual-obliq, and source for everything. VIDEO: XFree86 configuration is deep voodoo magic. I got the generic 16bit server running, and perhaps that's the best I'm gonna get out of this hardware, but I don't even know. I also don't know how much video performance I can get from an ISA card. Do I need localbus video? What exactly is SVGA? NETWORK: I've got a 14.4 USRobotic Sportster. ftp over term is cool and works, but I don't relish the thought of sucking the whole M3 distribution through that skinny pipe. But until this diversion starts generating some serious revenue, I don't see an ISDN connection in the near future. Anybody have any success with AFS or Alex over PPP or slip? Given the amount of software available for <$50 on CD ROM, and my low bandwidth connection to the net, I'm pretty sold on the idea of a CD rom drive too. To SCSI or not to SCSI, that again, is the question. And I'll probably want a tape backup device. Again: SCSI? I'm currently running various parts of Slackware 2.0 -- I was running their 1.0.9 kernel, but I had to reconfigure and recompile it to get my mouse to work. Anybody want to suggest a kernel? 1.1.36? How stable is gcc 2.6.0? 2.5.8 works like a champ, and I've heard some problem reports about 2.6. But 2.5.8 won't compile Fresco, and I'd like to check it out in more detail. Anyway... Here's what "syscheck.exe" says about my system: Advanced Personal Systems SYSCHK Information Printout Friday, Aug. 5, 1994 Version: 2.39 PROCESSOR---------------------------------------------------------------------- - Model: AST Premium Processor: 80486DX-33 MHz Coprocessor: Internal Extended BIOS data area: No DMA Channel 3 used: No Slave 8259 Present: Yes Real Time Clock: Yes I/O Bus Type: ISA (Industry Standard Architecture) SYSTEM BIOS-------------------------------------------------------------------- - Source: AST Research Version: Not Found Date: 11/06/90 BIOS Extensions: Segment Copyright C000-C5FF AST Research, Inc. C680-C7FF Unknown INPUT/OUTPUT------------------------------------------------------------------- - Keyboard: 101 Key Enhanced Mouse Driver Installed: No Parallel Ports: 1 Device Base Addr. Interrupt LPT1 378h IRQ ? Serial Ports: 2 Device Base Addr. Interrupt UART COM1 3F8h IRQ 4 16550A COM2 2F8h IRQ 3 16450 HARD DISK DRIVES--------------------------------------------------------------- - Disk # Tracks Heads Sectors Size CMOS Controller ------ ------ ----- ------- -------- ---- --------------- Disk 1 745 4 28 40.74 MB 36Unknown Disk 2 805 4 26 40.88 MB 23 Conner Peripherals 40MB - P LOGICAL DRIVES----------------------------------------------------------------- - Drive Total Used Free Volume Name ----- ---------- ---------- ---------- ------------ C: 31.90 MB 31.45 MB 0.45 MB VOLUME 1 D: 8.66 MB 3.32 MB 5.34 MB OTHER DISKS-------------------------------------------------------------------- - Floppy Disk 1: 1.44 MB 3+" Floppy Disk 2: 1.2 MB 5," VIDEO-------------------------------------------------------------------------- - Active Video: VGA + Analog Color Monitor BIOS Source: AST Research, Inc. MEMORY------------------------------------------------------------------------- - Conventional Memory: 640 KB (576 KB Free) Extended Memory: 15360 KB (0 KB Free) Expanded Memory: None RESIDENT PROGRAMS-------------------------------------------------------------- - Lower Memory Block Mem Segmt Size Type Owner Name --------- ---- ------- ---------------------- 025B-0873 24K Config DOS 5.0 kernel 0874-0878 1K Resrved DOS 5.0 kernel 0879-090D 2K Shell COMMAND.COM 090E-0912 1K Free DOS 0913-0923 1K Sys Env COMMAND.COM 0924-0928 1K Free DOS 0929-1012 27K TSR SMARTDRV 1013-101C 1K Envnmnt SYSC 101D-9FFF 575K Free DOS Available Memory ENVIRONMENT VARIABLES---------------------------------------------------------- - COMSPEC=C:\COMMAND.COM PATH=D:\WINWORD;C:\WINDOWS;C:\DOS;C:\UT;E... ...:\NU NU=E:\NU TEMP=C:\WINDOWS\TEMP INTERRUPTS--------------------------------------------------------------------- - IRQ # Active Device Name ----- ------ ------------------------------ IRQ0 Yes System Timer IRQ1 Yes Keyboard IRQ2 Yes Cascade->IRQ9 IRQ3 Yes COM2 IRQ4 Yes COM1 IRQ5 No Open IRQ6 Yes Floppy Disk Controller IRQ7 No Open IRQ8 Yes Real-Time Clock IRQ9 Yes IRQ2->Cascade IRQ10 No Open IRQ11 No Open IRQ12 No Open IRQ13 Yes 80486 (Math Coprocessor) IRQ14 Yes Unknown IRQ15 No Open SPEED-------------------------------------------------------------------------- - Throughput Speed: 92.33 MHz CPU Clock Speed: 33 MHz p.s. Please forgive the crosspost. I hope to contribute something in return for any information sent by you generous folks out there... -- 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 ======================================================================= 18 === Date: 08 Aug 1994 07:21:12 GMT From: connolly@hal.com (Dan Connolly) Subject: How much hardware for Modula-3 on Linux? I am interested in developing distributed hypermedia applications -- WWW clients, servers; experimenting with data formats, protocols, and user interfaces. After a casual but fairly thorough search of the available/unavailable development tools and platforms, (DCE, X windows, tk/tcl, python, perl, wafe, X11R6, C++, fresco, Windows 4, Windows NT, NeXTStep, OLE2.0, OpenDoc, Corba, Bento, Dylan, schem48, Common Lisp, CLOS, Motif) I have decided that Modula-3 and Linux will best suit my purposes. I think. Over the last week, I managed to get a hodge-podge Linux installation going on my hodge-podge PC. I just managed to get the X server running, but none too quick. I am seeking information about how various hardware upgrades will affect the performance of this box for this purpose. I am also seeking bids from folks with hardware to sell me (particularly folks in Austin with disk drives, CD rom drives, and tape backup systems -- perhaps even a motherboard). I'm almost ready to send $2.5 grand to the guys in california who sell packaged linux workstations, but I've decided that "getting there is half the fun," and I'd rather put the thing together myself. After all, ever since I gave up OS/9 on my Radio Shack color computer for a Macintosh, I miss OS hacking! (why didn't Apple use OS/9 68k? I bet they're regretting ever letting apps run in supervisor mode these days!) Success stories from M3-on-linux users are also welcome. I have a an AST Cupid motherboard 486DX with 16MB RAM, 80MB (!) of disk, and a VGA display of unknown origin. See below for gory details. A recent article in Computer Shopper summarized PC performance issues nicely: the three subsystems are CPU/memory, Disk, and Video. I guess he left out networking. Along those lines, my theory is: CPU/memory: I'm OK here. Perhaps I could use some cache memory (anybody know how to find out if I've already got some? I have this funky Cupid motherboard, where the CPU and memory are on an ISA card...) I'll eventually want more RAM and a higher clock speed, but who doesn't? DISK: Critical need here. I think a 540MB IDE disk would suffice for a while, though I wonder if I should get a SCSI disk. I am still very unclear about the stability of SCSI devices on linux. How much disk does a full-blown M3 installation use? I want everything, including visual-obliq, and source for everything. VIDEO: XFree86 configuration is deep voodoo magic. I got the generic 16bit server running, and perhaps that's the best I'm gonna get out of this hardware, but I don't even know. I also don't know how much video performance I can get from an ISA card. Do I need localbus video? What exactly is SVGA? NETWORK: I've got a 14.4 USRobotic Sportster. ftp over term is cool and works, but I don't relish the thought of sucking the whole M3 distribution through that skinny pipe. But until this diversion starts generating some serious revenue, I don't see an ISDN connection in the near future. Anybody have any success with AFS or Alex over PPP or slip? Given the amount of software available for <$50 on CD ROM, and my low bandwidth connection to the net, I'm pretty sold on the idea of a CD rom drive too. To SCSI or not to SCSI, that again, is the question. And I'll probably want a tape backup device. Again: SCSI? I'm currently running various parts of Slackware 2.0 -- I was running their 1.0.9 kernel, but I had to reconfigure and recompile it to get my mouse to work. Anybody want to suggest a kernel? 1.1.36? How stable is gcc 2.6.0? 2.5.8 works like a champ, and I've heard some problem reports about 2.6. But 2.5.8 won't compile Fresco, and I'd like to check it out in more detail. Anyway... Here's what "syscheck.exe" says about my system: Advanced Personal Systems SYSCHK Information Printout Friday, Aug. 5, 1994 Version: 2.39 PROCESSOR---------------------------------------------------------------------- - Model: AST Premium Processor: 80486DX-33 MHz Coprocessor: Internal Extended BIOS data area: No DMA Channel 3 used: No Slave 8259 Present: Yes Real Time Clock: Yes I/O Bus Type: ISA (Industry Standard Architecture) SYSTEM BIOS-------------------------------------------------------------------- - Source: AST Research Version: Not Found Date: 11/06/90 BIOS Extensions: Segment Copyright C000-C5FF AST Research, Inc. C680-C7FF Unknown INPUT/OUTPUT------------------------------------------------------------------- - Keyboard: 101 Key Enhanced Mouse Driver Installed: No Parallel Ports: 1 Device Base Addr. Interrupt LPT1 378h IRQ ? Serial Ports: 2 Device Base Addr. Interrupt UART COM1 3F8h IRQ 4 16550A COM2 2F8h IRQ 3 16450 HARD DISK DRIVES--------------------------------------------------------------- - Disk # Tracks Heads Sectors Size CMOS Controller ------ ------ ----- ------- -------- ---- --------------- Disk 1 745 4 28 40.74 MB 36Unknown Disk 2 805 4 26 40.88 MB 23 Conner Peripherals 40MB - P LOGICAL DRIVES----------------------------------------------------------------- - Drive Total Used Free Volume Name ----- ---------- ---------- ---------- ------------ C: 31.90 MB 31.45 MB 0.45 MB VOLUME 1 D: 8.66 MB 3.32 MB 5.34 MB OTHER DISKS-------------------------------------------------------------------- - Floppy Disk 1: 1.44 MB 3+" Floppy Disk 2: 1.2 MB 5," VIDEO-------------------------------------------------------------------------- - Active Video: VGA + Analog Color Monitor BIOS Source: AST Research, Inc. MEMORY------------------------------------------------------------------------- - Conventional Memory: 640 KB (576 KB Free) Extended Memory: 15360 KB (0 KB Free) Expanded Memory: None RESIDENT PROGRAMS-------------------------------------------------------------- - Lower Memory Block Mem Segmt Size Type Owner Name --------- ---- ------- ---------------------- 025B-0873 24K Config DOS 5.0 kernel 0874-0878 1K Resrved DOS 5.0 kernel 0879-090D 2K Shell COMMAND.COM 090E-0912 1K Free DOS 0913-0923 1K Sys Env COMMAND.COM 0924-0928 1K Free DOS 0929-1012 27K TSR SMARTDRV 1013-101C 1K Envnmnt SYSC 101D-9FFF 575K Free DOS Available Memory ENVIRONMENT VARIABLES---------------------------------------------------------- - COMSPEC=C:\COMMAND.COM PATH=D:\WINWORD;C:\WINDOWS;C:\DOS;C:\UT;E... ...:\NU NU=E:\NU TEMP=C:\WINDOWS\TEMP INTERRUPTS--------------------------------------------------------------------- - IRQ # Active Device Name ----- ------ ------------------------------ IRQ0 Yes System Timer IRQ1 Yes Keyboard IRQ2 Yes Cascade->IRQ9 IRQ3 Yes COM2 IRQ4 Yes COM1 IRQ5 No Open IRQ6 Yes Floppy Disk Controller IRQ7 No Open IRQ8 Yes Real-Time Clock IRQ9 Yes IRQ2->Cascade IRQ10 No Open IRQ11 No Open IRQ12 No Open IRQ13 Yes 80486 (Math Coprocessor) IRQ14 Yes Unknown IRQ15 No Open SPEED-------------------------------------------------------------------------- - Throughput Speed: 92.33 MHz CPU Clock Speed: 33 MHz p.s. Please forgive the crosspost. I hope to contribute something in return for any information sent by you generous folks out there... -- 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 ======================================================================= 19 === Date: 08 Aug 1994 11:56:23 GMT From: gwyant@cloyd.east.sun.com (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: Re: How much hardware for Modula-3 on Linux? Glad to hear that you are interested in M3 and Linux ! I think it is an excellent basis for building distributed hypermedia applications. I have successfully used M3 on a laptop with 8Mb of physical memory and 130Mb hard disk. The CPU was a 33Mhz 486. I have found compilation performance to be acceptable (thoug not stunning) with that configuration. Execution performance has also seemed fine. I suspect that a machine with 16Mb of memory would be more than adequate. Disk speed is more important than CPU speed. I'm not sure how much help this is, but if I can answer any more questions, don't hesitate to send mail ! --geoff -- Geoff Wyant Geoff.Wyant@east.sun.com Sun Microsystems Laboratories, Inc. 2 Elizabeth Drive Chelmsford, Ma. 01824 ======================================================================= 20 === Date: 8 Aug 1994 12:41:41 GMT From: pk@i3.informatik.rwth-aachen.de (Peter Klein) Subject: Network Objects & Authorization Hello network object experts, it seems pretty natural to me that a network object server instance wants to behave differently depending on the client who wants to execute a server method. So, is there any chance for a server method to find out something about the surrogate object which requested its call? Thanks for any help, Peter --- Peter Klein E-Mail: pk@i3.informatik.rwth-aachen.de Lehrstuhl fuer Informatik III Tel.: +49/241/80-21311 Ahornstrasse 55 Fax.: +49/241/8888-218 RWTH Aachen 52074 Aachen Germany ======================================================================= 21 === Date: Tue, 9 Aug 1994 16:04:57 GMT From: clark@ryn.mro.dec.com Subject: CFP OOPSLA Workshop: OO Compilation -- What are the Objects? The co-sponsors are pleased to invite your participation in a workshop associated with the upcoming OOPSLA '94 conference in Portland Oregon. Overview: This workshop will cover object-oriented compilation techniques. These are OO techniques applied to the compilation process (as opposed to techniques for compiling OO languages). This workshop will attempt to identify some of the areas where objects have been designed to support the compilation process or to include parts of the compilation process in an application framework. Goals: The purpose of the workshop is to gather applications of OO concepts to the compilation process. The participants will share their experiences in treating some portion of the compilation process in an OO manner. The workshop will be organized to provide a forum for discussion of ways to further objectify the compilation process. The workshop will be a success if the participants take home new ideas on ways they can structure compilers in a more OO manner. Focus: Of particular interest are cases where an OO technique either unified parts of the compilation process that were previously distinct,extended a particular part of the compilation process so that it could be used in a wider context,or made a portion of the compilation process easier to implement or understand. Requirements for Attendance: Prospective participants must submit a short (< 6 page) position paper by August 15,1994,preferably by electronic mail. Participants will be chosen on the basis of suitability of these papers. Participants will be selected and notified by September 7,1994. Organizers: Boris Burshteyn (Oracle Corporation) Chris Clark (Digital Equipment Corporation) Ralph E. Johnson (University of Illinois at Urbana-Champaign) Terence Parr (University of Minnesota) Barbara Zino (Compiler Resources,Inc.) Submissions: Barbara Zino OOPSLA '94 OO Compilation Workshop Compiler Resources,Inc. 85 Main St,Suite 310 Hopkinton,MA 01748 USA Phone: 1 (508) 435-5016 Fax: 1 (508) 435-4847 Email: compres@world.std.com CompuServe: 74252,1375 Some examples of work in the area are: Class hierarchies which include phases of a compiler (such as lexers,parsers,symbol tables,or code generators) Phases of a compiler being treated as objects Class hierarchies for symbol table design Class hierarchies for representing Abstract Syntax Trees (ASTs) or Intermediate Representations/Languages (IRs/ILs) Object-oriented attribute grammars Object-oriented extensions to compiler generators Object-oriented approaches to parsing,optimization,or code generation Some Relevant Papers: Burshteyn,Boris,MUSKOX - a tool for Object-Oriented Analysis and Design , ftp iecc.com:pub/file/muskox.ps.gz Crenshaw,Jack,A Perfect Marriage: Syntax Directed Design, Computer Language,pp 44-55 (Jun 91) Hedin,Gorel,An Object-Oriented Notation for Attribute Grammars, Proceedings of the European Conference on Object-Oriented Programming, pp 329-345 (1989) Grass,J. E.,Chandra Kintala,and Ravi Sethi, Object-oriented Redesign using C++: Experience with Parser Generators, Usenix C++ Conference Proceedings,pp 75-86 (Apr 1990) Graver,Justin O.,The Evolution of an Object-oriented Compiler Framework , Software Practice and Experience,v 22(7) pp 519-535 (Jul 92) Graver,Justin O., T-gen: a String-To-Object Translator Generator, Journal of Object-oriented Programming,v 5(6) pp 35-42 (Sep 92) Grosch,Josef,Object-Oriented Attribute Grammars, Proceedings of the Fifth Symposium on Computer and Information Sciences , pp 807-816 (Oct 90) Grosch,Josef,Multiple Inheritance in Object-Oriented Attribute Grammars , GMD Technical Report,Compiler Generation Report 28,(Feb 92) Johnson,S. C.,Yacc Meets C++, Computing Systems,v1(2),(Spring 88) Lalonde,Wilf & John Pugh,Implementing Event-oriented Parsers, Journal of Object Oriented Programming,Part 2 v 6(4) pp 70-73 (Jul/Aug 93) Lieberherr,Karl J. & Arthur J. Riel, Contributions to Teaching Object-oriented Programming, OOPSLA 89 Proceedings,SIGPLAN Notices,v24(10),pp 11-22 (Oct 89) Wu,Pei-Chi,An Object-Oriented Specification for Compilers, SIGPLAN Notices,v 27(1) pp 85-94 (Jan 92) Zino,Barbara,The Domino Effect -- Parsing and Lexing Objects with Yacc+ +, SunWorld,v4(5) pp 86-92 (May 91) ======================================================================= 22 === Date: Wed, 10 Aug 1994 14:20:26 GMT From: se93sst@brunel.ac.uk (Stig Tollefsen) Subject: Can't install libm3 I'm installing the new 3.3 SRC implementation on a SUN SPARC. I've successfully installed the boot archive, but libm3 refuses to build. This is what I get: titan% m3build --- building in SPARC --- m3 -w1 -why -g -times -a libm3.a -F/usr/tmp/qkAAAa04383 sh: 4745 Bus error *** error code 138 (ignored) missing libm3.a: not building libm3.so.1.1 titan% I'm no UNIX wizard, but it seems there is a tmp directory I don't have access to. Can anyone tell me what is wrong? --- Stig Tollefsen se93sst@brunel.ac.uk "I'm a law-abiding man / I'm a good Samaritan / I pay my taxes when I can / Model Citizen" - Warren Zevon ======================================================================= 23 === Date: 10 Aug 1994 12:22:52 GMT From: mead@bucknell.edu (Jerry Mead) Subject: Modula3-based CS1/CS2 texts???!!! Do any of you know of any authors who are preparing CS1/CS2 level textbooks based on Modula-3? At last Spring's national ACM meeting in Phoenix the publishers displayed a vast array of C++-based CS1/CS2 texts. Modula-3 seems to most likely viable alternative. I hope someone can post some good news on this front. jerry --------------------- Jerry Mead Dept of Computer Science Bucknell University Lewisburg, PA 17837 mead@bucknell.edu ======================================================================= 24 === Date: Wed, 10 Aug 1994 14:13:55 GMT From: mmeola@cahill (Matt Meola) Subject: HP Modula3? What's the status of Modula3 under HP-UX (on an HP, of course)? Last I heard, there were some problems... (********************************************************) (* Matt Meola mmeola@cahill.ecte.uswc.uswest.com *) (* NRA Life Member, Militiaman, Libertarian *) (* Gun control means using two hands. *) (********************************************************) ======================================================================= 25 === Date: 10 Aug 1994 23:47:25 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Sequent Modula3 > Is the Sequent platform still being supported? Not at the moment. No doubt, some pieces of the port have decayed. I will try building it and see what happens. > If not, is it possible to > obtain the Sequent implementation for a previous release of m3? I don't have one. - Bill Kalsow ======================================================================= 26 === Date: Wed, 10 Aug 1994 21:05:06 GMT From: jmoore@jsun.okstate.edu (JOE MOORE) Subject: Sequent Modula3 The SRC-Modula 3 home page lists SEQUENT as a supported platform. However, there is no boot file for Sequent in the release-3.3 directory on gatekeeper.dec.com. Is the Sequent platform still being supported? If not, is it possible to obtain the Sequent implementation for a previous release of m3? Joe Moore Agricultural Engineering Oklahoma State University ======================================================================= 27 === Date: 12 Aug 94 16:39:41 GMT From: bruce@mdavcr.mda.ca (Bruce Thompson) Subject: Any examples of Modula-3 and Noweb around? Hi. I'm just getting started with Modula-3, and I noticed that m3build will work with NoWeb. Having never used NoWeb (CWEB, SpiderWeb yes, but not NoWeb), I'm intrigued. Being the type to jump in with both feet, I'm working on a library that will help me with some projects that I've been putting off, and naturally, I want to go whole hog and do it all up using NoWeb. What I'm looking for is some pointers to non-trivial examples of NoWeb being used with Modula-3. Examples that build one document from a bunch of interfaces/modules would be even better. It appears that a number of the research reports incorporate NoWeb, particularly the VBTkit Reference Manual. Is the .nw source around somewhere where I can peruse it for stylistic ideas? While I'm here, I'm just beginning work on a Postgres interface to Modula-3. Is there anyone else out there who's already working on this? If so, any advice? Is there anything I can do to help in the effort? Otherwise, are there any features that people would like to see, or recommendations on how the interface should look/feel? Cheers, Bruce. -- Bruce Thompson, B.Sc. | "A great many people think they are Software Engineer | thinking when they are merely MacDonald Dettwiler, | rearranging their prejudices." 13800 Commerce Parkway, | -- William James Richmond, BC | (604) 278-3411 | Usual disclaimers apply NAPRA #473 | ======================================================================= 28 === Date: Fri, 12 Aug 94 11:24:50 -0700 From: weich@src.dec.com Subject: Re: Modula3-based CS1/CS2 texts???!!! Jerry Mead wrote: > Do any of you know of any authors who are preparing CS1/CS2 level > textbooks based on Modula-3?> Jerry Mead We (i.e. Laszlo Boszormenyi and Carsten Weich) are currently writing a book called "Programmieren mit Stil, eine Einfuehrung in das Programmieren mit Modula-3". The first version (in German) is currently being reviewed. The English version (the title might be "Programming with Style, an Indroduction to Programming with Modula-3") should be available in the spring of 1995, soon after the German version. The first part of the book is a gentle introduction to programming, it discusses types, statements, structuring programs and modules. The second part discusses recursion, recursive data structures, objects, exceptions and persistence (files). The last part is a short introduction to parallel programing. The book concentrates on programing techniques. It leaves most of pecification and design issues to others. We plan to make available a complete PC-distribution of Modula-3 to the buyers of the book. All the examples will be distributed, too. Carsten ======================================================================= 29 === Date: Sat, 13 Aug 1994 19:51:25 GMT From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: How much hardware for Modula-3 on Linux? If you want EVERYTHING on disk, the DEC SRC Modula-3 source code (with m3gdb, m3cc...) uncompressed is around 120MB while the full LINUX binary distribution is between 20 and 50MB (with debugging info shared and static libs...). While 8MB of RAM runs fine for most programs, i expect a big boost from the additional memory i just ordered (to get to 16MB). Indeed, when compiling several modules, the two compiler passes (m3cc and m3cg) should remain in the buffer cache; loading these two large programs from disk seems to dominate the elapsed time. Furthermore, some very large programs such as mentor are trashing with only 8MB. -- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 30 === Date: 14 Aug 1994 03:32:49 GMT From: markg@kelly.teleport.com (Mark C. Gay) Subject: Modula 3 for the Amiga? Is anyone working on a port for the amiga? -- --Mark markg@teleport.COM Not affiliated with anything in particular, including teleport. ======================================================================= 31 === Date: Sun, 14 Aug 1994 17:42:19 GMT From: robsch@robkaos.ping.de (Robert Schien) Subject: Modula-3 for SVR4/386 or FreeBSD Is there a M-3 implementation for SVR4/386 or FreeBSD/NetBSD? Thanks in advance. Robert ======================================================================= 32 === Date: 15 Aug 1994 15:15:23 +0200 From: laverman@cs.rug.nl (Bert Laverman) Subject: SRC-m3 v3.3 on the HPPA/HP-UX Hi all. In coorporation with Bill Kalsow at DEC and Dick Orgass at CMU I have managed to get SRC-m3 release 3.3 working on the HPPA, running HP-UX (9.01 in my case). The binaries I am using myself have been tarred and gzipped, and are now available from Michel Dagenais' ftp site: ftp://ftp.vlsi.polymtl.ca/pub/m3/hppa As a consequence of this port a few changes have been made to the SRC-m3 compiler, which will be in the 3.4 release. If you try to rebuild the 3.3 compiler from the compiler.tar.gz sources at gatekeeper.dec.com, you will generate buggy code. Since this port a new bug has been discovered in the libm3 archive for the HPPA. It is not yet fixed: The non-blocking code in libm3/os/POSIX/FileRead.m3, line 202, wrongly uses Unix.O_NDELAY. It should use Unix.O_NONBLOCK. If you do not patch this, the non-blocking reads will fail with an End-Of-File exception if no input is available. A question bound to come up: ...shared libraries...? Sorry, no. gcc on the HPPA is not (yet) capable of generating Position- Independent-Code, which is a requirement for this. I have been told gcc 2.7.0 should have it, whenever it may come. The README file I made for the HPPA distribution: ------------------------------------------------------------------------------- This is a binary distribution of SRC-m3 version 3.3 for the HPPA processor. It has been built under HP-UX 9.01. All Modula-3 libraries are static. This distribution has been built in the following setup: /usr/local/m3/ - The base directory for Modula-3 packages/3.3/ - The release 3.3 base bin/ - The binary directories, including HPPA/ - The HPPA binaries man/ - The manual files lib/m3/ - Libraries HPPA/ - The compiler etc. pkg/ - The packages I choose this layout so as to be able to build new releases without any- body noticing it, under the /usr/local/m3/packages directory. /usr/local/m3/bin is just a symbolic link to the bin directory of the current release. m3build and the templates know, and always use, the full path including release number. You MUST use the gnu assembler gas; the linker will crash if you don't, nor wil l it understand the debug info generated by the Modula-3 compiler. The current HP PA template uses /usr/local/bin/gas and /usr/local/bin/gcc. The suggested procedure is: $ mkdir -p /usr/local/m3/packages/3.3/bin/HPPA $ cd /usr/local/m3 $ ln -s /usr/local/m3/packages/3.3/bin/HPPA ./bin $ ln -s /usr/local/m3/packages/3.3/man ./man $ cd bin $ ... unpack binaries ... $ cd /usr/local/m3/packages/3.3 $ ... unpack lib-m3-... All the lib-m3-... files have directory trees in them starting with 'lib/m3/'. REMEMBER! The 3.4 release will be the 'real' release supporting the HPPA. This binary distribution is a working copy of 3.3. Don't try to build and use the 3.3 compiler/driver set. You will get BUS errors and crashing exceptions! With this release you can at least start adapting your programs to the new library interfaces. It works on my system, it may work for you. PS the vbtapps binaries are not in the set. You can build them. :-) The tar files are: size name remarks ======== ================================== =================== 3678036 m3bin.tar.gz The basic binaries 3138969 mentorbin.tar.gz m3zume/mentor 801473 netobjbin.tar.gz Netobj binaries 6469641 obliqbin.tar.gz Obliq binaries 1475147 lib-m3-HPPA.tar.gz lib/m3/HPPA 178617 lib-m3-pkg-X11R4.tar.gz ..etc 56831 lib-m3-pkg-codeview.tar.gz 304115 lib-m3-pkg-formsvbt.tar.gz 9989 lib-m3-pkg-formsvbtpixmaps.tar.gz 113387 lib-m3-pkg-jvideo.tar.gz 2448647 lib-m3-pkg-libm3.tar.gz 15171 lib-m3-pkg-m3build.tar.gz 1865693 lib-m3-pkg-m3tk.tar.gz 27073 lib-m3-pkg-m3tools.tar.gz 1335 lib-m3-pkg-m3zume.tar.gz 54021 lib-m3-pkg-metasyn.tar.gz 209315 lib-m3-pkg-mg.tar.gz 243243 lib-m3-pkg-mgkit.tar.gz 201128 lib-m3-pkg-netobj.tar.gz 55394 lib-m3-pkg-obliq.tar.gz 41775 lib-m3-pkg-obliqlibanim.tar.gz 32409 lib-m3-pkg-obliqlibm3.tar.gz 23951 lib-m3-pkg-obliqlibui.tar.gz 60375 lib-m3-pkg-obliqparse.tar.gz 44078 lib-m3-pkg-obliqprint.tar.gz 244885 lib-m3-pkg-obliqrt.tar.gz 67516 lib-m3-pkg-synex.tar.gz 12977 lib-m3-pkg-synloc.tar.gz 40726 lib-m3-pkg-tcp.tar.gz 1030003 lib-m3-pkg-ui.tar.gz 959367 lib-m3-pkg-vbtkit.tar.gz 36143 lib-m3-pkg-videovbt.tar.gz 203935 lib-m3-pkg-zeus.tar.gz ---------------------------------------------------------------------------- Enjoy, Bert Laverman -- ------------------------------------------------------------------ Bert Laverman, Dept. of Computing Science, Groningen University Email: laverman@cs.rug.nl Phone: +31-50-633948 Home: bert@rakis.iaf.nl Fax: +31-50-633800 ======================================================================= 33 === Date: 15 Aug 94 10:51:48 GMT From: R.Winder@cs.ucl.ac.uk (Russel Winder) Subject: Object-Oriented Systems (A new journal) Object-Oriented Systems First Announcement and Call for Papers Aims and Scope Object-Oriented Systems (OOS) is a quarterly journal publishing research and experience papers on all aspects of object-orientation. The journal fosters communication amongst all those working with object technology, as well as providing a source of quality refereed material for perpetual reference. Thus, it is a forum for researchers and practitioners to communicate and examine ideas. OOS has an international editorial board of recognized practitioners and researchers, whose intention is to maintain high standards and quality by means of a thorough and balanced review process. As timely reporting of work is increasingly important, OOS intends to establish a maximum turnaround time for papers of 9 months between submission and appearance in print. A number of different styles of paper are published by OOS: . Research Papers. . Experience Papers. . Research Perspectives (forward-looking papers). . State-of-the-Art Surveys. . Responses to Earlier Papers. . Book Reviews, especially extended ones offering technical commentary. OOS encourages contributions in the following areas: . Object-oriented systems development methods. . Object-oriented analysis and design techniques. . Object-oriented systems architectures. . Object-oriented applications. . Object-oriented interfaces and interaction. . Object-oriented algorithms and programming techniques. . Object-oriented programming languages. . Object-oriented development and/or programming environments. . Object-oriented operating systems. . Theoretical issues in object-oriented systems. . Metrics in object-oriented systems. . Object sharing and persistent. . Objectbases; object-oriented databases (OODBMS). . Object-oriented enterprise systems. . Issues in the adoption of object technology. Editorial Board The editorial structure is a four level one: . the Editor-in-Chief . 3 Regional Editors (The Americas; Europe, Middle East and Africa; Asia, Australia and Oceana) and a Book Reviews Editor. . Editorial Board members. . Referees. The current assingment of roles to people is: Editor-in-Chief Russel Winder. Department of Computer Science, University College London, Gower Street, London WC1E 6BT, UK. Tel: +44 (0)71 380 7293. Fax: +44 (0)71 387 1397. Email: R.Winder@cs.ucl.ac.uk. Regional Editor (Europe, Middle East and Africa) Russel Winder. Department of Computer Science, University College London, Gower Street, London WC1E 6BT, UK. Tel: +44 (0)71 380 7293. Fax: +44 (0)71 387 1397. Email: R.Winder@cs.ucl.ac.uk. Regional Editor (The Americas) Mark Whiting. Battelle Pacific Northwest Laboratories, P O Box 999 M/S K7-22, Richland, WA 99352, USA. Tel: +1 (509) 375 2237. Fax: +1 (509) 375 3641. Email: ma_whiting@pnl.gov. Regional Editor (Asia, Australia and Oceana) Brian Henderson-Sellers. School of Computing Sciences, University of Technology Sydney, PO Box 123, Broadway, New South Wales 2007, Australia. Tel: +61 2 330 1189. Fax: +61 2 330 1807. Email: brian@socs.uts.edu.au. Book Reviews Editor Graham Roberts. Department of Computer Science, University College London, Gower Street, London WC1E 6BT, UK. Tel: +44 (0)71 387 7050 x 3711. Fax: +44 (0)71 387 1397. Email: G.Roberts@cs.ucl.ac.uk. Members of the Editorial Board Pierre America. Philips Research Labs, The Netherlands. Jean Bezivin. University of Nantes, France. Steve Cook. Object Designers Ltd, UK. John Hosking. University of Auckland, New Zealand. Ralph Johnson. University of Illinois at Urbana--Champaign, USA. Doug Lea. SUNY Oswego, USA. Ole Lehrmann Madsen. Aarhus University, Denmark. Boris Magnusson. Lund University, Sweden. Christine Mingins. Monash University, Australia. Satoshi Matsuoka. University of Tokyo, Japan. Oscar Nierstrasz. Universite de Geneve, Switzerland. Peter Wegner. Brown University, USA. To Submit a Paper... Authors should submit four copies of their paper with original artwork to the appropriate Regional Editor. Full instructions for authors are available from the Regional Editors, the Publisher, or by anonymous ftp from cs.ucl.ac.uk/oos. To Subscribe... Simply complete the order form below. Please note that personal subscriptions must be paid for by either a personal cheque or a credit card. ====================================================================== ORDER FORM OBJECT-ORIENTED SYSTEMS (ISSN: 0969-9767) ___ Please send me a free sample copy ___ Please send me instruction for authors ___ Please enter my subscription to Volume 1 (1994 - 4 issues) at: Institutional Rate: ___ 120 pounds (EC), ___ 210 USdollars (USA/Canada), ___ 130 pounds ( RoW) Personal Rate*: ___ 50 pounds (EC), ___ 93 USdollars (USA/Canada), ___ 50 pounds (RoW ) (* Payable by personal cheque or credit card only) ___ I enclose a cheque made payable to Chapman & Hall ___ Please send me a proforma invoice ___ Please bill my: ___ Access/Mastercard, ___ Visa, ___ AmEx (Card Number: ________________, Expires _________) Name:__________________________ Signature:_________________________ Address:_______________________________________________________ _______________________________________________________________ _______________________________________________________________ (If paying by credit card, please use billing addresss) Send to: USA/Canada: Journals Promotion Dept., Chapman & Hall, 29 West 35th Street, New York, NY 20001-2299, USA. Tel: (212) 244 3336 Fax: (212) 244 3426 EMail: 71201.1651@compuserve.com EC/RoW: Journals Promotions Dept., Chapman & Hall, 2-6 Boundary Row, London SE1 8HN, UK. Tel: +44 (0)71 865 0066 Fax: +44 (0)71 522 9623 EMail: journal@chall.mhs.compuserve.com ======================================================================= 34 === Date: Tue, 16 Aug 1994 05:34:48 GMT From: Bob Hathaway Subject: Chicago SPIN Inaugural Meeting with Watts S. Humphrey!!! Chicago SPIN Inaugural Meeting GUEST SPEAKER: Watts S. Humphrey Thursday, September 1, 1994 6:00 PM William Rainey Harper College Auditorium of Building J Algonquin and Roselle Roads Palatine, IL Watts S. Humphrey will be the featured speaker at the inaugural meeting of the Chicago area Software Process Improvement Network (SPIN) chapter. Mr. Humphrey founded the Software Process Program of the Software Engineering Institute (SEI) and is an SEI Fellow. He will present a lecture on the Personal Software Process (PSP) relating PSP methods to practices in other engineering and scientific disciplines. He will describe practical planning and quality management techniques that individuals can apply. The Chicago SPIN was established by software professionals from organizations in the Chicago area. It is a leadership forum for the free and open exchange of software process improvement experiences and practical ideas among practicing professionals. SPIN promotes higher levels of process maturity and software quality. Companies, academic institutions, government organizations and individuals are invited. Registration is free of charge but is required as seating is limited. The meeting will begin at 6:00 PM with the opportunity to network and enjoy refreshments. Mr. Humphrey will speak at 7:00 PM. To Register Call Pat Turner At (708) 925-6140 or FAX at (708) 925-6031 by August 26. For more information or map and directions, call Girish Seshagiri at (708) 498-4303 or Hamid Ghezevat at (708) 797-4105. How to get to Harper College: From the North: Take Highway 53 south to Algonquin Road exit. Go west on Algonquin Road to Harper College. From the South: Take Highwway 53 north to Algonquin Road exit. Go west on Algonquin Road to Harper College. From the East: Go west on the Northwest Tollway (I-90) to the Roselle Road exit. Go north on Roselle Road to Harper College. From te West: Go east on the Northwest Tollway (I-90) to Highway 53. Go north on Highway 53 to the Algonquin Road exit. Go west on Algonquin Road to Harper College. ======================================================================= 35 === Date: 16 Aug 1994 16:28:45 GMT From: kendall@pot.East.Sun.COM (Sam Kendall - Sun Microsystems Labs BOS) Subject: Re: What are BRANDS in Modula3 ? huebner@PrakInf.TU-Ilmenau.DE (Huebner) writes: > In an article I found a short explanation of "brands" in Modula3. > I didn't understand it and have no book about M3 at hand. > So could somebody give me an example of brands? Sure. In Modula-3, type equivalence is structural rather than by name. So the following two types A and B are identical: TYPE A = REF RECORD x, y: INTEGER END; B = REF RECORD x, y: INTEGER END; If you want to prevent a type from being accidentally equivalent to some other, give it a unique brand, eg: TYPE C = BRANDED "C's brand" REF RECORD x, y: INTEGER END; D = BRANDED "D's brand" 1.0" REF RECORD x, y: INTEGER END; C and D are distinct from each other and from A and B. The explicit brands (the strings "C's brand" and "D's brand") must be unique within the program. You can omit the explicit brands, in which case you get an automatically generated brand unique within the program. These issues become important in distributed computing, where type equivalence BETWEEN programs matters. For a more thorough (and more entertaining!) explanation, see chapter 8 of Greg Nelson, editor, _Systems Programming with Modula-3_. ---- Sam Kendall Sun Microsystems Laboratories BOS ======================================================================= 36 === Date: 16 Aug 1994 13:01:20 GMT From: huebner@PrakInf.TU-Ilmenau.DE (Huebner) Subject: What are BRANDS in Modula3 ? In an article I found a short explanation of "brands" in Modula3. I didn't understand it and have no book about M3 at hand. So could somebody give me an example of brands? Thanks in advance -- Michael H"ubner ======================================================================= 37 === Date: 16 Aug 1994 14:13:21 -0600 From: sims@usa.acsys.com (dave sims) Subject: finding the size of the heap How do I get the size of the heap? I've got an M3 program running as a server. In my stress tests, the server failed after a few hours on the error message, "GC: could not extend the traced heap." So, to help debug my server, I want to periodically check the size of the heap to see if it is steadily increasing. I looked through the libm3 runtime interfaces but couldn't find anything simple that would tell me the size of the heap. Is there such a function? thanks. -- Dave Sims (-.. .- ...- . ... .. -- ...) PGP encryption key available Internet: sims@usa.acsys.com on my home page. Packet: coming soon to a repeater near you WWW: my home page ======================================================================= 38 === Date: Wed, 17 Aug 1994 12:22:51 GMT From: mmc@imada.ou.dk (Morten Christensen) Subject: Exceptions in Modula-3. How to implement? Implementation of Exceptions in Modula-3 ? Where can i get information about implementation details of exceptions in the Modula-3 programming language ? I shall use this for my graduation work. - Any info will be greatly appreciated!!! Please MAIL(!) mmc@imada.ou.dk Thanks, Morten M. Christensen Odense Uni., Denmark ======================================================================= 39 === Date: Wed, 17 Aug 1994 13:55:10 GMT From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: finding the size of the heap I've got an M3 program running as a server. In my stress tests, the server failed after a few hours on the error message, "GC: could not extend the traced heap." So, to help debug my server, I want to periodically check the size of the heap to see if it is steadily increasing. Of course you can use the system (Unix) tools to find the total size of your program; any increase is normally due to the heap. However, you will get a much more detailed picture if you run your program with shownew; it will show you the total number of allocated objects for each type... in color. $ myprog @M3shownew -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 40 === Date: Wed, 17 Aug 94 15:07:54 EDT From: gwyant@cloyd.East.Sun.COM Subject: Re: Exceptions in Modula-3. How to implement? > Where can i get information about implementation details of exceptions in > the Modula-3 programming language ? > > I shall use this for my graduation work. - Any info will be greatly > appreciated!!! I don't think there is anything written down, but the details are in sources. You can find them in: libm3/src/runtime/common libm3/src/runtime/ex_stack libm3/src/runtime/ex_frame In a nutshell, the exception handling works as follows. There are two exception handling implementations. On machines without self-describing stacks, 'setjmp' and 'longjmp' are used to effect exception handling. On machines with self-describing stacks, a set of tables are generated containing exception handlers on a per-frame basis. When an exception is raised, the stack is walked to find the appropriate exception handler. I hope this answers some of your questions and helps you understand the sources better. --geoff Geoff Wyant Geoff.Wyant@east.sun.com Sun Microsystems Laboratories, Inc. 2 Elizabeth Drive Chelmsford, Ma. 01824 ======================================================================= 41 === Date: Wed, 17 Aug 94 14:31:16 EDT From: gwyant@cloyd.East.Sun.COM Subject: Re: Modula-3 for SVR4/386 or FreeBSD From: robsch@robkaos.ping.de (Robert Schien) Date: Sun, 14 Aug 1994 17:42:19 GMT Subject: Modula-3 for SVR4/386 or FreeBSD Newsgroups: comp.lang.modula3 Message-ID: <1994Aug14.174219.300@robkaos.ping.de> > Is there a M-3 implementation for SVR4/386 or FreeBSD/NetBSD? Not that I know of, though the Linux implementation would probably make a good starting point. ======================================================================= 42 === Date: 18 Aug 1994 13:03:24 GMT From: pk@i3.informatik.rwth-aachen.de (Peter Klein) Subject: Network Objects: Server Alerting Another Network Objects question: The "Network Objects" TR says (on page 12): If a thread engaged in a remote call is alerted, the runtime causes the thread to raise NetObj.Error and simultaneously attempts to notify and alert the server thread executing the call. [ ... ] The network object system also uses alerts to handle the situation in which a client crashes while it has an outstanding remote method call. In this case, the network object runtime alerts the thread that is executing the method call in the owner. I don't know, but this doesn't work for me. I never managed to get a client crash/alert notification on the server side, although the NetObj.Error on client side works. Can somebody give me an example of this, or is this really not implemented as described? Peter --- Peter Klein E-Mail: pk@i3.informatik.rwth-aachen.de Lehrstuhl fuer Informatik III Tel.: +49/241/80-21311 Ahornstrasse 55 Fax.: +49/241/8888-218 RWTH Aachen 52074 Aachen Germany ======================================================================= 43 === Date: 19 Aug 1994 20:07:45 GMT From: connolly@ulua.hal.com (Dan Connolly) Subject: M3 on linux 1.1 : network config problem? I am getting closer to a modula-3 development system on my desk at home, but I am having some problems. I have assembled a working Linux system from Slakware 2.0 and other materials. I downloaded Michel Dagenais's binary distribution of src-m3 on Linux ftp://ftp.vlsi.polymtl.ca/pub/m3/linux/src-m3-3.3l1.strip.tar.gz and the compiler works (yeah!!) -- I was able to build the hello world program as described in: http://www.research.digital.com/SRC/modula-3/html/example.html But I am unable to run most of the pre-compiled (formsedit, etc.), apps and m3mkdir dumps core. With Michel's help, I have traced the problem down to either a faulty network configuration, or incompatiblilities between old and new linux configurations. Does anyone have any more clues? Details below... To: dagenais@vlsi.polymtl.ca Subject: src-m3 on Linux: a little help? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2810.777272147.1@austin2.hal.com> Date: Thu, 18 Aug 1994 23:55:47 -0500 From: "Daniel W. Connolly" Hi! I saw your announcement somewhere (comp.os.linux.announce maybe?) for M3 binaries for linux, and I managed to download it to my box (isn't term incredible?), but I'm not having any luck running it. I downloaded the stripped version, so I can't get much info, but I noticed you're using fairly old OS and libc.so, so I suspect that's my problem. The behaviour I see is: The compiler works! (yeah!) Most of the apps dont (boo!) bash$ m3mkdir foo Segmentation fault bash$ formsedit *** *** runtime error: *** Exception "MachineIDPosix.Failure" not in RAISES list *** My configuration is: bash$ uname -a Linux spike 1.1.0 #85 Tue Aug 16 00:57:10 CDT 1994 i486 bash$ ls -l /lib/libc.* lrwxrwxrwx 1 root root 14 Aug 15 18:22 /lib/libc.so.4 -> libc.s o.4.5.26 -rwxr-xr-x 1 root root 623620 Aug 15 18:22 /lib/libc.so.4.5.26 bash$ /usr/dll/bin/libinfo -L /usr/lib -- -lc libinfo v2.11 Reading /usr/lib/libc.sa: Library requires libc.so.4 Library version is 4.5pl26 Library resides in registered area occupied by libc.so (c, math, curses, termcap, yp etc.) Start address of library is 0x60000000 Global Offset Table size is 0x1000 (4096) Jump Table size is 0x4000 (16384) Encountered 732 function(s) and 48 global var(s) in stub I get this info about the hello world program: bash$ ./LINUX/foo Hello world. bash$ ldd LINUX/foo libm3.so.3 (DLL Jump 3.3) => /usr/local/soft/modula3-3.3/lib/m3/LINUX/l ibm3.so.3 libm.so.4 (DLL Jump 4.5pl26) => /lib/libm.so.4.5.26 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.5.26 I don't look forward to building the whole thing from source, but beggars can't be choosers... Any hints you can give would be greatly appreciated!!! Dan Date: Fri, 19 Aug 94 14:22:57 EDT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Message-Id: <9408191822.AA03170@gutrune.vlsi.polymtl.ca> To: connolly@hal.com In-Reply-To: "Daniel W. Connolly"'s message of Thu, 18 Aug 1994 23:55:47 -0500 <9408190455.AA02812@austin2.hal.com> Subject: src-m3 on Linux: a little help? MachineIDPosix.Failure is raised when gethostname or gethostbyname does not return a coherent result. Either your config files are not set right (hosts file and the like or the DISPLAY environment variable for X windows) or this is a random symptom of incompatibilities between my "old" LINUX version and newer versions. I was not planning to upgrade my LINUX box yet. January is more likely. Besides you are the first to report such problems. You may want to post to comp.lang.modula3 and ask if anyone succeeded in running M3 with LINUX > 1.xxx. To: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: Re: src-m3 on Linux: a little help? In-reply-to: Your message of "Fri, 19 Aug 1994 14:22:57 EDT." <9408191822.AA03170@gutrune.vlsi.polymtl.ca> Date: Fri, 19 Aug 1994 14:56:33 -0500 From: "Daniel W. Connolly" In message <9408191822.AA03170@gutrune.vlsi.polymtl.ca>, Michel Dagenais writes : >MachineIDPosix.Failure is raised when gethostname or gethostbyname does >not return a coherent result. Either your config files are not set >right (hosts file and the like or the DISPLAY environment variable >for X windows) or this is a random symptom of incompatibilities between >my "old" LINUX version and newer versions. Quite possibly... I have no /etc/hosts file... it seems I also need an /etc/hosts.conf file... Ok... now gethostname() works (I wrote a little C program...) and gethostbyname('localhost') works (from perl), but gethostbyname('spike') still doesn't work. Hmmm... Could you tell me exactly how gethostbyname/gethostname is invoked? Alternately, could you tell me which of the M3 archives the relavent source is in so I can read it myself? >I was not planning to upgrade my LINUX box yet. January is more likely. >Besides you are the first to report such problems. Have there been any/many reports of success? > You may want to >post to comp.lang.modula3 and ask if anyone >succeeded in running M3 with LINUX > 1.xxx. Will do... Thanks for the info. 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 ======================================================================= 44 === Date: Fri, 19 Aug 1994 19:51:30 GMT From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Several new things available on ftp.vlsi.polymtl.ca You will now find on ftp.vlsi.polymtl.ca:pub/m3: A new version of the LINUX distribution (3.3l1 instead of 3.3l0) is available; it fixes small problems in the LINUX templates that caused the link or ship to fail in some cases. HPPA binaries. Slides for a presentation of the Modula-3 tools and libraries. A Zeus animation of computer memory hierarchies (virtual memory, RAM and cache). Preliminary versions (not yet passed through the interface police) of a real geometry library and insertable sequences. If you have useful packages to share, or perhaps binaries for other architectures (DS3100, ALPHA...) i can provide FTP disk space if you need. -- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 45 === Date: Mon, 22 Aug 94 19:22:33 GMT From: rcv@ukc.ac.uk (R.C.Van-Den-Bergh) Subject: [Q] How to use Unix.ioctl ? Hi, I am trying to get the terminal into 'raw' mode. Unfortunatly, the documentation on the Unix.ioctl() procedure is none too clear. The basic question becomes: How do I set up the argp paramater that the header <*EXTERNAL*> PROCEDURE ioctl (d, request: int; argp: ADDRESS): int; demands ? What are the TIOCGETD range of constants used for (and how) ? The structures are commented out, so they can't be used to do C-style bit twiddling before calling Unix.ioctl. Thanks, Cedric Vandenbergh ======================================================================= 46 === Date: 23 Aug 1994 22:18:37 GMT From: connolly@ulua.hal.com (Dan Connolly) Subject: Robustness, <*FATAL*>, NEW() I am trying to determine whether Modula-3 is suitable for writing applications that handle large quatities of valuable data. Much of the documentation says that the compiler is still a research project, but I see a _lot_ of very good library code on which to build applications. On browsing through the library implementation code, I see a few more <*FATAL*> pragmas than I'd like. I don't mind these, if they signal coding errors, but some of them are not -- Rd.Failure is <*FATAL*> in some places. As long as fixing these "hacks" doesn't involve changes to the interfaces, this is OK. The implementation will improve over time. But if the library interfaces are not stable, or if the interfaces are limited to treating transient errors such as IO errors as checked runtime errors, then the value of M3 as a development platform is greatly decreased. Basically, I want to know if, no matter how well I write my application code, there are still cases where a correct M3 runtime will terminate my application and corrupt/lose application data. A while back, I asked what the specified and implemented behaviour of NEW() is when virtual memory is exhausted. I understand that the implemented behaviour is a fatal error. I'm still not sure what the specified behaviour is. It was suggested that a runtime might provide an interface for an application to deal with this situation, and that that interface might eventually become a standard interface (sorry, I can't come up with an exact citation.) In another forum, someone explained that the C++ runtime provides such a hook. The C++ model makes sense, and I suggest that something like this be integrated into Modula-3. In the C++ runtime, new() is implemented ala [Soustrup, p 312]: static void (*_new_handler)(); void *operator new(size_t size) { void *p; while( (p = malloc(size))==0 ){ if(_new_handler) (*_new_handler)(); // ask for help else return 0; } } An application can install a _new_handler ala: void (*oldh)() = set_new_handler(&my_new_handler); my_new_handler can try to free some memory to let new() try again. If it can't free any memory, it must not return. It _can_ raise exceptions. A common application technique that I've seen is to allocate a big "parachute" block of memory at startup. When the s*** hits the fan, your _new_handler gets called. It frees the "parachute" memory, which gives the application just enough memory to clean up its act and exit gracefully. The C++ runtime is not threadsafe, though. Well... I've never seen a threadsafe implementation. I don't know if the specification is compatible with a threadsafe implementation or not. Does it make sense to change the specification of M3's NEW() so that it can raise an exception? Granted, generally if there isn't enough VM to do a new NEW(T), then there isn't enough memory to do anything useful. But what if an application is allocating a great big buffer, and it wants to be able to deal with "there isn't quite that much memory available" errors? To me, treating virtual memory exhaustion as a checked runtime error rather than an exception is like treating EOF from a file as a checked runtime error -- the application programmer has no way to detect/prevent this error. 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 ======================================================================= 47 === Date: 24 Aug 1994 11:50:26 GMT From: murphy@wsc.com (Paul Murphy) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? We use Eiffel for developing the core of our applications and Objective-C for the GUI layer and are very happy with that mix. - Paul murphy@wsc.com > ... >It would appear, that for applications with lots of human interaction, where >the run-time overhead cost is acceptable, dynamically typed languages such >such as Objective-C, Smalltalk, or CLOS, offer superior productivity >enhancement, and superior re-use, at the cost type safety. > ... ======================================================================= 48 === Date: 24 Aug 1994 01:02:50 GMT From: derway@ndc.com (D. Erway) Subject: Static vs Dynamic Typing: Effects on Productivity? The comp.object faq, (a beautiful piece of work!), correctly states that languages with dynamic typing and run-time method lookup are inherently more powerful than statically-typed dynamically bound languages such as C++, modula3 & Eiffel. Others have pointed out that dynamic typing actually allows better encapsulation, and looser coupling, as a client need know less about an object than with static typing. It would appear, that for applications with lots of human interaction, where the run-time overhead cost is acceptable, dynamically typed languages such such as Objective-C, Smalltalk, or CLOS, offer superior productivity enhancement, and superior re-use, at the cost type safety. Does anyone have experience that would confirm or contradict this? For instance, that type safety leads to greater enhancement of productivity and/or re-use? Any insights, or ideas are appreciated! Thanks, Don ======================================================================= 49 === Date: Wed, 24 Aug 1994 03:05:59 GMT From: pfkeb@kaon.SLAC.Stanford.EDU (Paul F. Kunz) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >>>>> On 24 Aug 1994 01:02:50 GMT, derway@ndc.com (D. Erway) said: > The comp.object faq, (a beautiful piece of work!), correctly states > that languages with dynamic typing and run-time method lookup are > inherently more powerful than statically-typed dynamically bound > languages such as C++, modula3 & Eiffel. Others have pointed out > that dynamic typing actually allows better encapsulation, and looser > coupling, as a client need know less about an object than with > static typing. > It would appear, that for applications with lots of human > interaction, where the run-time overhead cost is acceptable, > dynamically typed languages such such as Objective-C, Smalltalk, or > CLOS, offer superior productivity enhancement, and superior re-use, > at the cost type safety. You don't lose all of your type safety with Objective-C. You lose it where you chose to lose it. For example, if you have a Button object that sends a message when pressed, then to enchance productivity and gain superior re-use, you would like the Button to be able send the message to an object of any class. So you decide to lose type safety for the target of the button message and declare... id target; // object to receive button pushed message In addition, you might have multiple Buttons on the same panel each of which would like to send a different message to the same object. So you declare... SEL action; // message to send when button is pushed where 'action' can be changed at runtime. Now you compile the Button and put it in a library. The Button is ready for re-use no matter what class of object the target will be or what method the target wants invoked when the Button is pushed. On the other hand, Objective-C is strongly typed as well. Suppose you have a Panel object which contains a Slider. Only a Slider responds to certain methods such as setMinValue:, setMaxValue:, etc. In your Panel you can declare... @class Slider; @interface MyPanel:Panel { Slider *mySlider; < ... other stuff ...> } This done, any implemenation code that attempts to send a message to 'mySlider' that an object of class Slider doesn't respond to will result in a strong warning message. If you take warning messages as errors (like I do), then you have strong typing. In this case I've kept my strong typing. That is, I did not chose to ignore it. This discussion assumes the Objective-C compiler as implemented by NeXT or FSF's gcc. The '@class' directive is not supported by Stepstone. > Does anyone have experience that would confirm or contradict this? > For instance, that type safety leads to greater enhancement of > productivity and/or re-use? Any insights, or ideas are appreciated! I confirm that run-time binding is a good thing. Strict adherence to compile time type checking is too orthodox for me. I believe you can not live well without a few little "white lies" or a bit of sin. All within reason of course. Objective-C offers that. It is a reasonable compromise between strong type checking and selective type ignorance. -- Paul F. Kunz Paul_Kunz@slac.stanford.edu (NeXT mail ok) Stanford Linear Accelerator Center, Stanford University Voice: (415) 926-2884 (NeXT) Fax: (415) 926-3587 ======================================================================= 50 === Date: Wed, 24 Aug 1994 07:15:03 GMT From: n8243274@henson.cc.wwu.edu (S. Lee ODEGARD) Subject: EXTENSIONS PROPOSAL FOR CLIENTS USING MODIFICATIONS FROM THE STANDARD It may be human nature to try to outdo the standard given. In this newsgroup, for example, there have been many changes proposed to the very fine Modula-3 standard -- notably from users of other object-oriented standards that complain 'why can't I do _x_?'. Later on in the life-cycle of a language standard, there are developed extensions to the original that prove exceptionally popular or useful. Though I must admit that heretofore the original standard of the now popular languages were quite weak, I still hope that Modula-3 evolves to that point. This proposal is to address this issue and call for a uniform means of registering the extensions used by clients. All deviations from the Standard that are used must be declared. I propose that the module declaration of section 5.3 be changed to read as follows: 5.3 Modules A module has the form MODULE Id WITH { Ex1, Ex2, ... Exn } EXPORTS Interfaces ; IMPORTS Block id. where __id__ is an identifier than names the module, __Interfaces__ is a list of distinct names of interfaces exported by the module. __Imports__ is a list of import statements, and __Block__ is a block, the _body_ of the module. The name __id__ must be repeated after the __END__ that terminates the body. "__EXPORTS Interfaces__" can be omitted, in which case Interfacus defaults to __id__. __Ex1__, __Ex2__, ..., __Exn__ is a list of _extensions_, declaring that the module empolyies implementation-dependant fascilities, named __Ex1__, __Ex2__, and so on through __Exn__. The __WITH { Ex1, ... }__ can be omitted to indicate no extensions are used. To illustrate this, in the remainder of this paper I propose an extension, whose implementation can be done by writing a simple translator into unextended Modula-3. I would hope that the community considers this proposal on its own merit, and apart from the theme of this paper, the registration of extensions by clients. <> THE TYPE CONSTRUCTOR, "TYPECONS". M3 introduces structural equivalence of types, which frees the implementation from having to track type names. The extension of type constructors may present a more concise notation in some circumstances, or may be useful in prototyping. A type constructor is declared like this: TYPE id( name_1, name_2, ..., name_n ) = type ; This declares __id__ to be of type __type__, with every appearance of __name_i__ replaced with its actual. for example TYPE field( length ) = ARRAY [ 0 .. length-1 ] OF CHAR ; VAR f1 : field( 12 ) ; Declares __f1__ to be of type __ARRAY [ 0 .. 11 ] OF CHAR__. Using this proposed protocol, a complete program might appear: MODULE example1 WITH{ TYPECONS } EXPORTS Main ; TYPE trio( form ) = ARRAY [ 0 .. 2 ] OF form ; Jset = SET OF [ 0 .. 7 ] ; CONST R1 = trio( Jset ){ Jset{ 3, 2 }, .. } ; TYPE pk = ARRAY [ 0 .. 7 ] OF trio( BOOLEAN ) ; CONST pk1 = pk{ trio( BOOLEAN ){ FALSE, .. }, .. } ; ... END example1. ---------------------------------------------------------------- S. Lee Odegard ======================================================================= 51 === Date: 24 Aug 1994 09:12:12 GMT From: schaetz@fzi.DE (Roland Schaetzle) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? Hallo, Don Erway (derway@ndc.com) wrote: > It would appear, that for applications with lots of human interaction, where > the run-time overhead cost is acceptable, dynamically typed languages such > such as Objective-C, Smalltalk, or CLOS, offer superior productivity > enhancement, and superior re-use, at the cost type safety. > Does anyone have experience that would confirm or contradict this? For > instance, that type safety leads to greater enhancement of productivity and/o r > re-use? Any insights, or ideas are appreciated! In the past few years I have worked on projects using Eiffel, CLOS and currently I am using Smalltalk. My experience with the Eiffel-type-system is quite good. Errors are caught at a very early stage (by the compiler), so you don't have to expect any big surprises when the compiler has accepted a program. Another advantage of this type-system is, that it forces you to think about your class-structure befor your implement it. Languages like Smalltalk or CLOS give you more freedom to implement poor designs. And what I have seen is, that people use this freedom! The importance of good analysis and design is rated very low and since the language permits it, implementation is begun very early. Some people consider this early code production as a success, because they can show something at an early stage (anlaysis and design produces just some diagramms ;) ). The difficulties with this code show up only in the long run, when the system is changed and when it grows. Another problem with CLOS and Smalltalk are the hardware resources they need. The Eiffel-project I've done was implemented on a PC-386 (16 MB) using Unix V4.0 with acceptable performance, whereas the CLOS- and the Smalltalk-projects run on Sun-SPARCstations with large amounts of main memory and especially the CLOS-system was only acceptable on a SPARCstation10. Roland ======================================================================= 52 === Date: 24 Aug 1994 18:23:10 +0200 From: agulbra@tigern.nvg.unit.no (Arnt Gulbrandsen) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <33f2tc$lht@gate.fzi.de>, Roland Schaetzle wrote: >... give you more freedom to implement poor designs. >And what I have seen is, that people use this freedom! Please forgive me for posting without anything real to say. I just wanted you to read the above once more. Theory is very nice, but the practice Roland describes has to be considered, in typing, class hierarchies and everywhere else. Down with the "an int for all purposes" C library! Down with thoughtlessly extended-ten-times struct/class definitions! Down with overused multiple inheritance! Down with similar-but-different methods/functions/variables! --Arnt (frustraded implementer) ======================================================================= 53 === Date: Wed, 24 Aug 1994 14:55:21 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? pfkeb@kaon.SLAC.Stanford.EDU (Paul F. Kunz) writes: > You don't lose all of your type safety with Objective-C. You lose >it where you chose to lose it. [example elided] > I confirm that run-time binding is a good thing. Strict adherence >to compile time type checking is too orthodox for me. I believe you >can not live well without a few little "white lies" or a bit of sin. >All within reason of course. Objective-C offers that. It is a >reasonable compromise between strong type checking and selective type >ignorance. Well said. I think that there are times when dynamic typing is very effective. A design based upon dynamic types has fewer explicit dependencies than a design based upon static types. To be sure, there are implicit dependencies. i.e. when you send a message to an object, the lack of that interface will not be detected until run time. But, for many application domains, this is a tenable situation and the simpler static dependency structure is a good trade off. -- 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: Wed, 24 Aug 1994 15:08:50 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? schaetz@fzi.DE (Roland Schaetzle) writes: [Regarding Eiffel] >Another advantage of this type-system is, that it forces you to think >about your class-structure befor your implement it. Languages like >Smalltalk or CLOS give you more freedom to implement poor designs. I dislike arguments like this. Good design cannot be legislated; it must be produced by good designers. A good designer will be able to use either a dynamic or static language with equal efficacy (as long as the different paradigms are adequately understood). >And what I have seen is, that people use this freedom! If they use it in dynamic language, then they will use it in static languages too. They will just express it differently. The result will be the same. >Another problem with CLOS and Smalltalk are the hardware resources >they need. The Eiffel-project I've done was implemented on a PC-386 (16 MB) >using Unix V4.0 with acceptable performance, whereas the CLOS- and the >Smalltalk-projects run on Sun-SPARCstations with large amounts of main >memory and especially the CLOS-system was only acceptable on a >SPARCstation10. This used to be a big problem. It is far less so today. -- 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++ ======================================================================= 55 === Date: 24 Aug 1994 09:39:35 GMT From: Robb.Nebbe@di.epfl.ch (Robb Nebbe) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article , derway@ndc.com (D. Erway) wri tes: |> |> The comp.object faq, (a beautiful piece of work!), correctly states that |> languages with dynamic typing and run-time method lookup are inherently more |> powerful than statically-typed dynamically bound languages such as C++, |> modula3 & Eiffel. Others have pointed out that dynamic typing actually allo ws |> better encapsulation, and looser coupling, as a client need know less about an |> object than with static typing. |> If we have two similar logical systems, one that is inconsistant and one that is consistant then the inconsistant system is in some twisted sense more "powerful" because you can express things that you can't with the other system. The question is whether the extra flexability that results from dynamic typing, as found in say Smalltalk, lets us express things that may not be restructured and expressed in Ada, C++ or Eiffel, and that is "worth expressing". - Robb Nebbe ======================================================================= 56 === Date: 24 Aug 1994 15:49:22 GMT From: tmb@arolla.idiap.ch (Thomas M. Breuel) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article derway@ndc.com (D. Erway) writ es: |It would appear, that for applications with lots of human interaction, where |the run-time overhead cost is acceptable, dynamically typed languages such |such as Objective-C, Smalltalk, or CLOS, offer superior productivity |enhancement, and superior re-use, at the cost type safety. | |Does anyone have experience that would confirm or contradict this? For |instance, that type safety leads to greater enhancement of productivity and/or |re-use? Any insights, or ideas are appreciated! That depends on what kind of static type system we are talking about and what other facilities exist in the language. I think statically typed OO languages that base OO polymorphism on inheritance do pose problems for reuse. There are alternatives, however, that preserve many of the advantages of dynamic typing while giving you type safety. Some that I am familiar with are: (1) OO polymorphism based on signatures rather than inheritance: this exists as a C++ extension (among others) and means that any object that has the right methods and types can be substituted for one another (some consider this a risk, but in practice it doesn't seem to be a problem) (2) Use closures in a statically typed language: similar to (1), but even more powerful and general. (3) Use existential type quantification: similar to (2), but some additional power. (4) Use parameterized modules that don't replicate code: NJ/SML has those. They provide a superset of the functionality of C++ template classes but without the code bloat. (5) Use Milner-style polymorphism: similar to C++ template functions, but much easier to use and without the code bloat. I have used (2), (4), and (5) extensively (in the programming language SML) and find that they provide much better reuse than any approach based on objects (I have used both C++ and CLOS extensively as well). I suspect that (1) would be a good compromise for staying within the OO paradigm, while giving the programmer some extra power. Also, what makes life with a statically typed language much more convenient is type inference in the compiler. Many people using a statically typed language with type inference initially don't even realize that it isn't a dynamically typed language, since they don't have to add type declarations. And yet, the compiler makes certain that only type-correct programs get executed. Thomas. ======================================================================= 57 === Date: 24 Aug 1994 10:28:49 GMT From: Robb.Nebbe@di.epfl.ch (Robb Nebbe) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? My opinion is that if your thinking is fuzzy about a problem then a language like Smalltalk can be a big help. Static typing can be more of an obstacle to exploring the solution space than anything else. If you have done a reasonable amount of analysis and design then ideally you should be able to express a signifigant portion of you design constraints in a statically typed language and use the language as a tool to verify what you consider to be a good consistant design. - Robb Nebbe ======================================================================= 58 === Date: 24 Aug 1994 15:59:22 GMT From: baechler@lia.di.epfl.ch (Emmanuel Baechler) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? > Another advantage of this type-system is, that it forces you to think > about your class-structure befor your implement it. Languages like > Smalltalk or CLOS give you more freedom to implement poor designs. > And what I have seen is, that people use this freedom! The importance > of good analysis and design is rated very low and since the language > permits it, implementation is begun very early. Some people consider > this early code production as a success, because they can show > something at an early stage (anlaysis and design produces just some > diagramms ;) ). The difficulties with this code show up > only in the long run, when the system is changed and when it grows. There's no doubt that you can use CLOS for poor programs. On another hand It is much more flexible if your task is to create a model and to explore its various aspects. -- 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. ======================================================================= 59 === Date: 24 Aug 1994 15:59:47 GMT From: jeske@ux4.cso.uiuc.edu (David Jeske) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? My experience has been similar to many of those who have posted. I may just see things in a different way. It is true that many get themselves in more trouble with a dynamically typed language by not putting enough thought into their project. However, I think that's their fault, not the languages. You put someone in a ferrari and if he gets a speeding ticket, is it his fault or the ferrari's? Put the same amount of Design time in and you'll get a similar quality product out, with superior flexibility and reusability. Most of the more experienced programmers I know find it painfull to work in statically typed languages like C++ because some reason always comes up that they (or I) need run-time binding, and we end up having to cheat the compiler and the language. Ultimately this leads to a much less elegant and maintainable program. Too often I have head of people speak of C++ as the language of "casting", where to get anything done you have to cast everything. Many of these situations where one ends up needing to cast to get some flexibility COULD be turned around into something which would be legal in C++ by using extra "protocol" style classes and multiple-inheritence. It just creates even more of a painfull mess though. If you know a language like C++ or Eifell well enough, you should be able to implement the same functionality as you could in Objective-C or SmallTalk. I personally find that not only does it take alot more work, but the solutions seem much less elegant. There are a few things you will never truly be able to pull of in the more static languages though, and I find that it is infinitly usefull in some larger projects. Objective-C (specifically on NeXT, but FSF gcc supports this as well, not sure about StepStone) has Dynamic "bundle" loading capabilities which are far superior to anything I've seen anyone do in a similar language (say C++) with DLL, or loaded .o files, or anything. Most people don't really miss this.. but then again, that's because they never had it. -- David Jeske(N9LCA)/CompEng Student at Univ of Ill at Cham-Urbana/NeXT Programme r CoCreator of the GTalk Chat Software System - online at (708)998-0008 Mail: jeske@ux4.cso.uiuc.edu NeXTMail: jeske@sumter.cso.uiuc.edu ======================================================================= 60 === Date: Wed, 24 Aug 94 09:05:33 -0700 From: mcjones@src.dec.com Subject: Re: Robustness, <*FATAL*>, NEW() Dan, You say: On browsing through the library implementation code, I see a few more <*FATAL*> pragmas than I'd like. I don't mind these, if they signal coding errors, but some of them are not -- Rd.Failure is <*FATAL*> in some places. While designing Modula-3 libraries at SRC, our philosophy has been to treat conditions that could only be caused by client programming error as checked runtime errors rather than as declared exceptions. So in general, input/output errors are treated as exceptions. (The interface IO is itself an exception! It was designed to be as "Pascal-like" as possible, for teaching a first course in programming.) If you see a specific occurrence of <*FATAL*> that you believe is a "hack", feel free to report it as a bug. But note that there are legitimate reasons for using it, say when a program is dealing with a known reader class like TextRd.T that never raises Failure. * * * You also comment on the problem of recovering from running out of virtual memory. This turns out to be quite a thorny problem. I think the best thing I can do is by attaching to this message the dialog that went on during the "beta test" of the new library interfaces (SRC Research Report 113, "Some Useful Modula-3 Interfaces). The parties are Xerox PARC's David Goldberg, Hans Boehm, Alan Demers, and David Nichols, and SRC's John DeTreville, who designed and implemented the garbage collector in SRC Modula-3. The dialog covers many of the issues, and apparently ends when the participants run out of steam. Paul McJones mcjones@src.dec.com (editor of SRC 113) ----- RTAllocator should allow handling out of memory ----------------------------------------------- David Goldberg: ... there is one system problem that is not currently handled, namely running out of memory. I would very, very much like to see this handled in RTAllocator. One approach was suggested by Roy Levin a while back: Have a RegisterNoMemory(proc) routine that causes proc() to be called when memory is gone (or very low). Example of use: in the 'Solitaire' program, the 'Hint' button generates a tree of possible moves. If this tree gets very big and consumes all memory, the RegisterNoMemory proc could abandon the search down the current branch, NIL-out that branch, and ask for a garbage collection. Currently what happens is that Solitaire crashes if you bug 'Hint' and memory is low. Interface Police: Ok, make a concrete proposal and we'll talk. How low should memory be before the runtime complains? Before or after a collection? Is it ok to call your procedure from inside a runtime critical section (after all, you're probably in the middle of a NEW)? Are multiple notification procedures allowed to be registered? Shouldn't a routine that consumes arbitrary amounts of memory be coded to poll the allocator to ask how much memory is available? Hans Boehm/Alan Demers/David Goldberg/David Nichols: We believe that programs wishing to handle allocation failures will be able to do so with high (but not perfect) reliability if the interface provides two features: versions of the RTAllocator.New routines that report if the allocation is not possible (either by returning NIL or raising an exception), and a way to register a callback when memory is low. Both features are necessary. Here are two typical scenarios: (1) The Solitaire program. Before starting, Solitaire allocates a 'safety net' block of memory, and registers a callback. When memory is exhausted, the callback frees the safety net, sets a flag, and returns. In the Solitaire program proper, the inner loop of the move generator checks the flag immediately after allocating a new node. If the flag is set, it abandons the search. It would not work for Solitiare to allocate new tree nodes with RTAllocator.New() and check for an error: as memory gets low, a library routine in some other package could cause an allocation failure. Unfortunately, there is a race condition since another thread could run and do an allocation between the time the faulting NEW returns and all references to the search tree are NIL'ed. This can be mimimized by adding some slop to the safety net. (2) An editor that allocates O(n) bytes of memory when opening an n-byte file. If the users tries to open a huge file, you don't want to crash, but rather tell the user that the file can't be opened (in UNIX, the user can then kill some processes to regain swap space and try again, or in an emacs-style editor he can delete some buffers and try again). A callback won't work for this, because when attempting to open a huge file, the allocation must be aborted: there just isn't enough memory to go around. Instead an RTAllocator.New() routine should be used for this allocation. However, the editor will also want to register a callback proc to guard against NEW()s in other parts of the program that can't be satisfied. If the callback is passed the size of the memory allocation that can't be satisfied, the callback will be able to pick between two strategies. If there is a 'safety net' which is larger than the block to be allocated, the callback can free it and set a "low on memory" flag, with the editor cleaning up properly later. If the safety net is not big enough, the callback itself can attempt an emergency save before crashing. Here's a specific proposal that embodies these ideas. We're not wedded to the details. Note that RTCollector.LimitRelative is not essential: it just lifts some of the functionality currently in RTHeapPolicy. 1. Add the following to RTCollector.i3: PROCEDURE LimitAbsolute(n: CARDINAL); (* Don't let the heap grow beyond n bytes. The collector/allocator should observe this in all heap growth decisions. *) [Comment from Hans: I don't think there is a way to write programs that are reasonable citizens on a shared system without some such facility.] PROCEDURE LimitRelative(x: REAL); (* Advisory. Try to keep the heap size at roughly x times the amount of live data. (For ref counting it affects only the backup collector for cycles.) *) [Comments from Hans: The performance of all collectors with which I am familiar depends crucially on such a parameter. Thus it might as well be exposed in some portable interface. (The allocator should of course use less memory if it gains no time advantage from using more.) The "amount of live data" is, of course, implementation defined, as are the minimum values of x that have any chance of being observed.] 2. In RTAllocator.i3, add OutOfMemory to RAISES clauses of all the New routines, and add the following: EXCEPTION OutOfMemory; TYPE CallBackObj = OBJECT notify(bytes: CARDINAL) END; PROCEDURE RegisterHeapFullCallback(obj: CallBackObj); (* Add obj.notify to the list of procs to be called if an allocation request is about to fail, either because of lack of memory, or due to violation of an RTCollector.LimitAbsolute imposed limit. The notify method will be called with an argument specifying the size in bytes of the allocate call that triggered the callback. The notify method may not allocate or acquire locks, or call any procedures that do. It may be invoked synchronously with any combination of locks held. (Should there be a way to delete a registered callback?). If a garbage collection after this callback fails to reclaim enough memory to allocate the requested object, an exception will be raised if the allocation was through RTAllocator. Otherwise a checked runtime error will result. The notify proc is not called when memory fails from an RTAllocator.New call (these failures can be caught by the user). Typical actions by notify would include one of the following: 1) Clearing pointers to reduce the amount of accessible memory. 2) Calling RTCollector.LimitAbsolute with a larger limit. *) 3. Variations on this proposal: Might want to consider adding: PROCEDURE GetLimitAbsolute(): CARDINAL; (* Return the current absolute heap limit *) The usefulness of RTCollector.LimitAbsolute in the callback would be increased if there was a way to tell if this actually freed up any more memory. One approach would be to change CallBackObj to TYPE CallBackObj = OBJECT notify(bytes: CARDINAL; retry: BOOLEAN): BOOLEAN END; and change the action of RegisterHeapFullCallback to: (* If a garbage collection after all callbacks have been executed fails to reclaim enough memory to allocate the requested object, then any notify() procs that returned TRUE will be called again with retry := TRUE. Otherwise an exception will be raised if the allocation was through RTAllocator, or else a checked runtime error will result. *) Thus, if you wanted to first try and get more memory in the callback by calling RTCollector.LimitAbsolute, you could return TRUE and wait for a callback with retry = TRUE. If this second callback occurs, you will need to clear some pointers to free up memory. Or another variation: add PROCEDURE GetTotalBytesAllocated(): CARDINAL; (* Returns the total number of bytes allocated since the program begin. A CARDINAL may not be big enough, perhaps this should be a LONGREAL? *) Then the retry argument to the notify method can be eliminated, since a call is a retry only if GetTotalBytesAllocated() shows no additional allocations since the last callback. John DeTreville: When I read your March proposal for handling running out of memory on the traced heap, I didn't quite see how to implement the details you gave. I've been iterating to create mechanisms that are simpler and more implementable, and I've now arrived at quite a simple interface. In particular, I now believe that (almost) all the functionality you ask for is already provided by the current interface. I say "almost" because there's a few status calls to be added, and because some of the current mechanisms are clunky, but I believe I can tell a convincing story. Note that these mechanisms are or would be in SRC-specific interfaces (currently called RTAllocatorSRC, RTCollectorSRC, and RTHeapRep); I don't think we understand them well enough to put them into the public IP interfaces. Let's first distinguish VM limits from application-imposed limits. The amount of VM available to the application is a hard limit, although not one that can easily be predicted. In the current SRC M3 implementation, both the allocator and the collector allocate VM from the kernel when necessary. If the collector tries to allocate VM and fails, the program must crash: there is no way to reestablish the necessary invariants to let it continue. I propose treating VM exhaustion as a checked runtime error, in the allocator and in the collector. The goal is then to establish and maintain an application-imposed limit that is uniformly stricter than the VM limit, whatever that may be. You propose a mechanism to allow calls to the New* procedures to fail if they would exceed the application-imposed limit. Of course, only a small part of the code would take advantage of this facility. This code could equally well query the heap to determine the current size, and compare it against the limit; if the program can also predict the size of the object to be allocated, it can decide whether or not to proceed. This approach requires some collector-dependent code in the application, but I doubt that it would be very much. It also allows possible race conditions, but I believe they're not much worse in practice than in the original proposal. You also propose a mechanism to notify the program whenever the limit is about to be exceeded. It's quite complicated to get such immediate notification. First, the procedures notified can't acquire locks or call most procedures in other modules. Second, it requires a new collection to run synchronously after the procedures to see if enough space has been freed and whether some of the procedures must be called again; this causes an interruption of service. Here's a different proposal, which might not allow space bounds as tight as in the original proposal, but which seems simpler. We would add a mechanism for an application thread to wait for the next collection to finish. This mechanism could replace the current mechanisms for registering and unregistering synchronous monitors, which have numerous complex and poorly documented constraints on what actions they can perform. Each time through, the thread could compare the amount of space still reachable to the application-imposed limit, and either free some data before the next collection (the ability to hold locks would be handy here) or increase "gcRatio" to make the collector work harder and keep the total heap size under control, or both. There is still the danger that the application could allocate so rapidly that this asynchronous thread might not be able to keep up, but otherwise asynchronous actions seem a lot more reasonable than synchronous. This is one approach, and there are others. What's nice about this design is that it requires almost no changes to the interface, only better status reporting and a replacement of the mechanisms for registering and unregistering synchronous collection monitors. Maybe you could even work around the current lack of these facilities. Let me know what you think. Hans: One quick comment, without having thought much about the rest: "This code could equally well query the heap to determine the current size, and compare it against the limit; if the program can also predict the size of the object to be allocated, it can decide whether or not to proceed." Is this really true? Since the collector can't move some objects, there are presumably fragmentation issues. Am I guaranteed to be able to allocate 1 MB if the current heap size is 1 MB below the limit? This is certainly false in PCR, and I'm not sure how you could guarantee it without remapping pages. John: Hans Boehm notes that I was wrong about the client of New* being able to predict whether an allocation would succeed or fail, because of likely page-level fragmentation. This needs to be fixed in my proposal. To expand on my earlier message, let me outline a completely different approach for handling heap overflow, that perhaps has more in common with the original PARC proposal, but which seems far too complex and unwieldy to me. This complexity is why I tried to work out a simpler approach, even at the cost of providing fewer guarantees. We start by imagining that we want to be able to continue to run even if we exhaust VM. First, this means that we can never allocate VM from inside the collector. The implication is that whenever we allocate VM in the allocator, we allocate enough extra to tide us over through the next collection, no matter how much of the heap it retains. This suggests that we will significantly overallocate VM. For example, with a stop-and-copy collector and gcRatio set to 1, a program with a stably-sized reachable set currently requires 3 times as much space as the reachable set, but the "failsafe gc" would require 4 times. (Doing even this well depends crucially upon the SRC implementation detail that the current collector never copies objects bigger than one page, but leaves them in place. Otherwise, the possibility of fragmentation would make it much more difficult to determine how much memory to leave free for the collector, and in what sizes of runs of pages. It will also take some work to avoid off-by-one errors in predicting how much memory a collection could take.) Of course, if the client decreases gcRatio, or switches from sort-and-copy collection to concurrent collection, that would require allocating more VM, to ensure that the collector cannot run out of VM. That means that these operations can also fail, just like allocator operations. Only some programs will want to be able to back off when they reach VM limits. Others won't mind getting a checked runtime error; in return, they will require less VM. Therefore, we need procedures to switch back and forth between these two modes. Again, attempting to switch to failsafe mode can fail. The collector currently allocates its own space on the traced heap during collections, which will have to be moved to the untraced heap if we are to predict how much traced heap a collection can use. Note that in general, once VM is exhausted, allocations on the untraced heap may start to fail, and so programs will probably die very quickly once VM is exhausted. But let's move on. In addition to the VM limit, we also want an application-imposed limit on heap size. The allocator and collector will guarantee that the heap size will never exceed this limit. Again, we will overallocate VM in the allocator to avoid exceeding the limit in the collector. Again, setting the limit may fail. So what happens when a NEW fails, or a New*, or switching to concurrent collection, or setting the application-imposed limit, or whatever? This happens whenever performing the operation would exceed the application-imposed limit, or when attempts to allocate enough extra VM fail. Some of these can signal an error, and the client can chose to do something else instead. In some cases, such as setting gcRatio, it might make sense for the failing operation to tell the client how close to the impossible value would be possible. NEW, though, should not signal an error; this would require massive changes in all existing modules that would not be add value to most clients. In this case, I can't think of anything much better than the original proposal. Before attempting to allocate the object, the collector will try to free up some storage. First, it can perform a collection, or finish the current one. If that doesn't do it, it can call one or more procedures registered by the application to drop links to some storage, or to change collector parameters. If that doesn't do it, we can perform another collection. And so on and so on, until the procedures say to give up. Note that these collections must be synchronous, since no allocations may be possible until this mechanism completes, and the collections will therefore cause interruptions of service. Note also that the procedures cannot acquire locks, cannot allocate storage, cannot call thread primitives, and so on, and therefore cannot call into most libraries; they are essentially restricted to reading and writing data structures whose implementations they know, and changing collector parameters. This seems excessively restrictive, but also unavoidable in this approach. In short, this seems like a lot of extra mechanism to add to the allocator and collector, that doesn't seem to do quite what you want; it gives you strict limits, but at a cost. My proposal of this morning is at least much simpler, although it can give looser limits. John, continuing: Thinking a little more about the problem of running out of storage in the untraced heap, it seems that the only reasonable thing to do is to merge the implementation of the untraced heap with the traced heap. This was, untraced NEWs that fail can be handled exactly the same way as traced NEWs, with a synchronous cleanup routine that frees enough VM to proceed, or resets parameters. This means that the allocator and collector cannot use the untraced heap, but must either use a static amount of storage which they could overflow, or must allocate enough extra in response to client applications that they cannot possibly run out of space. The potential space overhead for maximum-sized stacks, for example, is huge. The more this proposal is fleshed out, it more it seems that doing a good job of recovering from heap overflows is quite tricky, which is why I suggest a lower-tech approach for now. Hans: I just went over the last few messages in this thread again. I think the bottom line is, as you say: It's hard to implement an out-of-memory call-back on top of the current collector. Given the current collector, a collector call-back that allows polling is probably the best you can reasonably do, and should certainly be provided. The remaining question, which also seems to be motivated by other concerns here, is: To what extent are you tied to this collector design? The problem here seems to be mainly caused by copying old generation objects, since you could perhaps bound the size of the young generation? My suspicion, based unfortunately only on anecdotes, is that this is not a good idea anyway, since it uses too much space, and is also fairly expensive in copying cost. (PARCPlace seems to have arrived at the same conclusion, so there's probably at least one other supporter of this position. Some recent complaints here about space usage of Modula-3 programs also point a bit in this direction.) Do you agree? If so, should the interface be designed ignoring current constraints, and should we initially accept a partial implementation? John: It's been a while, so let me recap where we are, or at least where I am. We've been discussing mechanisms for Modula-3 programs to manage their memory better. In particular, we have proposed ways that programs could bound the heap size and recover from heap overflow. I think this topic is complicated enough, and new enough, that we shouldn't try to get it into the current set of portable interfaces. The Interface Police concur. We've floated two broad (families of) proposals for attacking this problem: 1) Allow strong guarantees on the heap size; these guarantees would never be broken. 2) Allow the program to monitor its memory usage, discarding excess data as necessary. I think that #1 is achievable. Adapting the current SRC Modula-3 (allocator and) collector to allow such guarantees would take a month or so. The principal problem is that the current collector tries to maximize space/time performance, and giving such guarantees will probably require extra memory to be set aside that will never be used. The collector would have two modes: with or without guarantees. Most programs would run without guarantees. I also think that a usable version of #2 is possible with almost no change to the current collector. The programmer would have to do more work, and wouldn't get any strong guarantees, but this approach should work for many programs. We've also been discussing a third family of proposals, that seem to combine the worst features of #1 and #2: they require significant changes to the current collector, but son't give very strong guarantees. These seem much less interesting to me. Here's two pieces of opinion. First, I propose that we work out the details of #2, and you use it for a couple of programs. Get some experience with it. This could help inform a heavier-weight solution. Second, I wonder whether any of these solutions is a good candidate for a portable interface. It's one thing not to be strictly incompatible with a given collector strategy, but quite another to be easy to plug into an existing collector. Modula-3 currently doesn't require very much from its collector; making these proposals standard would significantly increase the requirements on a Modula-3 implementor. ======================================================================= 61 === Date: 24 Aug 1994 14:38:43 GMT From: satish@sun.mcs.clarkson.edu (Satish Thatte) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >From article , by derway@ndc.com (D. Erway) : > > Others have pointed out that dynamic typing actually allows > better encapsulation, and looser coupling, as a client need know less about an > object than with static typing. Could you give an example? It seems to me that this has more to do with the choices made by particular languages, especially C++. Inlining, for instance, requires exposing storage layout. Perhaps you are talking about the fact that Smalltalk methods will accept objects with the right functionality whereas C++ methods want objects of a certain declared type. Even here, the corresponding type constraint could be stated and checked statically. Satish ======================================================================= 62 === Date: 24 Aug 1994 22:10:52 GMT From: derway@ndc.com (D. Erway) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >>>>> "Robb" == Robb Nebbe writes: Robb> My opinion is that if your thinking is fuzzy about a problem then a Robb> language like Smalltalk can be a big help. Static typing can be more of Robb> an obstacle to exploring the solution space than anything else. This makes sense. Robb> If you have done a reasonable amount of analysis and design then Robb> ideally you should be able to express a signifigant portion of you Robb> design constraints in a statically typed language and use the language Robb> as a tool to verify what you consider to be a good consistant design. This makes sense in a static world. In my world, the analysis and design I do today, are great, and can lead to very clean systems, but sales will come up with something unexpected tomorrow. It is in this fluidity of handling software evolution, that (I hope) dynamic typing & binding win. I never know as much today as I will tomorrow. Static typing seems to force me to try to make more decisions today, that will effect what I can do tomorrow, (without going back and re-working). Dynamic typing seems to let me leave things more open, so that the classes I design today don't need so much explicit information about the classes I will design next week, and they don't constrain those classes so much. What do you all think? Don ======================================================================= 63 === Date: 24 Aug 1994 18:11:32 GMT From: goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7151) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article , derway@ndc.com (D. Erway) wri tes: |> .... |> It would appear, that for applications with lots of human interaction, where |> the run-time overhead cost is acceptable, dynamically typed languages such |> such as Objective-C, Smalltalk, or CLOS, offer superior productivity |> enhancement, and superior re-use, at the cost type safety. |> |> Does anyone have experience that would confirm or contradict this? For |> instance, that type safety leads to greater enhancement of productivity and/ or |> re-use? Any insights, or ideas are appreciated! Having done work in CLOS, C++ and Smalltalk, I find that the freedom and flexibility provided by dynamic typing is quite helpful. I would also point out that type safety can be obtained in dynamically-typed languages by appropriate use of explicit type checks. ======================================================================= 64 === Date: 24 Aug 1994 21:58:06 GMT From: derway@ndc.com (D. Erway) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >>>>> "Bill" == Bill Gooch on SWIM project x7140 >>>>> writes: In article <33f2tc$lht@gate.fzi.de>, schaetz@fzi.DE (Roland Schaetzle) writes: |> .... The difficulties with this code show up only in the long run, when |> the system is changed and when it grows. Bill> I'm having a little trouble with this statement. Since the code grows Bill> and changes most rapidly during its initial development, wouldn't the Bill> problems show up almost immediately? This fits with my experience. I think the concern here is that it is quick and easy to get the first 80 or 90% of the job done, but that last 10 or 20% will be extended, due to the the lack of type safety. For instance, run time bugs that make it out to the customers will be more prevalent. Integration and debugging of large systems will be tougher, and more time consuming, etc. I don't know that this is so, it just seems likely. Don ======================================================================= 65 === Date: 24 Aug 1994 18:27:11 GMT From: goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7151) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <1994Aug24.112731@di.epfl.ch>, Robb.Nebbe@di.epfl.ch (Robb Nebbe) wr ites: |> |> If we have two similar logical systems, one that is inconsistant and |> one that is consistant then the inconsistant system is in some twisted |> sense more "powerful" because you can express things that you can't |> with the other system. The question wasn't about logic systems, and a language with dynamic typing capability is not in some way "inconsistant" [sic]. ======================================================================= 66 === Date: 24 Aug 1994 22:16:16 GMT From: derway@ndc.com (D. Erway) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >>>>> "Satish" == Satish Thatte writes: Satish> From article , by derway@ndc.com Satish> (D. Erway) : >> Others have pointed out that dynamic typing actually allows better >> encapsulation, and looser coupling, as a client need know less about an >> object than with static typing. Satish> Could you give an example? It seems to me that this has more to do Satish> with the choices made by particular languages, especially C++. Satish> Inlining, for instance, requires exposing storage layout. Satish> Perhaps you are talking about the fact that Smalltalk methods will Satish> accept objects with the right functionality whereas C++ methods want Satish> objects of a certain declared type. Even here, the corresponding Satish> type constraint could be stated and checked statically. The example that was pointed out to me, (by someone on the net), was that in C++, if I change the definition of a class, (which might change the virtual function table), I will have to re-compile all the clients of that class. This seems to be breaking encapsulation by making users of an object hooked into internal representation. Perhaps, as you say, this is a C++ particular problem, and not a problem in eiffel, or modula-3. Anyone know? Don ======================================================================= 67 === Date: 24 Aug 1994 18:22:48 GMT From: goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <33f2tc$lht@gate.fzi.de>, schaetz@fzi.DE (Roland Schaetzle) writes: |> .... |> Another advantage of this type-system is, that it forces you to think |> about your class-structure befor your implement it. Languages like |> Smalltalk or CLOS give you more freedom to implement poor designs. They give you more freedom, period. |> And what I have seen is, that people use this freedom! The importance |> of good analysis and design is rated very low and since the language |> permits it, implementation is begun very early. Some people consider |> this early code production as a success, because they can show |> something at an early stage (anlaysis and design produces just some |> diagramms ;) ). What you are describing is a people problem, not a language problem. Failure to do effective analysis will lead to bad code in any language. Deferring selected design decisions until some implementation is done, on the other hand, can be extremely beneficial. I can provide concrete examples of this for you if you want. |> .... The difficulties with this code show up |> only in the long run, when the system is changed and when it grows. I'm having a little trouble with this statement. Since the code grows and changes most rapidly during its initial development, wouldn't the problems show up almost immediately? This fits with my experience. ======================================================================= 68 === Date: 25 Aug 1994 05:48:41 GMT From: djohnson@arnold.ucsd.edu (Darin Johnson) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article derway@ndc.com (D. Erway) writ es: > Thomas> Also, what makes life with a statically typed language much more > Thomas> convenient is type inference in the compiler. Many people using a > Thomas> statically typed language with type inference initially don't even > Thomas> realize that it isn't a dynamically typed language, since they don't > Thomas> have to add type declarations. And yet, the compiler makes certain > Thomas> that only type-correct programs get executed. > > What languages and what compilers are available that use type inference? > Wouldn't this also be a boon to dynamically typed languages, to do as much > static type checking as possible? SML, and other more functional languages do this. However, I have to disagree with the original assumption. Inferred types come up and bite you constantly when you're doing exploratory style programming. The most annoying this is when you make a tiny change (like adding a new field to a structure) and you get back hundreds of type errors in something that you thought was dynamically typed. I actually goofed on this during an interview, since I didn't realize I was talking to one of the prime SML keepers. I said what I hated about it and why I was so much happier when I went to lisp (and I got this strange stare). This sort of stuff is great *IF* you have a design to start with, and you're not going to change things partway through. It's terrible if you don't have (or can't have) a complete design, since you spend most of your time pounding the types back into line. -- Darin Johnson djohnson@ucsd.edu Support your right to own gnus. ======================================================================= 69 === Date: 25 Aug 1994 08:49:52 +0200 From: steinrya@ifi.uio.no (Stein Jxrgen Ryan) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? Dynamic typing can give your more freedom in the prototyping phase. However, I would rather not use it in anything that should be maintained over time. It is my experience that programming errors are mainly introduced when making changes to old code in order to implement new functionality. The problem is that the programmer doing the modification has a slightly incorrect mental model of how the code is currently working. This easily leads to small glitches in the code. Static typing makes it possible to write the code so it stronger reflects the ideas behind the program. There is effectively a straightjacket that the compiler enforces on the programmer. This sounds very counterproductive when what you want to do is to make changes to the program. It seems you are forced to stay within the straightjacket. But if done right, the straightjacket is nothing but a reminder that you are about to make changes that will require drastic reengineering. Stein J. Ryan PhD student University of Oslo ======================================================================= 70 === Date: 25 Aug 1994 08:00:28 GMT From: Robb.Nebbe@di.epfl.ch (Robb Nebbe) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <33heug$4ss@molik.ifi.uio.no>, steinrya@ifi.uio.no (Stein Jxrgen Rya n) writes: |> |> Static typing makes it possible to write the code so it stronger reflects th e |> ideas behind the program. There is effectively a straightjacket that the |> compiler enforces on the programmer. This sounds very counterproductive when |> what you want to do is to make changes to the program. It seems you are forc ed |> to stay within the straightjacket. But if done right, the straightjacket is |> nothing but a reminder that you are about to make changes that will require |> drastic reengineering. Static type systems are also evolving. Ada was often accused of being a straightjacket but with the simple additions of child modules (a hierarchical module system) and type extension it has become fairly flexible -- more so than other comparable statically typed langauges --, while retaining the same level of safety as before. Static type systems are becomming less of an obstacle and more of a tool. - Robb Nebbe ======================================================================= 71 === Date: 25 Aug 1994 01:32:46 GMT From: djohnson@elvis.ucsd.edu (Darin Johnson) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article baechler@lia.di.epfl.ch (Emm anuel Baechler) writes: > There's no doubt that you can use CLOS for poor programs. On another > hand It is much more flexible if your task is to create a model and > to explore its various aspects. Yes, this is one of the big advantages of dynamically typed systems. No matter what someones viewpoints are, there is a tendency to assume everyone else has the same requirements they do. It's not true though. Someone who has a great need to to software engineering and do tons of up front design may be perplexed that not everyone programs the same way. And vice versa, the person who needs to get the program done by Friday or lose the sale, or who can't fully spell out the design ahead of time, will be perplexed at those who spend more time pushing papers than coding. -- Darin Johnson djohnson@ucsd.edu Ensign, activate the Wesley Crusher! ======================================================================= 72 === Date: 25 Aug 1994 03:46:43 GMT From: tmb@arolla.idiap.ch (Thomas M. Breuel) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? goochb@swim1.eng.sematech.org writes: >Having done work in CLOS, C++ and Smalltalk, I find that the freedom >and flexibility provided by dynamic typing is quite helpful. I would >also point out that type safety can be obtained in dynamically-typed >languages by appropriate use of explicit type checks. I suspect that's because you are mainly familiar with C++-style static type systems. Those are constraining and inconvenient. Static type systems have progressed far beyond that stage in recent decades. rmartin@rcmcon.com writes: >A design based upon dynamic types has fewer explicit >dependencies than a design based upon static types. I think dynamic typing is actually important. But good, modern static type systems don't constrain design significantly. Thomas. ======================================================================= 73 === Date: 25 Aug 1994 01:28:10 GMT From: derway@ndc.com (D. Erway) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >>>>> "Thomas" == Thomas M Breuel writes: Thomas> There are alternatives, however, that preserve many of the advantages Thomas> of dynamic typing while giving you type safety. Some that I am Thomas> familiar with are: Thomas> (1) OO polymorphism based on signatures rather than Thomas> inheritance: this exists as a C++ extension (among others) and means Thomas> that any object that has the right methods and types can be Thomas> substituted for one another (some consider this a risk, but in Thomas> practice it doesn't seem to be a problem) This sounds equivalent to CLOS multiple dispatch, which can be shown, (see comp.object-faq), to require dynamic typing. Is it actually different? Thomas> I suspect that (1) would be a good compromise for staying within the Thomas> OO paradigm, while giving the programmer some extra power. Thomas> Also, what makes life with a statically typed language much more Thomas> convenient is type inference in the compiler. Many people using a Thomas> statically typed language with type inference initially don't even Thomas> realize that it isn't a dynamically typed language, since they don't Thomas> have to add type declarations. And yet, the compiler makes certain Thomas> that only type-correct programs get executed. What languages and what compilers are available that use type inference? Wouldn't this also be a boon to dynamically typed languages, to do as much static type checking as possible? ======================================================================= 74 === Date: 25 Aug 1994 07:16:18 GMT From: baechler@lia.di.epfl.ch (Emmanuel Baechler) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? > > There's no doubt that you can use CLOS for poor programs. On another > > hand It is much more flexible if your task is to create a model and > > to explore its various aspects. > > Yes, this is one of the big advantages of dynamically typed systems. > No matter what someones viewpoints are, there is a tendency to assume > everyone else has the same requirements they do. It's not true > though. Definitely. > Someone who has a great need to to software engineering and > do tons of up front design may be perplexed that not everyone programs > the same way. And vice versa, the person who needs to get the program > done by Friday or lose the sale, or who can't fully spell out the > design ahead of time, will be perplexed at those who spend more time > pushing papers than coding. There is also another aspect to this tradeoff. there's no doubt that requirements for engineering software (think for example of radar driver) are rather well defined and evolve progressively over time. Software supporting the work of organizations is a different matter. The mere fact that people start thinking about their needs change them. The more the project is going on, the more the needs of people change. The final installationf of these software systems change the organization it supports and changes its needs. This means that such software must be able to evlolve smoothly and regularly. In other words, changes (corrections, modifications, additions and so on) will be very frequent. In a such context, the most stable thing is the data structure, which must be very carefully designed. Dynamic typing and interactive languages are very useful for this early stage, in the sense that they allow a much more complete and in depth exploration of the issues raised by the data strucutre. They are also much quicker to integrate incremental modifications. Of course, when the design is fixed, statically typed languages may have a lot of advantages. -- 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. ======================================================================= 75 === Date: 25 Aug 1994 15:12:18 GMT From: connolly@hal.com (Dan Connolly) Subject: Re: Robustness, <*FATAL*>, NEW() In article <9408241605.AA11088@whitman.pa.dec.com> mcjones@src.dec.com writes: Thanks for the long answer. So I take it that the short answer is: Yes, no matter how well you code your application, there are cases where even a correct implementation of a Modula-3 runtime will abort the program, corruping/losing data. But work is being done to remedy this situation. What a shame. Even with all the great library code and static analysis tools (not the least of which is Larch...) it's not yet possible to write correct, portable implementations of applications that handle large amounts of vital data. But the article you posted gives me some guidelines on how to plan for the day when this is fixed. It really is a hairy problem! 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 ======================================================================= 76 === Date: 25 Aug 1994 12:30:26 GMT From: ucaa2385@iris3.csv.ica.uni-stuttgart.de (Peter Hermann) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? D. Erway (derway@ndc.com) wrote: : I think the concern here is that it is quick and easy to get the first 80 or : 90% of the job done, but that last 10 or 20% will be extended, due to the the : lack of type safety. For instance, run time bugs that make it out to the : customers will be more prevalent. Integration and debugging of large systems : will be tougher, and more time consuming, etc. : I don't know that this is so, it just seems likely. Yes, it is. ... and Ada professionals simply shake their head ... ;-) -- Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen Team Ada: "C'mon people let the world begin" (Paul McCartney) ======================================================================= 77 === Date: Thu, 25 Aug 1994 15:02:44 -0500 From: douglm@rpi.edu Subject: Re: Robustness, <*FATAL*>, NEW() >In article <9408241605.AA11088@whitman.pa.dec.com> mcjones@src.dec.com writes: > >What a shame. Even with all the great library code and static analysis >tools (not the least of which is Larch...) it's not yet possible to >write correct, portable implementations of applications that handle >large amounts of vital data. But what happens if you have a hardware or other failure out of m3s control? If data is tha valuable then the steps taken to preserve it in those circumstances should handle runtime system failures. ======================================================================= 78 === Date: Thu, 25 Aug 1994 16:54:57 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? jeske@ux4.cso.uiuc.edu (David Jeske) writes: >My experience has been similar to many of those who have posted. I >may just see things in a different way. It is true that many get >themselves in more trouble with a dynamically typed language by not >putting enough thought into their project. However, I think that's >their fault, not the languages. You put someone in a ferrari and if >he gets a speeding ticket, is it his fault or the ferrari's? Put the >same amount of Design time in and you'll get a similar quality >product out, with superior flexibility and reusability. Well said. The design is always a much bigger issue than the language. >Most of the more experienced programmers I know find it painfull to work in >statically typed languages like C++ because some reason always comes up that >they (or I) need run-time binding, and we end up having to cheat the compiler >and the language. Ultimately this leads to a much less elegant and >maintainable program. At first, I also found C++ difficult. I was used to Smalltalk. However, I soon realized that the programming and design styles that are most effective in C++ are very different from those that work well in Smalltalk. Having made this adjustment, I no longer experience these difficulties. >Too often I have head of people speak of C++ as the >language of "casting", where to get anything done you have to cast >everything. This is very indicative of a design paradigm mismatch. In C++ you should have to cast very little. I will occasionally use a "dynamic_cast" since that is the only way in C++ to access run time type identification. I will also occasionally use a const_cast to manipulate logical const-ness. But these occasions are rare. I do not find that copious casts are necessary. On the other hand, if I were to take a Smalltalk design and recode it in C++ I *should* expect lots and lots of casts. >Many of these situations where one ends up needing to cast to get some >flexibility COULD be turned around into something which would be legal in >C++ by using extra "protocol" style classes and multiple-inheritence. It >just creates even more of a painfull mess though. No. It creates a workable, type-consistent system. You may consider it a mess if it means rewriting a large batch of code. But had it been designed that way in the first place (or along the way) it would not be a mess. The more you get used to the design style of a static language, the less "messy" you will feel it to be. >If you know a language like C++ or Eifell well enough, you should >be able to implement the same functionality as you could in Objective-C or >SmallTalk. I personally find that not only does it take alot more work, but >the solutions seem much less elegant. There are certain sets of functionality that are far easier to implement in obj-c and ST than in C++. The converse is also true. Then there is a very wide band of functionality that both can do with roughly equal ease. >There are a few things you will never truly be able to pull of in the more >static languages though, and I find that it is infinitly usefull in some >larger projects. Objective-C (specifically on NeXT, but FSF gcc supports >this as well, not sure about StepStone) has Dynamic "bundle" loading >capabilities which are far superior to anything I've seen anyone do in >a similar language (say C++) with DLL, or loaded .o files, or >anything. Indeed. These issues are important. But they are not precluded from the static-type languages. Obj-C is, however, in the lead for such things. -- 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++ ======================================================================= 79 === Date: Thu, 25 Aug 1994 17:01:08 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) writes: >|> .... The difficulties with this code show up >|> only in the long run, when the system is changed and when it grows. >I'm having a little trouble with this statement. Since the code >grows and changes most rapidly during its initial development, wouldn't >the problems show up almost immediately? This fits with my experience. Not with mine. Although initial work on a product can be frenetic, the most severe changes tend to occur after the product has reached market and the customers start making demands. At least this is true in certain market segments. And what typically happens is that the original designers are off doing something new, and a horde of less experience programmers are hired to modify and maintain the product over several years. By the end of this period, the product is so horribly interconnected and patched that nobody dares make a change to it, since that change will almost certainly break something else somewhere else in the code. -- 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: Thu, 25 Aug 1994 17:33:46 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? derway@ndc.com (D. Erway) writes: >The example that was pointed out to me, (by someone on the net), was that in >C++, if I change the definition of a class, (which might change the virtual >function table), I will have to re-compile all the clients of that class. >This seems to be breaking encapsulation by making users of an object hooked >into internal representation. >Perhaps, as you say, this is a C++ particular problem, and not a problem in >eiffel, or modula-3. Anyone know? Those C++ programs that avoid this problem are those in which the inheritance hierarchies are all topped by abstract classes with no declared data members. These abstract classes are declarations of interface and have very little, if any, code. Clients use these abstract classes to manipulate derived objects. Thus the clients do not need to be compiled when the data members of the derived classes change. Some clients are responsible for creating objects. If done directly, these clients will be dependent upon the data members in the derived classes. However it is possible to create classes called "Object Factories" that break this dependency too. In real-life, C++ programs will use a mix of factories and explicit creation. Explicit creation is preferred when the objects being created are extremely stable. (i.e. Complex, Point, Line, etc.) Factory creation is preferred when the objects being created are subject to a large amount of derivation. (i.e. nobody can tell just how many subclasses will be created). -- 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++ ======================================================================= 81 === Date: 25 Aug 1994 17:55:45 +0200 From: amund@galileo.polito.it (A.Aarsten) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? > There's no doubt that you can use CLOS for poor programs. On another > hand It is much more flexible if your task is to create a model and > to explore its various aspects. Exactly; different programming situations have different requirements. May I suggest that the participants in this debate read "The Treaty of Orlando"? I think does an extremely nice job of summing this up. S. Stein, H. Lieberman, D. Ungar: A Shared View of Sharing: The Treaty of Orlando. In W. Kim and F. Lochovsky (eds): Object-Oriented Concepts, Databases and Applications. Addison-Wesley, 1989. - Amund ======================================================================= 82 === Date: Thu, 25 Aug 1994 16:57:52 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7151) writes: >Having done work in CLOS, C++ and Smalltalk, I find that the freedom >and flexibility provided by dynamic typing is quite helpful. I would >also point out that type safety can be obtained in dynamically-typed >languages by appropriate use of explicit type checks. Having done work in C++ and Smalltalk, I can agree with you. However I also find the compile time type checking of C++ to be very useful for the construction of self-consistent models. Although there is certainly some loss of flexibility, for many applications I view this as a positive trade off. -- 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++ ======================================================================= 83 === Date: Thu, 25 Aug 1994 17:27:02 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? derway@ndc.com (D. Erway) writes: >I never know as much today as I will tomorrow. Static typing seems to force >me to try to make more decisions today, that will effect what I can do >tomorrow, (without going back and re-working). Dynamic typing seems to let me >leave things more open, so that the classes I design today don't need so much >explicit information about the classes I will design next week, and they don't >constrain those classes so much. I think there is *some* truth in this. Dynamic typing is certainly more flexiby than static typing. However, there is another side to this. You never know today, as much as you will know tomorrow. Today's product design will not be completely compatible with tomorrow's. In a dynamic language, you can make tomorrows changes without worrying too much about the consistency with today's design. In a static language you must change today's design when you want to make tomorrow's changes. After a long evolution, the static system will still be consistent. But the dyanamic system may be riddled with inconsistencies. These will show up as run-time failures. Certainly good designers will not conciously let this happen. They will want to alter the design of the dynamic model when they "feel" that it has passed the limit of acceptable inconsistency. By then, however, the backlog of changes may be long, and the time required to restructure the system may be unacceptable to project management. A project manager will almost always consider the next feature more important than a design change which adds no new feature. To avoid this, the designers must update the design relatively often, so that the design changes do not rise to the level of visibility of the project managers. And so the designers become their own static type system. Now, having a dynamic system still give you more flexibility, because *you* can decide when to bring the design back into consistency. But the danger of accumulating inconsistency (whether undetected, or purposely unresolved) is real, and the problems are significant. For some systems, the trade off should be made in favor of the flexibility. For others, it should not. This is also a matter of personal taste. I prefer not to gamble with the extra flexibility. I am not that good at finding all the inconsistencies myself. I prefer that the compiler do as much as it can for me. Still, there have been times when I have opted for the flexibility because the nature of the application was such that I could tolerate the risk; and the extra flexibility made the program quicker and easier to write. Generally I will make such a trade off for projects that do not have long lifetimes; but this is just by personal bias. -- 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++ ======================================================================= 84 === Date: Thu, 25 Aug 1994 16:35:30 GMT From: jdean@bergen.cs.washington.edu (Jeffrey Dean) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article , derway@ndc.com (D. Erway) wri tes: |> It would appear, that for applications with lots of human interaction, where |> the run-time overhead cost is acceptable, dynamically typed languages such |> such as Objective-C, Smalltalk, or CLOS, offer superior productivity |> enhancement, and superior re-use, at the cost type safety. You might be interested in the approach taken in the Cecil language. Cecil supports an exploratory programming style without any static type declarations (similar to Smalltalk or Self), but permits migrating code to static checking by the inclusion of optional static type declarations. The idea is that for code that is still undergoing massive revisions, it's easier to not have to deal with static declarations. However, once interfaces become stable, you can add static type declarations and you obtain the benefits of static checking. See the paper titled "The Cecil Language: Specification and Rationale" on the Cecil Project's WWW page for further details: http://www.cs.washington.edu/research/projects/cecil/www/cecil-home.html The paper can also be accessed via anonymous ftp from: cs.washington.edu:/pub/chambers/cecil-spec.ps.Z -Jeff Graduate Student, Cecil Project Department of Computer Science & Engineering University of Washington ======================================================================= 85 === Date: Thu, 25 Aug 1994 17:46:56 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? djohnson@elvis.ucsd.edu (Darin Johnson) writes: >[...] the person who needs to get the program >done by Friday or lose the sale, or who can't fully spell out the >design ahead of time, will be perplexed at those who spend more time >pushing papers than coding. Tsk, tsk. This is an unfair characterization. Folks who use static languages are not, by nature, paper pushers. They code just as much as everybody else does. Still, the point you make is good. There are those whose viewpoints are too narrow to admit that both styles of programming are valid, and that the choice between them has a large content of personal bias. -- 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++ ======================================================================= 86 === Date: Thu, 25 Aug 1994 17:02:35 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7151) writes: >In article <1994Aug24.112731@di.epfl.ch>, Robb.Nebbe@di.epfl.ch (Robb Nebbe) w rites: >|> >|> If we have two similar logical systems, one that is inconsistant and >|> one that is consistant then the inconsistant system is in some twisted >|> sense more "powerful" because you can express things that you can't >|> with the other system. >The question wasn't about logic systems, and a language with dynamic >typing capability is not in some way "inconsistant" [sic]. No, but the programs written in them can be. When these inconsistencies are executed they lead to "interface mismatch" or "no such method" messages; or worse. -- 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++ ======================================================================= 87 === Date: Fri, 26 Aug 1994 03:26:43 GMT From: pfkeb@kaon.SLAC.Stanford.EDU (Paul F. Kunz) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >>>>> On Thu, 25 Aug 1994 16:54:57 GMT, rmartin@rcmcon.com (Robert Martin) said : >> There are a few things you will never truly be able to pull of in >> the more static languages though, and I find that it is infinitly >> usefull in some larger projects. Objective-C (specifically on NeXT, >> but FSF gcc supports this as well, not sure about StepStone) has >> Dynamic "bundle" loading capabilities which are far superior to >> anything I've seen anyone do in a similar language (say C++) with >> DLL, or loaded .o files, or anything. > Indeed. These issues are important. But they are not precluded > from the static-type languages. Obj-C is, however, in the lead for > such things. Indeed, Objective-C has a lead on this and other things. I've been reading up on SOM, IBM's CORBA implementation. There are just so many things in SOM that might appear to be new, yet are already in Objective-C language and its run-time system (both NeXT and GNU). Distributed object implementation that NeXT has done for Objective-C is particularly neat and we might see a GNU version. You don't need a separate .idl file to accomplish it. -- Paul F. Kunz Paul_Kunz@slac.stanford.edu (NeXT mail ok) Stanford Linear Accelerator Center, Stanford University Voice: (415) 926-2884 (NeXT) Fax: (415) 926-3587 ======================================================================= 88 === Date: Fri, 26 Aug 1994 10:46:43 GMT From: sknee@comlab.ox.ac.uk (Simon Knee) Subject: Seperate Compilation I have a question about Modula-3 and seperate compilation. I have written a compiler in Modula-3 and now wish to adapt it for a different target architecture. The general layout of the compiler is that each node in the parse tree is an object which is a subtype of an expression, statement object etc. Each object has methods for Type (), TypeCheck (), .., Compile (). Obviously the majority of the code is that same for any target architecture since type checking etc. will not change. The problem is with the Compile () method. At present I have declarations such as: MODULE Loop; IMPORT Stmt; REVEAL T = Stmt.T OBJECT METHODS OVERRIDES Compile := compileForLoop; END; ... END Loop. What I would like to do (Ada here I am afraid!) is to say something like: seperate (compileForLoop); and have a different module that implements the Compile () method. How do I do things like this in Modula-3? I could just copy each module and change the Compile () method for the new architecture - then at compile time decide which module to use. This duplicates code though and makes maintenance much more difficult. If I was not using objects then I could have two modules that export to the same interface - one for type checking etc. and one for code generation - then just use different compile modules in the build. The only way I can see to do it is to put the OVERRIDES in the interface and then export different definitions of say "compileForLoop". Thanks for you help, Simon Knee Programming Research Group, Oxford University, UK. Simon.Knee@comlab.ox.ac.uk ======================================================================= 89 === Date: 26 Aug 1994 15:49:39 GMT From: connolly@ulua.hal.com (Dan Connolly) Subject: Deploying M3 apps: external interfaces [BTW... The binary distribution of M3 for Linux works GREAT! I had some problems getting it to work, but they were all my fault...] After researching the issue of NEW() and VM exhaustion, I realized it's a really tricky issue. It's not really possible to write applications to any portable interface (be it ANSI C, POSIX, ...) that are 100% robust in the face of virtual memory failure. But while the theoretical problem is insoluable, there are some heuristic solutions that can work. Many C and C++ applications deal with VM exhaustion quite reliably. M3 clearly needs _some_ interface to a NEW() analog that causes an exception rather than a checked runtime error, but with threads, locks, garbage collection, etc., it's not clear what that interface is. So the next question is: can I write distributed applications in M3 that "look and feel" like -- and interoperate with -- their C/C++ counterparts? The external interfaces I'm interested in are: Platforms: * ABI of POSIX platforms (Sun4, Linux, etc. binaries) (supported by compiler and portable libraries) * Windows NT ABI (will be supported by compiler and portable libraries???) * Windows 4.0 (aka Chicago) ABI (any chance of this?) * Windows Win32s ABI (any chance of this?) * OS/2 ABI (port underway??? will Tresle, FormsVBT support OS/2 PM???) >From what I know, all of the above are possible in theory. Its a question of the amount of engineering resources thrown at the various problems. To me, the possiblility of developing an M3 app on a POSIX or NT based workstation and deploying it on OS/2 or Chicago looks very inviting. The M3 interfaces are clean enough to give some confidence that this is realistic. But in order to achieve good performance on the smaller platforms, the implementations would have to be finely tuned: get rid of as much runtime debugging stuff as possible, etc. Tuning a FormsVBT-based user interface for the various platforms would be something of an art, but a good set of motif macros would make it reasonable. Hmm... perhaps FormsVBT and the windows API are somewhat at odds. UI/application interoperability * X11 (supported by portable libraries) * Motif "look and feel" specification (could be implemented using FormsVBT???) * ICE (X11R6 InterClient Exchange interface) (via ILU???) * OLE 2.0 (???) * OpenDoc (???) * Any relevant COSE/CDE external interfaces (???) By the way... is the X11 library for M3 written in C or M3? Does it use the M3 TCP interface? Networking: * TCP (to write FTP, gopher, HTTP, etc. clients/servers) (supported by portable libraries) * DCE RPC (via ILU???) Is it reasonable to expect that some day an obliq application might interoperate with a Fresco application? A DCE server? That is, is it likely/possible that networked objects would interoperate with X11R6 ICE? It seems reasonable to me, but I haven't done enough reading about the nitty gritty details of networked objects and ICE to be able to decide. Pointers to relavent papers would be appreciated. Would somebody who knows OLE 2.0 and/or OpenDoc comment on the possibility of interoperability with M3 networked objects and/or ILU? I suppose I lose the following external interfaces when I choose M3: * Xt client (XUSERFILESEARCHPATH, X resources files, etc.) (good riddance. Hello FormsVBT and snapshots!) * MS-DOS ABI (640K? forget it!) * Windows 3.1 ABI (segmented architecture) * Macintosh 68k ABI (formsVBT port would be hairy. how would you implement threads?) * POWER Mac ABI (any chance of this??? What about tresle and Quickdraw?) 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 ======================================================================= 90 === Date: Fri, 26 Aug 1994 15:09:32 GMT From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >>> On 25 Aug 1994 05:48:41 GMT, djohnson@arnold.ucsd.edu (Darin Johnson) said: Darin> In article derway@ndc.com Darin> (D. Erway) writes: Thomas> Also, what makes life with a statically typed language much more Thomas> convenient is type inference in the compiler. Many people using Thomas> a statically typed language with type inference initially don't Thomas> even realize that it isn't a dynamically typed language, since Thomas> they don't have to add type declarations. And yet, the compiler Thomas> makes certain that only type-correct programs get executed. Erway> What languages and what compilers are available that use type Erway> inference? Wouldn't this also be a boon to dynamically typed Erway> languages, to do as much static type checking as possible? Darin> SML, and other more functional languages do this. I think that the very interesting work by Ralph Johnson, Typed Smalltalk, also qualifies as a sort of type inference and, if I remember correctly, without the fascist type enforcer of SML. Darin> However, I have to disagree with the original assumption. Darin> Inferred types come up and bite you constantly when you're doing Darin> exploratory style programming. The most annoying this is when Darin> you make a tiny change (like adding a new field to a structure) Darin> and you get back hundreds of type errors in something that you Darin> thought was dynamically typed. But here we open a whole can of worms of terminology. I personally think that "dynamic typing" is usually used in a very misleading sense. What most people mean by "dynamic typing" should be more properly called "latent typing", in the sense that the type of a value does not change dynamically, it's only latent until runtime (or until a type inferencer finds ferrets it out). What you are discussing here is the case that truly deserves the title of "dynamic typing", that is values that change type or types that change definition over time (when you add a field to a structure you are actually either assigning a new type to all values of that "type", or you are changing the defition of its type). Now, there is still a lot of research to be done in dynamic typing (in the proper sense), and one thing that is certain is that type inference systems a la ML are designed for invariant types. Incidentally, very latent typing a la smalltalk helps with dynamic typing too; since type checking/inferencing is done at the last possible minute, and only for the part of the type interface you are using, you can get away with changing the definition of a type or the type of a value in most intuitively compatible cases. ======================================================================= 91 === Date: 26 Aug 1994 17:55:40 GMT From: djohnson@elvis.ucsd.edu (Darin Johnson) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <1994Aug25.172702.4984@rcmcon.com> rmartin@rcmcon.com (Robert Martin ) writes: > After a long evolution, the static system will still be consistent. > But the dyanamic system may be riddled with inconsistencies. These > will show up as run-time failures. One problem I see is that this attitude is often taken to the extreme. Static typing only catches bugs and design glitches with respect to typing only. I see some people however that seem to think that they catch almost all problems this way. The implication from "you dynamic typing people will have bugs sneak up on you" is that the static typing people don't have bugs - ludicrous. Are typing bugs even in the majority? -- Darin Johnson djohnson@ucsd.edu - Luxury! In MY day, we had to make do with 5 bytes of swap... ======================================================================= 92 === Date: 26 Aug 94 17:52:59 From: fn00@gte.com (Farshad Nayeri) Subject: Modula-3 on SGI Has anyone out there ported Modula-3 (2.x, 3.x) to Silicon Graphics Irix? If you have attempted a port or are in the process, please contact me. Thank you, -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 93 === Date: 26 Aug 1994 23:11:53 GMT From: goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7151) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article , tmb@arolla.idiap.ch (Thomas M. Breuel) writes: |> goochb@swim1.eng.sematech.org writes: |> >Having done work in CLOS, C++ and Smalltalk, I find that the freedom |> >and flexibility provided by dynamic typing is quite helpful. I would |> >also point out that type safety can be obtained in dynamically-typed |> >languages by appropriate use of explicit type checks. |> |> I suspect that's because you are mainly familiar with C++-style static |> type systems. Those are constraining and inconvenient. Static type |> systems have progressed far beyond that stage in recent decades. 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. Granted, it takes a lot of self-discipline to produce quality code when you have lots of freedom, but I think the same self-discipline is necessary anyway. I have yet to see a language that even comes close to constraints which guarantee good code regardless of undisciplined coders. ======================================================================= 94 === Date: 26 Aug 1994 23:22:50 GMT From: goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <1994Aug25.170108.4777@rcmcon.com>, rmartin@rcmcon.com (Robert Marti n) writes: |> goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) writes: |> |> >|> .... The difficulties with this code show up |> >|> only in the long run, when the system is changed and when it grows. |> |> >I'm having a little trouble with this statement. Since the code |> >grows and changes most rapidly during its initial development, wouldn't |> >the problems show up almost immediately? This fits with my experience. |> |> Not with mine. Although initial work on a product can be frenetic, |> the most severe changes tend to occur after the product has reached |> market and the customers start making demands. This can be largely avoided by enrolling users in the development process. To me, this problem represents a methodology flaw, not a weakness in the language. |> At least this is true in certain market segments. And what typically |> happens is that the original designers are off doing something new, |> and a horde of less experience programmers are hired to modify and |> maintain the product over several years. Lots of assumptions here: no experienced programmers around to help out and to do code reviews, technical documentation produced by the "original designers" is inadequate, etc.. With good technical docs, less experienced programmers should be able to obtain good results, especially with a few experienced hands around to provide guidance. |> By the end of this period, the product is so horribly interconnected |> and patched that nobody dares make a change to it, since that change |> will almost certainly break something else somewhere else in the code. It's hard for me to comment on this in the context of static vs. dynamic typing discussion. I don't really see the connection. ======================================================================= 95 === Date: 26 Aug 1994 19:07:09 GMT From: jacobi@parc.xerox.com (Christian Jacobi) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? This discussion baffles me. I thought people on a Modula 3 distribution list to have more insight into programming, but it looks like I'm wrong. The question of static versus dynamic typing is the wrong question. We know when static typing is better; we also know when dynamic typing is better. Sadl y, it really depends on the application, and none of the methods is better in all cases. However, static and dynamic typing can be combined. Since this is the standard way of programing in a language like Modula 3, I don't understand why this came up. There are two models on how static and dynamic typing can be combined known to me. Maybe somebody knows more models. (Casting in C is not a legitimate model as much as I'm concerned) The ML model: The programmer doesn't specify but the compiler infers where it can do so. This certainly is better then pure dynamic typing, and, more powerf ul then static typing. However this requires good compiler technology, and averag e programmers like me might have difficulties predicting what the compiler can in fer and what it will miss. The Cedar model. The programmers specifies types. He can specify types to be used staticly and also types whose type is determined dynamicly. The compiler just does what the programmer specifies; the programmer specifies the places fo r a runtime test. This is the model used by modula 3. Modula 3 adds dynamic subclassing to dynamic typing. Now I'm sorry that I do not have any comparative experiences about productivity . After all, each program I have seen was either made just once, not made by professional programmers, or, the second version was made after some lessons from the first version have already been learned. That doesn't prevent anybody from stating experiences of course... In the most Cedar programs I have seen or made, the combination of static and dynamic typing is quite natural (to the programmer). Sometimes it may be questionable what feature to make static and what feature to make dynamicly, but not very frequent. When it is questionable, neither choice can be really bad. Most interfaces are staticly typed for the types which matter, and, dynamicly typed for unknown clientdata or property lists. More often then not, this division leads to programs with dynamic behavior where most variable acces s happens with staticly known types. Christian Something is wrong; my first post to m3@src.dec.com seems not to have worked. Apologies if it was only delayed and you get two posts. ======================================================================= 96 === Date: 27 Aug 1994 00:50:01 GMT From: tmb@arolla.idiap.ch (Thomas M. Breuel) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article djohnson@arnold.ucsd.edu (D arin Johnson) writes: |However, I have to disagree with the original assumption. Inferred |types come up and bite you constantly when you're doing exploratory |style programming. The most annoying this is when you make a tiny |change (like adding a new field to a structure) and you get back |hundreds of type errors in something that you thought was dynamically |typed. If adding a field to a structure creates "hundreds of type errors", you are not using the static type system correctly (you should make a distinction between {x,...} and {x,y} where appropriate). It should create type errors only in those places where you actually need to change the code to account for the new field (e.g., in a "deep_copy" function). That's one of the great things about static type checking, in particular in SML (in C++, for example, type checking for structures doesn't do anything for you when you add a field; without static type checking, you'll easily get lots of obscure bugs). |This sort of stuff is |great *IF* you have a design to start with, and you're not |going to change things partway through. It's terrible if you |don't have (or can't have) a complete design, since you spend |most of your time pounding the types back into line. A static type checker is an extra gadget in a programming language that needs to be used properly. It's too bad that most people only learn about the effective use of static type checkers by trial and error. I have found SML a great language for prototyping, and its type system, when used correctly, really helps. Thomas. ======================================================================= 97 === Date: Fri, 26 Aug 94 23:36:31 -0700 From: msm@panther.pa.dec.com Subject: Re: Deploying M3 apps: external interfaces The plan for Trestle is to build a native Windows-API implementation. At present, the X implementation just uses vanilla Xlib (the C library), in a somewhat non-standard way. We don't see any major obstacles to doing the same thing for Windows. Given the way Trestle works, it's hard to use native widgets directly. FormsVBT could abandon VBTs altogether, and use native widgets to provide a look and feel, but it's hard to provide the same degree of multithreading in that case. We hope to add support for things like OLE, ICE, X defaults, etc. The main stumbling block is understanding them well enough to design interfaces that cleanly generalize and unify the subset of these standards that can be unified. I expect that the Windows port (which will probably be NT and Chicago only, not Win 3.1) will provide the same kinds of back-door hooks for performing direct window system-specific actions that the X layer currently does. It's not clean and beautiful, but generally people do this for things that aren't likely to be beautiful. I don't know what would be involved in a Mac port. Presumably the Mac supports some select-like operation (or at least some polling). If it also supports any mechanism for timer events, the current scheduler might be adaptable to provide threads. I don't think that Quickdraw would be much of an obstacle; the drawing and event models in Trestle were designed to be fairly easy to represent on all the systems we knew about. The interactor set is more interesting. Should Trestle applications attempt to obey the look-and-feel of the host environment, or some standard Trestle look-and-feel. Should the scroll bars change appearance and behavior to accomodate a one-button mouse? Should the scroll bars shift from the left side to the right for Mac and Windows? I don't know the ultimate answer; fortunately, most of that isn't *my* code. Mark ======================================================================= 98 === Date: 27 Aug 1994 00:40:56 GMT From: tmb@arolla.idiap.ch (Thomas M. Breuel) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article derway@ndc.com (D. Erway) writ es: | Thomas> (1) OO polymorphism based on signatures rather than | Thomas> inheritance: this exists as a C++ extension (among others) and means | Thomas> that any object that has the right methods and types can be | Thomas> substituted for one another (some consider this a risk, but in | Thomas> practice it doesn't seem to be a problem) | |This sounds equivalent to CLOS multiple dispatch, which can be shown, (see |comp.object-faq), to require dynamic typing. Is it actually different? No, it's just single dispatch. What it gives you is liberty from inheritance relationships. | Thomas> I suspect that (1) would be a good compromise for staying within the | Thomas> OO paradigm, while giving the programmer some extra power. | | Thomas> Also, what makes life with a statically typed language much more | Thomas> convenient is type inference in the compiler. Many people using a | Thomas> statically typed language with type inference initially don't even | Thomas> realize that it isn't a dynamically typed language, since they don't | Thomas> have to add type declarations. And yet, the compiler makes certain | Thomas> that only type-correct programs get executed. | |What languages and what compilers are available that use type inference? |Wouldn't this also be a boon to dynamically typed languages, to do as much |static type checking as possible? SML, Haskell, and a few other languages have type inference. You can add it to dynamically typed languages. The problem is that when you get a type error, you don't know whether it is because there is an actual error or whether you wrote something that is "too powerful" for a static type system. A reasonable compromise is to have a static type system with type inference and add a special "dynamic" type to it. Thomas. ======================================================================= 99 === Date: Sat, 27 Aug 1994 16:09:03 GMT From: mikec@metronet.com (Mike Christiansen) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <1994Aug25.172702.4984@rcmcon.com> rmartin@rcmcon.com (Robert Martin ) writes: >From: rmartin@rcmcon.com (Robert Martin) >Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >Date: Thu, 25 Aug 1994 17:27:02 GMT >After a long evolution, the static system will still be consistent. >But the dyanamic system may be riddled with inconsistencies. These >will show up as run-time failures. Not if you are forced to cast around restrictions placed by the compiler which you know are correct. But casting shouldn't be needed in a proper design, so the design should change. >Certainly good designers will not conciously let this happen. They >will want to alter the design of the dynamic model when they "feel" >that it has passed the limit of acceptable inconsistency. By then, >however, the backlog of changes may be long, and the time required to >restructure the system may be unacceptable to project management. A >project manager will almost always consider the next feature more >important than a design change which adds no new feature. I beleive that re-structuring the design / system is always needed (to some degree) to add new features. Modifying a class or re-factoring a set of classes to meet new requirements are a fact of life in OO. A dynamic language like Smalltalk, with Envy to support configuration control, makes this exploration and re-design orders of magnitude easier thanwhat I experienced within C++. If you are trying to avoid modifying the design but integrate new feature, there is something wrong. >Now, having a dynamic system still give you more flexibility, because >*you* can decide when to bring the design back into consistency. But >the danger of accumulating inconsistency (whether undetected, or >purposely unresolved) is real, and the problems are significant. True. Dont allow it to happen. >For some systems, the trade off should be made in favor of the >flexibility. For others, it should not. This is also a matter of >personal taste. I prefer not to gamble with the extra flexibility. I >am not that good at finding all the inconsistencies myself. I prefer >that the compiler do as much as it can for me. Errors like this should be discovered by the testing process. ********************************************* Mike Christiansen mikec@metronet.com ********************************************* ======================================================================= 100 === Date: Sat, 27 Aug 1994 15:44:34 GMT From: mikec@metronet.com (Mike Christiansen) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <33heug$4ss@molik.ifi.uio.no> steinrya@ifi.uio.no (Stein Jxrgen Ryan ) writes: >From: steinrya@ifi.uio.no (Stein Jxrgen Ryan) >Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >Date: 25 Aug 1994 08:49:52 +0200 >Dynamic typing can give your more freedom in the prototyping phase. However, >I would rather not use it in anything that should be maintained over time. It >is my experience that programming errors are mainly introduced when making >changes to old code in order to implement new functionality. The problem is >that the programmer doing the modification has a slightly incorrect mental >model of how the code is currently working. This easily leads to small >glitches in the code. It has been my experience that proper codeing standards is all the typing needed to capture and later properly reuse a design in Smalltalk. e.g. I always use the name of the expected class in an automatic variable (aStructuredGraphic, anEmployee, etc.). Also, record the expected type of an instance variable in the def. of the class comment. mike ********************************************* Mike Christiansen mikec@metronet.com ********************************************* ======================================================================= 101 === Date: 27 Aug 1994 15:32:10 GMT From: connolly@hal.com (Dan Connolly) Subject: Re: Deploying M3 apps: external interfaces In article <9408270636.AA11863@panther.pa.dec.com> msm@panther.pa.dec.com write s: Newsgroups: comp.lang.modula3 From: msm@panther.pa.dec.com Date: Fri, 26 Aug 94 23:36:31 -0700 The plan for Trestle is to build a native Windows-API implementation. [...] Given the way Trestle works, it's hard to use native widgets directly. FormsVBT could abandon VBTs altogether, and use native widgets to provide a look and feel, but it's hard to provide the same degree of multithreading in that case. I can see that. I'm not too hooked on Xt Widgets. But it might be very useful to support the visual basic control interface. We hope to add support for things like OLE, ICE, X defaults, etc. Good. I don't like the fact that the X resource database is "read only," i.e. most apps don't support direct-manipulation UI for configuration. But the X resource database is distributed in a way: after you do an xrdb -load .Xdefaults, all clients that connect to that display, no matter where they come from, can see the Xresources. Perhaps the Rsrc interface can be expanded to read properties from the X display as well as bundles and files. I'd put more priority on ICE and OLE, though. [...] I expect that the Windows port (which will probably be NT and Chicago only, not Win 3.1) What about Win32s? On the other hand, I suppose that by the time the port is ready, Chicago will be widely deployed. The interactor set is more interesting. Should Trestle applications attempt to obey the look-and-feel of the host environment, YES! This is what I meant by an "external interface" that looks, feels, and interoperates with C/C++ counterparts. or some standard Trestle look-and-feel. NO! Not another Andrew toolkit! We don't need Yet Another look and feel. Please resist the temptation. Should the scroll bars change appearance and behavior to accomodate a one-button mouse? Should the scroll bars shift from the left side to the right for Mac and Windows? Some of this might be hidden from the application programmer (appearance of the scrollbar) and some might not (left/right side). A FormsVBT app developed on X might not run "out of the box" on Windows, but the platform dependencies should be isolated. The formsedit, for example, displays a different look&feel depending on whether the display is monochrome or color. Seems like a reasonable approach. 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 ======================================================================= 102 === Date: Sat, 27 Aug 1994 17:16:34 -1200 From: lprent@godknows.nacjack.gen.nz (Lynn Prentice) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >>I never know as much today as I will tomorrow. Static typing seems to force >>me to try to make more decisions today, that will effect what I can do >>tomorrow, (without going back and re-working). Dynamic typing seems to let m e >>leave things more open, so that the classes I design today don't need so much >>explicit information about the classes I will design next week, and they don' t >>constrain those classes so much. >You never know today, as much as you will know tomorrow. Today's >product design will not be completely compatible with tomorrow's. In >a dynamic language, you can make tomorrows changes without worrying >too much about the consistency with today's design. In a static >language you must change today's design when you want to make >tomorrow's changes. To a certain degree a lot of the uncertainty can be reduced by using typedef's in a language like C++, or simply inheriting from the today's classes. If you make abstractions about what an object is being used for, rather than its implementation - it gets a lot easier to change later. For instance, if a list class is mostly being used for lookup's (ie its pretty static in what is included in it), I'd define it as :- template (class Type) class Lookup : public DoubleList { }; Then at any stage in the application development it gets easier to change the actual implementation (say to an AVL tree or hash table). Of course what you are pre-supposing with this approach is that the names of the methods, and the parameters are similar - but even if they aren't then the compiler will find the inconsistencies for you. I tend to use templates for this kind of name spacing to get strong type-checking on the parameters. The only problem with this approach is that you start testing the compiler & linkers name space limits. >After a long evolution, the static system will still be consistent. >But the dyanamic system may be riddled with inconsistencies. These >will show up as run-time failures. >I prefer not to gamble with the extra flexibility. I >am not that good at finding all the inconsistencies myself. I prefer >that the compiler do as much as it can for me. And run-time failures will usually morph into disgruntled customers. Its bad enough having logical inconsistencies in my code to test for, without having to look for what are essentially syntax errors. Basically, I have a strong preference towards releasing robust code. It reduces those irritating interuptions on your next project, when the system crashes after they tried something that used to work during early testing, was missed in later testing, and the compiler would have caught it if you had used a static type-checking approach. ======================================================================= 103 === Date: 27 Aug 1994 22:06:27 GMT From: djohnson@elvis.ucsd.edu (Darin Johnson) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article tmb@arolla.idiap.ch (Thomas M. B reuel) writes: (re: sml) > If adding a field to a structure creates "hundreds of type errors", > you are not using the static type system correctly (you should make a > distinction between {x,...} and {x,y} where appropriate). I agree there. I wasn't using it correctly. But it was more improtant to me to get a working program quickly, than to spend tons of time rewriting existing code. No one else really knew diddly about SML, and apparently I knew enough to write SML, but not enough to write correct SML. The program was simulating a dataflow machine. I got the emulator working for the original model that had 2 major types of tokens (most of it was existing code written by someone else before the model was finalized). Problems became abundant when adding a third type of token - even though the variety each token could be unambiguously determined from its structure. But this new type had to go through the same data path as all the other types - ie, a large subset of functions. I think I realized that I would indeed have to redesign the basic types just to be able to continue forwards, and decided to go with lisp - where such problems in the future would be simpler to deal with. If there were an initial design, perhaps the types in SML could have been easier to deal with. Besides which, the Lisp version ran tons faster and was easier to debug :-) Separate compilation in SML appeared possible from the (limited) docs, but I never got it to work. Yet somehow, *everytime* I've met an SML expert, their opinion is that I must have been using types incorrectly, rather than take the radical opinion that perhaps SML isn't the perfect solution to all problems. Maybe an expert could have done it, but for a non-expert with a fuzzy design, it was painful. > A static type checker is an extra gadget in a programming language > that needs to be used properly. It's too bad that most people > only learn about the effective use of static type checkers by > trial and error. That's the other thing that irked me about SML. Everytime I tried to get help (on the net) with my problems, people would keep saying I wasn't using the static types correctly, but no one ever gave any help. Undoubtedly it's learned by trial and error because that's the only method most people have. I'm wasn't a beginning programmer scared by new computation models, and I did find out what the problems were (trial and error clarified the docs I had) and decided my problems had to be solved by lots of rewrites - and that going with a dynamically typed language that I knew better would be less likely to have trial and error sneak up on me, and that would be more amenable to radical changes in the future. Also - *IS* effective use of static type checking possible with a fuzzy amorphous design? -- Darin Johnson djohnson@ucsd.edu Caution! Under no circumstances confuse the mesh with the interleave operator, except under confusing circumstances! ======================================================================= 104 === Date: Sun, 28 Aug 1994 14:40:23 GMT From: jjb@watson.ibm.com (John Barton) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? Perhaps this has been said before, but the impact of static vs dynamic typing on productivity depend strongly on the problem being solved. In programming holographic reconstructions of atomic crystal structure, I thought that static typing was vital and could not imagine working in a language without it. The objects in the program were set by the source code, the polymorphism was parametric and ad hoc, and the running time was many times longer than the compile time. Later on another project, I tried to force a static typed view onto a source code analyzer. Then I discovered that other problems have other solutions. The objects in this program appear in groups but don't necessarily have common function; apparent commonality tended to vanish under further design, the commonality tended to be a function or two, and test cases could be run in a fraction of the compile time. We use a mix of static and dynamic type checking. -- John. John J. Barton jjb@watson.ibm.com (914)784-6645 H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598 ======================================================================= 105 === Date: Sun, 28 Aug 94 12:13:43 GMT From: rcv@ukc.ac.uk (R.C.Van-Den-Bergh) Subject: M3Check for V3.3 ? Hi, Before I spend some time porting m3check to v3.3, I was wondering if anyone has already done so. I grabed the src from: gatekeeper.dec.com:/contrib/src/pa/m3-2.07/src/m3check and couldn't find a later version. Thanks, CEdric Vandenbergh ======================================================================= 106 === Date: 28 Aug 1994 23:30:18 GMT From: vbidarko@classic4.cs.ttu.edu (Vinod Bidarkoppa) Subject: QUESTIONNAIRE ON OO ANALYSIS AND DESIGN METHODOLOGIES 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 ======================================================================= 107 === Date: 28 Aug 1994 23:31:19 GMT From: vbidarko@classic4.cs.ttu.edu (Vinod Bidarkoppa) Subject: EXPERIENCE / OPINION WITH OO METHODOLOGIES I am interested in knowing about peoples experience / opinion about the following characteristics regarding any of the five Object oriented analysi s and design methodologies as listed below. 1) Booch 2) Coad and Yourdon 3) Shlaer and Mellor 4) Rumbaugh 5) Wirfs-Brock Characteristics 1) Understandability of process and notation 2) Transferability ( ease with which it can be taught to others ) 3) Case tool support ( both drawing and advanced viz. reusability, code generation, syntax checks etc.) 4) Range of application ( ease of application to real world problems viz. information modeling, real time systems, database ddevelopment, etc. 5) Usage pattern ( Extent of usage by software organizations ) 6) Methodology training facilities existing 7) Repeatability ( Extent to which similar results can be obtained by applying the method to the same problem ) Please post the information on the net or forward to following address vbidarko@cs.ttu.edu ======================================================================= 108 === Date: 29 Aug 1994 04:07:21 GMT From: jeske@ux4.cso.uiuc.edu (David Jeske) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? I think a very strong argument for dynamic typing (more for actually dynamically linked programs) has not been mentioned here at all. By allowing loose typing, and dynamic link services, object kits can provide usability for you that would be impossible otherwise. Yes, in some cases it takes much more work on the part of the person doing the object kit, and it certainly takes some thought. However, I feel that enhancements like this are indispensable. As an example, the idea which NEXTSTEP presents as "delegates" of objects. For those non-NeXT aware people. A delegate of an object is something which takes over responsibility for implementing some certain methods. Because of the dynamic typing and linking nature of Objective-C, you are not required to implement a given method in order to be a delegate of the object. I find that using classes such as NXBrowser under NEXTSTEP is extremely simplified by the use of delegate methods. If I remember correctly, there are 5 "browser delegate methods" and one only needs to implement 2 of them for a given scenerio. Depending on what you need from (or want to give to) the NXBrowser you choose the 2 methods which suit your task. Of course the NXBrowser object has to actually check to see if your object (the delegate) actually implements these methods before involking them (or not). However, with a statically typed/bound language, this type of interaction is not possible. I find that this approach is very clean. I prefer it to the static alternative which would be to make a class which implemented dummy versions of all the "delegate" methods and then multiple inherit this into the class where you wanted to make it a delegate of something else. Although there would be no real way for the "NXBrowser" (or whatever) to tell which methods you overrode and which you left, so it would be rather difficult to have it decide what to do. -- David Jeske(N9LCA)/CompEng Student at Univ of Ill at Cham-Urbana/NeXT Programme r CoCreator of the GTalk Chat Software System - online at (708)998-0008 jeske@uiuc.edu (NeXTMail accepted) ======================================================================= 109 === Date: Mon, 29 Aug 1994 02:20:54 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? 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? >Granted, it takes a lot of self-discipline >to produce quality code when you have lots of freedom, but I >think the same self-discipline is necessary anyway. I have >yet to see a language that even comes close to constraints >which guarantee good code regardless of undisciplined coders. Granted. And no reasonable programmer should assert such a thing. On the other hand, a static typed language is a great help for those who wish to exercise their self-discipline. -- 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++ ======================================================================= 110 === Date: Mon, 29 Aug 1994 02:15:48 GMT From: rmartin@rcmcon.com (Robert Martin) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? djohnson@elvis.ucsd.edu (Darin Johnson) writes: >Static typing only catches bugs and design glitches with respect >to typing only. I see some people however that seem to think that >they catch almost all problems this way. The implication from >"you dynamic typing people will have bugs sneak up on you" is that >the static typing people don't have bugs - ludicrous. Are typing >bugs even in the majority? They are a source. In my experience, they are a significant source. But they are certainly not the only source. -- 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++ ======================================================================= 111 === Date: 29 Aug 1994 16:00:55 GMT From: goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <1994Aug29.022054.4589@rcmcon.com>, rmartin@rcmcon.com (Robert Marti n) writes: |> |> 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? Variations in grammar, vocabulary and formatting are ubiquitous. Following your analogy a bit further, one might ask why we don't have "static spelling." I don't think it's a good analogy, though. |> the other hand, a static typed language is a great help for those who |> wish to exercise their self-discipline. If you mean strict static typing, it's more like "who wish to have their self-discipline exercised for them." If static typing is provided as an option, then I agree with you. ======================================================================= 112 === Date: 29 Aug 1994 14:46:48 GMT From: meyering@cs.sun.ac.za (R Meyering) Subject: A Question only... Is there a big difference between Modula2 and Modula3 ? We are currently using Modula2 as the programming language at my university (which I terribly regret over), and it seems very boring without the nice online help like C++ and Pascal. From: Rudi (South Africa) ======================================================================= 113 === Date: 29 Aug 1994 16:14:57 GMT From: connolly@ulua.hal.com (Dan Connolly) Subject: DragNDrop, XtOwnSelection equivalent in FormsVBT? I have the FormsVBT reference, and I've been trolling through the source code (the HTML version is nifty! Bop from module to interface to procedure implementation..), but I can't find the equivalent of XtOwnSelection or support for drag-n-drop data transfer in FormsVBT. I found DragSwitchVBT, but that just allows me to respond to events during a drag. From this, I suppose I could build a drag-n-drop data transfer implementation. But my guess is that this has already been done somewhere. Is there some FormsVBT code that supports the Motif DragNDrop protocol? How about the plain old ICCCM selection protocol? Something like (very roughly): VAR comeNgetIt := NEW VBT.SelectionClosure OVERRIDES convert = Convert; END; BEGIN VBT.OwnSelection(v, XA.PRIMARY, comeNgetIt, timeStamp) END; PROCEDURE Convert(self: VBT.SelectionClosure; selection: Atom.T; target: Atom.T;) : TEXT BEGIN return "testing 1.. 2.. 3.."; END; I'm also interested in X11R6 ICE support. I doubt that's been done. Maybe I could put it together, if I could find some details about ICE. Anybody got any pointers to details on ICE that I can get without downloading the whole X11R6 world? 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 ======================================================================= 114 === Date: Mon, 29 Aug 1994 13:34:26 GMT From: richieb@bony1.bony.com (Richard Bielak) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <33fqpj$mda@vixen.cso.uiuc.edu> jeske@ux4.cso.uiuc.edu (David Jeske) writes: > >My experience has been similar to many of those who have posted. I may just >see things in a different way. It is true that many get themselves in more >trouble with a dynamically typed language by not putting enough thought >into their project. However, I think that's their fault, not the languages. >You put someone in a ferrari and if he gets a speeding ticket, is it his >fault or the ferrari's? Put the same amount of Design time in and you'll >get a similar quality product out, with superior flexibility and reusability. > [...] Rather than talking about speeding Ferrari's consider this analogy. Back in the 60s, private airplane used to have two switches, one for flaps and one for landing gear, that were positioned next to each other on the panel and had the same shape (of course there were labels above them). After every landing when the pilot gets off the runway he must retract the flaps. Unfortunately, many pilots kept flipping the wrong switch and would wind up retracting the landing gear instead of the flaps, which resulted in an embarassing situation. :-) Clearly, this was the pilots problem. They should know which switch is which and be more careful. Right? Well, since then the design on airplanes had changed. Today the flap switch is flat like a flap and the gear switch is round like a wheel. -- * Richie Bielak (212)-635-4835 | * * Internet: richieb@bony.com | Beware of geeks, bearing GIFs. * * Bang {uupsi,uunet}!bony1!richieb | * * - Strictly my opinions - | * ======================================================================= 115 === Date: Mon, 29 Aug 94 12:27:04 -0700 From: mhb@src.dec.com ("Marc H. Brown") Subject: Re: DragNDrop, XtOwnSelection equivalent in FormsVBT? You are correct in noting that the FormsVBT drag-n-drop just allows you to respond to events during a drag. It doesn't use the Motif DragNDrop, ICCCM selection, or X11R6 ICE protocols. I don't know if anybody has do so. ======================================================================= 116 === Date: 29 Aug 1994 18:47:23 GMT From: connolly@ulua.hal.com (Dan Connolly) Subject: DragNDrop, XtOwnSelection equivalent in FormsVBT? I have the FormsVBT reference, and I've been trolling through the source code (the HTML version is nifty! Bop from module to interface to procedure implementation..), but I can't find the equivalent of XtOwnSelection or support for drag-n-drop data transfer in FormsVBT. I found DragSwitchVBT, but that just allows me to respond to events during a drag. From this, I suppose I could build a drag-n-drop data transfer implementation. But my guess is that this has already been done somewhere. Is there some FormsVBT code that supports the Motif DragNDrop protocol? How about the plain old ICCCM selection protocol? Something like (very roughly): VAR comeNgetIt := NEW VBT.SelectionClosure OVERRIDES convert = Convert; END; BEGIN VBT.OwnSelection(v, XA.PRIMARY, comeNgetIt, timeStamp) END; PROCEDURE Convert(self: VBT.SelectionClosure; selection: Atom.T; target: Atom.T;) : TEXT BEGIN return "testing 1.. 2.. 3.."; END; I'm also interested in X11R6 ICE support. I doubt that's been done. Maybe I could put it together, if I could find some details about ICE. (Ah... found them at: ftp://ftp.x.org/pub/R6untarred/xc/doc/specs/Fresco ftp://ftp.x.org/pub/R6untarred/xc/doc/specs/ICE ) 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 ======================================================================= 117 === Date: 29 Aug 1994 16:12:55 GMT From: mjj@Eng.Sun.COM (Mick Jordan) Subject: Re: Seperate Compilation In article 27265@client43.comlab.ox.ac.uk, sknee@comlab.ox.ac.uk (Simon Knee) w rites: > > I have a question about Modula-3 and seperate compilation. I have written > a compiler in Modula-3 and now wish to adapt it for a different target > architecture. The general layout of the compiler is that each node in > the parse tree is an object which is a subtype of an expression, statement > object etc. Each object has methods for Type (), TypeCheck (), .., Compile ( ). > > Obviously the majority of the code is that same for any target architecture > since type checking etc. will not change. The problem is with the > Compile () method. At present I have declarations such as: > > MODULE Loop; > > IMPORT Stmt; > > REVEAL T = Stmt.T OBJECT > METHODS > OVERRIDES > Compile := compileForLoop; > END; > > .... > > END Loop. > > What I would like to do (Ada here I am afraid!) is to say something like: > > seperate (compileForLoop); > > and have a different module that implements the Compile () method. How > do I do things like this in Modula-3? Provided you are happy with the restriction that there can be only one implemen tation of a top-level procedure in a given program there are no problems. You just put the declaration in a common interface and implement it with a separate module. So it is separate as in Ada but there is no nested support, i.e. compileForLoop has to be a top-level procedure. There is certainly no need to put the OVERRIDE S in the interface. E.g. INTERFACE Compiler; PROCEDURE compileForLoop; (* etc *) END Compiler. MODULE Loop; IMPORT Stmt; IMPORT Compiler; REVEAL T = Stmt.T OBJECT METHODS OVERRIDES Compile := Compiler.compileForLoop; END; .... END Loop. Things get harder when you want to have more than one implementation of Compile around in a single program. Then you must resort to subtypes to capture the different method instances. Which then gets tricky for code like the parser which doesnt want to be bound to a particular subtype. There are various solutions to this. For example, check out M3TK, which has an elaborate scheme for such extensibility based on partial revelations. In particular read the comments in the gast/AST.i3 subdirectory. Mick Jordan ======================================================================= 118 === Date: Mon, 29 Aug 1994 23:13:04 GMT From: Bob Hathaway Subject: CHICAGO SPIN INAUGURAL MEETING WITH WATTS HUMPHREY!!! Chicago SPIN Inaugural Meeting GUEST SPEAKER: Watts S. Humphrey TOPIC: Personal Software Process Thursday, September 1, 1994 6:00 PM William Rainey Harper College Auditorium of Building J Algonquin and Roselle Roads Palatine, IL Watts S. Humphrey will be the featured speaker at the inaugural meeting of the Chicago area Software Process Improvement Network (SPIN) chapter. Mr. Humphrey founded the Software Process Program of the Software Engineering Institute (SEI) and is an SEI Fellow. He will present a lecture on the Personal Software Process (PSP) relating PSP methods to practices in other engineering and scientific disciplines. He will describe practical planning and quality management techniques that individuals can apply. The Chicago SPIN was established by software professionals from organizations in the Chicago area. It is a leadership forum for the free and open exchange of software process improvement experiences and practical ideas among practicing professionals. SPIN promotes higher levels of process maturity and software quality. Companies, academic institutions, government organizations and individuals are invited. Registration is free of charge but is required as seating is limited. The meeting will begin at 6:00 PM with the opportunity to network and enjoy refreshments. Mr. Humphrey will speak at 7:00 PM. To Register Call Pat Turner At (708) 925-6140 or FAX at (708) 925-6031. For more information or map and directions, call Girish Seshagiri at (708) 498-4303 or Hamid Ghezevat at (708) 797-4105. How to get to Harper College: From the North: Take Highway 53 south to Algonquin Road exit. Go west on Algonquin Road to Harper College. From the South: Take Highway 53 north to Algonquin Road exit. Go west on Algonquin Road to Harper College. From the East (Chicago): Go west on the Northwest Tollway (I-90) to the Roselle Road exit. Go north on Roselle Road to Harper College. From the West: Go east on the Northwest Tollway (I-90) to Highway 53. Go north on Highway 53 to the Algonquin Road exit. Go west on Algonquin Road to Harper College. ======================================================================= 119 === Date: 29 Aug 1994 21:13:46 GMT From: speters@samsun.us.oracle.com (Stephen Peters) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <1994Aug29.022054.4589@rcmcon.com> rmartin@rcmcon.com (Robert Martin ) 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? 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. 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! :-) Stephen Peters ======================================================================= 120 === Date: 29 Aug 1994 19:00:23 GMT From: connolly@ulua.hal.com (Dan Connolly) Subject: static object methods... why not? All object methods in Modula-3 are "virtual" or "dynamic" or whatever -- the binding of name to procedure is not resolved at compile time, but rather at runtime. Why not allow "static" methods also? It's just syntactic sugar -- it doesn't change the expressiveness of the language. (And I'm not interested in overloading or any of that nonsense). But I grow weary of writing/seeing: Wr.PutText(Stdio.stderr, msg); IF flush THEN Wr.Flush(Stdio.stderr); END; I'd prefer to write/see: Stdio.stderr.putText(msg); IF flush THEN Stdio.stderr.flush(); END; The compiler would have enough info to tranlate the latter into the former given: INTERFACE Wr; TYPE T <: Public; Public = OBJECT METHODS ... PROCEDURES (* or whatever keyword you like *) putText := PutText; flush := Flush; END; ... Does this interact badly with the type system somehow? Couldn't you just say that the PROCEDURES part of an OBJECT constructor has no impact on the type? Certainly there's a good reason why this hasn't already been done. Somebody care to tell me what it is? 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 ======================================================================= 121 === Date: 30 Aug 1994 06:11:57 GMT From: jont@krakatoa.mpce.mq.edu.au (Jonathon Earnshaw TIDSWELL) Subject: Re: Deploying M3 apps: external interfaces I'm on an ugly vt100 emulator, I apologise in advance for bad formating. A program written to the Win32s API should run o Windows 4.0 (chicago), Windows-NT and sometimes under WfW3.11 using the 32bit system extensions. There is an Xlib libary for Windows-NT that was done to port Tk ( of Tcl/Tk ) to Windows-NT (Win32s) this may be of some use. I am wondering what the status of the Win32?s? platform work is ? - JonT -- Jonathon Earnshaw Tidswell Postgraduate Student, Department of Computing School of Mathematics, Physics, Computing and Engineering Macquarie University, NSW Australia 2039 Phone: +61 2 850 9507 Fax: +61 2 850 9551 Internet: jont@mpce.mq.edu.au --- Research Fellow Microsoft Institute of Advanced Software Technology 65 Epping Road North Ryde NSW Australia 2062 Phone: +61 2 870 2776 Fax: +61 2 870 2255 Internet: t-jont@microsoft.com --- Disclaimer: I think my thoughts are my own, and I believe my writings are too. "These are my opinions, others may have similar ones, but these are MINE." ======================================================================= 122 === Date: 29 Aug 94 20:22:34 GMT From: bruce@mdavcr.mda.ca (Bruce Thompson) Subject: TCP Module strangeness. Intended? Hi. I'm in the process of (slowly) developing a Modula-3 interface to Postgres. For various reasons, I'm _not_ simply importing the libPQ calls into Postgres. The main reason is that I'd like the Postgres interface to be thread friendly and the libPQ library is decidedly _not_ thread friendly. Thus, I'm rolling my own, from scratch. As you may or may not be aware, the communications path to the Postgres backend is based on a Streams socket between the frontend client and the backend. The client initiates a connection to the PostMaster, passes over some connection info and then starts talking to the Postgres backend (which is launched by the PostMaster). My initial attempt to connect to the PostMaster hangs at the TCP.Connect call. On investigating the code, I see that TCP.Connect blocks the calling thread waiting for something from the other end, but the other end is waiting for something from the client! Am I interpreting this wrong? Is this indeed how the TCP Module is intended to work? For the moment, I'm working down at the lower-level C-library calls to work around this, but I'd rather use a more standard library and reduce the risk of making my interface heavily Linux dependant. Any hints would be gratefully appreciated. Cheers, Bruce. -- Bruce Thompson, B.Sc. | "A great many people think they are Software Engineer | thinking when they are merely MacDonald Dettwiler, | rearranging their prejudices." 13800 Commerce Parkway, | -- William James Richmond, BC | (604) 278-3411 | Usual disclaimers apply NAPRA #473 | ======================================================================= 123 === Date: 29 Aug 1994 19:36:07 -0700 From: bunbury@vienna.eiffel.com (Richard Bunbury) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? 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. There is nothing new in it as all the points have been made before (often on Usenet), but it may be useful to state them again concisely. Here they are. Static typing is for dynamic programmers: On the Eiffel approach to typing. Interactive Software Engineering Inc. August 1994 Static typing helps productivity and flexibility rather than hampering them. But this assumes that typing is done properly. C++ offers some of the typing mechanisms described below. But static typing a la C++ is too constraining for realistic software development. This is evidenced by the observation that most C++ programs use casts, that is to say, cheat with the type system. Eiffel, in contrast, does not offer any such mechanism (it is simply not possible to bypass the type system); yet Eiffel programmers do not seem to find that typing limits their creativity in any way! So there must be something in the typing mechanism system that reconciles the safety and clarity of typing with the programmer's natural desire for power and flexibility. What makes the Eiffel approach to typing realistic and productive is in particular the following combination of facilities. Multiple inheritance ==================== This is used routinely in Eiffel (as opposed to C++ where it is viewed with suspicion; the difference, we think, is that the machinery of multiple and repeated inheritance has been more carefully thought out in Eiffel, making multiple inheritance a realistic tool). 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. Genericity ========== By having parameterized classes you keep the necessary flexibility for generic structures: for example class LIST [G] describes lists of any type G. If you use it as LIST [MY_TYPE] for some type MY_TYPE, the elements may be of any descendant type of MY_TYPE. C++ templates pursue a similar role. Constrained genericity ====================== The constrained form of genericity is essential in practice, and not present in C++. It enables you to define e.g. a class EXCHANGE_LIST [G -> NETWORK_EXCHANGEABLE] meaning that if you use it as EXCHANGE_LIST [MY_TYPE] then MY_TYPE must be a descendant of the type given as constraint, here NETWORK_EXCHANGEABLE. As a result you can in the body of class EXCHANGE_LIST use all the features (operations, methods) of class NETWORK_EXCHANGEABLE on objects of type G. Assignment attempt ================== Assignment attempt is an operation of the form x ?= y which will work in cases where normal assignment x := y may not be legal. The assignment x := y, by the rules of typing, requires the type of y to be a descendant of the type of x. In some cases, however, you "just know" that the object denoted by y is "of the right type" even though the static declaration of y is more general than that of x. This may be the case, for example, if y denotes an object retrieved from a file, a database or a network. But you still want the assignment to be safe, in case the type of the y object at run time is NOT compatible with that of x. Assignment attempt x ?= y achieves this: it 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). Assignment attempt is not used very often in a well-written object-oriented system, but when it is needed it is needed badly - without it static typing would indeed become too constraining. Covariance ========== Anything declared of type T in a class can be redefined to a descendant of T in a descendant class. This is what is usually needed in practice. Anchored declarations ===================== An anchored declaration is of the form x: like y meaning: whenever y is redeclared in a descendant class, make sure that x follows automatically. This saves a considerable amount of tedious redeclarations; it goes with the covariant policy and is not available in C++. As a result of these mechanisms, typing in Eiffel is not a straitjacket but a help. Declaring every software entity with a type makes the software easier to read and maintain. We know of no case where typing limited anyone's creativity. As a (not so negligible) aside, typing helps Eiffel compilers generate highly optimized code. Finally, of course, one should never forget the main argument for stating typing: the resulting increase in the safety of the software. It is good that this benefit can be obtained without damage to the programmers' creative power. ISE (Providers of ISE Eiffel) -- Richard Bunbury ISE Eiffel Customer Support Reply to: ======================================================================= 124 === Date: Tue, 30 Aug 1994 14:53:47 GMT From: kotula@camax.com (Jeff Kotula) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) writes: >In article <33f2tc$lht@gate.fzi.de>, schaetz@fzi.DE (Roland Schaetzle) writes: >|> .... The difficulties with this code show up >|> only in the long run, when the system is changed and when it grows. >I'm having a little trouble with this statement. Since the code >grows and changes most rapidly during its initial development, wouldn't >the problems show up almost immediately? This fits with my experience. If your code is changing that rapidly during initial development you didn't do adequate design and exploration before beginning production. What was that about this being a 'people-problem'? :) -- ------------------------------------------------------------------------------- - Jeff Kotula kotula@camax.com Camax Systems Inc. Speaking only for mysel f ---------------------------------------------- - ======================================================================= 125 === Date: 30 Aug 1994 16:52:32 GMT From: goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <1994Aug30.145347.17886@camax.com>, kotula@camax.com (Jeff Kotula) w rites: |> goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) writes: |> |> >....Since the code |> >grows and changes most rapidly during its initial development, wouldn't |> >the problems show up almost immediately? This fits with my experience. |> |> If your code is changing that rapidly during initial development you didn't |> do adequate design and exploration before beginning production. What was Unless you're using a code-generating CASE tool (and perhaps even if you are), rapid code changes during early development are a given. By my definition, adding new code to an implementation is the most significant kind of change, and early development is the stage at which most new code is created, tested, debugged, revised, etc. This leads to the conclusion, supported by my personal experience, that it is also a stage at which many or most of the potential type-handling problems are likely to be found, whether you go searching for them or not. |> that about this being a 'people-problem'? :) Sorry, but I don't accept smileys as compensation for veiled insults. Just stick to substance, please. ======================================================================= 126 === Date: 30 Aug 1994 16:30:39 GMT From: mjj@Eng.Sun.COM (Mick Jordan) Subject: Re: M3Check for V3.3 ? In article 10514@gos.ukc.ac.uk, rcv@ukc.ac.uk (R.C.Van-Den-Bergh) writes: > Hi, > > Before I spend some time porting m3check to v3.3, I was wondering if anyone > has already done so. I grabed the src from: > > gatekeeper.dec.com:/contrib/src/pa/m3-2.07/src/m3check > > and couldn't find a later version. > > Thanks, > > CEdric Vandenbergh None of the M3TK apps are included in the 3.3 distribution as yet. I am, in my copious spare time, preparing them for inclusion. Since I now work for Sun ther e are some minor bureaucratic problems to solve regarding modifications that I have made since moving here. I do have m3check working - the main change is to drive the location of sources from m3build rather than m3path files. This was one of my goals for doing m3build since users were irritated at having to maintain both files. Currently there is still a need to modify the m3build template in order to get a map that includes both interfaces and modules. [I am considering rewriting m3build in Tcl, so that I can get access to the state of the interpreter directly - of course quake could be made a library also]. Mick Jordan ======================================================================= 127 === Date: 30 Aug 1994 21:54:47 GMT From: derway@ndc.com (D. Erway) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >>>>> "DJ" == David Jeske writes: DJ> derway@ndc.com (D. Erway) writes: >> I suppose the equivalent of Objective-C's Protocol is to use MI, and have >> one of the parent classes specify the desired protocol. This sounds >> pretty good. DJ> I think it should be looked at from the other end. Objective-C's DJ> protocols are designed to give the "type checking" of an MI system in a DJ> language which is bound at run time. Yeah, I was just looking at it the other way. That MI provides the flexibility that equal to specifying protocols in Obj-C. However, MI may be much better, since it can also supply default implementation, whereas protocols only provide interface. >> What about delegation? Does Eiffel have any equivalent? Does the run >> time system support it? DJ> I think Eiffel is statically bound. (I'm have not used it, so don't flame DJ> me if this is a mistake, it would be highly irregular to have a static DJ> typed language with late binding in the run time system) Eiffel is statically typed, with run time typing as well. Indeed, you can easily write code which tries out an object at run time to see if it conforms to some protocol, (i.e. decends from some super-class), and then apply a method to it if it does. DJ> So it would have to be a "compile time" system that supported delegation. DJ> This would be fine for a simple "static delegate" system which would DJ> almost definetly have to be integrated into the language as well, however DJ> to have anywhere near the delegation flexibility that is present in DJ> Objective-C and is heavily used in the NeXT Appkit one needs to have a DJ> dynamically bound language. Yes. This makes sense. >> Several people have even mentioned that they use Eiffel for the domain >> model, and Obj-C for the GUI. In order to make this dual language >> development attractive, there MUST be some power in each, that is missing >> from the other. As the comp.object faq used to say, (approximately): >> "Proponents of dynamically typed languages claim that the lack of compile >> time type checking is not a problem. This is a lie. Proponent of >> statically typed languages claim that the lack of dynamic typing is not a >> problem. This is also a lie." >> Where is the truth? DJ> Dynamically _TYPED_? and statically _TYPED_? Yes, these are the common terms. Read the comp.object faq. DJ> I think the issues get confused. DJ> FACT: Strong type checking is usefull to help programmers catch compile DJ> time errors. DJ> FACT: Dynamic binding can allow more flexibly program designs. Fact: Strong type checking may be done at compile time, or at run-time. Strong/weak typing is an orthogonal issue to early/late, (i.e. static/dynamic) typing. (Though I suppose doing weak typing at compile time means nothing.) ======================================================================= 128 === Date: 30 Aug 1994 18:24:22 GMT From: derway@ndc.com (D. Erway) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >>>>> "RB" == Richard Bunbury writes: RB> Static typing helps productivity and flexibility rather than hampering RB> them. But this assumes that typing is done properly. RB> C++ offers some of the typing mechanisms described below. But RB> static typing a la C++ is too constraining for realistic software RB> development. This is evidenced by the observation that most C++ programs RB> use casts, that is to say, cheat with the type system. RB> Eiffel, in contrast, does not offer any such mechanism (it is simply RB> not possible to bypass the type system); yet Eiffel programmers do not RB> seem to find that typing limits their creativity in any way! So there RB> must be something in the typing mechanism system that reconciles the RB> safety and clarity of typing with the programmer's natural desire for RB> power and flexibility. RB> What makes the Eiffel approach to typing realistic and productive is RB> in particular the following combination of facilities. RB> Multiple inheritance ==================== RB> Genericity ========== RB> Constrained genericity ====================== RB> Assignment attempt ================== RB> Covariance ========== RB> Anchored declarations ===================== RB> As a result of these mechanisms, typing in Eiffel is not a RB> straitjacket but a help. Declaring every software entity with a type RB> makes the software easier to read and maintain. We know of no case where RB> typing limited anyone's creativity. So, we have some strong claims here, and they sound really good. How true are they? Has anyone gone from CLOS, SmallTalk, or Objective-C, to use Eiffel, and found that the power of the language was not diminished? I suppose the equivalent of Objective-C's Protocol is to use MI, and have one of the parent classes specify the desired protocol. This sounds pretty good. What about integrating new code, classes and objects with old, without having to change the old? Does this usually work in Eiffel? What about multi-methods? What about delegation? Does Eiffel have any equivalent? Does the run time system support it? It seems like alot of the power of Next's Interface Builder is dependent upon late type binding. Is this an illusion? Several people have even mentioned that they use Eiffel for the domain model, and Obj-C for the GUI. In order to make this dual language development attractive, there MUST be some power in each, that is missing from the other. As the comp.object faq used to say, (approximately): "Proponents of dynamically typed languages claim that the lack of compile time type checking is not a problem. This is a lie. Proponent of statically typed languages claim that the lack of dynamic typing is not a problem. This is also a lie." Where is the truth? What is wrong with Eiffel? Why isn't everyone using it? It sounds so good. How many companies are actually using it? RB> As a (not so negligible) aside, typing helps Eiffel compilers RB> generate highly optimized code. RB> Finally, of course, one should never forget the main argument for RB> stating typing: the resulting increase in the safety of the software. It RB> is good that this benefit can be obtained without damage to the RB> programmers' creative power. Yeah safety is great. And obtained without damage to the RB> programmers' creative power. Yeah safety is great. And perhaps eiffel offers a minimal trade off of flexibility to get it. But surely not "NONE". Don ======================================================================= 129 === Date: 30 Aug 1994 15:24:43 -0400 From: rdippold@qualcomm.com (Ron "Asbestos" Dippold) Subject: RESULT: comp.lang.beta passes 354:18 RESULT unmoderated group comp.lang.beta passes 354:18 There were 354 YES votes and 18 NO votes, for a total of 372 valid votes. There were 3 abstains and 2 invalid ballots. For group passage, YES votes must be at least 2/3 of all valid (YES and NO) votes. There also must be at least 100 more YES votes than NO votes. There is a five day discussion period after these results are posted. If no serious allegations of voting irregularities are raised, the moderator of news.announce.newgroups will create the group shortly thereafter. Newsgroups line: comp.lang.beta The object-oriented programming language BETA. This vote is being conducted by a neutral third party. For voting questions only contact rdippold@qualcomm.com. For questions about the proposed group contact Kaj Gronbak . CHARTER comp.lang.beta will receive all the postings from comp.lang.misc and comp.object concerning the BETA language and the programs and systems written in or supporting BETA. Discussions concerning object-oriented programming principles based on the concepts known from BETA will also take place, possibly cross-posted to comp.object. The group will be unmoderated. The beta-language-faq will be cross-posted to comp.lang.beta, and the most frequently asked questions from comp.lang.beta will be included in the subsequent versions of the FAQ. RATIONALE Currently articles concerning BETA are directed to comp.object, comp.lang.misc, and various other groups. Besides this several mailing lists exist which includes several hundred people. Concentrating these posts in a specific group would offer many advantages for the people using or discussing BETA. There would be no need to scan the different groups when looking for a specific subject concerning BETA. There would be no need to cross-post an article in order to make sure everyone else reads it. And finally the very interesting discussions taking place in the various mailing lists will become public. A FAQ named beta-language-faq is currently being posted regularly to news.answers. It would be an advantage to post this FAQ to a language specific group too. comp.lang.beta Final Vote Ack Voted Yes ------------------------------------------------------------------------------ 73501.3447@compuserve.com Andy Pols abdullin@mx.ihep.su ADRIAN.OASIS@AppleLink.Apple.COM Adrian Johnson, Oasis Group,GB,IHD ae446@freenet.carleton.ca Nigel Allen agesen@CS.Stanford.EDU Ole Agesen alexandr@world.std.com Scott Alexander alfh@ifi.uio.no Alf-Ivar Holm allenbach@eleao.epfl.ch amd@fct.unl.pt Artur Miguel Dias andersk@daimi.aau.dk Anders Kristensen andersm@ifi.uio.no Anders Morch Andre.van.Leeuwen@cwi.nl Andrew.Fitzell@analog.com Andrew Fitzell andrewd@sfe.com.au Andrew Davison anti@cs.uq.oz.au arleth@fzi.de Ekkehard Arleth astor@ifi.uio.no Alexander Kjeldaas atler@ifi.uio.no Atle Rinvoll atocasv@ato.abb.se Caj E Svensson ault@cs.albany.edu Jim Ault beaul005@maroon.tc.umn.edu Conrad Beaulieu beckmann@Informatik.Mathematik.Uni-Mainz.DE BERGINF@PACEVM.DAC.PACE.EDU Joseph Bergin berjon@infi.net Bernard Jones bernd@bwhwob.escape.de Bernd Wiegmann bernied@netcom.com Bernhard Damberger bgowing@dsg.cs.tcd.ie Brendan Gowing billb@ripley.sunquest.com Bill Burcham biocad!byrd.biocad.com!david@sgi.com David S. Harrison Birger.Moller-Pedersen@nr.no blach@informatik.hu-berlin.de Ruediger Blach blin@socs.uts.EDU.AU Benjamin Lin bnielsen@daimi.aau.dk booka@netcom.com Matt Nordling borchert@mathematik.uni-ulm.de Andreas Borchert braams@MFDD2.CIMS.NYU.EDU Bastiaan J. Braams Brad.Appleton@mail.csd.harris.com Brad Appleton broendum@daimi.aau.dk John Br|ndum Bruce.Feist@f615.n109.z1.fidonet.org Bruce Feist bstone@acs.ucalgary.ca bue@uebemc.siemens.de Gregor Buehler butorac@informatik.tu-muenchen.de Kristian Butorac ccl@arhus.mentor.dk Christian Clausen choo-young-il@CS.YALE.EDU Young-il Choo christian.hoffmann@wsl.ch christian hoffmann christim@ifi.uio.no Christian Moen chris_treichel@il.us.swissbank.com Chris Treichel chuckp@u.washington.edu Chuck Pliske cl@GOEDEL.UNI-MUENSTER.DE Achim Clausing clstampe@mailbox.syr.edu Chris Stamper cn@cci.dk Claus Noergaard covingcm@cda.mrs.umn.edu Chris M. Covington crawford@pt4427.pto.ford.com William L. Crawford csaliba@manitou.cse.dnd.ca Charles Saliba ctaylor@eecs.uic.edu Conrad Taylor cwturner@cycom.demon.co.uk Christopher William Turner D6B@ecl.psu.edu dan@daimi.aau.dk Dan N|dskouv Christensen dan@oea.hacktic.nl danw@connected.com Dan Wilder datpete@mjolner.dk Peter Andersen dcmay1@penfold.cc.monash.edu.au Daniel C.M. May dconner@clark.net David Conner dec@gsl.com derway@alumni.caltech.edu D. Erway dib@signal.dra.hmg.gb David Bruce dingbat@diku.dk Niels Skou Olsen dlarsson@sw.seisy.abb.se doaitse@cs.ruu.nl S. Doaitse Swierstra dougm@cs.rice.edu Doug Moore dp@bounce.apana.org.au Deeran Peethamparam duke@diku.dk dunham@cl-next4.cl.msu.edu Steve Dunham DVERRIER%ESOC.BITNET@vm.gmd.de D. Verrier dvldbg@cs.umu.se dwmck@bailey.com Derek McKearney eernst@daimi.aau.dk Erik Ernst egil@ifi.uio.no Egil Andersen ehhchi@epx.cis.umn.edu Ed H. Chi els@provis.com Eric Stechmann Erwin.Mooij@lr.tudelft.nl Erwin Mooij Espen.Frimann.Koren@si.sintef.no essandvad@daimi.aau.dk Elmer Sandvad esskov@daimi.aau.dk Esben Skovenborg Even.Larsen@nr.no EXC6FLORAG@CLUSTER.NORTH-LONDON.AC.UK HELLO THERE F.N.Toth@et.tudelft.nl Ferry Toth Faber@europarc.xerox.com Lone Faber faulstic@risc01.informatik.mu-luebeck.de Lukas Faulstich forrest@rose.rsoc.rockwell.com Dave Forrest franke@wien.informatik.uni-dortmund.de Wolfgang Franke frederib@ifi.uio.no Frederick Boakye frode@toaster.SFSU.EDU Frode Odegard frolund@gudenaa.cs.uiuc.edu Svend Frolund fuhr@sally.informatik.uni-dortmund.de Norbert Fuhr futtrup@daimi.aau.dk Erik Futtrup S|rensen g2devi@cdf.toronto.edu Robert N. Deviasse gaponoff@halcyon.com Mark Gaponoff gardner@osm7.cs.byu.edu Mark K. Gardner geir.pedersen@usit.uio.no gessling@brahms.amd.com James Gessling gilbert@marin.cc.ca.us `Slim Tim' Gilbert Gisle.Aas@nr.no glynn@vcdcs6.lsi.tmg.nec.co.jp Leo Glynn gobe@iesd.auc.dk Lars Bendix gransart@lifl.fr grarup@dial.eunet.ch Steffen Grarup greve@daimi.aau.dk J|rgen Greve grossjoh@schroeder.informatik.uni-dortmund.de Kai Grossjohann grouleff@daimi.aau.dk Morten Grouleff gruber@ani.univie.ac.at Bernhard GRUBER grydholt@daimi.aau.dk Jacob Grydholt Jensen gsc@cairo.anu.edu.au Sean Case haible@ma2s2.mathematik.uni-karlsruhe.de Bruno Haible halskov@imv.aau.dk Kim Halskov Madsen hein@math.uni-frankfurt.de Hein Roehrig heine@redbank.tinac.com henryml@daimi.aau.dk Henry Michael Lassen Hilde.Lovett@nr.no Hilde Lovett hnridder@cs.ruu.nl Ernst de Ridder holiday@bnr.ca matthew (m.) holiday hph@oslonett.no Hans Petter Holen huehne@kleene.informatik.uni-dortmund.de Martin Huehne hugh@cosc.canterbury.ac.nz Hugh Emberson hykkelbj@daimi.aau.dk Jens Hedegaard Hykkelbjerg Ian_Upright@mindlink.bc.ca Ian Upright indu@caesar.rice.edu Indrani Sengupta ivan@boole.une.edu.au Ivan Fris J.Bos@CT.TUDelft.NL Joan Bos jacobi.PARC@xerox.com jacobse@daimi.aau.dk Jacob Seligmann JAGSTAID@uni2a.unige.ch JAMESGA@WordPerfect.com James Gates janhvid@VNET.IBM.COM jannicke@ifi.uio.no =?iso-8859-1?Q?Jannicke_Riisn=E6s?= jbuhl@daimi.aau.dk Jesper Buhl jcd@CSOS.ORST.EDU Joshua Dunfield jcm@mstr.hgc.edu James McKim jco@daimi.aau.dk Jens Cornelius Olsen jefu@prism.nmt.edu Jeff Putnam Jerry.Wilcox@ucop.edu Jerry Wilcox jjfeiler@relief.com John Jay Feiler jlknudsen@daimi.aau.dk Jorgen Lindskov Knudsen jls@summit.novell.com jmdaluz@kquest.com Jose M. daLuz joachim@matematik.su.se Joachim Hollman jockel90%charon.physik.Uni-Osnabrueck.DE@unios.rz.Uni-Osnabrueck.DE Joachim Joe.Klemmer@f370.n109.z1.fidonet.org Joe Klemmer johnston@caiman.enet.dec.com jolomo@netcom.com Joe Morris Jonn.Skretting@nr.no Jonn Skretting jtpi@jytkoson2.jyu.fi Juha Pirhonen jubo@cs.umu.se jvitek@cui.unige.ch vitek jan jwbaxter@olympus.net John W. Baxter jwg@bailey.com John W. Gilbert kaelin@bridge.com Kaelin Colclasure karen@ankh-morpork.hacktic.nl Karen Plomp karljo@imv.aau.dk Karl Johan Guld Olsen kbauer@cs.washington.edu Ken Bauer kgronbak@daimi.aau.dk Kaj Gronbak khm@daimi.aau.dk Kjeld H|yer Mortensen kielmann@lira.informatik.uni-siegen.de Thilo Kielmann kirschnt@cis.uni-muenchen.de kja@daimi.aau.dk Kim Jakobsen kjm@mjolner.dk Kim Jensen Moller klauss@daimi.aau.dk Klaus Seidenfaden klute@tommy.informatik.uni-dortmund.de Rainer Klute kragh@daimi.aau.dk Michael Kragh Strandsbjerg kre@fimp01.fim.uni-linz.ac.at Ulrich Kreuzeder Kresten_Thorup@NeXT.COM Kresten Krab Thorup KRUGER_RC@corning.com L15D@ZFN.UNI-BREMEN.DE Martin Schroeder laden@math.tau.ac.il Lars.Bak@Eng.Sun.COM Lars Bak law@tauon.ph.unimelb.edu.au Lachlan Witham ledrecrg@aston.ac.uk ledrecrg lenngray@netcom.com Lenny Gray les@daimi.aau.dk Lennert Sloth lmollebj@daimi.aau.dk Lars M|llebjerg Lokowandt@informatik.uni-stuttgart.de Georg Lokowandt lrf6as@gps1.leeds.ac.uk A Staines madsn@daimi.aau.dk Mads Nielsen MALHOTRA@ACM.ORG JAWAHAR MALHOTRA mandrake@netcom.com Wakko Singer mandrewa@cais.cais.com Mark Andrew Amerman mangalam@uci.edu Harry Mangalam Mario.Wolczko@Eng.Sun.COM Mario Wolczko martino@daimi.aau.dk Hans Erik Martino Hansen matsl@contactor.se Mats Lidell matthias@geek.grf.ov.com Matthias Autrata mcarroll@watson.ibm.com Mark Chu-Carroll mcgrant@rascals.stanford.edu Michael C. Grant mcgraw@cc.gatech.edu Lee McGraw mcross@sw.stratus.com Matt Cross mfx@cs.tu-berlin.de Markus Freericks mg@ac.duke.edu Michael Grubb mga@smuhep1.physics.smu.edu Michael Aivazis Michael.Haller@mq.edu.au Michael Haller michaelw@desaster.student.uni-tuebingen.de Michael Will Mick.Jordan@Eng.Sun.COM Mick Jordan Mikael.Benzinger@eua.ericsson.se Mikael Benzinger mikeg@psg.com Mike Gallo mitchell@ug.cs.dal.ca Dave Mitchell mito@daimi.aau.dk Michael Thomsen Mok-Kong.Shen@lrz-muenchen.de M. K. Shen mos@inesca.inesca.pt Miguel Augusto Mendes Oliveira e Silva moss@usceast.cs.scarolina.edu James LewisMoss mrstampe@mailbox.syr.edu Marjorie R. Stamper mualims@agcs.com Satrio Mualim myg@gate.net Mark Grosberg mynster@imv.aau.dk Rasmus H. Mynster myoung@farad.elee.calpoly.edu May T. Young N.Sharma@LR.TUDelft.NL Sharma ndh@daimi.aau.dk Niels Damgaard neil@aldur.demon.co.uk Neil Wilson neilb@khoros.unm.edu Neil Bowers nenad@cs.rice.edu Nenad Nedeljkovic niemann@swt.ruhr-uni-bochum.de Christoph Niemann nilsb@daimi.aau.dk Nils Bundgaard nop@ccs.neu.edu Jay Carlson normark@iesd.auc.dk Kurt Noermark ns@sandes.dk Nick Sandru olaf@gibson.logware.de Olaf Wagner Ole-Bjorn.Tuftedal@ifi.uib.no Ole-Bjorn Tuftedal Ole.Madsen@Eng.Sun.COM Ole L. Madsen olesm@ifi.uio.no Ole =?iso-8859-1?Q?Sm=F8rdal?= olevi@daimi.aau.dk Ole Villumsen oolsen@hoh.mbl.edu Oystein Olsen oorient@extro.ucc.su.OZ.AU Object Oriented ordan@irst.it Zeno Ordan oreinert@daimi.aau.dk Olav Reinert overlord@access.digex.net David Coe oystein@powertech.no Oystein Homelien oyvind.waal@kjemi.uio.no yvind Waal P.Dale@mailbox.uq.oz.au p00386@psilink.com Lawrence R. Maturo paalso@ifi.uio.no =?iso-8859-1?Q?P=E5l_S=F8rgaard?= pabuhr@plg.uwaterloo.ca Peter A. Buhr pagter@daimi.aau.dk Jakob Pagter pal.kirkebo@usit.uio.no =?iso-8859-1?Q?P=E5l?= =?iso-8859-1?Q?_?= =?iso-885 panielsen@iesd.auc.dk Peter Axel Nielsen pap@goog.larc.nasa.gov Peter A. Padilla papresco@undergrad.math.uwaterloo.ca Paul Prescod Per-Ake.Ek@eua.ericsson.se Per-Ake Ek pete@dswi.com Pete Kruckenberg Peter.Holmes@nr.no Peter.Sommerlad@zfe.siemens.de Peter Sommerlad peterw@arch.su.EDU.AU Peter Williams pfeifer@sally.informatik.uni-dortmund.de Ulrich Pfeifer philk@henson.cc.wwu.edu Philip Kane pingel@daimi.aau.dk S|ren Pingel Dalsgaard pjensen@netcom.com Peter Jensen pjs@mjolner.dk Per Jessen Schmidt ploesch@swe.uni-linz.ac.at Reinhold Ploesch poe@daimi.aau.dk Peter Orbaek pryberg@mjolner.dk Peter Ryberg Jensen ptp@fallschurch-acirs2.army.mil Paul Pryor pvpt@cc.flinders.edu.au P.Trezise quinn@phoenix.Princeton.EDU Michael J. Quinn R.J.Stroud@newcastle.ac.uk Robert Stroud r.keenan@ee.mu.OZ.AU Russell Keenan ragnar@centrum.is Gudmundur Ragnar Gudmundsson ralf%amg.uucp@Germany.EU.net Ralf E. Stranzenbach rcarvalh@spd.dsccc.com Roger Carvalho rco@di.uminho.pt Rui Carlos Oliveira redrock@noc.tor.hookup.net Bob Hutchison reedv@rpi.edu Vince Reed -- "Sub Zero ric@daimi.aau.dk Richard J|rgensen rick@bcm.tmc.edu Richard H. Miller RICK@dfwvx1.DALLAS.GEOQUEST.SLB.COM Rick Caldwell, Schlumberger GeoQuest, 2 rideau@mathp7.jussieu.fr Francois Rideau riehle@rzdspc1.informatik.uni-hamburg.de Dirk Riehle rl@de-montfort.ac.uk Robert Logan robinsons@cix.compulink.co.uk Robinson Associates roen@daimi.aau.dk Henrik R|n rogoff@sccm.Stanford.EDU Brian Rogoff rorschak@daimi.aau.dk Jesper Lauridsen rprice@reunion.umd.edu Rodney Price rufinus@cae.wisc.edu rv@cs.brown.edu rodrigo vanegas rvmeenen@consultdata.knoware.nl Robbert J. van Meenen ry03@Lehigh.EDU RICHARD A. YANCY S.Lewis@bnr.co.uk s923383@minyos.xx.rmit.EDU.AU Wai Long Fong sahai@fintronic.com Paraminder (Bob) Sahai saheien@ifi.unit.no Sten Aksel Heien salvo@eskimo.com Marc Salvatori sander@ankh-morpork.hacktic.nl Sander Plomp sander@daimi.aau.dk Jan Sander Jensen sbrandt@daimi.aau.dk S|ren Brandt schwenk@richsun.cpg.trs.reuter.com Mark Schwenk scott@bse.com Scott A. Krutsch seabrook@clark.net Seabrook shang@cadsun.corp.mot.com David Lujun Shang sharma@duticai.twi.tudelft.nl Naresh Sharma - aio fac L en R shendrix@escape.widomaker.com Shannon Hendrix sherif@auc-aix.eun.eg shioya@sran125.sra.co.jp Kazunori Shioya shirly::watson@futurs.enet.dec.com Rik Watson (7)782 2238 skalwani@brutus.ct.gmr.com Sharan Kalwani CT/90 skeeve@hpb.cis.pitt.edu John Huffman skovby@daimi.aau.dk Mikael Skovby Hansen skulski@Csa5.LBL.Gov Wojtek Skulski sledge@hammer.oche.de Thomas Bueschgens smithrud@advtech.uswest.com Gary M. Smithrud sobottka@udo.informatik.uni-dortmund.de Hans-Gerald Sobottka stanf@rmii.com Stan Foy Stefan.VanBaelen@CS.kuleuven.ac.be Stefan Van Baelen Steinar.Kristoffersen@nr.no stephan@rodion.muc.de Stephan Wacker stephenb@scribendum.win-uk.net Stephen Benson sunny@daimi.aau.dk Rene Wenzel Schmidt svanberg@daimi.aau.dk Henrik Svanberg sverker@dfki.uni-sb.de Sverker Janson swd@cse.unl.edu Scot Dyer tbl@maelstrom.timeplex.com Tom Lyons thomas@hauberl.greenie.muc.de Thomas Gfuellner thomas@is.s.u-tokyo.ac.jp thops@centrum.is Thorbergur P. Sigurjonsson toby@daimi.aau.dk Michael Christensen tompkins@chdasic.sps.mot.com Terry Tompkins tor@geomatic.no Torgeir.Veimo@nr.no Torgeir Veimo (Sommer stud) tox@daimi.aau.dk Jan Toksvig trigg@parc.xerox.com Randy Trigg trygve-s@johanna5.hsr.no Trygve Soerdal tsikes@netcom.com Terry Sikes twl@cs.brown.edu Ted \"Theodore\" W. Leung T_Fiala%caasd1@MWMGATE1.mitre.org u930534@daimi.aau.dk Martin Eli Erhardsen u930617@daimi.aau.dk Benny Amorsen u930702@daimi.aau.dk Kim Burgaard ups@daimi.aau.dk Ulrik Pagh Schultz vanwormh@lifl.fr vanwormhoudt gilles Vaucher@IRO.UMontreal.CA vermeule@WI.LeidenUniv.NL Hans Vermeulen vlvonar@dutrex.tudelft.nl Naresh Sharma ir vollers@austin.eds.com Bill Vollers vonbrand@inf.utfsm.cl Horst von Brand W0103%YMS@MSBG.med.ge.com wagnermi@informatik.tu-muenchen.de Wagner Michael wegge@daimi.aau.dk Anders Wegge Jakobsen wehansen@mcs.kent.edu William Hansen whatis@primus.COM ....What Is?.... williams@well.sf.ca.us Joe Williams wing@research.canon.oz.au Wing Chung wnj@indigo.hobby.nl Willy Jacobs woodfiel@osm7.cs.byu.edu Scott N. Woodfield wr@irb.informatik.uni-dortmund.de Wilfried Rupflin yadallee@GALlif.ERsys.EDmonTON.Ab.cA Dave Shariff Yadallee YAJNIK@ecs.umass.edu yminsky@phoenix.Princeton.EDU Yaron Minsky Yves.Arrouye@imag.fr Yves Arrouye Voted No ------------------------------------------------------------------------------ antersbe@informatik.tu-muenchen.de Stefan Antersberger atkinss@inmos.co.uk Steve Atkins bop@daimi.aau.dk Bo Pedersen cjackson@csugrad.cs.vt.edu Chris 'Action' Jackson crouchkp@flidh102.delcoelect.com cward@Think.COM Christopher Ward fsspr@camelot.acf-lab.alaska.edu Sean P. Ryan grohol@alpha.acast.nova.edu John Grohol henker@Informatik.Uni-Bremen.DE jeffg@loki.engr.sgi.com Jeff C. Glover john@iastate.edu johnl@avocado.ucs.indiana.edu John Lacey kherron@ms.uky.edu siamak@kaiwan.com Siamak Ansari smarry@turing.toronto.edu Smarasderagd srogers@tps.mcs.eds.com stainles@bga.com Dwight Brown WARD@ernie.van.forintek.ca Ward F. Bush Abstained ------------------------------------------------------------------------------ birchall@pilot.njin.net Shag Aristotelis carlson@cap.gwu.edu Eric C. Carlson mmt@RedBrick.COM Maxime Taksar KC6ZPS Votes in error ------------------------------------------------------------------------------ guest@pleione.cc.upv.es guest user ! Invalid address lupper@informatik.uni-ulm.de Alfred Lupper ! No vote statement in message ======================================================================= 130 === Date: 30 Aug 1994 19:27:08 GMT From: jeske@ux4.cso.uiuc.edu (David Jeske) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? derway@ndc.com (D. Erway) writes: >I suppose the equivalent of Objective-C's Protocol is to use MI, and have one >of the parent classes specify the desired protocol. This sounds pretty good. I think it should be looked at from the other end. Objective-C's protocols are designed to give the "type checking" of an MI system in a language which is bound at run time. Some people have brought up the lack of MI as a deficiency in Objective-C. If you had a case where you had two completely separate classes that for some reason you wanted to mush togeather to create a new class, then this is true, you would need MI to do it "efficiently" in the class heirarchy. However, it seems that the more usefull and common use of MI (how I see MI usefull in C++) is how it was discussed with regard to Eiffel. However, since Objective-C is run-time bound, there is no reason that you are required to have a "class" which is inherited in order to provide "protocol" like functionality. In Objective-C, the system was designed to be a flexible run-time system. Then, because people need type systems to catch their mistakes , things like "protocols" and "@object" were added to allow people to do type checking themselves. >What about delegation? Does Eiffel have any equivalent? Does the run time >system support it? I think Eiffel is statically bound. (I'm have not used it, so don't flame me if this is a mistake, it would be highly irregular to have a static typed language with late binding in the run time system) So it would have to be a "compile time" system that supported delegation. This would be fine for a simple "static delegate" system which would almost definetly have to be integrated into the language as well, however to have anywhere near the delegation flexibility that is present in Objective-C and is heavily used in the NeXT Appkit one needs to have a dynamically bound language. Of course you can always find a way to do your own dynamic binding, in C you can just put a bunch of structures togeather and make dynamic binding, but essentially this is cheating the language, as I believe would have to be done in Eiffel. >It seems like alot of the power of Next's Interface Builder is dependent upon >late type binding. Is this an illusion? to some degree. The whole nib/bundle setup which is provided by the NeXT appkit/interface builder is dependent on the bundle loading facilities. O One could compare .nib files to "resources" which are used in Windows and Mac development. However, InterfaceBuilder's ability to let you link your code objects into the "graphical" (or other code objects) objects I think is highly dependent on the late binding. >Several people have even mentioned that they use Eiffel for the domain model, >and Obj-C for the GUI. In order to make this dual language development >attractive, there MUST be some power in each, that is missing from the other. >As the comp.object faq used to say, (approximately): "Proponents of >dynamically typed languages claim that the lack of compile time type checking >is not a problem. This is a lie. Proponent of statically typed languages >claim that the lack of dynamic typing is not a problem. This is also a lie." >Where is the truth? Dynamically _TYPED_? and statically _TYPED_? I think the issues get confused. FACT: Strong type checking is usefull to help programmers catch compile time errors. FACT: Dynamic binding can allow more flexibly program designs. Proponents of languages like C++ and Eiffel will state that they like the Strong typing better. This is completely understood. Many people get themselves into trouble in late-bound/weak-typed languages (SmallTalk). Proponents of languages like SmallTalk state that they need the run-time binding flexibility. This is also completely understood, as there are some programming problems where the solutions merely come out much more elegant and flexible in a Dynamic system. (delegates being one) Now, Objective-C provides a mechanism for strong typing (maybe not quite as strong as C++ or Eiffel, but quite effective), and it provides the run-time binding features of SmallTalk. Is Objective-C the language for everything? No, nothing ever is. Because Objective-C is run-time bound, programs will be slower than they would be in C++ or Eiffel. Of course you can optimize small pieces by reducing the number of object messages and integrating C-function calls, a program where large amounts of "time-expensive" code are involved would more likely be split up into a C++/Objective-C or Eiffel/Objective-C combination. >What is wrong with Eiffel? Why isn't everyone using it? It sounds so good. >How many companies are actually using it? I believe Eiffel is relatively new. From what I have seen, it is spreading rather quickly. I have been meaning for a while to get involved and learn Eiffel, but you know how things go. -- David Jeske(N9LCA)/CompEng Student at Univ of Ill at Cham-Urbana/NeXT Programme r CoCreator of the GTalk Chat Software System - online at (708)998-0008 jeske@uiuc.edu (NeXTMail accepted) ======================================================================= 131 === Date: 30 Aug 1994 22:55:08 GMT From: amitp@owlnet.rice.edu (Amit Jayant Patel) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? > Static typing is for dynamic programmers: > On the Eiffel approach to typing. > > Interactive Software Engineering Inc. > August 1994 > >Static typing helps productivity and flexibility rather than >hampering them. But this assumes that typing is done properly. > > C++ offers some of the typing mechanisms described below. But >static typing a la C++ is too constraining for realistic software >development. This is evidenced by the observation that most C++ >programs use casts, that is to say, cheat with the type system. 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. Thanks! Amit -- o --/-- __\ <|> \ ======================================================================= 132 === Date: 30 Aug 1994 19:09:16 GMT From: derway@ndc.com (D. Erway) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >>>>> "RB" == Richard Bunbury writes: < a bunch of info re: eiffel's type safety and flexibility > Hey you modula-3 programmers! How does modula-3 look compared to eiffel? They seem to have a lot of the same features, except for multiple inheritance. Do you often find the type system of modula-3 preventing you from doing something obvious, that you know will work? Don ======================================================================= 133 === Date: Tue, 30 Aug 1994 22:30:38 GMT From: norman@flaubert.bellcore.com (Norman Ramsey) Subject: Implicit NARROW considered harmful I have never understood why when TYPE T <: U; VAR u : U; t : T; the language designers chose to permit t := u; instead of requiring the more explicit t := NARROW(u, T); (There's an analogy with assignment to values of subrange types, which also requires an implicit run-time check, but in that case the designers didn't provide an operator like NARROW.) I have just been bitten again by a checked runtime error in code I thought could not bring down my application, because there was an implicit NARROW lurking in my code. Could compiler writers please issue a warning when an assignment requires a run-time check that is equivalent to NARROW? Thank you. -- Norman Ramsey norman@bellcore.com ======================================================================= 134 === Date: Tue, 30 Aug 1994 18:55:46 GMT From: Michel Dagenais Subject: Modula-3 Frequently Asked Questions (FAQ) Archive-name: Modula-3-faq MODULA-3 FAQ Michel Dagenais, dagenais@vlsi.polymtl.ca v2.2, 30 August 1994 Contents * Contents * What is new? * The language + What is Modula-3? + Is Modula-3 a superset of Modula-2? * The documentation + Where can I get a description of Modula-3? + Where can I get other information on Modula-3? * The implementations + Where can I get an implementation? + What is SRC Modula-3? + What is m3pc? * Some specific questions + Why is "Hello World" so large? + Why objects and interfaces? + Comparisons between Modula-3 and other languages? + What is the story with Trestle and OpenWindows? + Linking with C++ code + Flushing writers to see the output immediately * FTP + How To Obtain Pre-Compiled Binaries + What if I don't have ftp access? * Contributing + Can I contribute Modula-3 software? + ILU, an object-oriented multi-lingual RPC-capable module system * Modula-3 for teaching * Modula-3 In Industry * Work In Progress + The SRC Compiler + Modula-2 To Modula-3 Converter + Integrated Development Environment + Windowing And User Interfaces o Rotated Text o Postscript VBTs + Persistent Objects + Abstract Syntax Tree Tools (M3 Parser) + Computer Assisted Learning Tools (Algorithm Animation) + Presentations, Tutorials And Teaching Material + Reports And Books + Parallel Programming * Wish List + M3Build + Coverage And Performance Analysis + More VBTs + Distributed Computing (Network Objects) + Interfaces To Other Libraries And Programs (Tcl, Dps...) * Who's Who ABSTRACT: This document contains references to most of the material available on the Modula-3 language, compiler, tools and libraries. It should answer all the most frequently asked questions about Modula-3. The FAQ was originally written by Eric Muller. Send corrections, suggestions, additions to the current maintainer, Michel Dagenais dagenais@vlsi.polymtl.ca. The postscript version is available on ftp.vlsi.polymtl.ca:pub/m3/m3-faq.ps. An hypertext WWW version is found on http://froh.vlsi.polymtl.ca/m3/m3-faq.html. WHAT IS NEW? Release 3.3 from DEC SRC recently came out. Its content is listed in the FAQ. A list of known problems and patches is now available and referenced in the FAQ. The language definition and documentation for most of the libraries is now available on the World Wide Web (thus accessible through Mosaic) Modula-3 Home THE LANGUAGE What is Modula-3? Modula-3 is a systems programming language that descends from Mesa, Modula-2, Cedar, and Modula-2+. It also resembles its cousins Object Pascal, Oberon, and Euclid. The goal of Modula-3 is to be as simple and safe as it can be while meeting the needs of modern systems programmers. Instead of exploring new features, they studied the features of the Modula family of languages that have proven themselves in practice and tried to simplify them into a harmonious language. They found that most of the successful features were aimed at one of two main goals: greater robustness, and a simpler, more systematic type system. Modula-3 retains one of Modula-2's most successful features, the provision for explicit interfaces between modules. It adds objects and classes, exception handling, garbage collection, lightweight processes (or threads), and the isolation of unsafe features. Is Modula-3 a superset of Modula-2? No; valid Modula-2 programs are not valid Modula-3 programs. However, there is a tool to help convert Modula-2 programs to Modula-3. THE DOCUMENTATION Where can I get a description of Modula-3? The language definition and most electronically available Modula-3 information can be accessed on: Modula-3 Home The definition of Modula-3 is contained in: * System Programming with Modula-3 Edited by Greg Nelson Prentice Hall Series in Innovative Technology ISBN 0-13-590464-1 L.C. QA76.66.S87 1991 also known as SPwM3. Here is the table of contents: 1. Introduction 2. Language Definition 3. Standard Interfaces 4. An Introduction to Programming with Threads 5. Thread Synchronization: A Formal Specification 6. I/O Streams: Abstract Types, Real Programs 7. Trestle Window System Tutorial 8. How the Language Got its Spots Chapters 2 and 3 have been reprinted in Sigplan Notices, Volume 27, Number 8, August 1992, pp 15-42. Sam Harbison has written a more tutorial book about Modula3: * Modula-3 Samuel P. Harbison Prentice Hall, 1992 ISBN 0-13-596396-6 The table of contents is as follows: 1. Introduction 2. Declarations 3. Statements 4. Basic Types 5. Structured Types 6. Procedures 7. Exceptions 8. Interfaces and Modules 9. Generics 10. Dynamic Programming 11. Objects 12. Threads 13. Low-Level Programming 14. Programming Conventions 15. SRC Modula-3 16. Modula-3 Syntax 17. Answers to Selected Exercises The errata sheet is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/errata. Errata If you cannot find these books at your favorite bookstore, here are bookstores connected to the net known to carry them: UCI carries both books: UCI Bookstore While Roswell is known to at least carry the language definition (SPwM3): Roswell Electronic Computer Bookstore (rjames@fox.nstn.ns.ca) Roswell Bookstore Where can I get other information on Modula-3? There is a Usenet newsgroup, comp.lang.modula3. The archives of that group are available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/comp.lang.modula3. If you do not have access to Usenet, there is a relay mailing list; send a message to m3-request@src.dec.com to be added to it. Comp.lang.modula3 archive There are a couple high-level overview articles available: * ``Modula-3'', Sam Harbison, Byte, Vol. 15, No. 12, November 1990, pp 385+. * ``Safe Programming with Modula-3'', Sam Harbison, Dr. Dobb's Journal, Vol. 17, No. 10, October 1992, pp 88+. A description of the Modula-3 type system is in * ``The Modula-3 Type System'', Luca Cardelli, Jim Donahue, Mick Jordan, Bill Kalsow, Greg Nelson, Conference Record of the Sixteenth Annual ACM Symposium on Principles of Programming Languages (POPL), Austin Texas, January 11-13 1989, pp 202-212. The Modula-3 treatment of floating-point values is described in * ``The Design of Floating-Point Data Types'', David Goldberg, ACM Letters on Programming Languages and Systems (LOPLAS), June 1992, Vol 1, no.2, pp 138-151 The core library interfaces are described and indexed in * ``Some Useful Modula-3 Interfaces'', Jim Horning, Bill Kalsow, Paul McJones, Greg Nelson, SRC Research Report 113. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-113.ps.Z Libm3 * ``Pickles: a system for automatic serialization of typed values'', Andrew Birrell, Greg Nelson, Susan Owicki, Edward Wobber, Systems Research Center, Digital Equipment Corp., in preparation. The Trestle window system toolkit, higher-level FormsVBT toolkit, and Zeus animation system available with Modula-3, are documented in the following reports: * ``Trestle Reference Manual'', Mark S. Manasse and Greg Nelson, SRC Research Report 68, December 1991. * ``Trestle Tutorial'', Mark S. Manasse and Greg Nelson, SRC Research Report 69, May 1, 1992. * ``VBTkit Reference Manual: A toolkit for Trestle'', edited by Marc H. Brown and James R. Meehan. (to be a SRC Research Report) A draft version is available via anonymous FTP from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/vbtkit.25Mar93.ps.Z. VBTKit * ``The FormsVBT Reference Manual'', Marc H. Brown and James R. Meehan, (to be a SRC Research Report). A draft version is available via anonymous FTP from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/formsvbt.25Mar93.ps.Z and pub/DEC/Modula-3/contrib/formsvbt.AppC.26Mar93.ps.Z. VBTKit library VBTKit applications * ``Zeus: A System for Algorithm Animation and Multi-View Editing'', Marc H. Brown, SRC Research Report 75, February 28, 1992. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-075*.ps.Z. Zeus * ``Color and Sound in Algorithm Animation'', Marc H. Brown and John Hershberger, SRC Research Report 76a, August 30, 1991. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-076a*.ps.Z. Color and Sound * ``The 1992 SRC Algorithm Animation Festival'', Marc H. Brown, SRC Research Report 98, March 27, 1993. Available via anonymous ftp from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-098*.ps.Z. Animation Festival Network objects are described in the following reports: * ``Network Objects'', Andrew Birrell, Greg Nelson, Susan Owicki, and Edward Wobber, SRC Research Report 115, February 28, 1994. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-115*.ps.Z. Network Objects * ``Distributed garbage collection for Network Objects'', Andrew Birrell, David Evers, Greg Nelson, Susan Owicki, and Edward Wobber, SRC Research Report 116, December 1993. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/SRC/research-reports/SRC-116*.ps.Z. Distributed GC While the Obliq embeddable interpreter is documented in: * ``Obliq: A lightweight language for network objects'', Luca Cardelli, User's Manual, Systems Research Center, Digital Equipment Corp., 1994. Available via anonymous FTP from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/Obliq.ps. Obliq Hardcopy versions of these reports can be ordered by e-mail; send your request including a postal mail address to src-reports@src.dec.com. SRC research reports Sedgewick's classic text on computer algorithms is presented in Modula-3 in: * Algorithms in Modula-3 Robert Sedgewick Addison-Wesley, 1993 ISBN 0-201-53351-0 THE IMPLEMENTATIONS Where can I get an implementation? Two implementations are available, SRC Modula-3 and a PC version of it (m3pc). As far as we know, implementations are not available for VMS, Macintosh. What is SRC Modula-3? SRC Modula-3 was built by the DEC Systems Research Center and is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3. The most recent version is release 3.3. The previous release, 3.1, was a major new release intended mostly for porting to architectures other than DEC. A list of known problems and patches is available in: patches This release is known to work on at least on the DS3100, HPPA, SPARC and LINUX architectures. The SPARC release notes may be found on ftp.gte.com:pub/m3 while the LINUX ones are available on ftp.vlsi.polymtl.ca:pub/m3/linux/README and the HPPA notes are in ftp.vlsi.polymtl.ca:pub/m3/hppa/README. SRC-Modula-3 SPARC release notes LINUX release notes HPPA release notes The compiler implements the language defined in SPwM3. There are versions for the architectures listed below. While SRC can test on DS3100, ALPHA/OSF and LINUX, it can only rely on what users on other platforms tell them to integrate all the platform specific code. Because of the improved portability of the 3.* release, ports to non Unix platforms are easier. A port to Windows NT and/or Windows 3.1 may be available in the future. The Windows NT port, in progress, uses native threads. This should be a good model for other implementations of Thread using native threads. * AIX386 IBM PC running AIX/PS2, * AOSF DEC Alpha AXP running OSF/1 * AP3000 Apollo DN4500 running Domain/OS * ARM Acorn R260 running RISC iX 1.21 * DS3100 DECstation 3100 and 5000 running Ultrix 4.0 and 4.2 * HP300 HP 9000/300 running HP-UX 8.0 * HPPA HP 9000/700, 9000/800 running HP-UX 8.0 * IBMR2 IBM R6000 running AIX 3.1, * IBMRT IBM RT running IBM/4.3, * LINUX Intel 386 running LINUX * NEXT NeXT running ?? * NT386 Intel 386 running Windows NT * OKI Okidata 7300 (i860) running UNIX SVR4.0 * SEQUENT Sequent computers running ?? * SOL2 Sparc running Solaris 2.x * SPARC SPARCstation running SunOS 4.1.x * SUN3 SUN3 running SunOS * SUN386 Sun 386i running SunOS 4.0.1 * UMAX Encore Multimax running UMAX 4.3 (R4.1.1) * VAX VAX running Ultrix 3.1 The new native compiler is based on GCC and should be fairly easy to port. Except for the very lowest levels of the thread implementation, the entire system is written in Modula-3. The DEC SRC Modula-3 release 3.3 contains the following: * A native code compiler: uses the GCC backend; on machines/operating systems that have self-describing stacks, an optimized exception handling mechanism is provided, on other architectures, setjmp/longjmp is used. The compilation system provides for minimal recompilation. Only those units that depend on the modified interface item will be recompiled. * m3utils/m3build: tool that performs dependency analysis and builds the Modula-3 programs and libraries. * A large standard library (libm3) providing + A multithread, incremental, generational, conservative garbage collector + Text manipulation. + Generic Containers: Lists, Sequences, Tables, SortedLists, SortedTables + Atoms and Symbolic expressions (Lisp like lists) + An extensible stream IO system + Typesafe binary object transcription (persistent objects) + Operating system interfaces + Portable interfaces to the language runtime All standard libraries are thread-friendly. Modula-3 can readily link with existing C libraries; many libraries including X11R4 and various UNIX libraries are available as part of libm3. * m3gdb: a Modula-3 aware version of GDB. * trestle: a multi-threaded window system interface that sits on top of X windows. It is not unlike InterViews and comes with several sample programs. * trestle/tcp: a library for simplified access to TCP/IP. * vbtkit: a higher level toolkit on top of Trestle. It offers buttons, menus, editors, file choosers... and has a Motif-like look and feel. * formsvbt: an interactive user interface builder. A symbolic expression representing the user interface is edited and the graphical view is immediately produced. * tools/coverage: tool to determine the number of times each statement is executed. * tools/pp: pretty printer for Modula-3 programs. * tools/gnuemacs: emacs lisp files to help editing and debugging Modula-3 programs in emacs. * tools/m3bundle: tool to bundle data files into an executable to produce standalone programs. * tools/m3totex: extract TeX documentation from Modula-3 programs for a form of literate programming. * tools/showheap: tool to graphically see the behavior of the garbage collector. * tools/shownew: tool to graphically see the allocation behavior of a running program. * tools/showthread: tool to see the activation of threads in a running program. * zeus: framework to develop graphical animations of algorithms (heapsort, quicksort, LRU cache replacement, network protocols...) for visualization and teaching purposes. * mentor: a dozen of animations developed using Zeus. * netobj: network objects that allow the transparent execution of methods across process and machine boundaries. A simple yet very effective way to build distributed applications. * obliq: simple, interpreted, lexically scoped, object oriented, distributed programming language that can be embedded in Modula-3 programs and call/be-called by Modula-3 procedures. The Obliq object model is based on prototypes and delegation. * A framework for parsing and analyzing Modula-3 programs. This is a complete AST toolkit for Modula-3. This can parse arbitrary Modula-3 sources (input isn't required to be a complete unit) and produce detailed ASTs representing the input. The ASTs can be used to do a variety of semantic analysis tasks, or program generation tasks similar to Lisp environments. (m3tk). * pkgtools/smalldb: library to store objects on disk with logging and recovery capabilities. * pkgtools: distribution tool that insures that several copies of a package (software, document...) are updated simultaneously. * postcard: mail and news reading environment. * visualobliq: a graphical user interface builder coupled with a simple yet powerful interpreted language, Obliq, for rapid development of interactive distributed applications. * This is a rather new component and is undergoing a fair amount of evolution; however, it is still very useful and exciting. Visual Obliq provides an application builder similiar in nature to Visual Basic. However, it uses Obliq as its scripting language. This makes it easy to build and prototype interesting distributed and groupware applications. It can be used for building non-distributed applications as well. * misc/tcl: interface to access the Tcl language from Modula-3. * misc/dps: interface to access Display Postscript from Modula-3. * games: more sample Trestle applications. What is m3pc? A newer version of m3pc, code named EX32 in the README file, is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/contrib/M3forDOS. PC Modula-3 From the README, written by Klaus Preschern: EX32 ("A 32-bit Extension of DOS") is a environment for the developement and execution of 32-bit applications with DOS. EX32 is a collection of DOS programs (drivers + kernel). It provides services for applications executed in protected mode. It does process management, virtual memory management, interprocess communication via pipes and it offers a file system with 32 character filenames. EX32 runs on MS-DOS 5.00, 6.00 and 6.02. You need a i386/i387 (coprocessor required) or upward (i486, Pentium). EX32 supports DOS XMS memory (but not EMS, VCPI or DPMI). No support for the i286. You should have at least 4 MB memory (8 MB or more recommended). The whole package occupies unzipped and untared approximately 44 MB of disk space. EX32 comes with GNU C++ (version 2.4.5), SRC Modula-3 (version 3.1, including threads), two C libraries, a graphics library for VGA and a number of commands (i.e. ls, cp, rm, mkdir, make, ...). Note: This is a system for experienced programmers! They should be familiar with Unix and DOS. SOME SPECIFIC QUESTIONS Why is "Hello World" so large? Modula-3 programs are larger than C programs for the following reasons: 1. The fixed runtime is substantially larger. It contains a garbage collector, a thread runtime, and exception support. Note that "Hello World" is virtually all runtime. For larger programs the runtime is not an issue. 2. The generated code includes runtime checks for out-of-bound array references and NIL pointer. Many of these checks could be removed by a more sophisticated compiler. Why objects and interfaces? Allan Heydon on comp.lang.modula3, May 4th 1993: Modula-3 provides two separate mechanisms for data-hiding: one for hiding details about how interfaces are implemented, and the other for hiding details about how objects are implemented. The first data-hiding mechanism is realized by the distinction between interfaces and modules. Clients can only import interfaces, so the names declared in the modules implementing those interfaces are hidden from clients. Note that this mechanism has only two levels; a name is either declared in an interface, or it isn't. If a name is only declared in a module, it can't be used by a client. The second data-hiding mechanism is realized by opaque types and revelations. A Modula-3 interface may declare an object type to be opaque, in which case only a subset of the fields and methods of that object are revealed to clients importing the interface. Furthermore, the Modula-3 revelation mechanism allows a designer to reveal successively more fields and methods of an object in a series of interfaces. The fields and methods visible to a client then depends on which interfaces the client imports. The latter mechanism is quite flexible. As opposed to the interface/module data-hiding mechanism, opaque types allow you to define an arbitrary number of levels at which more and more information about the implementation of your object is revealed. See Sections 2.2.10, 2.4.6, and 2.4.7 of ``Systems Programming with Modula-3" for more information about opaque types and about partial and complete revelations. Comparisons between Modula-3 and other languages? From: laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI) "A Comparison of Modula-3 and Oberon-2" by myself in "Structured Programming" 1993, 14:15-22 From: nayeri@gte.com Robert Henderson, Benjamin Zorn, A Comparison of Object-Oriented Programming in Four Modern Languages, Department of Computer Science, University of Colorado, Boulder, Colorado, Technical Report CU-CS-641-93. Available by anonymous FTP and e-mail from ftp.cs.colorado.edu in the file pub/cs/techreports/zorn/CU-CS-641-93.ps.Z The paper evaluates Oberon, Modula-3, Sather, and Self in the context of object-oriented programming. While each of these programming languages provide support for classes with inheritance, dynamic dispatch, code reuse, and information hiding, they do so in very different ways and with varying levels of efficiency and simplicity. A single application was coded in each language and the experience gained forms the foundation on which the subjective critique is based. What is the story with Trestle and OpenWindows? Mark Manasse says: I think that the OpenWindows release should be enough (no need to get the MIT X release), although there are a few things in Trestle that trigger devastating bugs in OpenWindows. But the only library we depend on is Xlib, R4 or later. The main thing I know that crashes OW 2.0 is the code where we call GrabKey specifying AnyKey. You can either loop over all of the keys, or you can just comment out the call; programs won't run exactly the same, but you probably won't notice the difference. Linking with C++ code Apparently there is no problem to call C++ functions declared as extern "C". From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) You must use your C++ compiler as the linker, rather than /bin/cc or /bin/ld. You need to call the function '_main'. The easiest way to do this is to have the following set of interfaces and implementations: INTERFACE CXXMain; <*EXTERN "_main"*> CxxMain; END CXXMain; MODULE CXXMain; BEGIN CxxMain(); END; and then import CXXMain into your M3 main module. This will ensure that the C++ function "_main" gets called. Flushing writers to see the output immediately Modula-3 Writers are buffered. Thus, you need to issue a Wr.Flush when the output should appear immediately, for instance to prompt the user for some input. Since this can become annoying, libraries in other languages sometimes offer the option of unbuffered writes. In Modula-3, an equivalent behavior is obtained with AutoFlushWr which gets a background thread to flush a writer at a specified interval. FTP How To Obtain Pre-Compiled Binaries The following binaries are available for FTP. If you are willing to provide binaries for other architectures, please contact dagenais@vlsi.polymtl.ca; they may be put on his FTP server or links to your server can be included in the FAQ. Starting with release 3.2, more detailed instructions will be included for those who need to install these binaries in different locations, for instance in their home directory. * Release 3.3 SPARC binaries. Contains most of the 3.3 release and comes with static and shared libraries. If you have problems building the 3.3 release for SPARC, you may want to look at the lude/modula3-3.3/src/poly directory as it contains all the locally modified files. It can be retrieved from ftp.vlsi.polymtl.ca:lude/modula3-3.3/run/poly.tar.Z and should be placed in /usr/local/soft/modula3-3.3/run/poly... Then, /usr/local/soft/modula3-3.3/run/poly/sun4.1_sparc/bin must be added to your path. Compiled by Michel Dagenais. SPARC Modula3-3.1 * Release 3.3 LINUX binaries. It can be retrieved from ftp.vlsi.polymtl.ca:pub/m3/linux/src-m3-3.3l0.tar.gz and should be placed in /usr/local/soft/modula3-3.3... Then, /usr/local/soft/modula3-3.3/run/bin must be added to your path. Compiled by Michel Dagenais. LINUX Modula3-3.3 * Release 3.3 HPPA binaries. It can be retrieved from ftp.vlsi.polymtl.ca:pub/m3/hppa/src-m3-3.3l0.tar.gz. Compiled by Bert Laverman. HPPA Modula3-3.3 What if I don't have ftp access? Unfortunately, DEC SRC cannot deliver Modula-3 other than by anonymous ftp. Fortunately, Prime Time Freeware (PTF) includes Modula-3. PTF is a set of two ISO-9660 CDroms filled with 3GB of freeware, issued semi-annually. The latest issue, Volume 1, Number 2, July 1992, contains SRC Modula-3 2.07. PTF is distributed via bookstores and mail. You can reach PTF using: Email: ptf@cfcl.com Fax: [1] (408) 738 2050 Voice: [1] (408) 738 4832 Mail: Prime Time Freeware 415-112 N. Mary Ave., Suite 50 Sunnyvale, CA 94086 USA CONTRIBUTING Can I contribute Modula-3 software? Certainly. Send to m3-request@src.dec.com what you are willing to share, be it programs, libraries or other things. They will be put in the distribution. Right now, the pub/DEC/Modula-3/contrib directory contains: Contrib * m3rpc a Sun RPC system from Xerox Parc * M2toM3 a translator from Modula-2 to Modula-3 * m3pc an implementation of Modula-3 for PCs. You will also find on ftp.vlsi.polymtl.ca in pub/m3: Modula-3 contributions * present-src-m3 slides for presenting the Modula-3 tools and libraries. * cache-anim a zeus graphical animation of the computer memory hierarchy. * realgeometry a floating point geometry package. * sequences sequences allowing insertions in the middle. ILU, an object-oriented multi-lingual RPC-capable module system The following was recently announced by Xerox PARC: Version 1.6.4 of the Xerox PARC Inter-Language Unification (ILU) system is now available for general use. WHAT'S ILU? ILU (pronounced eye'-loo) is a system that promotes software interoperability via interfaces. Interfaces between what? Whatever units of program structure are desired; we call them by the generic term "modules". They could be parts of one process, all written in the same language; they could be parts written in different languages, sharing runtime support in one memory image; they could be parts running in different memory images on different machines (on different sides of the planet). A module could even be a distributed system implemented by many programs on many machines. Calls across ILU interfaces involve only as much mechanism as necessary for the calling and called modules to interact. In particular, when the two modules are in the same memory image and use the same data representations, the calls are direct local procedure calls - no stubs or other RPC mechanisms are involved. ILU modules are known by their interfaces. A module interface is specified once in ILU's object-oriented Interface Specification Language (called, simply, ISL). For each of the particular programming languages supported by ILU (currently Common Lisp, ANSI C, C++, and Modula-3; Python, Tcl, and GNU Emacs-Lisp are in the works), a version of the interface in that particular programming language can be generated. The ILU kernel library provides services which may be used by the language-specific interface to overcome intermodule language or address space differences. GETTING THE RELEASE The release is only available via FTP from the PARC ftp server. Perhaps the simplest way is to go through our World Wide Web home page, ILU CONTRIBUTORS Antony Courtney, Doug Cutting, Bill Janssen, Denis Severson, Mike Spreitzer, Mark Stefik, Farrell Wymore MODULA-3 FOR TEACHING Modula-3 is very well suited for teaching: simple yet powerful, and safe. It avoids the complexity of legacy languages. It can be used to demonstrate modules and interfaces, object oriented programming, multi-threading (concurrency issues), graphical user interfaces (Trestle, VBTKit, FormsVBT) and even distributed programming (Network Objects, Obliq). Since less time is spent by students and teaching assistants chasing dangling pointers and corrupted data, more time is available for learning the important concepts. It is used for teaching in a number of universities. This list is far from complete, send corrections and additions to dagenais@vlsi.polymtl.ca. From: Carsten Whimster (bcrwhims@undergrad.math.uwaterloo.ca) University of Waterloo: CS246 - Third introductory course in computer science. Software engineering and software systems. Medium size projects. Uses Modula-3 to demonstrate proper OO programming, as well as general programming practices. CS241 - Fourth and final intro course to CS. Focuses mainly on compilers and languages. Various assignments has students create most of the different parts of a compiler. Also introduces Scheme (lisp). From: Peter.Robinson@cl.cam.ac.uk University of Cambridge, England. The Computer Science course at the University of Cambridge teaches ML as an introductory language at the beginning of the freshman year, and then uses Modula-3 to develop imperative programming at the end of that year. Further lectures on advanced features of the language are given early in the second year, together with separate lectures on other, specialised languages. The course has been given to about 70 students each year since 1990, and has developed with the language. It ties in with other lectures on data structures and algorithms, software engineering and concurrency. Modula-3 is used for student group projects in the second year and for about a quarter of individual projects in the final year (where, interestingly, students using Modula-3 tend to earn higher grades than those using C/C++). Modula-3 is also used in the Computer Laboratory at Cambridge for a number of research projects on distributed computing, human-computer interaction and electronic CAD. From: Matthew.Huntbach@dcs.qmw.ac.uk We have used it for three years here at Queen Mary and Westfield College, London. The main problem I find with the language is the slow compilation speed on our teaching machines (Macs running A/UX), otherwise it's a nice language to teach with. From: laszlo@ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI) University Klagenfurt Modula-3 is used at the following courses: Undergraduate: Softwaretechnology-1 (actually an introduction into programming) (on PCs) Softwaretechnology-2 (data structures and algorithms) (on PCs) Graduate: Computer Networks (on a network of DECs and SUNs) Parallel Programming (on an DEC-Alpha Farm) Modula-3 has been in use since ca. one year, with very good experiences. From: pk@i3.informatik.rwth-aachen.de (Peter Klein) Lehrstuhl fuer Informatik III, RWTH Aachen, Germany: Software Development Projects, now held for the second time using Modula-3. Aim of these projects is to introduce different aspects of software development to graduate students. This includes project planning, supervision, design, and cooperative implementation of small but usable software systems. Central ideas of software design and object-oriented implementation are presented and discussed with the concepts of Modula-3, which is also the implementation language. Future plans: Maybe Modula-3 will replace Modula-2 in some undergraduate programming lectures in the future. From: rro@cs.colostate.edu (Rod Oldehoeft) In the Computer Science Department at Colorado State University, M3 is envisioned as a vehicle for several courses. M3 is introduced in the second course (data structures) to implement the ADT concept, including generics. In the sophomore languages course, it is an example of an O-O language. In the junior software engineering course, additional relevant features are brought in, and threads are added in the junior operating systems course. From: viggo@nada.kth.se Royal Institute of Technology. Several courses at the computer science department use Modula-3. The courses contain programming projects, and many students choose to use Trestle. (Dr. Viggo Kann, viggo@nada.kth.se) From: Arnulf Mester (mester@tamfana.informatik.uni-dortmund.de) University of Dortmund, Department of Computer Science, Germany. An undergraduate course (scheduled for September) for students within their second year of studies this time takes Modula-3 as third language. Maybe later network programming courses will also use M3/NO/Obliq. The Modula-3 class has it's own WWW home page which is planned to be filled during the class in Oktober/September this year. Modula-3 Class From: "Dave Snelling" (snelling@cs.man.ac.uk) Department of Computer Science, University of Manchester, Manchester U.K. We have a small, interdisciplinary collection of people using Modula-3 for a variety of activities. Our major production code is a hardware architecture simulator (about 120 modules). Smaller projects include a Lattice Gass model and a Shallow Water model. At: University of Massachusetts at Amherst Modula-3 is used as an input language for the Computer Science course on Compilation techniques. The professor is Eliot Moss. From: Michel Dagenais (dagenais@vlsi.polymtl.ca) Modula-3 is used as the main example in a graduate course on ``Algorithmic Aspects of CAD'', which includes a large portion on OO programming and databases. From: pbh@cs.sunysb.edu (Peter Henderson) Modula-3 is currently used for teaching Computer Science I and Computer Science II at SUNY at Stony Brook. We are currently developing a sequence of laboratory assignments and case studies introducing OO techniques and software reuse in these two courses. The first course for computer science majors at Stony Brook is "Foundations of Computer Science" which emphasizes general problem solving, mathematics and the relationships between mathematics and computer science. There is an extensive laboratory component using theorem provers, Prolog and Standard ML. MODULA-3 IN INDUSTRY A number of programming teams in industry selected Modula-3 for their project. It encourages good programming practices and comes with excellent libraries for distributed programming and graphical user interfaces. From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Sun Microsystems Laboratories, Inc. (East) is using Modula-3 (Network Objects, FormsVBT) as the basis for its research in large scale distributed object systems. From: Farshad Nayeri (nayeri@gte.com) Distributed Object Computing, GTE Labs, Waltham, Massachusetts USA Modula-3 (FormsVBT, Sx, Netobj libraries) is used to prototype distributed object management. (Farshad Nayeri nayeri@gte.com). Report WORK IN PROGRESS The purpose of this section is to let everyone know what is being worked on. This is not a commitment to a quick release or even to completion. However it may enable parties interested in the same topics to pool their efforts, avoid duplication or better integrate their packages. To find more information about the names mentioned, see the Who's Who section. The SRC Compiler The compiler already implements the full language and runs on several platforms. Speed enhancements and support for some popular non-Unix platforms may be expected. Modula-2 To Modula-3 Converter A better Modula-2 to Modula-3 converter (99%conversion...) is in the works under the supervision of Peter Klein. Integrated Development Environment A number of groups have made experiments in this area. Tools such as VBTkit for the user interface, m3tk for syntax and dependency analysis, dynamic linking... could be used to produce such an environment. It is worth noting that precompiled interfaces are much easier to achieve in M3 than in several other popular languages. Peter Klein is working on a Modula-3 development environment and associated user interface. See the paper entitled ``Designing Software with Modula-3'', it describes a software architecture description language based on Modula-3. Report Klaus Preschern, Carsten Weich, Laszlo Boszormenyi have made the port of Modula-3 to the PC. The M3-PC environment will be enhanced, especially with threads and graphics, including a student-friendly environment. David N. Gray of Lucid Inc. has been experimenting with connecting the Modula-3 compiler with the Lucid Energize Programming System (currently sold as a development environment for C and C++ on Sun SPARCstations). The modified compiler is available as an unsupported as-is hack, to accompany the new Energize release that it works with. Energize Modula-3 Geoff Wyant is experimenting with FormsVBT/VBTKit to build a simple friendly development environment. Windowing And User Interfaces ROTATED TEXT Currently, there is no VBT to show non horizontal text, because of X windows limitations. This would be desirable and can be implemented in one of the following ways: a) open a pipe to the ghostscript Postscript interpreter and use it as a font renderer, cache and display the character bitmaps produced; b) have Bezier curves for the most popular Postscript fonts, Trestle handles Bezier curves; c) use the new text facilities in X11R6 that remove previous limitations. A prototype implementation of a) has been implemented by Alain Dube (contact Michel Dagenais); the performance with the cache is good but this remains a relatively complex solution. The b) solution would be relatively easy to implement but the resulting quality may not be as good as a real font renderer. The c) solution may not be available for some time since many workstation vendors take a long time before integrating the new X windows facilities. POSTSCRIPT VBTS It is often useful to display Postscript files in a VBT, for example for an included diagram in a document editor. This can be achieved by using the ghostscript Postscript interpreter as a rasterizer. A prototype has been programmed by Alain Dube (contact Michel Dagenais) but the performance is not too good when large color bitmaps are handled. An alternative implementation is to convert Postscript files into display lists (Bezier curves and text) as a preprocessing step. Further displaying and even editing becomes very simple. A prototype implementation of this has been done by Benoit Poirier (contact Michel Dagenais). Persistent Objects With Pickles to store objects in files, the implementation of persistent objects is simplified. Furthermore, with the m3tk library it is not too difficult to read a type description and to write the needed methods to handle that type. Combined with FormsVBT, network objects and Obliq, all the ingredients are there to have a nice environment for developing graphical distributed applications with persistent state and querying facilities. Peter Klein has a specialized database for annotated graphs, GRAS, that is being re-implemented in Modula-3. Eliot Moss is working on persistent Modula-3 objects. The main features are persistence through reachability, load on demand and a very low overhead for using persistent objects. The high performance is obtained by modifying the compiler and run-time. Initially a modified version of GCC, GNU M3, was being worked on. However, with the release of the SRC native compiler, the modifications are being moved to the SRC compiler instead. Persistency Abstract Syntax Tree Tools (M3 Parser) The m3tk library can be used to analyze Modula-3 source code in order to find specific constructions (use of OBSOLETE facilities, un-handled exceptions), build source code browser and analysis tools, stubs generators for network or persistent objects... Mick Jordan is preparing the 3.2 release of m3tk and finishing the documentation, in his spare time. From: hudson@yough.ucs.umass.edu (Rick Hudson) If anyone is interested we have developed a Bison grammar that parses the Modula-3 language input. If interested please feel free to contact me hudson@cs.umass.edu. Computer Assisted Learning Tools (Algorithm Animation) The Zeus Algorithm Animation package may be used to quickly develop graphical and animated teaching aids. Most of the algorithms described in Robert Sedgewick's Algorithms book have been animated at DEC SRC through the work of Marc H. Brown. Animation of compilation techniques have been produced by students at University of Illinois with the help of Marc Najork. From: "Arnulf Mester" (mester@ls4.informatik.uni-dortmund.de) As part of a studental project advised by a college of mine and me a Mentor-like collection of Zeus-based animations of typical distributed algorithms and communication protocols (termed ZADA) has been compiled. Hopefully I'll get to include more information and access during the next weeks into our ZADA WWW home page ZADA Presentations, Tutorials And Teaching Material Modula 3 is used for teaching in a number of Universities. Some Modula-3 related teaching material may be shared between interested parties. Michel Dagenais has a French presentation about the Modula 3 language that could be distributed. Geoff Wyant is preparing a tutorial on Modula-3 for the upcoming OOPSLA conference. Reports And Books Sam Harbison is preparing a revised version of his existing book on Modula-3. He may include more material on the new libraries. Laszlo Boszormenyi, Roland Mittermeir and Carsten Weich are working on a book (it will be published in German and in English) with the work-title: "Programming in Style - An Introduction into Programming with Modula-3" The book will be published at Springer (in German in October 1994, in English maybe or December, or January 1995). For the book, the M3-PC environment will be enhanced, especially with threads and graphics, including a student-friendly environment. A book about writing distributed object oriented applications, using Modula-3, m3build, m3gdb, analyze_coverage, FormsVBT, Obliq and Network Objects is being planned by Geoff Wyant, Farshad Nayeri and Michel Dagenais. From: BERGINF@PACEVM.DAC.PACE.EDU (Joseph Bergin) I am also at work on a Modula-3 college level textbook. It will cover the data structures course and will stress data abstraction. It will be similar to my current book: Data Abstraction: The Object-Oriented Approach using C++, published by McGraw Hill. Status: The software has been built and I am currently writing the text itself. Joe Bergin, berginf@pacevm.dac.pace.edu, Pace University Parallel Programming From: Ernst A. Heinz, University of Karlsruhe, F.R. Germany (email: heinze@ira.uka.de) I would like to inform you about our ongoing Modula-3* project here at the University of Karlsruhe. At the moment, we are actively involved in adding sophisticated dependence and data flow analysis to DEC's Modula-3 compiler (release 3.x!). The Modula-3* compiler will be able to generate code for real parallel machines, for networks of workstations, and for standard sequential execution. (Our new IPD Modula-2* system available by anonymous ftp from ftp.ira.uka.de in "pub/programming/modula2star" may give you an initial feeling about it!) For all interested folks I have made my JSPP'93 paper publicly available by anonymous ftp. The title of the paper reads as follows: "Modula-3*: An Efficiently Compilable Extension of Modula-3 for Problem-Oriented Explicitly Parallel Programming". Paper WISH LIST The Modula-3 development environment now contains a large number of very good tools and libraries that work nicely together. The purpose of this section is to help contributors determine what additions would be helpful to others. It may get you in contact with people that would like to use your contribution or with people that may provide some items on your wanted list or team with you for their development. M3Build The descriptions of programs and libraries stored in m3makefiles are simple and efficient. It would be interesting to be able to specify different m3-options for some files (debugging, performance analysis...), and to have the dependency analysis take into account previously used options when determining modules to recompile (Michel Dagenais). Although makefiles cannot perform the same consistency checks as m3build and are more cumbersome to use, it may be useful to be able to drive the compiler through makefiles for training purposes (i.e. learn Modula-3 and Makefiles at the same time) (bwbecker@watdragon.uwaterloo.ca). Coverage And Performance Analysis Tools already exist for coverage analysis, pretty printing, performance analysis, viewing the threads and the garbage collected heap. It would be nice to have these easily accessible through an integrated development environment (Michel Dagenais). More VBTs An editor widget with multiple fonts (fixed and proportional character spacing) perhaps even with direct support for HTML (item lists, centered headings...) (Geoff Wyant, Farshad Nayeri). A diagram editor widget (Farshad Nayeri). A split VBT that positions NxM childs in aligned rows and columns (Geoff Wyant). A Graph VBT that displays arbitrary graphs (such as call trees, cross references...). This could be implemented adding a placement module (to determine the vertex positions) to work on the existing GraphVBT module (Geoff Wyant). Some of the VBTs implemented in miscellaneous libraries (such as GraphVBT in Mentor/Zeus) could be placed in a more visible location such as VBTKit (Michel Dagenais). MIME extensions to Postcard (Farshad Nayeri). Submit Trestle to a graphical designer (Farshad Nayeri). Distributed Computing (Network Objects) Network objects are an exciting recent addition. The underlying model is very simple and effective. Authentication and access control will be required in many applications. A network object daemon that starts specific programs upon need, like inetd does using inetd.conf for most network services, would be very useful (Michel Dagenais). Interfaces To Other Libraries And Programs (Tcl, Dps...) C functions are easily called from Modula 3. Thus, stubs have been produced to access John Ousterhout's Tcl and also Display Postscript from Modula 3. An automatic tool to produce such stubs from .h C files would be very useful (Geoff Wyant). Stubs to access the Motif X Windows library would be useful (Geoff Wyant). Similar stubs would be desirable to access databases such as Postgres or Exodus and access/provide World Wide Web information using the hypertext transfer protocol libraries (HTTP) (Geoff Wyant). WHO'S WHO Modula-3 enthusiasts, users or contributors. Please notify me for additions, corrections or removals. * Robert Ayers, Adobe, (ayers@Mv.Us.Adobe.Com), the Display Postscript to Modula-3 interface * Andrew Birrell, DEC SRC, (birrell@src.dec.com), Network objects. * Laszlo Boeszoermenyi, Universitaet Klagenfurt, Austria, (laszlo@ifi.uni-klu.ac.at), PC port (m3pc), Programming in style book. * Marc H. Brown, DEC SRC, (mhb@src.dec.com), VBTKit, FormsVBT, Zeus. * Luca Cardelli, DEC SRC, (luca@src.dec.com), Modula-3 definition, Obliq. * Michel Dagenais, Ecole Polytechnique de Montreal, (dagenais@vlsi.polymtl.ca), LINUX and SPARC M3 binaries, M3 FAQ. * John D. DeTreville, DEC SRC, (jdd@src.dec.com), Incremental garbage collector. * David N. Gray, Lucid Inc., Menlo Park, (gray@Lucid.Com), interface between the Lucid environment and the M3 compiler. * Sam Harbison, Tartan, harbison@tartan.com, Modula-3 book. * Ernst A. Heinz, University of Karlsruhe, F.R. Germany (heinze@ira.uka.de) * Allan Heydon, DEC SRC, (heydon@src.dec.com), IP, Lex, Fmt, PQueue, DblBufferVBT modules. * Jim Horning, DEC SRC, (horning@src.dec.com), Useful Modula-3 interfaces. * Rick Hudson, University of Massachusetts at Amherst, (hudson@cs.umass.edu), GNU Modula-3. * Mick Jordan, Sunlabs near Palo Alto, mick.jordan@eng.sun.com, Modula-3 definition, M3TK and related tools. * Bill Kalsow, DEC SRC, (kalsow@src.dec.com), Modula-3 definition, M3 compiler and run-time. * Peter Klein, Lehrstuhl fuer Informatik III, (pk@i3.informatik.rwth-aachen.de). Modula-2 to Modula-3 converter. * Bert Laverman, Groningen University, (laverman@cs.rug.nl), HPPA support. * Mark S. Manasse, DEC SRC, (msm@src.dec.com), Trestle. * Paul McJones, DEC SRC, (mcjones@src.dec.com), Useful Modula-3 interfaces. * James R. Meehan, Adobe (jmeehan@mv.us.adobe.com), VBTKit, FormsVBT. * Roland Mittermeir, Universitaet Klagenfurt, Austria, (mittermeir@ifi.uni-klu.ac.at), Programming in style book. * Eliot Moss, University Of Massachusetts At Amherst, (moss@Cs.Umass.Edu), GNU Modula-3. * Eric Muller, DEC SRC, (muller@src.dec.com), M3 compiler and run-time. * Marc Najork, DEC SRC, (najork@src.dec.com), 3D animation. * Greg Nelson, DEC SRC, (gnelson@src.dec.com), Modula-3 definition, Systems Programming with Modula-3 book editor, Trestle, Network objects. * Farshad Nayeri, GTE Labs Near Boston, (nayeri@Gte.Com), m3-sparc mailing list. * Frode Odegard, (frode@Odegard.Com), commercial Modula-3 support. * Susan Owicki, Stanford University, (owicki@mojave.stanford.edu), Network objects. * Klaus Preschern, Universitaet Klagenfurt, Austria, (preschern@ifi.uni-klu.ac.at), PC port (m3pc). * Robert Sedgewick, Princeton University, Algorithms in Modula-3 book. * Jorge Stolfi, Brazil, (stolfi@atibaia.dcc.unicamp.br), Computational geometry procedures. * Carsten Weich, Universitaet Klagenfurt, Austria, (weich@ifi.uni-klu.ac.at), PC port (m3pc), Programming in style book. * Edward Wobber, DEC SRC, (wobber@src.dec.com), Network objects. * Geoff Wyant, Sunlabs Near Boston, (gwyant@East.Sun.COM), SPARC port. _________________________________________________________________ Michel Dagenais, dagenais@vlsi.polymtl.ca, Tue Aug 30 14:10:56 GMT 1994 -- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 135 === Date: 31 Aug 1994 05:12:56 GMT From: djohnson@arnold.ucsd.edu (Darin Johnson) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? > Static typing is for dynamic programmers: > On the Eiffel approach to typing. I don't want to put down Eiffel - but don't you think it's a cheap shot using C++ as the comparison? You can make any OO language look like the ultimate answer this way :-) :-) -- Darin Johnson djohnson@ucsd.edu -- Toy cows in Africa ======================================================================= 136 === Date: 31 Aug 1994 07:21:18 GMT From: bogoethe@rbg.informatik.th-darmstadt.de (Michael Bonetsmueller) Subject: [Q] Description of Modula-3? 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. :-( Thanks for your help! boni. ======================================================================= 137 === Date: 31 Aug 1994 07:27:51 GMT From: bogoethe@rbg.informatik.th-darmstadt.de (Michael Bonetsmueller) Subject: M3 for OS/2? I just installed EX32, the M3 for DOS. I'm no fan of DOS and I don't want my harddisk filled with tons of file like EX32 does. (Nothing against it: You probably can't do it better on a 80's OS with a 60ies design...). My question: is there a version of M3 for OS/2 available? This should be by far easier to port to than to DOS! Thanks for your help, Boni. bogoethe@rs3.hrz.th-darmstadt.de ======================================================================= 138 === Date: 31 Aug 1994 07:18:17 GMT From: token@erno.de (Thomas.Kendelbacher) 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: |> > Static typing is for dynamic programmers: |> > On the Eiffel approach to typing. |> > |> > Interactive Software Engineering Inc. |> > August 1994 |> > |> >Static typing helps productivity and flexibility rather than |> >hampering them. But this assumes that typing is done properly. |> > |> > C++ offers some of the typing mechanisms described below. But |> >static typing a la C++ is too constraining for realistic software |> >development. This is evidenced by the observation that most C++ |> >programs use casts, that is to say, cheat with the type system. |> |> 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. Maybe it's just bad habits (?): Most C++ is written by C programmers, and C programmers can't do without. OK, I hereby publicly confess that I have used casts even in Ada.. =:-O but of course only in the C interfaces ! ;-) -- Thomas Kendelbacher | email : Thomas.Kendelbacher@erno.de DASA RI / Abt. RIT14 | voice : +49 421 539 5492 (07.00-15.00 GMT) Postfach 10 59 09 | or : +49 421 57 04 37 (any other time) D-28059 Bremen | fax : +49 421 539 4529 (any time) Germany --- Please discard all previous versions of this signature. --- ======================================================================= 139 === Date: 31 Aug 1994 14:17:54 GMT From: chase@michaelcenterline.com (David Chase) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? derway@ndc.com (D. Erway) writes: > Hey you modula-3 programmers! How does modula-3 > look compared to eiffel? They seem to have a lot of > the same features, except for multiple inheritance. > Do you often find the type system of modula-3 > preventing you from doing something obvious, that > you know will work? I haven't done any Eiffel programming, though I've tried to figure the language out from a compiler-writer's point of view. I think they are different in more ways than multiple inheritance. Generally, the superficial feature lists are the same, but the details of the features tend to differ slightly. The accumulation of different details makes for different languages. Eiffel appears to have many features designed to let you deal with things like name clashes (the ability to rename away the clash) and ways to enforce those things that are merely conventions in Modula-3 programs. All this makes the language a good deal larger, which makes it harder to learn, but it's a much better "larger" than C++'s "larger". Eiffel includes language constructs to allow specification of things that are extra-lingual in Modula-3 (pre- and post- conditions are one example, I think). This is "better", in the sense that it is good to do these things, or "worse", in the sense that these are issues are (were?) still being examined for Modula-3 in hopes of building a more comprehensive system (basically, this is a bird-in-the-hand/bush issue). Also, the presentations of the two languages are different. To me, Modula-3 looks like a fairly thin object-organizing veneer on an ordinary procedural language. All my old friends, functions, statements, and expressions, are all there. I view this as a good thing, in that I think it is substantially object-oriented without the introduction of excess mystery. Eiffel is much more object/class-centric in its presentation. This does NOT mean it is more object-oriented, just that its presentation is that way. David Chase Centerline Software ======================================================================= 140 === Date: Wed, 31 Aug 1994 12:20:15 GMT From: richieb@bony1.bony.com (Richard Bielak) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article mikec@metronet.com (Mike Christians en) writes: >In article <1994Aug25.172702.4984@rcmcon.com> rmartin@rcmcon.com (Robert Marti n) writes: > >>For some systems, the trade off should be made in favor of the >>flexibility. For others, it should not. This is also a matter of >>personal taste. I prefer not to gamble with the extra flexibility. I >>am not that good at finding all the inconsistencies myself. I prefer >>that the compiler do as much as it can for me. > >Errors like this should be discovered by the testing process. > 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. ...richie -- * Richie Bielak (212)-635-4835 | * * Internet: richieb@bony.com | Beware of geeks, bearing GIFs. * * Bang {uupsi,uunet}!bony1!richieb | * * - Strictly my opinions - | * ======================================================================= 141 === Date: 31 Aug 1994 14:18:30 +0200 From: amund@galileo.polito.it (A.Aarsten) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? I find your statements regarding the capabilities of C++ rather strange; you are probably not familiar with recent versions of language? In particular, > The constrained form of genericity is essential in practice, and not > present in C++. It enables you to define e.g. a class > > EXCHANGE_LIST [G -> NETWORK_EXCHANGEABLE] > > meaning that if you use it as > > EXCHANGE_LIST [MY_TYPE] > > then MY_TYPE must be a descendant of the type given as constraint, > here NETWORK_EXCHANGEABLE. As a result you can in the body of > class EXCHANGE_LIST use all the features (operations, methods) of > class NETWORK_EXCHANGEABLE on objects of type G. In what way is this generic? If the parameter of my "generic" class and the features I can use from ut is constrained by NETWORK_EXCHANGABLE, why not use simple subtyping polymorphism? 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. > 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. > 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. - Amund ======================================================================= 142 === Date: 31 Aug 1994 15:33:53 +0200 From: steinrya@ifi.uio.no (Stein Jxrgen Ryan) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <341sem$82e@galileo.polito.it>, amund@galileo.polito.it (A.Aarsten) 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. > So a class A is a qualified type parameter for generic class B if it has methods with the right names? You must be joking? It is not interesting if the procedure has the right NAME - what is interesting is whether it has the correct SEMANTICS! A subclass is expected to have a behaviour which is compatible with that of its superclass, so by restricting the generic type parameter to A and its subclasses, we point out the behaviour that is required of the generic parameter type. The C++ "mechanism" seems purely syntactic and quite useless in building a rigorous class library. I must add that I have not used the template feature of C++, but if your description is correct, I am rather puzzled about the (lack of) logic in the template construct. You seem to point out as something positive that you can "use any class you want". But in practice you can only use a class that provides the same semantics. The Eiffel constructs gives you a way to specify WHICH class that is. Stein J. Ryan PhD student University of Oslo ======================================================================= 143 === Date: 31 Aug 1994 18:32:01 GMT From: amitp@owlnet.rice.edu (Amit Jayant Patel) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In article <3420s1$8mh@molik.ifi.uio.no>, Stein Jxrgen Ryan wrote: > >In article <341sem$82e@galileo.polito.it>, amund@galileo.polito.it (A.Aarsten) writes: >> 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. >> > >So a class A is a qualified type parameter for generic class B if it has >methods with the right names? You must be joking? It is not interesting if >the procedure has the right NAME - what is interesting is whether it has the >correct SEMANTICS! > >A subclass is expected to have a behaviour which is compatible with that of >its superclass, so by restricting the generic type parameter to A and >its subclasses, we point out the behaviour that is required of the generic >parameter type. The C++ "mechanism" seems purely syntactic and quite useless >in building a rigorous class library. I must add that I have not used the >template feature of C++, but if your description is correct, I am rather >puzzled about the (lack of) logic in the template construct. > >You seem to point out as something positive that you can "use any class you >want". But in practice you can only use a class that provides the same >semantics. The Eiffel constructs gives you a way to specify WHICH class that >is. 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.] 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++. Amit -- o --/-- __\ <|> \ ======================================================================= 144 === Date: 31 Aug 94 06:30:10 GMT From: bruce@mdavcr.mda.ca (Bruce Thompson) Subject: Re: TCP Module strangeness. Intended? First off, a public "Thank You" for the quick response from dagenais@vlsi.polymtl.ca. He offered some very good suggestions and sanity checks. Thanks to one of his suggestions, I've at least isolated the problem, though I'm not sure where to go from here. For your consideration, I'm enclosing a note I sent out this evening outlining the steps taken and the results found. For context, I wrote a short test program that simply attempted to connect to an existing TCP daemon. Using strace, I tracked down the system calls and their parameters. The results are discussed below. >From bruce Tue Aug 30 23:25:31 1994 Return-Path: Received: by mda.ca (4.1/SMI-4.1) id AA27842; Tue, 30 Aug 94 23:25:29 PDT Date: Tue, 30 Aug 94 23:25:29 PDT From: bruce (Bruce Thompson) Message-Id: <9408310625.AA27842@mda.ca> To: dagenais@vlsi.polymtl.ca Subject: Re: TCP Module strangeness. Intended? Status: R Hi again. Hmmm. This is most strange. If you want I can send you my test program(s) and the trace(s), but I'll summarize here: - The first attempt did nothing more than to a connect to localhost:4321 (the port that the Postgres postmaster listens to. - The strace showed a call to connect like: connect(4, {sin_family=AF_INET, sin_port=htons(57616), ... - This looked suspicious. The process blocked on the select as you described, nothing useful ever happened after that. I let it sit for a few minutes, but all that happened was that the select returned, and the connect was retried giving an EALREADY error. The connect never failed. Incidentally, I checked and nothing is listening at port 57616. - My second attempt was to connect to localhost:57616, instead of 4321. This one worked! The strace showed a call like: connect(4, {sin_family=AF_INET, sin_port=htons(4321), ... - This was followed by a select, then another call like the above. The second call returned with EISCONN, the connection succeeded. I've checked the Postgres source, and netstat -a and I'm convinced that the Postgres backend _is_ actually listening at 4321. (The netstat output firmly convinced me) I see two problems here. First, the non-blocking connect doesn't seem to be timing out. This may be (probably is) a Linux specific problem. The second problem is that the byte order between the m3 source and the call to connect is being messed up. After a brief look at TCP.m3, I can't see anything obviously wrong. Incidentally, the problem manifests itself both with the compiled version of the TCP package provided in the latest LINUX port, and in a freshly compiled copy of the source (obtained directly from the FTP site). For the moment, I'm stumped. Any ideas? I'll be posting a summary of this note to the net this evening, so hopefully some additional input will be found. Cheers, Bruce. -- Bruce Thompson, B.Sc. | "The first ten million years, were the Software Engineer | worst. The second ten million years, they MacDonald Dettwiler, | were the worst too. The third ten million 13800 Commerce Parkway, | years I didn't enjoy at all. After that I Richmond, BC | went into a bit of a decline." (604) 278-3411 | -- Marvin the Paranoid Android NAPRA #473 | | Usual disclaimers apply -- Bruce Thompson, B.Sc. | "A great many people think they are Software Engineer | thinking when they are merely MacDonald Dettwiler, | rearranging their prejudices." 13800 Commerce Parkway, | -- William James Richmond, BC | (604) 278-3411 | Usual disclaimers apply NAPRA #473 | ======================================================================= 145 === Date: Wed, 31 Aug 1994 15:40:47 GMT From: richieb@bony1.bony.com (Richard Bielak) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? 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. ^^^^^^^ > > >...richie > Clearly I need to use a spelling checker prove _absence_ of spelling errors! ...richie -- * Richie Bielak (212)-635-4835 | * * Internet: richieb@bony.com | Beware of geeks, bearing GIFs. * * Bang {uupsi,uunet}!bony1!richieb | * * - Strictly my opinions - | * ======================================================================= 146 === Date: 31 Aug 1994 19:21:35 GMT From: diwan@cs.umass.edu (Amer Diwan) Subject: Visualizing Modula-3 data structures Are there any tools for visualizing Modula-3 data structures? I have large linked data structures and would like to be able to them graphically. Amer -- ------------------------------------------------------------------------------ Amer Diwan Department of Computer Science Object Systems Lab University of Massachusetts diwan@cs.umass.edu Amherst, MA 01003 (413) 545-0256 ======================================================================= 147 === Date: 31 Aug 1994 10:58:10 -0400 From: hal-j@alpha.netusa.net (Hal) Subject: ftp site for Mod-3 compiler can someone tell me where i can ftp a Modula 3 compiler for linux? please mail me at root@vicslip.netusa.net. thank you ======================================================================= 148 === Date: Wed, 31 Aug 1994 21:32:16 GMT From: jdean@bergen.cs.washington.edu (Jeffrey Dean) Subject: Re: Visualizing Modula-3 data structures In article , diwan@cs.umass.edu (Amer Di wan) writes: |> Are there any tools for visualizing Modula-3 data structures? I have large |> linked data structures and would like to be able to them graphically. |> Amer |> -- It may not be quite as automated as you would like, but we've had excellent luck with 'dot', an automatic graph layout program from Bell Labs. We use it to visualize Cecil data structures, but the approach should work for Modula-3, too. To graph a data structure pictures, I write a routine to walk the data structure and dump out a graph file in the format that dot expects (the format's pretty simple: a list of nodes and edges). I use the address of an object as the node's identifier, and some reasonable string representation of the object's meaning as the node's label. Dot can output postscript, Frame MIF, or HPGL files, and it's available free of charge to universities. Contact Peter North (north@research.att.com) for more info about getting dot. -Jeff Jeffrey Dean (jdean@cs.washington.edu) Graduate Student Dept. of Computer Science & Engineering University of Washington ======================================================================= 149 === Date: 31 Aug 1994 20:30:58 GMT From: derway@ndc.com (D. Erway) Subject: Re: Static vs Dynamic Typing: Effects on Productivity? >>>>> "Amit" == Amit Jayant Patel writes: Amit> If I want a sorted list, in C++'s templates, I can write a template Amit> class that uses the "operator <" on the class for sorting. I can use Amit> ints or strings or any class that has an operator < defined on it. Amit> [Note: operator < is not a method here; it is a "global" function.] Amit> However, ints, strings, and all my other classes are not all derived Amit> from some Sortable class. I can't specify "derived from Sortable" in Amit> my template. Amit> I have not used Eiffel, so I am not speaking from experience here, but Amit> it seems like I have to anticipate what classes my users might want my 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. ======================================================================= 150 === Date: Wed, 31 Aug 1994 17:40:45 GMT From: bcrwhims@undergrad.math.uwaterloo.ca (Carsten Whimster) Subject: Re: [Q] Description of Modula-3? 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. -- ------------------------------------------------------------------- Carsten Whimster EDM/2 Associate Editor bcrwhims@cayley.uwaterloo.ca EDM/2 Book Review columnist ---- Author of POVPanel ------ SRX600 ------- TEAM OS/2 ----------- ======================================================================= 154 === Date: Wed, 31 Aug 1994 23:40:20 GMT From: sknee@comlab.ox.ac.uk (Simon Knee) Subject: Re: Seperate Compilation > In article 27265@client43.comlab.ox.ac.uk, sknee@comlab.ox.ac.uk (Simon Knee) > writes: > > > > I have a question about Modula-3 and seperate compilation. I have written > > a compiler in Modula-3 and now wish to adapt it for a different target > > architecture. The general layout of the compiler is that each node in > > the parse tree is an object which is a subtype of an expression, statement > > object etc. Each object has methods for Type (), TypeCheck (), .., Compile (). > > > > Obviously the majority of the code is that same for any target architecture > > since type checking etc. will not change. The problem is with the > > Compile () method. At present I have declarations such as: > > > > MODULE Loop; > > > > IMPORT Stmt; > > > > REVEAL T = Stmt.T OBJECT > > METHODS > > OVERRIDES > > Compile := compileForLoop; > > END; > > > > .... > > > > END Loop. > > > > What I would like to do (Ada here I am afraid!) is to say something like: > > > > seperate (compileForLoop); > > > > and have a different module that implements the Compile () method. How > > do I do things like this in Modula-3? > > Provided you are happy with the restriction that there can be only one > implementation of a top-level procedure in a given program there are no > problems. You just put the declaration in a common interface and implement > it with a separate module. So it is separate as in Ada but there is no > nested support, i.e. compileForLoop has to be a top-level procedure. There > is certainly no need to put the OVERRIDES in the interface. > > E.g. > > INTERFACE Compiler; > PROCEDURE compileForLoop; > (* etc *) > END Compiler. > > MODULE Loop; > > IMPORT Stmt; > IMPORT Compiler; > > REVEAL T = Stmt.T OBJECT > METHODS > OVERRIDES > Compile := Compiler.compileForLoop; > END; > > .... > > END Loop. The problem with this is that if Loop.T has any extra fields or methods that are revealed in its body then Compiler.compileForLoop cannot access them (unless they are passed as parameters). Is there any tidy way to get around this? It is a bit tricky since compileForLoop will have to be within the scope of the revealation, but I do not want the user of Loop.i3 to see this revealation! > Things get harder when you want to have more than one implementation of > Compile around in a single program. Then you must resort to subtypes to > capture the different method instances. Which then gets tricky for code > like the parser which doesnt want to be bound to a particular subtype. > There are various solutions to this. For example, check out M3TK, which has > an elaborate scheme for such extensibility based on partial revelations. In > particular read the comments in the gast/AST.i3 subdirectory. > > Mick Jordan I shall have a look at M3TK! Thanks, Simon Knee. Simon.Knee@comlab.ox.ac.uk