======================================================================= 4 ===
Date:    Tue, 2 Aug 1994 10:53:19 -0400
From:    Dick Orgass <orgass+@CMU.EDU>
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.94Aug3003520@argon.prosign.fi>, 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 <Ctxyyy.B6C@undergrad.math.uwaterloo.ca>, 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
<connolly@hal.com>                   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
<connolly@hal.com>                   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 <rjh@geodesic.com>
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:       <A HREF="http://cnn.acsys.com:5050/~sims/">my home page</A>


======================================================================= 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" <connolly@austin2.hal.com>

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" <connolly@ulua>

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
<connolly@hal.com>                   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
<connolly@hal.com>                   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 <fzi.de> 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.94Aug23180251@alumni.ndc.com>, 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.94Aug23180251@alumni.ndc.com> 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 <DERWAY.94Aug23180251@alumni.ndc.com>, 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 <Robb.Nebbe@di.epfl.ch> 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.94Aug23180251@alumni.ndc.com>, 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
>>>>> <goochb@swim1.eng.sematech.org> 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 <satish@sun.mcs.clarkson.edu> writes:

 Satish> From article <DERWAY.94Aug23180251@alumni.ndc.com>, 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.94Aug24182810@alumni.ndc.com> 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.94Aug24175922@lia.di.epfl.ch> 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 <tmb@arolla.idiap.ch> 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
<connolly@hal.com>                   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.94Aug23180251@alumni.ndc.com>, 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
<connolly@hal.com>                   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.94Aug24182810@alumni.ndc.com> 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.94Aug25054643@arolla.idiap.ch>, 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.94Aug24224842@arnold.ucsd.edu> 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.94Aug24182810@alumni.ndc.com> 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
<connolly@hal.com>                   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<Type>
    {
    };

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.94Aug27025001@arolla.idiap.ch> 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
<connolly@hal.com>                   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
<connolly@hal.com>                   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 <rjh@geodesic.com>
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
<connolly@hal.com>                   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: <info@eiffel.com>


======================================================================= 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 <jeske@ux4.cso.uiuc.edu> 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 <bunbury@vienna.eiffel.com> 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 ====================
	<snip>
 RB> Genericity ==========
	<snip>
 RB> Constrained genericity ======================
	<snip>
 RB> Assignment attempt ==================
	<snip>
 RB> Covariance ==========
	<snip>
 RB> Anchored declarations =====================
	<snip>


 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 <kgronbak@daimi.aau.dk>.


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 <bunbury@vienna.eiffel.com> 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 <dagenais@vlsi.polymtl.ca>
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.21.000B26F7@metronet.com> 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 <steinrya@ifi.uio.no> 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: <bruce>
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 <CvEFLs.3vz@bony1.bony.com> 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.94Aug31152136@rhea.cs.umass.edu>, 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 <amitp@owlnet.rice.edu> 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 <bogoethe@rbg.informatik.th-darmstadt.de> 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




