======================================================================= 1 ===
Date:    Wed, 1 Apr 92 08:03:16 EST
From:    wyant@centerline.com
Subject: email address for requesting Trestle report ?

Is there an email address from which the
the Trestle report can be requested ?

thanks,

Geoff 

Geoff Wyant
wyant@centerline.com
Centerline Software, Inc.
(Formerly Saber Software, Inc)
10 Fawcett Street
Cambridge, Ma.
02137


======================================================================= 2 ===
Date:    Wed, 1 Apr 92 15:43:17 PST
From:    msm@src.dec.com (Mark S. Manasse)
Subject: Re: email address for requesting Trestle report ?


Send mail to src-report@src.dec.com asking for report #68,
the Trestle Reference Manual.

Mark


======================================================================= 3 ===
Date:    29 Mar 92 16:35:24
From:    vixie@pa.dec.com (Paul A Vixie)
Subject: Re: are Modula-3 records redundant?

A record has the option of existing directly, being passed by value, and so on.
Objects exist only by reference.  There's not much difference in actual perfor-
mance between the two, but certainly if you're just trying to aggregate some
variables together or you need substructures in an Object, you'd use a Record.
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Ready, Fire, Aim"
<vixie@pa.dec.com> decwrl!vixie
<paul@vix.com>     vixie!paul          


======================================================================= 4 ===
Date:    30 Mar 92 16:18:28 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Comments on Modula 3 Books

I just got a copy of the Book "Modula 3" by Sam Harbison and read it over
the weekend. It is clear and concise and contains a good number of
examples. The targeted audience is rather wide as it can be used for a
first programming language, replacing something like Introduction to
Pascal. Because of that, i feared that i would get bored. However,
the first 2 or 3 chapters are quickly over and, because of the language
simplicity, you rapidly become involved with interesting features like
interfaces and modules all the way to threads. I found the progression
interesting and natural as new elements were smoothly introduced from 
chapter to chapter.

It does not replace Systems Programming with Modula 3 which contains the
precise language reference and discussions about Trestle, Larch
specification language and discusses some of the choices made while
designing Modula 3.

In summary, i am happy to have both books on my shelves (eventually when i
finish lending them to other people). Students for graduate and 
undergraduate projects in Modula 3 will probably want to buy "Modula 3".
Some of them will want to dig further and read "Systems programming with
Modula 3".

This 266 pages (plus appendix) book is easy to read yet keeps a good pace
and goes further (threads) than equivalent 600+ pages books on C++. A good
part of the credit goes to the language itself but the author certainly
deserves some as well! Final verdict: among the 10% best written books on
this kind of topic.

Disclaimer: i have no ties with the author other than the fact that we
both subscribe to comp.lang.modula3 :-)

 
--
---------------------------------------------------------------------

Prof. Michel Dagenais			    dagenais@vlsi.polymtl.ca
Dept of Electrical and Computer Eng.
Ecole Polytechnique de Montreal		    tel: (514) 340-4029

---------------------------------------------------------------------


======================================================================= 5 ===
Date:    29 Mar 92 22:20:44 GMT
From:    n8243274@gonzo.cc.wwu.edu (steven l. odegard)
Subject: are Modula-3 records redundant?

A Styleist's question:
I see the recommendation that objects be used instead of records
to allow for possible future expansions.  If record types are functionally
equivalent to methodless object types, does the need for records remain?
How should I include record types in the coding design?


======================================================================= 6 ===
Date:    Mon, 30 Mar 1992 08:19:24 GMT
From:    mathew@elroy.jpl.nasa.gov (Mathew Yeates)
Subject: SRC tests on SparcStation

When I try and compile the ptests given with SRC compiler
I get strange behavior.After building libtest.a and cd' ing
to p001_X I type (I'm attempting to mimic the m3makefile)
m3 -g -w1 -D../.. -debug -v -o pgm ../base.b ../p001

and get

using ../base.b  (Note: base.b was built in a preceeding step)
Looking in ../p001/
Looking in ../p001//
Looking in ../p001///
Looking in ../p001//// 

ad infinitum.

1) Shouldnt the compiler quit at some point instead of just hanging?
2) What do the above debug statements indicate? WHATS GOING ON?

-Mathew Yeates



======================================================================= 7 ===
Date:    27 Mar 92 19:10:14 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Errata list for book "Modula-3"

It is time for one of the author's least-loved task--the publishing of
the errata sheet.

FYI, when an author discovers an error he or she ships the change off
to the publisher, who stores it until time for the next printing.
Corrections have a cost (in time and money), so cosmetic problems and
problems that aren't likely to confuse the reader typically don't get
corrected, unless they are lewd or embarassing or they occur on a page
that is changed for some other reason. Anyway, here are ALL the
problems I know of.

Thanks to those of you reporting problems, and feel free to report
more.  (Compliments are accepted also, of course.)

    Errata list for "Modula-3", by S. P. Harbison, Prentice Hall, 1992.
                    As of: March 27, 1992.

Page Line  Description
---- ----- ------------------------------------------------------
  1   -4   Change "it easy" to "it is easy".--> 2 
  3   -6   Change "MODULE Main" to "MODULE Hello1 EXPORTS Main".--> 2 
  3   -1   Change "END Main" to "END Hello1".--> 2 
  5  -13   Change "MODULEHello1" to "MODULE Hello1".--> 2 
  5   -5   Change "MODULE Main" to "MODULE Hello1 EXPORTS Main".--> 2 
  5   -4   Change "END Main" to "END Hello1".--> 2 
  8    7   Change "Hello, World!" to "Hello, World!\n"--> 2 
  8        Swap positions of Example 1-4 and Figure 1-3.--> 2 
 10   -4   Rewrite last paragraph; mention left-associativity.--> 2 
 20   -5   Mention that loop variable i is declared in FOR statement.--> 2 
 20        Swap positions of Box and Example 2-5.--> 2 
 32    1   Add space before "By".--> 2 
 32    6   Change "n := n" to "n := BITSIZE(n)"--> 2 
 32    7   Add "because the result type of BITSIZE is always CARDINAL."--> 2 
 33   -4   Add missing ")" at end of declaration.--> 2 
 33   -5   Add missing ")" at end of declaration.--> 2 
 33    8   Fix typeface of exercise 4d.--> 2 
 38  -17   Change "a,pos" to "a, pos".--> none
 43    5   Modula-2 requires "()" in function calls, but not 
               proper procedure calls.--> 
 49    8   "Solution" should be boldface.--> none
 50    1   In box, keywords should not be boldface.--> none
 57   -9   Rephrase as: "Which of the three versions is more readable?"--> 2 
 57   -5   Change "page 49" to "page 50".--> 2 
 64  -10    -8 MOD 3 is 1, not -1--> 2 
 64   -5   x MOD 2 is 1 if x is odd; it cannot be -1--> 2 
 67   19   Change "volume : [0..10]" to "volume: [0..10]".--> none
 74   -4   Add: The type of FIRST and LAST is the base type of T.--> 2 
 74   -4   Add: The type of NUMBER is CARDINAL.--> 2 
 74   -3   Add: "and has type T" to example of FIRST and LAST.--> 2 
111    6   Change "Point, the" to "Point (page 107), the".--> 2 
111   -6   Change "SET OF t" to "SET OF T".--> 2 
112   -5   Change "CARDINALITY" to "Cardinality".--> none
112   -2   Identifiers in italics should be in the program typeface.--> none
113    3   Change ":=" to "=".--> 2 
129    1   Remove "[A]".--> 2 
129   -3   Add "(or LAST(CARDINAL) if the array is empty)" before ":".--> 2 
129  -10   Change "the procedure" to "ForAllElements".--> 2 
141   18   Change "in procedure Forever" to "in the procedure".--> 2 
141  -14   Change "ELSE =>" to "ELSE".--> 2 
141   -9   Change "Chapter 12 (Threads)" to "Chapter 12".--> 2 
168    1   In box, keyword "END" should not be boldface--> none
214        Add "RETURN self" to InitPostion and InitRectangle.--> 2 
214  -19   Editorial changes to paragraph "The Rectangle.init method...".--> 2 
218        Add "RETURN self" to InitPosition and InitRectangle.--> 2 
219        Add "RETURN self" to InitCircle.--> 2 
219   -8   Editorial changes to last paragraph--> 2 
226   -7   Change typeface of "Child".--> none
227    8   Mention that untraced things are discussed in 13.2 on p. 258.--> 2 
227   -6   Change typeface of "name".--> 2 
234        Change "94681" to "94861" (four times).--> 2 
299    7   The answer to D.1.5(c) is 11, not 3.--> 2 
300    8   Change "a := y" to "b := y".--> 2 
300  -16   Change all "A" and "B" to "a" and "b" in answer to exercise 9.--> 2 
300  -11   Delete procedure heading; the solution is a block statement.--> 2 
305        Correct typeface of leading entry in letter groups 
               as necessary.--> none
305        Add "Alerted (Thread)" to the index (cite p. 250)-->

	----------
Line n       means the n'th line from the top of the page
Line -n      means the n'th line from the bottom of the page
"--> n"      means the correction should appear in the n'th printing
"--> none"   means the correction won't be made in the book unless the
                  page is corrected for some other reason
"--> (blank)" means no decision has been made on making the correction
	----------

Please send all comments and corrections to harbison@bert.pinecreek.com.

Sam Harbison 
Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213;
USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com.


======================================================================= 8 ===
Date:    27 Mar 92 14:05:58 GMT
From:    bruce@utafll.uta.edu (Bruce Samuelson)
Subject: Modula-3 vs Eiffel

I have a naive question as a Smalltalk programmer who hasn't used
either of these languages.  Eiffel has some nice software engineering
constructs but is struggling to establish a commercial beachhead in
the face of the C++ juggernaut.  Modula-3 resembles Eiffel but is in
an earlier stage of free availability and intellectual ferment.  What
features of Modula-3 make it more desirable than Eiffel, and do you
envision its becoming a viable commercial language some day?  I'm not
trying to start a language war at all, but just trying to satisfy my
curiosity.
--
**********************************************************
* Bruce Samuelson	Department of Linguistics	 *
* bruce@ling.uta.edu	University of Texas at Arlington *
**********************************************************


======================================================================= 9 ===
Date:    Fri, 27 Mar 1992 21:01:52 GMT
From:    mathew@elroy.jpl.nasa.gov (Mathew Yeates)
Subject: Problems on a SparcStation

Anyone with any experience using the SRC Modula 3 on a Sun
SparcStation? I'm a C++ refugee checking out modula3 and know
very little about the language. However, I installed the SRC
compiler and tried to run their demos. Heres what happened.

Solitaire crashes my window manager (olwm).

Tetris dumped core. I traced the problem to a bad return of
Uutmp.getlogin in Main.m3. I fixed the problem by setting the
environment variable TETRIS so the above function would not be
called. After this it worked okay.

How do you use dbx on this stuff. I compiled with -keep so I
would have the c files still around but dbx complains about
not being able to find the files(actually, its looking for
foo_m.c instead of foo.mc)

This is SunOs 4.1.2, openwindows 3.0, olwm. Also, I had to link
the X libs statically by compiling with -X2@-Bstatic@ because
Sun's patched loader is a piece of crap.

Anybody?? 

-Mathew Yeates



======================================================================= 10 ===
Date:    27 Mar 92 22:06:12 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Scan.i3 suggestions

First, I'd like Scan (and Fmt) to have "Extended" procedures to go
with "Real" and "LongReal". I like to suggest to people that they use
"Extended" routinely, but the lack of runtime routines makes it
difficult to do this. Math.i3 is another problem...

Next, I discovered that Scan.LongReal(t) and Scan.Real(t) pick off
whatever initial prefix of t seems to make up a number and return it.
They happily accept stuff like "0.1.2.3" (returns 0.1) and "1eee4"
(returns 1). Here's why this is Inconvenient: It's very cumbersome to
test if an ASCII floating-point number is correctly formatted,
although it's easy to separate out a string of digits and other
characters that might be part of a floating-point number.  What you'd
like to do is pick a candidate and let Scan.LongReal do the final test
and conversion, e.g.,

	TRY
	  x := Scan.LongReal(t);
	  (* It was OK *)
	  ...
	EXCEPT
	| Scan.BadFormat => (* whoops, not formatted correctly *)
	...
	END

This won't work in the current implementation, but it's easy to fix.
The lower-level Convert module tells you how many characters were
converted.  In the Scan.Real and Scan.LongReal routines, the
test-for-failure

  IF used = 0 THEN ...

can be changed to

  IF used # NUMBER(x^) THEN ...

Also, Scan.Real/Scan.LongReal treat the exception Convert.Failed as a
fatal error. I don't see any reason not to turn that exception into
Scan.BadFormat.

Sam Harbison 
Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213;
USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com.


======================================================================= 11 ===
Date:    26 Mar 92 22:19:44 GMT
From:    adam@visix.com
Subject: Re: Modula-3, Fortran, Numbers & Aliens


In article <1992Mar24.061919.21496@yrloc.ipsa.reuter.COM>, rbe@yrloc.ipsa.reute
r.COM (Robert Bernecky) writes:
|> In article <1992Mar20.154100.1603@visix.com> adam@visix.com writes:
|> >The point is, arguments of generality don't cut it with people who
|> >never have to deal with the extra cases.  If all they do is limited
|> >to a particular domain, then all they want is a notation that fits
|> >that domain.
|> >
|> >Is that wrong?

|> Well, no, it isn't wrong.
|> 
|> BUT, it does mean that they don't tend to think about ideas like:
|> (examples elided)... as ALL being minor variations on the SAME idea...

Agreed, they don't think that way.  Again, the point is that they never
have to.


|> I don't see how sigma and pi notation are easier,

You don't agree that using something you already know is easier than
learning something new?


|> except for the braindead who are unable to learn anything new.

Is this really necessary?


|> The insert notation
|> is easier to teach to children(not sure about grad students and doddering
|> professors)

But we are not discussing better notations for teaching children.


|> and is consistent, as well as generalizing to ANY function.

Again, arguments of generality don't cut it with people who never
have to deal with the extra cases.


Adam


======================================================================= 12 ===
Date:    Fri, 27 Mar 1992 14:51:28 GMT
From:    lowry@watson.ibm.com (Andy Lowry)
Subject: Re: Checking Subtype relationships.

In article <kt4622INNoaj@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Cha
se) writes:
   I heard that there was some paper (in TOPLAS, I think, last year or
   two) on efficiently performing lattice operations that might be of
   some help here.  That's all I know for now -- I have't had time to get
   to it.

   David Chase
   Sun

@article{aitkaci89a.B,
  author={A\"it-Kaci, Hassan and Robert Boyer and Patrick Lincoln and
Roger Nasr},
  title={Efficient Implementation of Lattice Operations},
  month=jan,
  year=1989,
  journal=toplas,
  pages={115-146},
  volume=11,
  number=1
}
--
Andy Lowry, lowry@watson.ibm.com, (914) 784-7925
IBM Research, P.O. Box 704, Yorktown Heights, NY  10598


======================================================================= 13 ===
Date:    Sat, 28 Mar 1992 01:24:11 GMT
From:    melling@cs.psu.edu (Michael D Mellinger)
Subject: Re: why modula3?


In article <kt7hjfINNn80@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Cha
se) writes:

   VERBOSE UPPERCASE IDENTIFIERS.

Will this be "fixed"?  My fingers bother me enough as it is without
having to reach for the shift key all the time.

-Mike



======================================================================= 14 ===
Date:    Fri, 27 Mar 1992 21:11:06 GMT
From:    mathew@elroy.jpl.nasa.gov (Mathew Yeates)
Subject: why modula3?

While I'm at it......

I'm interested in the relative advantages and disadvantages of
C++ versus Modula3. I'm an applications programmer so my concern
is not with the aesthetics of the language. Rather, I want
something thats going to help me quickly write applications.

Also, should I even be attempting this on a Sun SparcStation?
The SRC Modula3 compiler demo programs dumped core or crashed
my window manager. (Version 2.04). 

-Mathew



======================================================================= 15 ===
Date:    26 Mar 92 08:59:42 GMT
From:    ske@pkmab.se (Kristoffer Eriksson)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <1992Mar25.004218.12233@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim
 Giles) writes:
> And, in fact, new notations are invented by every other 
>author in these fields - and the best of these notations survive.

Why do you think it is the _best_ notation that survives? I would think
that is far from obvious.

-- 
Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone: +46 19-13 03 60  !  e-mail: ske@pkmab.se
Fax:   +46 19-11 51 03  !  or ...!{uunet,mcsun}!mail.swip.net!kullmar!pkmab!ske


======================================================================= 16 ===
Date:    27 Mar 92 14:06:42 GMT
From:    collberg@dna.lth.se (Christian S. Collberg)
Subject: Subtype checking.

Thanks to those who responded to my query. Here are the relevant references:

@CONFERENCE{Dietz82,
   AUTHOR    = "Paul F. Dietz",
   TITLE     = "Maintaining Order in a Linked List",
   BOOKTITLE = "Proceedings of the 14th Annual ACM Symposium on
                Theory of Computing",
   ADDRESS   = "San Francisco, California,
   PAGES     = {122--127},
   MONTH     = may,
   YEAR      = 1982
}

@ARTICLE{Cohen91,
   AUTHOR    = "Norman H. Cohen",
   TITLE     = "Type-Extension Type Tests Can Be Performed in Constant Time",
   JOURNAL   = "Transactions on Programming Languages and Systems",
   VOLUME    = 13,
   NUMBER    = 4,
   PAGES     = {626--629},
   MONTH     = oct,
   YEAR      = 1991
}

-- 
Christian.Collberg@dna.lth.se
Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden


======================================================================= 17 ===
Date:    28 Mar 92 01:05:51 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: why modula3?

In article <mathew.701730666@henry> mathew@elroy.jpl.nasa.gov (Mathew Yeates) w
rites:
>While I'm at it......

>I'm interested in the relative advantages and disadvantages of
>C++ versus Modula3. I'm an applications programmer so my concern
>is not with the aesthetics of the language. Rather, I want
>something thats going to help me quickly write applications.


Advantages of C++:

Everyone else is doing it.
It looks a lot like C, so if you already know C, you should be
   somewhat happy for a little while.
It takes fewer keystrokes to type in your programs.
It has multiple inheritance. 
It has templates.
It has exception handling.
It has operator overloading.


Disadvantages of C++:

It is easier to write programs than it is to read them.
No garbage collection (yes, I know I can implement a garbage
  collection class.  I'm not interested in Turing-equivalence.)
No thread support.
No run-time type system (yet).
I haven't found a use for multiple inheritance in 2 years of
  programming in C++.
Templates are not widely implemented (yet).
Exception handling is not widely implemented (yet), and
  asynchronous exceptions are not supported.  Use of longjmp
  is also banned.
C++ lacks a clean split between interface and implementation;
  all else being equal, this makes it more difficult to write
  tools to manipulate programs.
Many of the recent extensions don't mesh well with the rest
  of the language (for example, template syntax).


Advantages of Modula-3:

Programs tend to be more readable.
It has garbage collection.
It has threads.
It has exception handling.
It has generic modules.
It has a run-time type system.
It has checking for array accesses and base-to-derived type
   conversions.
It has nested functions.
It is pretty easy to write tools to manipulate Modula-3 programs.
Opaque supertypes allow you to avoid gratuitous recompilations.
Nifty tools are available now (e.g., pickling).

Disadvantages of Modula-3:

Insufficient bandwagon.
VERBOSE UPPERCASE IDENTIFIERS.
It lacks multiple inheritance.

I think that's a not-too-biased comparison.  My opinion (removing all
pretense of objectivity) is that C++ is one of the worst languages
I've ever come across.  It is *possible* to write good code in C++,
but it is *easy* to write terrible code in C++, and features already
present in the language will make it difficult to support truly useful
features like garbage collection.  Many of the techniques proposed for
doing "automatic" garbage collection in C++ (e.g., reference counting)
fall to pieces in a multi-threaded world.  I'm not too fond of the
exception handling model either -- no asynchronous exceptions (easy to
implement, but not quite what people want in practice), but the
dispatcher must implement "typecase" for multiple-inheritance class
types.  This is rarely useful (in full MI generality) but is a pain to
implement.  Multiple inheritance seems to be the source of many
implementation problems, actually.

David Chase
Sun


======================================================================= 18 ===
Date:    27 Mar 92 15:40:16 GMT
From:    jm13@GTE.COM (Joe Morrison)
Subject: Pkl.Write generates ASSERT failure (M3 2.03 on sparcstation)

The following program (taken from pg. 81 of SPwM3) compiles without
error on our system, but when executed, produces the error message
shown below.  Apart from this problem with pickles, our M3
installation seems fine (we've written, compiled and tested plenty of
pickle-free code...)

Is this any kind of known problem? Might it be fixed in 2.04?
Thanks in advance...

        Joe Morrison
--
GTE Laboratories Incorporated         Email: jmorrison@gte.com
40 Sylvan Road                        Phone: (617) 466-2614
Waltham, Massachusetts, 02254

--------------------------------------------------
MODULE P1 EXPORTS Main;
IMPORT Pkl, FileStream, Wr, Thread;
TYPE T = REF RECORD val: INTEGER END;
VAR
    r := NEW (T, val:=6);
    wr := FileStream.OpenWrite ("A.pickle");
<*FATAL Wr.Failure, Pkl.Error, Thread.Alerted *>
BEGIN
    Pkl.Write (r, wr);
    Wr.Close (wr);
END P1.
--------------------------------------------------

When executed:
--------------------------------------------------
*** runtime error: ASSERT failed ***
 
Quit (core dumped)
--------------------------------------------------

Here is the stack backtrace:
(gdb) where
#0  0xf775c120 in ?? ()
#1  0x10dfc in RTMisc__FatalError (msgA=(char *) 0x56634 , msgB=(char *) 0x0, m
sgC=(char *) 0x0) (RTMisc.m3 line 95)
#2  0x10f44 in RTMisc__AssertFault () (RTMisc.m3 line 121)
#3  0x16ee0 in RTTypeFP__Init () (RTTypeFP.m3 line 176)
#4  0x15f6c in RTTypeFP__ToFingerprint (tc=108, _return=(struct _array_tbd06c37
7 *) 0xf7fff91c) (RTTypeFP.m3 line 55)
#5  0x381d8 in PklWrite__WriteTypes (s=(_t8feaadfc) 0x65a90) (PklWrite.m3 line 
303)
#6  0x35608 in Pkl__Write (r=(char *) 0x65a58 , wr=(char *) 0x65a60 , lg2maxObj
s=14) (PklWrite.m3 line 96)
#7  0x242c in _init_ () (p1.m3 line 14)
#8  0x174a0 in RTMain__Run () (RTMain.m3 line 60)
#9  0x22f8 in main (argc=1, argv=(_td88ff127) 0xf7fffbd4, envp=(_td88ff127) 0xf
7fffbdc) (_m3main.c line 1473)
(gdb) 


======================================================================= 19 ===
Date:    Thu, 2 Apr 92 12:52:03 PST
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: why modula3?

In article <o64H0pya6@cs.psu.edu>, melling@cs.psu.edu (Michael D Mellinger) wri
tes:
> 
> In article <kt7hjfINNn80@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David C
hase) writes:
> 
>    VERBOSE UPPERCASE IDENTIFIERS.
> 
> Will this be "fixed"?  My fingers bother me enough as it is without
> having to reach for the shift key all the time.
> 
> -Mike
> 

I suggest you use the gnuemacs modula-3 mode in which case you will not
have to type reserved words very often.

Mick Jordan


======================================================================= 20 ===
Date:    28 Mar 92 22:50:48 GMT
From:    nr@dynamic (Norman Ramsey)
Subject: Re: Scan.i3 suggestions


I second Sam's comments about the Scan interface.  In fact, I even
seem to recall complaining about it earlier.  I'm willing to write the
new implementation if Sam will test it and the SRC guys will install
it.


======================================================================= 21 ===
Date:    Thu, 2 Apr 92 13:50:03 PST
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: terminology wanted

In article <1992Mar28.230249.2165@newross.Princeton.EDU>, nr@cs.Princeton.EDU w
rites:
> Do we have a standard word for a type that is never instantiated
> directly (only subtypes are actually instantiated)?  I've been using
> ``class,'' but I would happily use some other word that people would
> understand better.
> 

I use "class" with the same interpretation in the Modula-3 AST and am quite
happy with it.

Mick


======================================================================= 22 ===
Date:    27 Mar 92 02:33:54 GMT
From:    pereira@alice.att.com (Fernando Pereira)
Subject: Re: Checking Subtype relationships.

In article <kt4622INNoaj@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Cha
se) writes:
>I heard that there was some paper (in TOPLAS, I think, last year or
>two) on efficiently performing lattice operations that might be of
>some help here.  That's all I know for now -- I have't had time to get
>to it.
Indeed. I don't have the reference and title here, but the authors are
Hassan Ait-Kaci, Robert Boyer, Pat Lincoln and Roger Nasr (or some subset
thereof).

Fernando Pereira
AT&T Bell Laboratories, Murray Hill


======================================================================= 23 ===
Date:    29 Mar 92 16:56:22 GMT
From:    diwan@cs.umass.edu (Amer Diwan)
Subject: Re: terminology wanted

>>>>> On 28 Mar 92 23:02:49 GMT, nr@cs.Princeton.EDU said:
nr> Do we have a standard word for a type that is never instantiated
nr> directly (only subtypes are actually instantiated)?  I've been using
nr> ``class,'' but I would happily use some other word that people would
nr> understand better.

C++ uses the term "Abstract Class" for such classes.  These are classes that
don't give have an implementation for one or more methods.  These classes can
never be instantiated, only inherited from.  Eiffel uses the term "Deferred
Class", which IMHO is a much more descriptive term.
    Amer
--
------------------------------------------------------------------------------
			Amer Diwan
			Department of Computer Science
			University of Massachusetts
			Amherst, MA 01003
			(413) 545-0256  	diwan@cs.umass.edu
------------------------------------------------------------------------------


======================================================================= 24 ===
Date:    28 Mar 92 23:02:49 GMT
From:    nr@cs.Princeton.EDU
Subject: terminology wanted

Do we have a standard word for a type that is never instantiated
directly (only subtypes are actually instantiated)?  I've been using
``class,'' but I would happily use some other word that people would
understand better.

-- 
Norman Ramsey
nr@princeton.edu


======================================================================= 25 ===
Date:    Fri, 27 Mar 1992 23:32:20 GMT
From:    schwartz@roke.cs.psu.edu (Scott Schwartz)
Subject: Re: Problems on a SparcStation

mathew@elroy.jpl.nasa.gov (Mathew Yeates) writes:
   Anyone with any experience using the SRC Modula 3 on a Sun SparcStation?

2.03 works for me.  I'm running 4.1.1 with MIT's X server.


======================================================================= 26 ===
Date:    29 Mar 92 19:30:40 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: terminology wanted

I think "abstract" and "deferred" are reasonable options, and the abstract
class concept comes from Smalltalk, or even earlier. Personally, I think of it
this way: an abstract type is one that requires various representation
(fields) and/or methods to be implemented in each subtype, and may offer some
fields and methods itself, and those methods may rely on the subtype methods.
I use the term "deferred methods" for the subtype methods that must be
supplied. This all works nicely with M3's allowing an object type not to
specify the default binding for a method.
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================= 27 ===
Date:    Fri, 27 Mar 1992 18:42:00 GMT
From:    schwartz@roke.cs.psu.edu (Scott Schwartz)
Subject: make vs m3


In the trestle/apps directory, I type

; touch Monster.m3
; m3make
; 

The m3makefile doesn't correctly encode the dependencies between
files, so nothing is recompiled.

M3 and make are at odds, to an extent, since m3 will decide for itself
when to regenerate certain files.  But if you want to use make to
control recompilation, you need to give it accurate information.

Putting	`pgm: pgm.m3 sources; ...'' in the #define for test_pgm more
or less fixes it in this case.



======================================================================= 28 ===
Date:    28 Mar 92 15:32:39 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Scan.i3 suggestions

>>>>> On 27 Mar 92 22:06:12 GMT, harbison@bert.pinecreek.com (Sam Harbison)
>>>>> said:

Sam> Also, Scan.Real/Scan.LongReal treat the exception Convert.Failed as a
Sam> fatal error. I don't see any reason not to turn that exception into
Sam> Scan.BadFormat.

Well, it might be useful to distinguish a legally formatted number that cannot
be represented on the machine (overflow) from a badly formatted number. I tend
to agree that there is no reason why such errors should be fatal; I'd be
inclined to report tham as distinct exceptions (Scan.BadFormat,
Scan.ConversionFailed) and let the programmer do with them what she will ....
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================= 29 ===
Date:    29 Mar 92 12:55:01 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: Problems on a SparcStation


Mathew Yeates writes:
> Anyone with any experience using the SRC Modula 3 on a Sun
> SparcStation? I'm a C++ refugee checking out modula3 and know
> very little about the language. However, I installed the SRC
> compiler and tried to run their demos. Heres what happened.
We have SRC-m3 running on SPARC SLC's and a SUN 4/something server.

> Solitaire crashes my window manager (olwm).
Works fine.

> Tetris dumped core. I traced the problem to a bad return of
> Uutmp.getlogin in Main.m3. I fixed the problem by setting the
> environment variable TETRIS so the above function would not be
> called. After this it worked okay.
Haven't tried tetris for version 2. version 1.6 worked, but I didn't keep it.

> How do you use dbx on this stuff. I compiled with -keep so I
> would have the c files still around but dbx complains about
> not being able to find the files(actually, its looking for
> foo_m.c instead of foo.mc)
Those are symbolic links generated and removed by m3...

> This is SunOs 4.1.2, openwindows 3.0, olwm. Also, I had to link
> the X libs statically by compiling with -X2@-Bstatic@ because
> Sun's patched loader is a piece of crap.
Ah! We run SunOS 4.1 also, but I have a HP 700/RX X terminal,
with tvtwm and _real_ X libraries. The Openwindows libraries are
notoriously different... :-(

Greetings, Bert
-- 
#include <std/disclaimer>

  Bert Laverman,  Dept. of Computing Science, Groningen University
  Friendly mail to: laverman@cs.rug.nl      The rest to: /dev/null


======================================================================= 30 ===
Date:    Thu, 2 Apr 92 14:04:26 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: make vs m3

In article <2w9Hk6na6@cs.psu.edu>, schwartz@roke.cs.psu.edu (Scott Schwartz) wr
ites:
> 
> In the trestle/apps directory, I type
> 
> ; touch Monster.m3
> ; m3make
> ; 
> 
> The m3makefile doesn't correctly encode the dependencies between
> files, so nothing is recompiled.
> 
> M3 and make are at odds, to an extent, since m3 will decide for itself
> when to regenerate certain files.  But if you want to use make to
> control recompilation, you need to give it accurate information.
> 
> Putting	`pgm: pgm.m3 sources; ...'' in the #define for test_pgm more
> or less fixes it in this case.

Actually, the right thing is to have 'pgm: FRC; ...'.  We decided that
make was not good enough to do the dependency checking, and that m3
should do all of that work (with the -make option, it will do a fine
analyzis; without, it will simply recompile everything).  The trouble
in this case is that m3 is not invoked.  I have fixed our version.

Thanks for the report,
Eric.


======================================================================= 31 ===
Date:    Fri, 3 Apr 92 01:43:18 MST
From:    ggf@saifr00.cfsat.honeywell.com (Gary Frederick)
Subject: Porting Modula-3 to VMS 

I am evaluating support for POSIX under VMS.  I was
thinking of ways of testing how much trouble it was
to get 'UNIX' code to work on VMS using POSIX when
I had the idea of trying to port Modula-3.  That
should give POSIX a good work out, or point out
areas that will cause problems.

Is it nuts to try to port Modula-3 to VMS using the
POSIX support?

If it is worth trying, which version of the source
is the best to use as a starting point?

I have access to a Sun 4 and limited access to a
Decstation.  Which would be a better host for a
cross to VMS?

Gary Frederick
ggf@saifr00.cfsat.honeywell.com



======================================================================= 32 ===
Date:    30 Mar 92 10:46:26 GMT
From:    hendriks@serc.nl (Paul Hendriks)
Subject: ECOOP'92: Workshop Program

************************************************************************
*                                                                      *
*    EEEEEEE   CCCCCC   OOOOO    OOOOO   PPPPPP  ''  99999    2222     *
*    E        C        O     O  O     O  P     P '' 9     9  2    2    *
*    E        C        O     O  O     O  P     P    9     9       2    *
*    EEEE     C        O     O  O     O  PPPPPP      999999      2     *
*    E        C        O     O  O     O  P                9     2      *
*    E        C        O     O  O     O  P                9   2        *
*    EEEEEEE   CCCCCC   OOOOO    OOOOO   P           99999   222222    *
*                                                                      *
************************************************************************

    The sixth European Conference on Object Oriented Programming
    ------------------------------------------------------------

                        29 June - July 3, 1992
                       Utrecht, the Netherlands

Note: This posting does not include the complete conference program for
  ECOOP'92, nor does it contain registration information. This can be
  found in a separate posting. If you would like to receive the
  complete preliminary program, please contact:
      Gert Florijn
      Software Engineering Research Centre - SERC
      P.O. Box 424
      3500 AK  Utrecht
      The Netherlands
      E-mail: ecoop92@serc.nl
      Phone: +31 30 322640
      Fax:   +31 30 341249

************************************************************************
*                                                                      *
*     WORKSHOP PROGRAM                                                 *
*                                                                      *
************************************************************************

------------------------------------------------------------------------
-     Monday, June 29, 1992                                            -
------------------------------------------------------------------------

 8.00 - 18.00: REGISTRATION
 9.00 - 17.00: WORKSHOPS:
  - W1: Markku Sakkinen (University of Jyvaskyla, Finland)
    "Multiple Inheritance and Multiple Subtyping"
  - W2: Yolande Berbers (K.U.Leuven, Belgium) and Peter Dickman (ERCIM,
    currently at INRIA Rocquencourt, France)
    "Dynamic Object Placement and Load Balancing in Parallel and
     Distributed Systems"
  - W3: Matti Rossi (University of Jyvaskyla, Finland)
    "CASE for Object-Oriented methods"
  - W4: Pieter Jan Morssink (Leiden University, the Netherlands) and
    Jan Overbeck (Vienna Technical University, Austria)
    "Second European Workshop for Doctoral Students in Object-Oriented
     Systems"

------------------------------------------------------------------------
-     Tuesday, June 30, 1992                                           -
------------------------------------------------------------------------

 8.00 - 18.00: REGISTRATION
 9.00 - 17.00: WORKSHOPS:
  - W5: Brian Foote (University of Illinois, USA), Pierre Cointe
    (Universite Pierre et Marie Curie, France), Mamdouh Ibrahim
    (EDS/Artificial Intelligence Services, USA), Gregor Kiczales (Xerox
    Palo Alto Research Center, USA), and Satoshi Matsuoka (University
    of Tokyo, Japan)
    "Object-Oriented Reflection and Meta-level Architectures"
  - W6: Michael Papathomas and Oscar Nierstrasz (University of Geneva,
    Switzerland)
    "Object-Based Concurrency and Reuse"
  - W7: Dennis de Champeaux (Hewlett-Packard Labs, USA)
    "The Object-Oriented Software Development Process"

************************************************************************
*                                                                      *
*     DESCRIPTIONS                                                     *
*                                                                      *
************************************************************************

------------------------------------------------------------------------
-     Workshop W1: Multiple Inheritance and Multiple Subtyping         -
------------------------------------------------------------------------

Organiser: Markku Sakkinen (University of Jyvaskyla, Finland)

Time: Monday, June 29: 9.00 - 17.00.

Who should attend:
  Researchers interested in analysing and developing multiple
  inheritance and related concepts and implementing them in
  object-oriented systems, or strongly arguing that multiple
  inheritance should be avoided.

Topic:
  There seems to be a scale of different attitudes toward multiple
  inheritance.
  - There is no need for it; at least nobody has presented programming
    problems that could not be solved adequately with single
    inheritance.
  - Its disadvantages are greater than its benefits, so it should be
    avoided.
  - It is useful in principle, but its problems have not been
    satisfactorily solved (yet).
  - It is a good thing and there are conceptually sound approaches, but
    (perhaps) they cannot be implemented (at least not efficiently
    enough).
  - It can be implemented in a manner that is satisfactory both
    conceptually and pragmatically.
  - It is (almost) necessary for a good object-oriented language.
  All viewpoints supported by good arguments are welcome.

  There have been some discussions at earlier ECOOPs and elsewhere
  about the relationship of inheritance and subtyping (or conformance).
  Some people advocate a complete separation of these properties, while
  others think that they should largely coincide. Does multiple
  inheritance have any effect on this issue? Are the different
  approaches to multiple inheritance (e.g., "mixin" inheritance) in the
  end equally powerful and useful, or are there essential differences?
  Does multiple inheritance cause additional difficulties for
  concurrent objects?

How to apply:
  Inform the organiser preferably before 4 May. Short position papers
  or abstracts of current research (say 2 or 3 pages of A4) are
  solicited, but "passive" applicants can also be accepted unless the
  attendance would become too large for a convenient workshop.
  Notification of acceptance will be sent by 18 May, and the
  preliminary programme in reasonable time before the conference.

  Alternatives for sending the paper:
  - good quality print by mail;
  - PostScript by e-mail;
  - troff source text (possible macros: -me, -ms, -mm; indicate any
    required preprocessors) by e-mail;
  - TeX or LaTeX source text by e-mail;
  - Fax (not recommended because of print quality);
  - other formats by agreement with the organiser.

  Accepted papers and abstracts will at least be distributed to
  workshop participants. They might also be published (without further
  editing) as a department report; any applicant who does not want
  his/her paper to be included in such a collection should clearly say
  so.

Contact:
  Markku Sakkinen
  Department of Computer Science and Information Systems
  University of Jyvaskyla
  PL 35
  SF-40351 Jyvaskyla
  Finland
  Internet: sakkinen@jytko.jyu.fi
  Bitnet/EARN: SAKKINEN@FINJYU
  Phone: +358 41 603016
  Fax:   +358 41 603611

------------------------------------------------------------------------
-     Workshop W2: Dynamic Object Placement and Load Balancing in      -
-       Parallel and Distributed Systems                               -
------------------------------------------------------------------------

Organisers:
  Yolande Berbers (K.U.Leuven, Belgium) and
  Peter Dickman (ERCIM, currently at INRIA Rocquencourt, France)

Time: Monday, June 29: 9.00 - 17.00.

Topic:
  Recent years have seen the emergence of distributed and parallel
  systems in which "objects" play a central role. Many of these systems
  attempt to achieve (some form of) load balancing through dynamic
  object placement, dynamic object replication, and/or object
  migration.

  This workshop will provide a forum for the presentation and
  discussion of ideas, research proposals, new developments,
  experiences, and research results in this area.

  Relevant subjects of interest include, but are not limited to:
  - object-oriented systems with dynamic load balancing,
  - object models suited for dynamic (re)placement,
  - object migration mechanisms,
  - dynamic object replication mechanisms,
  - techniques for object and node load measurement and evaluation,
  - strategies for load information exchange between nodes,
  - detection of dynamic interdependencies and use of this information,
  - load balancing strategies,
  - scalable mechanisms and strategies.

Workshop Committee:
  - Yolande Berbers, yolande@cs.kuleuven.ac.be
  - Peter Dickman, dickman@corto.inria.fr

How to apply:
  Each attendee is requested to submit a position paper of 3 to 6
  pages. Please send your submission both by surface mail (three
  copies) and also electronically in Postscript, troff, TeX or LaTeX
  format to Yolande Berbers at the address mentioned below.

  Please ensure that the electronic submission can be printed without
  alteration on both European (A4) and US paper sizes. Accepted
  submissions will be made available to attendees, by electronic means,
  before the workshop.

  The deadline for submission is Monday, March 16th, 1992. Notification
  of acceptance will be sent out by Wednesday, April 29th, 1992. If
  this early date will cause you problems please contact one of the
  committee by e-mail, extensions permitting submissions to be accepted
  until late April may be granted in exceptional cases.

  The committee will group the submissions into relevant categories and
  select both long and short presentations. Ample time will be reserved
  for discussions.

Contact:
  Yolande Berbers
  K.U.Leuven
  Department of Computer Science
  Celestijnenlaan 200 A
  B-3001 Leuven
  Belgium
  E-mail: yolande@cs.kuleuven.ac.be 
  Phone: +32 16 201015
  Fax:   +32 16 205308

------------------------------------------------------------------------
-     Workshop W3: CASE for Object-Oriented Methods                    -
------------------------------------------------------------------------

Organiser: Matti Rossi (University of Jyvaskyla, Finland)

Who should attend:
  Researchers and developers of object-oriented methods and tools.

Time: Monday, June 29: 9.00 - 17.00.

Topic:
  Automated tools for object-oriented methods have existed for some
  time now. Various tool builders have presented different solutions to
  incorporate these new methods into CASE tools. Some vendors have
  added a new layer over a traditional ER-based model, whereas others
  have developed new platforms that use object oriented building blocks
  to support the new methods.

  The aim of the workshop is to bring together method and tool
  developers and researchers to discuss the concepts of object-oriented
  methods and how they can be defined or implemented in a CASE tool.
  The requirements for modelling the object-oriented methods (Booch,
  Yourdon, Rumbaugh, etc.) successfully and how they can be applied in
  CASE tools could be discussed. In other words, can we implement the
  new methods with traditional CASE tools (Excelerator etc.); do we
  need new dedicated tools (OOTool); or can we use tools with definable
  meta-models i.e., CASE shells (Paradigm+, VSF etc)? Experiences of
  defining and using different approaches to this problem would be the
  main topic of the workshop. Another topic could be, how to add
  measurement and project management features for an object-oriented
  method into a CASE tool. Also of interest are the ways to enhance the
  methods by the use of automated tools (for example the reuse of
  object-oriented specifications).

How to apply:
  Inform the organiser no later than 4th of May. Notification of
  acceptance will be sent by 20th of May, and the preliminary programme
  a few weeks before the conference. The main focus should be on short
  papers (2-5 pages) describing the implementation and use of
  object-oriented methods in various CASE tools. Also papers presenting
  ideas to extract metrics and project management information from
  object-oriented descriptions would be interesting.

  The alternative ways of sending your contribution are:
  - good quality print by mail;
  - uuencoded PostScript by e-mail;
  - uuencoded RTF by e-mail;
  - MS Word for Windows file on disk.
  Accepted papers and abstracts will be available for workshop
  participants and they will probably be published as a department
  report.

Contact:
  Matti Rossi
  Department of Computer Science and Information Systems
  University of Jyvaskyla
  PL 35
  SF-40351 Jyvaskyla
  Finland
  E-mail: Matti.Rossi@jyu.fi
  Phone: +358 41 603030

------------------------------------------------------------------------
-     Workshop W4: Second European Workshop for Doctoral Students in   -
-       Object-Oriented Systems                                        -
------------------------------------------------------------------------

Organisers:
  Pieter Jan Morssink (Leiden University, the Netherlands) and
  Jan Overbeck (Vienna Technical University, Austria)

Time: Monday, June 29: 9.00 - 17.00.

Topic:
  This one-day-workshop is intended to enhance the personal and
  professional development of about 35 PhD-level students who are
  working in the field of object-oriented systems. It shall enable them
  to meet, to discuss their research, and to develop their working
  skills. It will also serve as the continuation and enlargement of a
  European network of PhD students in object-oriented systems, which
  has been initiated at the "First Workshop for Doctoral Students in
  Object-Oriented Systems" held in conjunction with ECOOP'91 in
  Geneva/Switzerland. This network enables the participants to exchange
  information, give help and support, and to give wider access to
  resources and methods (Although the network is set up and based in
  Europe, non-European participants are welcome).

  The workshop is intended to focus on both technical exchange of ideas
  among the participants and a non-technical discussion of issues of
  particular interest to PhD students. Last year the workshop focussed
  on the writing of papers. This year the topic of writing a PhD thesis
  will be discussed. This discussion will be supported by a talk of an
  experienced researcher in the field of object-oriented systems. For
  this and other topics, senior facilitators will be invited.

  The general form of the workshop shall be interactive, focussing on
  active work in small groups and in the whole group. The workshop
  shall be divided into three major parts:
  - mutual introduction
  - technical program
  - non-technical program
  Each of the parts will be covered in one or more sessions over the
  day. The results shall be covered in a report covering the technical
  as well as the non-technical results of the day. Parts of the report
  will be written by the participants during the workshop. The report
  will either be published in conjunction with other ECOOP'92 workshop
  publications or, if this is not possible, as a distinct publication.

How to apply:
  Attendants of the workshop are asked to either send a one-page
  abstract of their dissertation research (first-time-attendants) or a
  technical position statement of particular interest to PhD students
  in object-oriented systems (second-time-attendants). The abstracts
  should be submitted electronically before April 30 to one of the two
  e-mail addresses given below. They will be distributed electronically
  to the workshop participants prior to the workshop. They will serve
  as the basis for the technical discussion at the workshop.

Contacts:
  Pieter Jan Morssink
  Department of Computer Science
  Leiden University
  Niels Bohrweg 1
  P.O. Box 9512
  2300 RA Leiden
  The Netherlands
  E-mail: morssink@rulcri.leidenuniv.nl
  Phone: (+31)-71-277101

  Jan Overbeck
  Vienna Technical University
  Institute for Information Systems
  Paniglgasse 16
  A-1040 Vienna
  Austria
  E-mail: overbeck@vexpert.dbai.tuwien.ac.at
  Phone: (+43)-1-58801-6141
  Fax:   (+43)-1-505-5304

------------------------------------------------------------------------
-     Workshop W5: Object-Oriented Reflection and Meta-level           -
-       Architectures                                                  -
------------------------------------------------------------------------

Organisers:
  Brian Foote (University of Illinois, USA),
  Pierre Cointe (Universite Pierre et Marie Curie, France),
  Mamdouh Ibrahim (EDS/Artificial Intelligence Services, USA),
  Gregor Kiczales (Xerox Palo Alto Research Center, USA), and
  Satoshi Matsuoka (University of Tokyo, Japan)

Time: Tuesday, June 30: 9.00 - 17.00.

Topic:
  The marriage of reflection with object-oriented programming and
  design techniques holds out the promise of dramatically changing the
  way that we think about, organise, implement, and use programming
  languages and systems. A programming language with an object-oriented
  meta-level architecture is one in which programs are themselves
  constructed out of first-class objects. A reflective object-oriented
  language allows a running program to look at or change the objects
  out of which it is built. Reflection can extend the reach of a
  programming system inward into the definition of the language itself,
  downward into its implementation, and outward into realms currently
  considered the provinces of operating systems, programming
  environments and database systems.

  Object-oriented reflective architectures allow issues that have
  heretofore been dealt with in ad hoc, extra-linguistic fashions, such
  as debugging and tracing, to be dealt with in a consistent fashion.
  Issues such as distributed computation, concurrency and object
  persistence are among those that be addressed using reflective
  approaches as well.

  This workshop is the third in a series that began at ECOOP/OOPSLA'90
  in Ottawa, and continued at OOPSLA'91 in Phoenix. It is intended to
  provide researchers who are interested in reflection with a forum in
  which they can present recent findings, debate outstanding issues in
  the area, and explore new ideas. The workshop will be organised into
  several sessions, each of which will be comprised of invited
  presentations and moderated discussions. Likely session topics
  include:
  - Reflective theory, definitions and terminology
  - The design and architecture of reflective languages and systems
  - The efficient implementation of reflective facilities
  - Reflection in concurrent and distributed systems
  - Applications and implications of reflective approaches

Workshop Committee:
  Questions concerning the workshop may be directed to any of the
  members of the workshop committee:
  - Brian Foote, foote@cs.uiuc.edu
  - Pierre Cointe, pc@rxf.ibp.fr
  - Mamdouh Ibrahim, mhi@ais.tsd.eds.com
  - Gregor Kiczales, gregor@parc.xerox.com
  - Satoshi Matsuoka, matsu@is.s.u-tokyo.ac.jp

How to apply:
  Potential participants are asked to submit a position paper of no
  more than 5 (single-spaced) pages. These papers may be extended
  abstracts of original work in progress, or position statements that
  outline the author's opinions on one or more issues in the area. We
  intend to distribute copies of all accepted position papers to all
  participants prior to the workshop. We will invite a number of
  authors to present their position papers at the workshop.

  Position papers should be submitted by Friday, 17 April 1992.
  Notifications of acceptance will be sent before Friday, 15 May 1992.

  Please send 5 copies and an electronic copy of your position paper
  to:

Contact:
  Brian Foote
  681 Psychology Building
  University of Illinois
  603 E. Daniel
  Champaign, IL  61820
  USA
  E-mail: reflection-workshop@p300.cpl.uiuc.edu

------------------------------------------------------------------------
-     Workshop W6: Object-Based Concurrency and Reuse                  -
------------------------------------------------------------------------

Organisers:
  Michael Papathomas and
  Oscar Nierstrasz (University of Geneva, Switzerland)

Time: Tuesday, June 30: 9.00 - 17.00.

Topic:
  The purpose of this one-day workshop is to identify the difficulties
  in taking advantage of the reuse potential of object-oriented
  programming techniques in developing concurrent software, to bring
  together and examine potential solutions, and to identify open
  problems and promising research directions.

How to apply:
  Prospective participants are invited to submit position papers
  stating how their research addresses the following questions:
  - To what extent is reuse of concurrent software a language design
    issue? What, if any, are the limitations, with respect to reuse, of
    library-based concurrency extensions to existing languages?
  - What are the most important language design issues in combining
    concurrency and object-oriented features? What is the relative
    importance of inheritance? Which specific language features will
    ease the development of reusable frameworks for concurrent
    object-oriented applications?
  - What criteria should be used to evaluate language features with
    respect to reuse of concurrent software? Are example problems
    satisfactory? What would constitute a canonical list of problems?
  - Are formal semantic models important or relevant to concurrent
    object-oriented reuse? If yes, what specific issues should they
    address?
  Submissions should be made by e-mail, if possible, and should include
  the author's full coordinates, including e-mail address. Submissions
  should not exceed 6 formatted pages and should be received before May
  15 at the address given below. Standard LaTeX is preferred, though
  plain ASCII files, troff, Framemaker MIF files or PostScript will
  also be accepted.

Contact:
  Michael Papathomas
  Centre Universitaire d'Informatique
  12 rue du Lac
  CH-1207 Geneva
  Switzerland
  E-mail: michael@cui.unige.ch

------------------------------------------------------------------------
-     Workshop W7: The Object-Oriented Software Development Process    -
------------------------------------------------------------------------

Organiser: Dennis de Champeaux (Hewlett-Packard Labs, USA)

Time: Tuesday, June 30: 9.00 - 17.00.

Topic:
  Software development is an expensive, labor intensive complex
  process. Carnegie-Mellon's Software Engineering Institute has defined
  development maturity levels ranging from "chaotic happy hacking" at
  level 1 to the application of a systemic process with continuous self
  improvement at level 5. Most software development organisations are
  still below level 2.

  Finding ways to push the SEI maturity level up for an organisation is
  highly desirable. The object-oriented paradigm promises to facilitate
  software development by several avenues. On the one hand development
  occurs by virtue of encapsulation which, among other advantages,
  should enhance re-usability. On the other hand development proceeds
  by the "naturalness" of the object notion which facilitates moving
  smoothly from requirements via analysis and design to an
  implementation. In addition, we suspect that object-oriented analysis
  yields qualitatively better models than structured analysis
  modelling. This should result in a deeper understanding of the
  requirements of systems and hence will reveal fatal misunderstandings
  earlier.

  At the same time, object-oriented methodologists are as yet, fairly
  uncommitted as to how to do object-oriented software development
  beyond denouncing the waterfall model and embracing the spiral model
  or relying upon muddled models that require an arbitrary number of
  backtrackings and iterations. The latter models are perhaps
  attractive from a software engineers perspective but are highly
  unattractive from a planning and management perspective.

  It would be quite helpful for the object-oriented paradigm to be able
  to outline a generic scenario/cook book/pseudo algorithm that would
  guide the object-oriented development process. It is quite plausible
  that the commitment to the object-oriented paradigm will allow
  identification of development sub-phases and sub-activities in the
  classic trio: analysis/design/implementation.

How to apply:
  In general, we invite contributions to this workshop that either:
  - contain reasoned proposals for the procedural dimension of
    (segments of) the object-oriented life cycle, and/or
  - describe an object-oriented development process on the basis of
    experience.
  Submissions should be in plain ASCII or vanilla LaTeX source and
  should contain less than 10K bytes. They should be submitted before
  May 15 to the following address.

Contact:
  Dennis de Champeaux
  Hewlett-Packard Labs, MS 1U-14
  P.O. Box 10490
  Palo Alto, CA 94303-0969
  USA
  E-mail: champeaux@hplabs.hp.com
  Phone: USA-(415) 857 6674
  Fax:   USA-(415) 857 8526


======================================================================= 33 ===
Date:    30 Mar 92 10:45:43 GMT
From:    hendriks@serc.nl (Paul Hendriks)
Subject: ECOOP'92: Tutorial Program

************************************************************************
*                                                                      *
*    EEEEEEE   CCCCCC   OOOOO    OOOOO   PPPPPP  ''  99999    2222     *
*    E        C        O     O  O     O  P     P '' 9     9  2    2    *
*    E        C        O     O  O     O  P     P    9     9       2    *
*    EEEE     C        O     O  O     O  PPPPPP      999999      2     *
*    E        C        O     O  O     O  P                9     2      *
*    E        C        O     O  O     O  P                9   2        *
*    EEEEEEE   CCCCCC   OOOOO    OOOOO   P           99999   222222    *
*                                                                      *
************************************************************************

    The sixth European Conference on Object Oriented Programming
    ------------------------------------------------------------

                        29 June - July 3, 1992
                       Utrecht, the Netherlands

Note: This posting does not include the complete conference program for
  ECOOP'92, nor does it contain registration information. This can be
  found in a separate posting. If you would like to receive the
  complete preliminary program, please contact:
      Gert Florijn
      Software Engineering Research Centre - SERC
      P.O. Box 424
      3500 AK  Utrecht
      The Netherlands
      E-mail: ecoop92@serc.nl
      Phone: +31 30 322640
      Fax:   +31 30 341249

************************************************************************
*                                                                      *
*     TUTORIAL PROGRAM                                                 *
*                                                                      *
************************************************************************

------------------------------------------------------------------------
-     Monday, June 29, 1992                                            -
------------------------------------------------------------------------

 8.00 - 18.00: REGISTRATION
 9.00 - 17.00: FULL-DAY TUTORIALS:
  - T1: Jean-Pierre Briot (LITP, France)
    "Object-Oriented Concurrent Programming"
  - T2: Michael Blaha and Frederick Eddy (GE Corporate Research &
    Development, USA)
    "Object-Oriented Modelling and Design"
 9.00 - 12.30: HALF-DAY TUTORIAL:
  - T3: Derek Coleman and Patrick Arnold (Hewlett-Packard Laboratories,
    United Kingdom)
    "The Anatomy of an Analysis and Design Method"
14.00 - 17.30: HALF-DAY TUTORIAL:
  - T4: Ray Weedon (Open University, United Kingdom)
    "Introduction to Eiffel"

------------------------------------------------------------------------
-     Tuesday, June 30, 1992                                           -
------------------------------------------------------------------------

 8.00 - 18.00: REGISTRATION
 9.00 - 17.00: FULL-DAY TUTORIALS:
  - T5: Roberto Zicari (Johann Wolfgang Goethe-Universitat, Germany)
    "Object-Oriented Database Management Systems"
  - T6: Stanley Lippman (AT&T Bell Laboratories, USA)
    "Introduction to C++"
  - T7: Karl Lieberherr (Northeastern University, USA)
    "The Demeter Method for Object-Oriented Software Development"
 9.00 - 12.30: HALF-DAY TUTORIAL:
  - T8: Anand Tripathi (University of Minnesota, USA)
    "Object-Oriented Concepts in Operating Systems"
14.00 - 17.30: HALF-DAY TUTORIAL:
  - T9: Urs Holzle (Stanford University, USA)
    "The Self Programming Language"

************************************************************************
*                                                                      *
*     DESCRIPTIONS                                                     *
*                                                                      *
************************************************************************

------------------------------------------------------------------------
-     Tutorial T1: Object-Oriented Concurrent Programming              -
------------------------------------------------------------------------

Instructor: Jean-Pierre Briot (LITP, France)

Time: Monday, June 29: 9.00 - 17.00.

Level: Intermediate to advanced.

Objectives:
  Concurrent programming is one of the key issues in achieving higher
  performance in modern computation. Object-oriented concurrent
  programming (OOCP) is the natural unification of object-oriented and
  concurrent programming. The resulting programming methodology allows
  decomposing large program as a collection of small modules that run
  and interact concurrently and capable in exploiting parallel
  hardware. This tutorial is attempted at introducing basic concepts
  and methodology of object-oriented concurrent programming.

Content:
  We consider that object-oriented concurrent programming is the
  natural generalisation of object-oriented programming. We discuss
  various levels of integration between object-oriented programming and
  concurrency, leading ultimately to the notion of active object which
  unifies object and activity, message passing and synchronisation. We
  selected an object-oriented concurrent programming language, namely
  ConcurrentSmalltalk, based on Smalltalk, in order to describe
  concepts, constructs, methodology and examples. Examples include
  programming with continuations, divide and conquer, pipeline
  strategies. We then shortly discuss implementation of active objects
  in Smalltalk. This implementation is the kernel of a platform, named
  Actalk, used to describe various OOCP models and languages. We will
  survey and compare some of the main OOCP models, with a special focus
  on the Actor computation model. We will conclude by surveying current
  and prospective application fields and research issues. A concise
  bibliography will be provided.

Who should attend:
  This tutorial is organised for those who are familiar with
  object-oriented programming in general and wish to comprehend and
  practically use object-oriented concurrent programming. The tutorial
  covers both a progressive introduction to concepts, a sample of
  program examples, and a survey of current state of the art.

Required previous knowledge:
  Some prior exposure to basic concepts of object-oriented programming
  is advisable. The Smalltalk language will be used as the programming
  language basis, therefore some notion of Smalltalk syntax is
  advisable, although definitely not necessary.

Instructor's profile:
  Jean-Pierre Briot is a researcher working at LITP, Institut Blaise
  Pascal, Paris. He took part in the design of several OOCP systems and
  applications to computer music and distributed AI. He designed the
  Actalk test bed as a means to model, classify and experiment with
  various OOCP models in some unified programming environment. This
  platform gave rise to various experiments in modelling OOCP languages
  and building distributed AI platforms. Jean-Pierre Briot is
  co-heading an Esprit parallel computing action to develop an OOCP
  programming environment on multiprocessors.

------------------------------------------------------------------------
-     Tutorial T2: Object-Oriented Modelling and Design                -
------------------------------------------------------------------------

Instructors:
  Michael Blaha and
  Frederick Eddy (GE Corporate Research & Development, USA)

Time: Monday, June 29: 9.00 - 17.00.

Objectives:
  The primary objective of this tutorial is to teach an object-oriented
  methodology for developing software systems. Attendees will learn how
  to construct object-oriented models of the real world and then
  transform the models into a design of programming language and/or
  database code.

Content:
  This tutorial will be based on our recent book "Object-Oriented
  Modelling and Design" published by Prentice Hall. This tutorial lies
  at the intersection of object-oriented technology and software
  engineering.

  We stress modelling a system from three distinct but related views:
  object model (static structure), dynamic model (interactions and
  control), and functional model (computation of values). The object
  model serves as the integrating vehicle for combining the information
  for design and implementation.

  The early object-oriented literature emphasized object-oriented
  programming but more recently there has been an appreciation of the
  usefulness of object-oriented concepts for analysis and design. Our
  course will emphasize that coding is the last stage in a process of
  development that includes stating a problem, understanding its
  requirements, designing a solution, and implementing a program in a
  particular language. However, our approach is not strictly linear;
  the seamless transformation from analysis to design facilitates
  incremental development.

Who should attend:
  Persons who would like to learn about an object-oriented software
  development methodology would benefit from this course. The course is
  also intended for persons who have read our book or a comparable
  book: We will be treating several advanced topics and have scheduled
  frequent question breaks.

Required previous knowledge:
  We rate the tutorial as intermediate level. We assume that attendees
  are familiar with object-oriented concepts and have read our book or
  a comparable book.

Instructor's profile:
  Michael Blaha received his D.Sc. in Chemical Engineering from
  Washington University in St. Louis. His dissertation applied database
  technology to chemical engineering applications. Dr. Blaha is a
  computer scientist at GE Corporate R&D and is currently interested in
  database theory, object-oriented concepts and methodologies, and
  unusual engineering database problems. He has published papers in
  various computer science and engineering forums.

  Frederick Eddy has a bachelors degree in physics from Yale
  University, and a masters degree in mathematics from the University
  of Vermont. He has been a Computer Scientist at GE R&D since 1984
  where he has applied the OMT methodology to several projects
  including graphical editors, a language compiler, a production
  planning system, and a prototyping environment. He is active in
  consulting and training for other departments in GE.

------------------------------------------------------------------------
-     Tutorial T3: The Anatomy of an Analysis and Design Method        -
------------------------------------------------------------------------

Instructors:
  Derek Coleman and
  Patrick Arnold (Hewlett-Packard Laboratories, United Kingdom)

Time: Monday, June 29: 9.00 - 12.30.

Level: Intermediate to advanced.

Objectives:
  The practitioner faces a bewildering profusion of OOA/D methods and
  notations. This tutorial provides a framework for understanding and
  evaluating current methods and applies it to three recent methods.
  The tutorial introduces a new best practice method, and its
  underlying rationale, which has been developed for use in
  Hewlett-Packard.

Content:
  The essence of the object-oriented analysis and design task is how to
  systematically map requirements onto the object-oriented
  computational model. Currently there are a large number of methods
  aimed at solving this problem. The methods are all different,
  employing a variety of models, notations and processes.

  The tutorial introduces a set of criteria for evaluating methods from
  the viewpoint of the object-oriented concepts they support, the kinds
  of models and notations they employ and the process steps that they
  recommend. The criteria provides a way of understanding the
  underlying similarities and differences between methods.

  The criteria were developed as part of a programme to assess what
  kind of method should be made available to HP engineers. The work has
  led to the development of a synthesised method which integrates the
  best aspects of existing techniques. The method and its rationale
  will be explained by means of an example. The tutorial ends with a
  brief account of the usefulness of the method in practice.

Who should attend:
  The target audience is software engineers and project managers who
  intend to use or who are interested in object-oriented analysis and
  design methods. The tutorial will also be of interest to research
  workers in the area.

Required previous knowledge:
  It will be assumed that the audience have at least some knowledge of
  software engineering and object-oriented programming. An
  understanding of the basic concepts of an object-oriented method
  would be an advantage.

Instructor's profile:
  Derek Coleman is a Project Manager at HP Laboratories leading a
  research and consultancy team working on object-oriented methods. The
  team have produced a method tailored to the needs of HP engineers and
  are currently evaluating its practical use. Derek is an active member
  of the object-oriented research community and the author of many
  papers on software engineering.

  Patrick Arnold has worked as a researcher in software engineering at
  HP Laboratories for the past five years. He has extensive experience
  of the development of formal specification languages and CASE tools
  to support them. For the past 18 months he has worked on
  object-oriented analysis and design.

  A paper evaluating five object-oriented methods, co-authored by the
  HP Laboratories research team, was published by the JOOP Focus on
  Analysis and Design in October 1991.

------------------------------------------------------------------------
-     Tutorial T4: Introduction to Eiffel                              -
------------------------------------------------------------------------

Instructor: Ray Weedon (Open University, United Kingdom)

Time: Monday, June 29: 14.00 - 17.30.

Level: Introductory.

Objectives:
  The main objective is to demonstrate how the design of Eiffel
  facilitates the development of quality production-level software
  using reusable software components. Participants will be given a
  clear understanding of the features of the design which do this and
  how they compare with those available in other important
  object-oriented languages.

Content:
  The design of Eiffel is based on Abstract Data Types (ADTs). An
  example will be given showing how a simple ADT (formally specified)
  is implemented as an Eiffel class. This will illustrate the use (and
  limitations) of Eiffel assertions. It will also lead to a discussion
  of the uses of assertions (programming by contract, the exception
  mechanism, documentation, debugging, etc.).

  If facilities are available, a demonstration will be given of how the
  example ADT implementation can be used in an actual Eiffel
  application. This will also provide a context in which to discuss the
  compilation of an Eiffel program (including the use of C as an
  intermediate language), debugging, and the browsing facilities
  available in the environment.

  Eiffel supports multiple inheritance, genericity, deferred classes,
  polymorphism and dynamic binding. These will be fully explained using
  examples and compared where appropriate with the facilities offered
  in other object-oriented languages (particularly C++, but also
  Smalltalk and Objective-C).

  Eiffel 's library and persistence mechanism will also be explained.

Who should attend:
  The tutorial should interest all those with experience in software
  development who want to know about the features of an object-oriented
  language and how these can contribute to meeting the goals of
  software development.

  It should also interest those already familiar with object-oriented
  technology who wish to know what features are offered in Eiffel and
  how these differ from those in other important object-oriented
  languages.

Required previous knowledge:
  Some experience in software development will be essential to get the
  most out of the tutorial. Knowledge of another object-oriented
  language is not essential but would be helpful.

Instructor's profile:
  Ray Weedon is a lecturer in Computing Science at the Open University,
  Milton Keynes, United Kingdom. He has been involved in the writing of
  the following 3rd level courses:
  - Data models and databases
  - Programming and programming languages (abstract data types, Prolog,
    and Eiffel)
  He has also written a book on Prolog (with 8 colleagues). His
  research is in Object Algebras.

------------------------------------------------------------------------
-     Tutorial T5: Object-Oriented Database Management Systems         -
------------------------------------------------------------------------

Instructor: Roberto Zicari (Johann Wolfgang Goethe-Universitat, Germany)

Time: Tuesday, June 30: 9.00 - 17.00.

Level: Introductory.

Objectives:
  This tutorial will provide attendees with an introduction to the
  basic concepts of object-oriented databases. The tutorial will
  provide a complete overview of the field: limitations of current
  database management systems, new application requirements, definition
  of an object-oriented database system (OODBMS), survey and comparison
  of existing systems and prototypes.

Content:
  Recently several new database products have been launched based on
  the object-oriented approach. There is no common agreement on what an
  OODBMS is, but many people agree on functionalities that such systems
  must provide. An OODBMS can be defined as a system which is a DBMS
  and is consistent with the object-oriented paradigm. The first part
  of this tutorial will introduce the basic functionalities of an
  Object Oriented Database System, namely:
  - Support for Complex Objects
  - Object Identity
  - Encapsulation
  - Types and Classes
  - Inheritance, Class or Type Hierarchies
  - Overriding, Overloading and Late Binding
  - Computational Completeness
  - Extensibility
  - Persistence
  - Secondary Storage Management
  - Concurrency
  - Recovery
  - Ad Hoc Query Facility
  The second part of the tutorial will review some of the most
  significant OODBMS products/prototypes available on the market;
  namely:
  - GemStone (Servio),
  - Iris (Hewlett-Packard),
  - O2 (O2Technology),
  - Orion (MCC).
  There is a strong debate on what will be the next generation of
  database systems. On one side, new object-oriented startups are
  engaged in a tight competition between them. On the other side, the
  vendors of relational systems are extending their functionalities and
  moving in the direction of the object features. The third and final
  part of the tutorial will compare the two approaches to develop
  database systems: Object-Oriented and Relational, with respect to the
  requirements posed by a variety of complex applications.

Who should attend:
  Software Engineers, Programmers, EDP Managers, Software developers.

Required previous knowledge:
  Attendees should have a basic knowledge of programming languages and
  databases.

Instructor's profile:
  Roberto Zicari is Full Professor of Computer Science (Databases and
  Information Systems) at the Johann Wolfgang Goethe Universitat -
  Frankfurt, Germany. Prior to that, he was Associate Professor of
  Computer Science at the Politecnico di Milano, Italy. He was Visiting
  Scientist at the University of California at Berkeley, USA (1985),
  IBM Almaden Research Laboratory, USA (1986), GIP Altair, France
  (1989),and Visiting Professor at the Ecole Polytechnique Federal de
  Lausanne, Switzerland (1991).

  He received his Doctor of Engineering degree in 1979 from Politecnico
  di Milano. His current research and professional interests are in
  object-oriented database systems and their applicability to complex
  applications. Professor Zicari has published in the major database
  journals and conferences and has extensively lectured both in Europe
  and in North America.

------------------------------------------------------------------------
-     Tutorial T6: Introduction to C++                                 -
------------------------------------------------------------------------

Instructor: Stanley Lippman (AT&T Bell Laboratories, USA)

Time: Tuesday, June 30: 9.00 - 17.00.

Objectives:
  To survey the main features of C++, illustrating both effective and
  ineffective uses. C++ is considered from three perspectives: briefly,
  as a "better" C; as a language supporting abstract data types through
  its class mechanism; and, finally, as a language supporting
  object-oriented programming through inheritance and dynamic binding.

Content:
  A Tour of C++: show the use of an abstract data type, then extend it
    by subtyping, illustrating inheritance and dynamic binding. That
    done, combine subtypes using multiple inheritance, and show how
    shared virtual base classes solve a particular design problem.
    Finally, illustrate how templates allow for the design of generic
    types.
  A Better C: support of strong type checking, function overloading,
    in-line functions, and template functions.
  Abstract Data Types: present a rationale. Show how C++ supports
    abstract data types, public interface, automatic class specific
    memory management, pointer to member functions, operator
    overloading, conversion operators, and class templates.
  Object-Oriented Programming: present a rationale. Show how C++
    supports inheritance. Discussion of subtyping versus inheritance
    and the use of composition. A detailed example illustrating dynamic
    binding, multiple inheritance and the use of virtual base classes
    using templates.

Who should attend:
  The Tutorial is aimed at application and system programmers who
  either have begun to work in C++ or are considering using it.

Required previous knowledge:
  Some knowledge of C is assumed. Knowledge of object-oriented
  programming or data abstraction is not required.

Instructor's profile:
  Stanley Lippman is a member of technical staff of the C++ Software
  Technology Center Laboratory of AT&T Bell Laboratories. He was one of
  the original members of the development team responsible for the AT&T
  C++ compiler, cfront. His book "A C++ Primer", 2nd Edition, published
  by Addison-Wesley, is considered by many to be the standard
  introductory book on C++. He has lectured widely on C++ for both
  novice and advanced users.

------------------------------------------------------------------------
-     Tutorial T7: The Demeter Method for Object-Oriented Software     -
-       Development                                                    -
------------------------------------------------------------------------

Instructor: Karl Lieberherr (Northeastern University, USA)

Time: Tuesday, June 30: 9.00 - 17.00.

Level: Intermediate.

Objectives:
  Mastering a formally defined object model and its mapping to
  programming languages. To learn well tested, yet very novel, design
  and programming techniques for developing object-oriented
  applications. The material is partitioned into easy to learn
  behavioral objectives as outlined in our OOPSLA'89 paper.

Content:
  You will learn a novel and effective approach to object-oriented
  design and programming, called the Demeter Method for object-oriented
  software development. The techniques you learn, such as propagation
  patterns and class optimisation, are programming language independent
  but we show their concrete use with C++ syntax.

  Key features of the Demeter Method are:
  - A simple and concise notation for conceptual modelling which has a
    mathematical foundation.
  - A class calculus for optimising class hierarchies which allows you
    to measure the quality of class hierarchies.
  - Propagation patterns, for describing groups of collaborating
    classes, leading to a remarkable reduction in the length of
    programs. The re-usability of programs is increased significantly.
  - A programming and design guideline, known as the "Law of Demeter"
    which promotes a clear programming style and which helps you
    distinguish good designs from bad designs.
  - A systematic way to develop an application development plan and a
    test plan based on the result of conceptual modelling.
  - A flexible technique to define application-specific objects in a
    declarative style.

Who should attend:
  Analysts, designers, and programmers who want to learn new formal
  methods for object-oriented software engineering. Managers of
  software projects will learn about planning object-oriented
  applications and they will benefit from the elegant and easy to learn
  theoretical foundations taught in this tutorial.

Required previous knowledge:
  Some experience with writing programs in object-oriented languages is
  expected. The programming language dependent part will rely on the
  C++ notation. We will use elementary graph theory (e.g., cycle
  checking, finding a path between two vertices, etc.)

Instructor's profile:
  Karl Lieberherr is the principal designer of the Demeter System. He
  has a Ph.D. from ETH Zurich, Switzerland and he was Assistant
  Professor of Computer Science at Princeton University and a Principal
  Member of Technical Staff at GTE Laboratories, in Waltham, MA. Since
  1985, he is a Professor of Computer Science at Northeastern
  University and since 1990 he is director of the Center for Software
  Sciences. Professor Lieberherr has taught courses on object-oriented
  analysis, design and programming for industry and at Northeastern
  University for 5 years using the Demeter Method presented in this
  course.

  Karl Lieberherr has previously taught for companies such as Data
  General, IBM, Mettler-Toledo, National Technological University (over
  500 attendees), Siemens, both in the US and Europe. He participated
  at several Summer Schools and Symposia on object-oriented technology
  in the Netherlands, Finland and Switzerland and recently presented a
  tutorial at OOPSLA'91 and at ELECTRO'92.

------------------------------------------------------------------------
-     Tutorial T8: Object-Oriented Concepts in Operating Systems       -
------------------------------------------------------------------------

Instructor: Anand Tripathi (University of Minnesota, USA)

Time: Tuesday, June 30: 9.00 - 12.30.

Level: Intermediate.

Objectives:
  To present the use of object-oriented concepts in operating systems.
  The focus will be on three aspects:
  - use of objects-based and object-oriented concepts in operating
    system designs,
  - support for user-level objects and object-oriented application
    systems, and
  - object-oriented interfaces to operating system functions.

Content:
  The recent advances in operating systems have focussed on providing
  support for object-based and distributed computing with emphasis on
  micro-kernel designs that support user-level extensible environments.
  Mach and Chorus exemplify this approach. The goal of this course is
  to present an exposition of object-oriented concepts in operating
  system designs. We distinguish three aspects in which
  object-orientation can relate to operating systems. One, an operating
  system itself is designed and implemented using object concepts.
  Second, an operating system provides explicit support for
  implementing objects and object-oriented applications. Third, an
  operating system provides extensible interfaces based on
  object-oriented concepts.

  We present, using examples from Mach, Chorus, and Clouds, the use of
  object-based concepts in operating system designs. Some of the
  specific aspects to be discussed include the object model and its
  relationship to virtual memory management, inter-object
  communication, protection, and process/thread management. The use of
  object oriented concepts such as class hierarchical approach to
  process management, exception handling, and memory management is
  presented with examples from Choices. The kernel-level support for
  objects includes functions for object creation, deletion, storage
  management (persistent objects), migration, network transparency, and
  remote invocations. Also needed is remote invocation level support
  for object oriented concepts such as polymorphism. In this context we
  present examples from Chorus and Nexus.

Who should attend:
  This course is intended for systems programmers/engineers,
  researchers, and project managers involved in the design and
  development of object-oriented distributed systems.

Required previous knowledge:
  Understanding of basic concepts in operating systems, distributed
  computing, and object-oriented programming.

Instructor's profile:
  Anand Tripathi is an Associate Professor in the Department of
  Computer Science, University of Minnesota, Minneapolis. He received
  the B.Tech degree from the Indian Institute of Technology, Bombay,
  India, 1972, and the M.S. and Ph.D. degrees from the University of
  Texas at Austin in 1978 and 1980, respectively, in Electrical
  Engineering. From 1972 to 1975 he worked as a research scientist at
  Bhabha Atomic Research Center, Bombay, India. During 1981 to 1984 he
  worked as a Senior Principal Research Scientist at Honeywell Computer
  Sciences Center, Bloomington, MN, where he was involved with the
  design and evaluation of distributed operating systems for command
  and control applications. He has designed and implemented an
  object-oriented distributed operating system called Nexus for
  supporting experimental studies in distributed computing.

  His research interests include parallel and distributed systems,
  object-oriented programming, and fault-tolerant computing. In the
  past, he has presented tutorials on distributed computing systems at
  some of the past ICDCS conferences, at some of the IEEE sponsored
  Tutorial Weeks in Washington DC and Boston, and also a number of
  times at the Berlin Continuing Engineering Education Program, AMK
  Berlin.

------------------------------------------------------------------------
-     Tutorial T9: The Self Programming Language                       -
------------------------------------------------------------------------

Instructor: Urs Holzle (Stanford University, USA)

Time: Tuesday, June 30: 14.00 - 17.30.

Level: Advanced to intermediate.

Objectives:
  To understand Self's object model and inheritance semantics, and the
  rationale behind them; to explore some typical situations where
  Self's flexibility allows simpler solutions than are available in
  more traditional languages like Smalltalk-80 and C++; to discuss
  techniques that allow an efficient implementation of Self.

Content:
  Self is an object-oriented language for exploratory programming based
  on a small number of simple yet powerful ideas. We start the tutorial
  by presenting the design principles underlying Self. Using simple
  examples, we then demonstrate how easy it is to reuse Self code even
  in situations where more traditional languages like Smalltalk stand
  in the programmer's way.

  The second part of the tutorial covers programming on a larger scale,
  showing how Self programs can be organised in the absence of classes.
  We also show how inheritance can be used to model concepts such as
  global variables and scoping without introducing extra language
  mechanisms.

  Finally, we address some of the performance implications of the Self
  language model and discuss how very good performance can be achieved
  despite the seemingly costly "everything is a message send" model.

Who should attend:
  Programmers, students and researchers who are interested in a fresh
  look at object-oriented language design and prototype-based systems;
  anybody who is wondering why it is often harder than expected to
  reuse code in his/her favourite programming language.

Required previous knowledge:
  Participants are expected to be familiar with the principles of
  object-oriented programming and at least one object-oriented
  programming language. Previous experience with Smalltalk-80 is
  helpful but not necessary.

Instructor's profile:
  Urs Holzle is a Ph.D. candidate at Stanford University and a
  Research Assistant at the Center for Integrated Systems. He joined
  the Self group three years ago and has implemented major parts of the
  Self system. His current research concentrates on new techniques for
  the optimisation of pure object-oriented languages.


======================================================================= 34 ===
Date:    30 Mar 92 18:47:46 GMT
From:    nr@cs.Princeton.EDU
Subject: Division Wars

Given that I've seen discussion of division in this space, and that
the Modula-3 definitions of DIV and MOD are different from the
definitions in e.g. C and Pascal, I thought the following article
(from the most recent TOPLAS) might be of interest to the Modula-3
crowd:

@article{boute:euclidean,
  month=apr,
  pages="127-144",
  number="2",
  author="Raymond T. Boute",
  title="The {Euclidean} Definition of the Functions div and mod",
  keywords="division arithmetic",
  annote="Compares the mathematical properties of three definitions of
div and m od, based on truncation, floor, and Euclid's theorem
respectively.  Also compares the advantages and disadvantages for
various purposes.  Nice ammunication for the division wars.",
  journal=toplas,
  year="1992",
  volume="14"}
-- 
Norman Ramsey
nr@princeton.edu


======================================================================= 35 ===
Date:    30 Mar 92 20:08:20 GMT
From:    figueroa@SPUNKY.CS.NYU.EDU (Samuel A. Figueroa)
Subject: UPPERCASE IDENTIFIERS (was: why modula3?)

In article <kt7hjfINNn80@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM
(David Chase) writes:

   VERBOSE UPPERCASE IDENTIFIERS.

My preference would be to make reserved words case insensitive, all other
words case sensitive.  This way one can choose one's own convention for
capitalization of words.
------------
Sam Figueroa (figueroa@cs.nyu.edu)
This is not a .signature virus.
Do NOT copy me into your .signature file!


======================================================================= 36 ===
Date:    1 Apr 92 22:42:55 GMT
From:    mod3sys@gonzo.cc.wwu.edu (modula3 system programmer)
Subject: why does my debugger say "source not available"?

I spent about an hour trying to tweak dbx into figuring out where the source
file is.  Is there a standard way for DS-3100 users of SRC Modula-3 Version
2.04 to step through lines, and so on?  Yes, I used the -g1 switch at
compile and link time.

(main source not available)


======================================================================= 37 ===
Date:    2 Apr 92 00:00:37 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Network Reader and Writer


Has anyone implemented a (TCP/IP stream-based) network reader/writer
for Modula-3? 

Thank you,
--farshad
--
Farshad Nayeri                Intelligent Database Systems
fn00@gte.com                  Computer and Intelligent Systems Laboratory
(617)466-2473                 GTE Laboratories, Waltham, MA


======================================================================= 38 ===
Date:    1 Apr 92 23:25:21 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Problems on a SparcStation

In article <1992Mar29.125501.27339@cs.rug.nl> laverman@cs.rug.nl (Bert Laverman
) writes:


   Mathew Yeates writes:
   > Anyone with any experience using the SRC Modula 3 on a Sun
   > SparcStation? I'm a C++ refugee checking out modula3 and know
   > very little about the language. However, I installed the SRC
   > compiler and tried to run their demos. Heres what happened.
   We have SRC-m3 running on SPARC SLC's and a SUN 4/something server.

   > Solitaire crashes my window manager (olwm).
   Works fine.

   > This is SunOs 4.1.2, openwindows 3.0, olwm. Also, I had to link
   > the X libs statically by compiling with -X2@-Bstatic@ because
   > Sun's patched loader is a piece of crap.
   Ah! We run SunOS 4.1 also, but I have a HP 700/RX X terminal,
   with tvtwm and _real_ X libraries. The Openwindows libraries are
   notoriously different... :-(


Does anyone know what it takes to get Trestle to work with OpenWindows?
Has anyone attempted to get them work together? Thanks,

--farshad


--
Farshad Nayeri                Intelligent Database Systems
fn00@gte.com                  Computer and Intelligent Systems Laboratory
(617)466-2473                 GTE Laboratories, Waltham, MA


======================================================================= 39 ===
Date:    30 Mar 92 10:44:47 GMT
From:    hendriks@serc.nl (Paul Hendriks)
Subject: ECOOP'92: Call for Participation & Preliminary Program

************************************************************************
*                                                                      *
*    EEEEEEE   CCCCCC   OOOOO    OOOOO   PPPPPP  ''  99999    2222     *
*    E        C        O     O  O     O  P     P '' 9     9  2    2    *
*    E        C        O     O  O     O  P     P    9     9       2    *
*    EEEE     C        O     O  O     O  PPPPPP      999999      2     *
*    E        C        O     O  O     O  P                9     2      *
*    E        C        O     O  O     O  P                9   2        *
*    EEEEEEE   CCCCCC   OOOOO    OOOOO   P           99999   222222    *
*                                                                      *
************************************************************************

                       Call for Participation
                         Preliminary Program

    The sixth European Conference on Object Oriented Programming
    ------------------------------------------------------------

                        29 June - July 3, 1992
                       Utrecht, the Netherlands

ECOOP'92 is the sixth European Conference on Object-Oriented
Programming. It will be held in Utrecht, the Netherlands, from June 29
to July 3, 1992. It continues the tradition of previous years, when
ECOOP was held in Paris (France), Oslo (Norway), Nottingham (England),
Ottawa (Canada, jointly with OOPSLA) and Geneva (Switzerland).

The ECOOP conferences are a platform for researchers and practitioners
from academia and industry to discuss and exchange new developments in
object-oriented languages, systems and methods. The program of events
for ECOOP'92 provides an excellent starting point for these stimulating
discussions.

Contents:
  - Conference Program
  - Exhibition, Demonstrations, and Presentations
  - Organisation
  - General Information and Registration
    - Registration Form
    - Hotel Reservation Form

Note: The descriptions of tutorials and workshops are posted separately.

************************************************************************
*                                                                      *
*     CONFERENCE PROGRAM                                               *
*                                                                      *
************************************************************************

------------------------------------------------------------------------
-     Monday, June 29, 1992                                            -
------------------------------------------------------------------------

 8.00 - 18.00: REGISTRATION
 9.00 - 17.00: FULL-DAY TUTORIALS:
  - T1: Jean-Pierre Briot (LITP, France)
    "Object-Oriented Concurrent Programming"
  - T2: Michael Blaha and Frederick Eddy (GE Corporate Research &
    Development, USA)
    "Object-Oriented Modelling and Design"
 9.00 - 17.00: WORKSHOPS:
  - W1: Markku Sakkinen (University of Jyvaskyla, Finland)
    "Multiple Inheritance and Multiple Subtyping"
  - W2: Yolande Berbers (K.U.Leuven, Belgium) and Peter Dickman (ERCIM,
    currently at INRIA Rocquencourt, France)
    "Dynamic Object Placement and Load Balancing in Parallel and
     Distributed Systems"
  - W3: Matti Rossi (University of Jyvaskyla, Finland)
    "CASE for Object-Oriented methods"
  - W4: Pieter Jan Morssink (Leiden University, the Netherlands) and
    Jan Overbeck (Vienna Technical University, Austria)
    "Second European Workshop for Doctoral Students in Object-Oriented
     Systems"
 9.00 - 12.30: HALF-DAY TUTORIAL:
  - T3: Derek Coleman and Patrick Arnold (Hewlett-Packard Laboratories,
    United Kingdom)
    "The Anatomy of an Analysis and Design Method"
14.00 - 17.30: HALF-DAY TUTORIAL:
  - T4: Ray Weedon (Open University, United Kingdom)
    "Introduction to Eiffel"

------------------------------------------------------------------------
-     Tuesday, June 30, 1992                                           -
------------------------------------------------------------------------

 8.00 - 18.00: REGISTRATION
 9.00 - 17.00: FULL-DAY TUTORIALS:
  - T5: Roberto Zicari (Johann Wolfgang Goethe-Universitat, Germany)
    "Object-Oriented Database Management Systems"
  - T6: Stanley Lippman (AT&T Bell Laboratories, USA)
    "Introduction to C++"
  - T7: Karl Lieberherr (Northeastern University, USA)
    "The Demeter Method for Object-Oriented Software Development"
 9.00 - 17.00: WORKSHOPS:
  - W5: Brian Foote (University of Illinois, USA), Pierre Cointe
    (Universite Pierre et Marie Curie, France), Mamdouh Ibrahim
    (EDS/Artificial Intelligence Services, USA), Gregor Kiczales (Xerox
    Palo Alto Research Center, USA), and Satoshi Matsuoka (University
    of Tokyo, Japan)
    "Object-Oriented Reflection and Meta-level Architectures"
  - W6: Michael Papathomas and Oscar Nierstrasz (University of Geneva,
    Switzerland)
    "Object-Based Concurrency and Reuse"
  - W7: Dennis de Champeaux (Hewlett-Packard Labs, USA)
    "The Object-Oriented Software Development Process"
 9.00 - 12.30: HALF-DAY TUTORIAL:
  - T8: Anand Tripathi (University of Minnesota, USA)
    "Object-Oriented Concepts in Operating Systems"
14.00 - 17.30: HALF-DAY TUTORIAL:
  - T9: Urs Holzle (Stanford University, USA)
    "The Self Programming Language"

------------------------------------------------------------------------
-     Wednesday, July 1, 1992                                          -
------------------------------------------------------------------------

 9.00 - 18.00: EXHIBITION
 8.00 - 10.00: REGISTRATION
10.00 - 10.10: OPENING REMARKS
  - Pierre America (Philips, The Netherlands), Conference Chair
10.10 - 11.10: INVITED SPEAKER
  - Won Kim (UniSQL, USA)
    "On Unifying Relational and Object-Oriented Database Systems"
11.30 - 12.30: SESSION: LANGUAGES I (Chair: Markku Sakkinen)
  - Clemens A. Szyperski (Swiss Federal Institute of Technology,
    Switzerland)
    "Import is not Inheritance - Why We Need Both: Modules and Classes"
  - Craig Chambers (University of Washington, USA)
    "Object-Oriented Multi-Methods in Cecil"
14.00 - 15.30: SESSION: THEORY I (Chair: Elspeth Cusack)
  - Thorsten Hartmann, Ralf Jungclaus, and Gunter Saake (Technische
    Universitat Braunschweig, Germany)
    "Aggregation in a Behaviour Oriented Object Model"
  - K.C. Lano (Oxford University, United Kingdom) and H. Haughton
    (Lloyds Register of Shipping, United Kingdom)
    "Reasoning and Refinement in Object-Oriented Specification
     Languages"
  - Tarmo Uustalu (Estonian Academy of Sciences, Estonia)
    "Combining Object-Oriented and Logic Paradigms: A Modal Logic
     Programming Approach"
15.50 - 17.20: SESSION: CLASS EVOLUTION/METHODOLOGY/USER INTERFACES
  (Chair: Rebecca Wirfs-Brock)
  - Eduardo Casais (Forschungszentrum Informatik, Germany) 
    "Incremental Class Reorganization Algorithms"
  - Egil P. Andersen and Trygve Reenskaug (University of Oslo, Norway)
    "System Design by Composing Structures of Interacting Objects"
  - Veronique Normand (Bull-IMAG Systemes, France) and Joelle Coutaz
    (Laboratoire de Genie Informatique, France)
    "Unifying the Design and Implementation of User Interfaces through
     the Object Paradigm"
18.30 - 20.30: RECEPTION
  - Speech: Kristen Nygaard (University of Oslo, Norway)

------------------------------------------------------------------------
-     Thursday, July 2, 1992                                           -
------------------------------------------------------------------------

 9.00 - 18.00: EXHIBITION
 9.00 - 10.30: SESSION: CONCURRENCY (Chair: Mario Tokoro)
  - Rachid Guerraoui, Riccardo Capobianchi, Agnes Lanusse, and Pierre
    Roux (CE Saclay DEIN/SIR, France)
    "Nesting Actions through Asynchronous Message Passing: the ACS
     Protocol"
  - Svend Frolund (University of Illinois, USA)
    "Inheritance of Synchronization Constraints in Concurrent
     Object-Oriented Programming Languages"
  - J.-M. Jezequel (IRISA, France)
    "EPEE: an Eiffel Environment to Program Distributed Memory Parallel
     Computers"
11.00 - 12.30: SESSION: APPLICATIONS/EXPERIENCE (Chair: Walter Olthoff)
  - Bent Gabelgaard (Dansk MobilTelefon, Denmark)
    "Using Object-Oriented Programming Techniques for Implementing ISDN
     Supplementary Services"
  - Nguyen G.T., D. Rieu (Laboratoire de Genie Informatique, France)
    "An Object Model for Engineering Design"
  - Wing-cheong Lau (MCC, USA) and Vineet Singh (Hewlett-Packard Labs,
    USA)
    "An Object-Oriented Class Library for Scalable Parallel Heuristic
     Search"
14.00 - 15.00: INVITED SPEAKER
  - William Verplank (ID TWO, USA)
    "Object-Oriented User Interface Design"
15.20 - 16.20: SESSION: LANGUAGES II (Chair: Boris Magnusson)
  - Bjorn N. Freeman-Benson (University of Victoria, Canada) and Alan
    Borning (University of Washington, USA)
    "Integrating Constraints with an Object-Oriented Language"
  - Ian M. Holland (Northeastern University, USA)
    "Specifying Reusable Components using Contracts"
17.30 - 18.00: DEPARTURE FOR BANQUET
19.00 - 23.00: BANQUET in "Het Vechthuis"

------------------------------------------------------------------------
-     Friday, July 3, 1992                                             -
------------------------------------------------------------------------

 9.00 - 17.00: EXHIBITION
 9.00 - 10.30: PANEL (to be announced)
11.00 - 12.30: SESSION: THEORY II (Chair: Dave Thomas)
  - Mahesh Dodani and Chung-Shin Tsai (University of Iowa, USA)
    "ACTS: A Type System for Object-Oriented Programming Based on
     Abstract and Concrete Classes"
  - Nicholas Oxhoj, Jens Palsberg, and Michael I. Schwartzbach (Aarhus
    University, Denmark)
    "Making Type Inference Practical"
  - Suresh Jagannathan (NEC Research Institute, USA) and Gul Agha
    (University of Illinois, USA)
    "A Reflective Model of Inheritance"
14.00 - 15.30: SESSION: LANGUAGES/DATABASES (Chair: Anna-Kristin Profrock)
  - Mehmet Aksit, Lodewijk Bergmans, and Sinan Vural (University of
    Twente, the Netherlands)

************************************************************************
*                                                                      *
*     EXHIBITION, DEMONSTRATIONS, AND PRESENTATIONS                    *
*                                                                      *
************************************************************************

ECOOP'92 will be accompanied by an exhibition in which commercial as
well as non-commercial products supporting object-oriented technology
will be demonstrated. The exhibition is opened for three days
(Wednesday, Thursday, and Friday), not only to the participants of the
conference, but also to others that are interested. Exhibitors and
demonstrators have the possibility to give a half hour presentation in
a presentation session.

Exhibition:
  Companies interested in exhibiting their commercial products should
  contact Novep Conference Organizers in Amsterdam. They will provide
  you with an exhibitors kit, and answer all questions about the
  technical details of the exhibition. Novep can be contacted at:
      Novep Conference Organizers
      Paulus Potterstraat 40
      1071 DB  Amsterdam
      The Netherlands 
      Phone: +31 20 664 5876
      Fax:   +31 20 662 8136
  All additional questions concerning the exhibition can be directed
  to:
      Paul Hendriks
      Software Engineering Research Centre - SERC
      P.O. Box 424
      3500 AK  Utrecht
      The Netherlands
      E-mail: ecoop92-exh@serc.nl
      Phone: +31 30 322640
      Fax:   +31 30 341249

Demonstrations:
  Poster sessions and demonstrations of (academic) software can be
  given to illustrate innovative concepts. A description accompanied by
  platform requirements should be submitted before April 1 to the
  following address. A form to fill in this information can be acquired
  by contacting:
      Chris Laffra
      Software Engineering Research Centre - SERC
      P.O. Box 424
      3500 AK  Utrecht
      The Netherlands
      E-mail: ecoop92-demo@serc.nl
      Phone: +31 30 322640
      Fax:   +31 30 341249

Presentations:
  Participants in the exhibition or demonstrations have the opportunity
  to elucidate their products in a half hour presentation. They can
  express their willingness to do so by filling in the corresponding
  slots in the exhibitors kit or the demonstrations form.

************************************************************************
*                                                                      *
*     ORGANISATION                                                     *
*                                                                      *
************************************************************************

Sponsor:
  Software Engineering Research Centre - SERC, the Netherlands

Co-sponsoring Organisations:
  BCS (British Computer Society)          Koning en Hartman
  Datex                                   NGI (Dutch Computer Society)
  DND (Norwegian Computer Society)        Object Management Group
  Electric Engineering                    OCG (Austrian Computer Society)
  Georg Heeg Smalltalk-80-Systems         Philips
  Getronics Network Services              RAET
  Getronics Service                       SI (Swiss Computer Society)
  IBM                                     Sun Microsystems
  Interpersonal Computing Group

Organisation:
  Conference Chair:  Pierre America       Philips, the Netherlands
  Program Chair:     Ole Lehrmann Madsen  Aarhus University, Denmark
  Organising Chair:  Gert Florijn         SERC, the Netherlands
  Tutorials:         Mehmet Aksit         University of Twente, the Netherlands
  Exhibition:        Paul Hendriks        SERC, the Netherlands
  Demonstrations:    Chris Laffra         SERC, the Netherlands

Program Committee:
  Ole Lehrmann Madsen (chair)  Aarhus University, Denmark
  Alan Borning                 University of Washington, USA
  Jean-Pierre Briot            Universite Pierre et Marie Curie, France
  Pierre Cointe                Universite Pierre et Marie Curie, France
  Elspeth Cusack               British Telecom, United Kingdom
  Nigel Derrett                Hewlett-Packard Laboratories, United Kingdom
  Klaus Dittrich               Universitat Zurich, Switzerland
  Roger Duke                   University of Queensland, Australia
  Eric Jul                     Kobenhavns Universitet, Denmark
  Boris Magnusson              Lund University, Sweden
  Bertrand Meyer               Interactive Software Engineering, USA
  Ron Morrison                 University of St. Andrews, United Kingdom
  Oscar Nierstrasz             Universite de Geneve, Switzerland
  Walter Olthoff               German Research Center for AI, Germany
  Barbara Pernici              Universita di Udine, Italy
  Jean-Francois Perrot         Universite Pierre et Marie Curie, France
  Anna-Kristin Profrock        Siemens Nixdorf, Germany
  Trygve Reenskaug             Taskon A/S, Norway
  Markku Sakkinen              University of Jyvaskyla, Finland
  Dave Thomas                  Object Technology International, Canada
  Mario Tokoro                 Sony CSL, Japan
  Enn Tyugu                    Institute of Cybernetics, Estonia
  Rebecca Wirfs-Brock          Instantiations, USA
  Akinori Yonezawa             University of Tokyo, Japan
  Ed Yourdon                   American Programmer, USA 

************************************************************************
*                                                                      *
*     GENERAL INFORMATION AND REGISTRATION                             *
*                                                                      *
************************************************************************

Conference Venue:
  ECOOP'92 will be held in the Jaarbeurs Congress Centre in Utrecht.
  The "Jaarbeurs" is within walking distance of the city centre of
  Utrecht, and very near to Utrecht's central train station. The
  address of the Jaarbeurs is:
      Jaarbeurs Congress Centre
      Jaarbeursplein
      2521 AL  Utrecht
      The Netherlands

Transportation to and in Utrecht:
  Utrecht is one of the largest Dutch cities, and it is situated right
  in the centre of the Netherlands. Public transportation within
  Utrecht (by bus and tram) and to other parts of the Netherlands (by
  train) is excellent. Trains to other major cities such as Rotterdam,
  the Hague, and Amsterdam leave approximately every half hour, and
  take 30 to 60 minutes. Since the conference venue is very close to
  the central station, and Dutch roads and parking places are crowded,
  it is not advisable to rent a car.

  Utrecht does not have its own airport. A train-ride from Schiphol
  (the international airport of Amsterdam) to Utrecht takes about 60
  minutes. Trains from Schiphol to Amsterdam central station leave
  every half hour. There you can get a connection to Utrecht central
  station.

Accommodation:
  Hotel bookings are handled by the Utrecht Tourist Office (the "VVV").
  An application form is enclosed. It should be returned to the tourist
  office no later than May 1, 1992. For further information, you can
  contact the tourist office:
      Hotelreservations VVV Utrecht
      Vredenburg 90
      3511 BD  Utrecht
      The Netherlands
      Phone: +31 30 331544
      Fax:   +31 30 331417

Registration
  The registration for the conference is handled by Novep Conference
  Organizers in Amsterdam. Questions about registration, payment, etc.
  should be directed to them. You can contact them at:
      Novep Conference Organizers
      Paulus Potterstraat 40
      1071 DB  Amsterdam
      The Netherlands
      Phone: +31 20 664 5876
      Fax:   +31 20 662 8136

  - Copy the following registration form and fax or mail the completed
    form to Novep Conference Organizers.
  - All prices are indicated in Dutch guilders (Dfl) and are including
    VAT.
  - The conference fee includes a copy of the proceedings, reception,
    refreshments, and lunches on Wednesday, Thursday, and Friday.
  - The tutorial fee includes a copy of the tutorial notes,
    refreshments, and a lunch.
  - The early registration fee is only applicable if payment is
    received before May 1, 1992.
  - The reduced rates are only available to members of the British
    (BCS), Norwegian (DND), Dutch (NGI), Austrian (OCG), and Swiss (SI)
    computer societies.
  - The student rate is only available to full-time students. A
    photocopy of a valid student card, or other proof of student status
    has to be included with the registration form.
  - You will receive a confirmation of your registration as soon as
    your payment is received.
  - The organisation of ECOOP reserves the right to cancel a tutorial.
    In the event of cancellation you will be given the option of
    attending another tutorial.

Cancellation:
  Notification of cancellation must be sent to Novep Conference
  Organisers. Cancellation made prior to June 1, 1992 will be subject
  to a 25% cancellation fee. After this date fees are non-refundable. A
  substitute can be sent in place.

  In the event that any one of the advertised speakers is, for reasons
  outside the control of the organisation committee, unable to attend
  the conference, the organisation committee reserves the right,
  without notice, to make such alteration or substitution as it deems
  fit. Delegates will have no claims against the organisation
  committee, in respect of such alteration or substitution.

Further Information about the Program:
  For further information about the conference and the programme,
  please contact:
      Gert Florijn
      Software Engineering Research Centre - SERC
      P.O. Box 424
      3500 AK  Utrecht
      The Netherlands
      E-mail: ecoop92@serc.nl
      Phone: +31 30 322640
      Fax:   +31 30 341249

************************************************************************
*                                                                      *
*     Registration Form ECOOP'92                                       *
*                                                                      *
************************************************************************

Surname: ___________________________ First name: _________ [] Mr. [] Ms.

Company name: __________________________________________________________

Address: _______________________________________________________________

City: ____________________________________ Zip code: ___________________

State/Country: _________________________________________________________

Phone: _______________ Fax: _______________ E-mail: ____________________

[] BCS/DND/NGI/OCG/SI member no.: ______________________________________
[] Full-time student (please include a photocopy of a valid student
   card, or other proof of student status)

would like to register for:
                                                     Early        Late
Conference:              Dfl ______  | Conference:
Full-day Tutorials:                  |   Regular  Dfl 800,--  Dfl 900,--
  [] T1 or [] T2         Dfl ______  |   Reduced  Dfl 740,--  Dfl 820,--
  [] T5, [] T6, or [] T7 Dfl ______  |   Students Dfl 350,--  Dfl 400,--
Half-day Tutorials:                  | Full-day Tutorials:
  [] T3                  Dfl ______  |   Regular  Dfl 350,--  Dfl 400,--
  [] T4                  Dfl ______  |   Reduced  Dfl 300,--  Dfl 350,--
  [] T8                  Dfl ______  |   Students Dfl 175,--  Dfl 215,--
  [] T9                  Dfl ______  | Half-day Tutorials:
Banquet:                             |   Regular  Dfl 240,--  Dfl 280,--
  Dfl 75,-- x ___ =      Dfl ______  |   Reduced  Dfl 180,--  Dfl 220,--
                         ==========  |   Students Dfl 105,--  Dfl 135,--
Total amount to be paid: Dfl ______  | Banquet: (Dfl 75,-- per person)
                                     |   [] Vegetarian

The early registration fee is only applicable if payment is received
before May 1, 1992.

Please indicate by which means you have paid:

[] Remitted to bank account ABN/AMRO Utrecht, account number
   55.50.72.487, stating SERC-ECOOP'92 and attendees name.
[] Bankers' draft forwarded together with the registration form. The
   draft should be made out to SERC-ECOOP'92 net of bank charges.
[] Credit Card:
   [] Euro/Master/Access card [] American Express
   [] Diners Club             [] Visa Card
      Charge my card number: _____________ Expiration date: ____________
      This is a company/private card in the name of: ___________________

Place: ________________ Date: _____________ Signature: _________________

Please copy and mail or fax this form as soon as possible to:
  Novep Conference Organizers
  Paulus Potterstraat 40
  1071 DB  Amsterdam
  The Netherlands
  Phone: +31 20 664 5876
  Fax:   +31 20 662 8136

************************************************************************
*                                                                      *
*     Hotel Reservation Form ECOOP'92                                  *
*                                                                      *
************************************************************************

Surname: ___________________________ First name: _________ [] Mr. [] Ms.

Company name: __________________________________________________________

Address: _______________________________________________________________

City: ____________________________________ Zip code: ___________________

State/Country: _________________________________________________________

Phone: _______________ Fax: _______________ E-mail: ____________________

would like to reserve for ______ person(s)
________ single room(s) with/without bath/shower/toilet
________ double room(s) with/without bath/shower/toilet

Date of arrival: __________________ Date of departure: _________________

Price Categories (Please mark the requested category)

Single                           Double
[] Dfl 175,--  -  Dfl 255,--     [] Dfl 225,--  -  Dfl 295,--
[] Dfl 115,--  -  Dfl 165,--     [] Dfl 150,--  -  Dfl 200,--
[] Dfl  75,--  -  Dfl 110,--     [] Dfl 110,--  -  Dfl 140,--
[] Dfl  45,--  -  Dfl  70,--     [] Dfl  70,--  -  Dfl 100,--

When the hotels are fully booked, I will/will not accept a reservation
in another class/outside Utrecht.

Send this form back before May 1, 1992 to:
  VVV Utrecht
  Vredenburg 90
  3511 BD  Utrecht
  The Netherlands
  Phone: +31 30 331544
  Fax:   +31 30 331417

You will receive a confirmation of your reservation from the tourist
information office. The reservation has to be paid to the tourist
information office in Dutch guilders. Means of payment are indicated in
the reservation confirmation.

Further information on the hotel reservation:

Hotelreservations VVV Utrecht, Phone: +31 30 331544, Fax: +31 30 331417.


======================================================================= 40 ===
Date:    2 Apr 92 06:48:32 GMT
From:    nichols@parc.xerox.com (David Nichols)
Subject: Re: Network Reader and Writer

Yes, just create a socket using Usocket.socket bind it and connect
normally, and then use UFileRdWr.CreateFileReader or
UFileRdWr.CreateFileWriter to create a reader or writer on it.  You don't
get access to things like urgent data handling, but it's good for most
purposes.

	David


======================================================================= 41 ===
Date:    Fri, 3 Apr 1992 00:07:42 -0800 (PST)
From:    "David L. Miller" <dmiller@beta.tricity.wsu.edu>
Subject: Passing Procedure pointers

Newsgroups: comp.lang.modula3
Distribution: world
Organization: Washington State University Tri-Cities, Richland
Keywords: 

I need to be able to pass a reference to a procedure from one module to
another.  In C, I would do it something like:

	struct entry { 
		void (*pfunc)() ;	/* pointer to function */
		int p0, p1, p2 ;	/* parameters to pfunc() */
	}

	struct entry A[100] ;

	void f1(int q0, q1, q2)
		{
		...
		}

	main()
		{
		A[0].pfunc = f1 ;	
		A[1].pfunc = f2 ;	
		...
		(*(A[0].pfunc))(A[0].p1,A[0].p2,A[0].p0) ; /* execute f1 */
		...
		}

Is there a way to do this in Modula-3?

--DLM

*****************************************************************************
David L. Miller                       Internet: dmiller@beta.tricity.wsu.edu
Systems Programmer/Network Analyst      BITNET: MILLERD@WSUVM1
Washington State University Tri-Cities    UUCP: ...!yoda!dmiller
100 Sprout Road                          
Richland, WA 99352                       Phone: (509)375-9245
*****************************************************************************


======================================================================= 42 ===
Date:    2 Apr 92 15:39:02 GMT
From:    bs@alice.att.com (Bjarne Stroustrup)
Subject: Re: Modula 3 versus C++ libraries



mathew@elroy.jpl.nasa.gov (Mathew Yeates @ Image Analysis Systems Group, JPL) w
rites

 > Furthermore, exception handling has not yet been 
 > approved in ANSI C++. Thus implementations are possibly two years away 

Minor correction: Exception handling was approved by the ANSI/ISO C++ committee
last year. Implementations exists an the first commercial ones are shipping thi
s
year (e.g. IBM has announced a C++ compiler supporting exceptions for their RS/
6000
series to ship in May or June ((I don't remember which))


======================================================================= 43 ===
Date:    Wed, 1 Apr 1992 23:26:19 GMT
From:    nr@elan (Norman Ramsey)
Subject: Re: tcl and Modula-3


> Has anyone implemented a Modula-3/TCL interface?

A long time back, Eric Muller posted a Modula-3 interface to the C TCL
library.  I wrote down a Modula-3/TCL interface that used Modula-3
types rather than C types, and that used objects to build closures for
commands.  I wrote part of the implementation but never finished it.
I have mailed copies to carroll@udel.edu, who asked the question, and
I will post them if there seems to be general interest.


======================================================================= 44 ===
Date:    Fri, 3 Apr 92 09:32:23 +0200
From:    a.vermeulen@ECN.NL (Vermeulen A.T.)
Subject: Re: Pkl.Write generates ASSERT failure (M3 2.03 on sparcstation)

Joe Morrison (jmorrison@gte.com) states in his email-message of 27 Mar 92 15:40
:16 GMT:

> Is this any kind of known problem? Might it be fixed in 2.04?
> Thanks in advance...

Get V2.04, because this one compiles also succesfully, but what's more importan
t, it even runs correctly, so Pickles is corrected in 2.04!

	Alex Vermeulen

--
Netherlands Energy Research Foundation	      Email: a.vermeulen@ecn.nl
P.O. Box 1 				      Phone: (+31) 2246 4194
1755 ZG  Petten, The Netherlands	


======================================================================= 45 ===
Date:    Fri, 3 Apr 92 11:09:55 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Passing Procedure pointers

In article <Pine.2.4.55.9204030034.N24999@beta.tricity.wsu.edu>, "David L. Mill
er" <dmiller@beta.tricity.wsu.edu> writes:

> I need to be able to pass a reference to a procedure from one module to
> another.  In C, I would do it something like:
> 
> 	struct entry { 
> 		void (*pfunc)() ;	/* pointer to function */
> 		int p0, p1, p2 ;	/* parameters to pfunc() */
> 	}
> 
> 	struct entry A[100] ;
> 
> 	void f1(int q0, q1, q2)
> 		{
> 		...
> 		}
> 
> 	main()
> 		{
> 		A[0].pfunc = f1 ;	
> 		A[1].pfunc = f2 ;	
> 		...
> 		(*(A[0].pfunc))(A[0].p1,A[0].p2,A[0].p0) ; /* execute f1 */
> 		...
> 		}

> Is there a way to do this in Modula-3?

Of course !

MODULE Main;

TYPE
  struct_entry = RECORD
       pfunc: PROCEDURE (q0, q1, q2: INTEGER);
       p0, p1, p2: INTEGER; END;

VAR
  A : ARRAY [0..99] OF struct_entry;


PROCEDURE f1 (q0, q1, q2: INTEGER) = ...
PROCEDURE f2 (q0, q1, q2: INTEGER) = ...

BEGIN
  A[0].pfunc := f1;
  A[1].pfunc := f2;
  ...
  A[0].pfunc (A[0].p1, A[0].p2, A[0].p0);
  ...
END Main.


This is the strict translation to C.  It offers the possibility of
building A in Modula-3 and to pass it to C code and use it as in your
example (or the other way around).

A more Modula-3ish way involves objects:

TYPE
  closure = OBJECT
              p0, p1, p2: INTEGER;
            METHOD
              apply (); END;

VAR
  A : ARRAY [0..99] OF closure;


PROCEDURE f1 (self: closure) =  ... (* use self.p0, self.p1, self.p2 *)

BEGIN
  A[0] := NEW (closure, apply := f1);
  ...
  A[0].p0 := 3;
  ...
  A[0].apply ();
  ...
END Main.

-- 
Eric.



======================================================================= 46 ===
Date:    Fri, 3 Apr 92 10:48:16 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: why does my debugger say "source not available"?

In article <mod3sys.702168175@gonzo>, mod3sys@gonzo.cc.wwu.edu (modula3 system 
programmer) writes:
> I spent about an hour trying to tweak dbx into figuring out where the source
> file is.  Is there a standard way for DS-3100 users of SRC Modula-3 Version
> 2.04 to step through lines, and so on?  Yes, I used the -g1 switch at
> compile and link time.

To help debugging, the result of a "normal" compilation contains
lines of the form:

#line 200 "Foo.m3"


However, this does not happens for the piece of C generated by the
linker, which defines main(), because there is no corresponding
Modula-3 source.  You can either:

- give the -k option to m3, this will keep this C file around
  (_m3main.c) and dbx should able to find it.

- ignore the message given by dbx, and put a breakpoint in your "real"
  main program.
  You can set a breakpoint in the function that implements the boby of 
  module Foo (in the file Foo.m3) by:

	(dbx) stop in Foo._init_

  (this function is static, and there is one _init_ per module; you 
   need to qualify it with the file name).


If you are trying to debug the compiler or the driver built from a
bootstrap archive, you don't have the Modula-3 sources (distributed
separately).  If you grab the compiler-2.04 or driver-2.04 archive and
unpack it, you will get the sources.  You just need to tell dbx where
they are:

	(dbx) use <somewhere>/compiler/src/exprs
	(dbx) use <somewhere>/compiler/src/types
	...

	or

	(dbx) use <somewhere>/driver/src

You also need to add:

	(dbx) use <somewhere>/compiler/boot-DS3100

	or

	(dbx) use <somewhere>/driver/boot-DS3100

to get the main program (in _m3main.c).

---
Eric.



======================================================================= 47 ===
Date:    Fri, 3 Apr 92 11:00:41 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: tcl and Modula-3

In article <1992Apr1.232619.18244@newross.Princeton.EDU>, nr@elan (Norman Ramse
y) writes:
> 
> > Has anyone implemented a Modula-3/TCL interface?
> 
> A long time back, Eric Muller posted a Modula-3 interface to the C TCL
> library.

Here it is.  It compiles, but I have no idea of the version of TCL
this corresponds to (except that I wrote it in March 91).  I'll be
happy to put this or an udpated version in the next release.

There is also a little test program to show how it works; I cannot
rebuild it right now, I don't have TCL installed; I don't even know if
it compiles.

-- 
Eric.


(* Copyright (C) 1991, Digital Equipment Corporation           *)
(* All rights reserved.                                        *)
(* See the file COPYRIGHT for a full description.              *)

(* Last modified on Fri Apr 03 10:57:20 PST 1992 by muller         *)


(* This file is derived from tcl.h, covered by the following copyright:

 * Copyright 1987, 1990 Regents of the University of California
 * Permission to use, copy, modify, and distribute this
 * software and its documentation for any purpose and without
 * fee is hereby granted, provided that the above copyright
 * notice appear in all copies.  The University of California
 * makes no representations about the suitability of this
 * software for any purpose.  It is provided "as is" without
 * express or implied warranty.
 *)

UNSAFE INTERFACE TclC;
FROM Ctypes IMPORT char_star, int_star, int, char, double;
IMPORT Word;

CONST
  TCL_OK       = 0;
  TCL_ERROR    = 1;
  TCL_RETURN   = 2;
  TCL_BREAK    = 3;
  TCL_CONTINUE = 4;

  BRACKET_TERM  = 1;
  NO_EVAL       = -1;

  STATIC   = 0;
  DYNAMIC  = 1;
  VOLATILE = 2;

  TRACE_READS	= 1;
  TRACE_WRITES  = 2;
  TRACE_DELETES = 4;

  VARIABLE_UNDEFINED = 8;


TYPE
  Argv   = UNTRACED REF ARRAY [0..255] OF char_star;
  Interp = RECORD
             result: char_star; (* Points to result string returned by 
                                   command. *)
             dynamic: int;	(* Non-zero means result is dynamically-
				   allocated and must be freed by Eval
				   before executing the next command. *)
             errorLine: int;    (* When TCL_ERROR is returned, this gives
				   the line number within the command where
				   the error occurred (1 means first line). *)
             END;
  InterpStar = UNTRACED REF Interp;
  ClientData = Word.T;

             

<*EXTERNAL Tcl_AddErrorInfo *>
PROCEDURE AddError (interp: InterpStar; message: char_star);

<*EXTERNAL Tcl_AppendResult *>
PROCEDURE AppendResult (interp: InterpStar;
			s1, s2, s3, s4, s5: char_star := NIL);

TYPE
  CmdBuf = int_star;

<*EXTERNAL Tcl_CreateCmdBuf *>
PROCEDURE CreateCmdBuf (): CmdBuf;

<*EXTERNAL Tcl_DeleteCmdBuf *>
PROCEDURE DeleteCmdBuf (buffer: CmdBuf);

<*EXTERNAL Tcl_AssembleCmd *>
PROCEDURE AssembleCmd (buffer: CmdBuf; string: char_star): char_star;

<*EXTERNAL Tcl_Backslash *>
PROCEDURE Backslash (src: char_star; VAR count: int): char;

<*EXTERNAL Tcl_Concat *>
PROCEDURE Concat (argc: int; argv: Argv): char_star;

TYPE
  CommandProc = PROCEDURE (clientData: ClientData;
                           interp: InterpStar;
                           argc:   int;
                           argv:   Argv): int;

  DeleteProc  = PROCEDURE (clientData: ClientData);

<*EXTERNAL Tcl_CreateCommand *>
PROCEDURE CreateCommand (interp: InterpStar; 
                         cmdName: char_star; 
                         proc: CommandProc;
                         clientData: ClientData;
                         deleteProc: DeleteProc);

<*EXTERNAL Tcl_CreateInterp *>
PROCEDURE CreateInterp (): InterpStar;

TYPE
  TraceProc = PROCEDURE (clientData: ClientData;
                         interp: InterpStar;
                         level: int;
                         command: char_star;
                         cmdProc: CommandProc;
                         cmdClientData: ClientData;
                         argc: int;
                         argv: Argv);
  Trace = int_star;

<*EXTERNAL Tcl_CreateTrace *>
PROCEDURE CreateTrace (interp: InterpStar;
                       level: int;
                       proc: TraceProc;
                       clientData: ClientData): Trace;

<*EXTERNAL Tcl_DeleteCommand *>
PROCEDURE DeleteCommand (interp: InterpStar; cmdName: char_star);

<*EXTERNAL Tcl_DeleteInterp *>
PROCEDURE DeleteInterp (interp: InterpStar);

<*EXTERNAL Tcl_DeleteTrace *>
PROCEDURE DeleteTrace (interp: InterpStar; trace: Trace);

<*EXTERNAL Tcl_Eval *>
PROCEDURE Eval (interp: InterpStar;
                cmd: char_star;
                flags: int;
                termPtr: Argv): int;

<*EXTERNAL Tcl_Expr *>
PROCEDURE Expr (interp: InterpStar; string: char_star; VAR value: int): int;

<*EXTERNAL Tcl_GetInt *>
PROCEDURE GetInt (interp: InterpStar; string: char_star; VAR val: int): int;

<*EXTERNAL Tcl_GetDouble *>
PROCEDURE GetDouble (interp: InterpStar;
		     string: char_star; VAR val: double): int;

<*EXTERNAL Tcl_GetBoolean *>
PROCEDURE GetBoolean (interp: InterpStar; 
		      string: char_star; VAR value: int): int;

<*EXTERNAL Tcl_GetVar *>
PROCEDURE GetVar (interp: InterpStar; 
		  varName: char_star; global: int): char_star;

<*EXTERNAL Tcl_Merge *>
PROCEDURE Merge (argc: int; argv: Argv): char_star;

<*EXTERNAL Tcl_ParseVar *>
PROCEDURE ParseVar (interp: InterpStar;
	            string: char_star;
		    term: Argv): char_star;

<*EXTERNAL Tcl_RecordAndEval *>
PROCEDURE RecordAndEval (interp: InterpStar; cmd: char_star; flags: int): int;

<*EXTERNAL Tcl_Return *>
PROCEDURE Return (interp: InterpStar; string: char_star; status: int);

<*EXTERNAL Tcl_SetVar *>
PROCEDURE SetVar (interp: InterpStar; varName, newValue: char_star; global: int
);

<*EXTERNAL Tcl_SplitList *>
PROCEDURE SplitList (interp: InterpStar; 
 		     list: char_star;
		     VAR argc: int;
		     VAR argv: Argv): int;

<*EXTERNAL Tcl_StringMatch *>
PROCEDURE StringMatch (string, pattern: char_star): int;

<*EXTERNAL Tcl_TildeSubst *>
PROCEDURE TildeSubst (interp: InterpStar; name: char_star): char_star;

TYPE
  VarTraceProc = PROCEDURE (clientData: ClientData;
                            interp: InterpStar;
			    varName: char_star;
                            global, flags: int;
                            oldValue, newValue: char_star): char_star;

<*EXTERNAL Tcl_TraceVar *>
PROCEDURE TraceVar (interp: InterpStar; 
		    varName: char_star;
		    global, flags: int;
		    proc: VarTraceProc;
		    clientData: ClientData): int;

<*EXTERNAL Tcl_UnTraceVar *>
PROCEDURE UnTraceVar (interp: InterpStar; varName: char_star; global: int);

<*EXTERNAL Tcl_VarTraceInfo *>
PROCEDURE VarTraceInfo (interp: InterpStar; 
			varName: char_star; 
			global: int;
			VAR proc: VarTraceProc;
			VAR clientData: ClientData): int;

END TclC.





(* Copyright (C) 1991, Digital Equipment Corporation           *)
(* All rights reserved.                                        *)
(* See the file COPYRIGHT for a full description.              *)


UNSAFE MODULE TclCTest EXPORTS Main;

IMPORT TclC;
IMPORT Rd, Wr, Stdio, Fmt;
FROM M3toC IMPORT TtoS, CopyTtoS, CopyStoT;
FROM Ctypes IMPORT int, char_star;

PROCEDURE FactCmd (<*UNUSED*> clientData: TclC.ClientData;
		   interp: TclC.InterpStar;
   	 	   argc: int;
		   argv: TclC.Argv): int =
  BEGIN
    IF argc # 2 THEN
      interp.result := TtoS ("fact has exactly one argument");
      RETURN TclC.TCL_ERROR; 
    ELSE
      VAR i: INTEGER; BEGIN
        IF TclC.GetInt (interp, argv[1], i) = TclC.TCL_ERROR THEN
          RETURN TclC.TCL_ERROR; END;
        interp.result := CopyTtoS (Fmt.Int (Fact (i)));
        RETURN TclC.TCL_OK; END; END;
  END FactCmd;

PROCEDURE Fact (i: INTEGER): INTEGER =
  BEGIN
    IF i = 1 THEN
      RETURN 1;
    ELSE 
      RETURN i * Fact (i - 1); END;
  END Fact;


VAR
  i: TclC.InterpStar;
  buf: TclC.CmdBuf;
  s: char_star;
  status: int;

BEGIN
  i := TclC.CreateInterp ();
  TclC.CreateCommand (i, TtoS ("fact"), FactCmd, 0, NIL);
  buf := TclC.CreateCmdBuf ();

  TRY
    LOOP 
      Wr.PutText (Stdio.stdout, "-> ");
      s := TclC.AssembleCmd (buf, TtoS (Rd.GetLine (Stdio.stdin) & "\n"));
      IF s # NIL THEN
        status := TclC.RecordAndEval (i, s, 0);
        CASE status OF 
        | TclC.TCL_OK =>
            Wr.PutText (Stdio.stdout, CopyStoT (i.result) & "\n"); 
        | TclC.TCL_ERROR =>
            Wr.PutText (Stdio.stderr, "error: " & CopyStoT (i.result) & "\n"); 
        ELSE
            Wr.PutText (Stdio.stderr, "TclC.Eval returned with code = " 
					& Fmt.Int (status) & "\n"); 
                                                        END; END; END; 
  EXCEPT
  | Rd.EndOfFile => END;

  TclC.DeleteCmdBuf (buf);
  TclC.DeleteInterp (i);
END TclCTest.


======================================================================= 48 ===
Date:    Fri, 3 Apr 92 19:12:25 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: tcl and Modula-3

In article <1992Apr3.110041.28332@src.dec.com>, muller@src.dec.com (Eric Muller
) writes:
> In article <1992Apr1.232619.18244@newross.Princeton.EDU>, nr@elan (Norman Ram
sey) writes:
> > 
> > > Has anyone implemented a Modula-3/TCL interface?
> > 
> > A long time back, Eric Muller posted a Modula-3 interface to the C TCL
> > library.
> 
> Here it is.  It compiles, but I have no idea of the version of TCL
> this corresponds to (except that I wrote it in March 91).  I'll be
> happy to put this or an udpated version in the next release.

Here is a version that should work with TCL 6.2.  I am working on a
nice Modula-3 interface (interpreters are objects, char_star are
Text.T, and so on). 

Enjoy,
Eric.

#!/bin/sh
# This is a shell archive (shar 3.32)
# made 04/04/1992 03:06 UTC by muller@procope.pa.dec.com
# Source directory /tmp_mnt/flimflam/r/dlusers5/muller/tmp/tclexport
#
# existing files WILL be overwritten
#
# This shar contains:
# length  mode       name
# ------ ---------- ------------------------------------------
#  13775 -rw-r--r-- TclC.i3
#    359 -rw-r--r-- TclC.m3
#   2167 -rw-r--r-- TclCTest.m3
#
if touch 2>&1 | fgrep 'amc' > /dev/null
 then TOUCH=touch
 else TOUCH=true
fi
# ============= TclC.i3 ==============
echo "x - extracting TclC.i3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > TclC.i3 &&
X(* Copyright (C) 1991, Digital Equipment Corporation           *)
X(* All rights reserved.                                        *)
X(* See the file COPYRIGHT for a full description.              *)
X
X(* Last modified on Fri Apr 03 19:09:01 PST 1992 by muller         *)
X
X(* Version 6.2 of TCL *)
X
X(* This file is derived from tcl.h, covered by the following copyright:
X
X * Copyright 1987, 1990 Regents of the University of California
X * Permission to use, copy, modify, and distribute this
X * software and its documentation for any purpose and without
X * fee is hereby granted, provided that the above copyright
X * notice appear in all copies.  The University of California
X * makes no representations about the suitability of this
X * software for any purpose.  It is provided "as is" without
X * express or implied warranty.
X *)
X
XUNSAFE INTERFACE TclC;
X
XFROM Ctypes IMPORT char_star, int_star, int, char,
X                   double_star, int_star_star, long_star;
XIMPORT Word;
X
XCONST
X  TCL_OK       = 0;
X  TCL_ERROR    = 1;
X  TCL_RETURN   = 2;
X  TCL_BREAK    = 3;
X  TCL_CONTINUE = 4;
X
X  TCL_RESULT_SIZE = 199;
X
X  BRACKET_TERM  = 1;
X  DONT_USE_BRACES = 1;
X  NO_EVAL       = -1;
X
XVAR (* READONLY *)
X  volatile,  static,  dynamic: FreeProc;
X
XCONST
X  GLOBAL_ONLY =      1;
X  APPEND_VALUE =     2;
X  LIST_ELEMENT =     4;
X  NO_SPACE =         8;
X  TRACE_READS =      16_10;
X  TRACE_WRITES =     16_20;
X  TRACE_UNSETS =     16_40;
X  TRACE_DESTROYED =  16_80;
X  INTERP_DESTROYED = 16_100;
X  LEAVE_ERR_MSG	=    16_200;
X
X  VARIABLE_UNDEFINED = 8;
X
XTYPE
X  FreeProc = PROCEDURE (blockPtr: char_star);
X
X  Interp = RECORD
X             result: char_star;
X             freeProc: FreeProc;
X             errorLine: int; END;
X
X  Interp_star = UNTRACED REF Interp;
X
X  ClientData = Word.T;
X
X  Argv = UNTRACED REF ARRAY [0..255] OF char_star;
X  Argv_star = UNTRACED REF Argv;
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_AddErrorInfo *>
XPROCEDURE AddErrorInfo (interp: Interp_star; message: char_star);
X
X<*EXTERNAL Tcl_SetErrorCode *>
XPROCEDURE SetErrorCode (interp: Interp_star;
X                        s1, s2, s3, s4, s5: char_star := NIL);
X
X<*EXTERNAL Tcl_UnixError *>
XPROCEDURE UnixError (interp: Interp_star): char_star;
X
X(*---------------------------------------------------------------------------*
)
X
XTYPE
X  CmdBuf = int_star;
X
X<*EXTERNAL Tcl_CreateCmdBuf *>
XPROCEDURE CreateCmdBuf (): CmdBuf;
X
X<*EXTERNAL Tcl_DeleteCmdBuf *>
XPROCEDURE DeleteCmdBuf (buffer: CmdBuf);
X
X<*EXTERNAL Tcl_AssembleCmd *>
XPROCEDURE AssembleCmd (buffer: CmdBuf; string: char_star): char_star;
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_Backslash *>
XPROCEDURE Backslash (src: char_star; count: int_star): char;
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_Concat *>
XPROCEDURE Concat (argc: int; argv: Argv): char_star;
X
X(*---------------------------------------------------------------------------*
)
X
XTYPE
X  CmdProc = PROCEDURE (clientData: ClientData;
X                       interp: Interp_star;
X                       argc:   int;
X                       argv:   Argv): int;
X
X  CmdDeleteProc  = PROCEDURE (clientData: ClientData);
X
X<*EXTERNAL Tcl_CreateCommand *>
XPROCEDURE CreateCommand (interp: Interp_star; 
X                         cmdName: char_star; 
X                         proc: CmdProc;
X                         clientData: ClientData;
X                         deleteProc: CmdDeleteProc);
X
X<*EXTERNAL Tcl_DeleteCommand *>
XPROCEDURE DeleteCommand (interp: Interp_star;
X                         cmdName: char_star);
X
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_CreateInterp *>
XPROCEDURE CreateInterp (): Interp_star;
X
X<*EXTERNAL Tcl_DeleteInterp *>
XPROCEDURE DeleteInterp (interp: Interp_star);
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_CreatePipeline *>
XPROCEDURE CreatePipeline (interp: Interp_star;
X                          argc: int;
X                          argv: Argv;
X                          pidArrayPtr: int_star_star;
X                          inPipePtr: char_star;
X                          outPipePtr: char_star;
X                          errFilePr: char_star): int;
X
X(*---------------------------------------------------------------------------*
)
X
XTYPE
X  CmdTraceProc = PROCEDURE (clientData: ClientData;
X                            interp: Interp_star;
X                            level: int;
X                            command: char_star;
X                            cmdProc: CmdProc;
X                            cmdClientData: ClientData;
X                            argc: int;
X                            argv: Argv);
X  Trace = int_star;
X
X<*EXTERNAL Tcl_CreateTrace *>
XPROCEDURE CreateTrace (interp: Interp_star;
X                       level: int;
X                       proc: CmdTraceProc;
X                       clientData: ClientData): Trace;
X
X<*EXTERNAL Tcl_DeleteTrace *>
XPROCEDURE DeleteTrace (interp: Interp_star; trace: Trace);
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_Eval *>
XPROCEDURE Eval (interp: Interp_star;
X                cmd: char_star;
X                flags: int;
X                termPtr: Argv): int;
X
X<*EXTERNAL Tcl_VarEval *>
XPROCEDURE VarEval (interp: Interp_star;
X                   s1, s2, s3, s4, s5: char_star := NIL): int;
X
X<*EXTERNAL Tcl_EvalFile *>
XPROCEDURE EvalFile (interp: Interp_star;
X                    fileName: char_star);
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_ExprLong *>
XPROCEDURE ExprLong (interp: Interp_star; 
X                    string: char_star; longPtr: long_star): int;
X
X<*EXTERNAL Tcl_ExprDouble *>
XPROCEDURE ExprDouble (interp: Interp_star; 
X                      string: char_star; doublePtr: double_star): int;
X
X<*EXTERNAL Tcl_ExprBoolean *>
XPROCEDURE ExprBoolean (interp: Interp_star; 
X                       string: char_star; booleanPtr: int_star): int;
X
X<*EXTERNAL Tcl_ExprString *>
XPROCEDURE ExprString (interp: Interp_star; 
X                      string: char_star): int;
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_Fork *>
XPROCEDURE Fork (): int;
X
X<*EXTERNAL Tcl_WaitPids *>
XPROCEDURE WaitPids (numPids: int; pidPtr, statusPtr: int_star): int;
X
X<*EXTERNAL Tcl_DetachPids *>
XPROCEDURE DetachPids (numPids: int; pidPtr: int_star): int;
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_GetInt *>
XPROCEDURE GetInt (interp: Interp_star; 
X                  string: char_star; intPtr: int_star): int;
X
X<*EXTERNAL Tcl_GetDouble *>
XPROCEDURE GetDouble (interp: Interp_star;
X		     string: char_star; doublePtr: double_star): int;
X
X<*EXTERNAL Tcl_GetBoolean *>
XPROCEDURE GetBoolean (interp: Interp_star; 
X		      string: char_star; boolPtr: int_star): int;
X
X(*---------------------------------------------------------------------------*
)
X
XTYPE
X  HashEntry = RECORD
X                nextPtr: HashEntry_star;
X                tablePtr: HashTable_star;
X                bucketPtr: HashEntry_star_star;
X                clientData: ClientData;
X                key: Word.T; END;
X  HashEntry_star = UNTRACED REF HashEntry;
X  HashEntry_star_star = UNTRACED REF HashEntry_star;
X  
X
XCONST
X  SMALL_HASH_TABLE = 4;
X
XTYPE
X  HashTable = RECORD 
X                buckets: HashEntry_star_star;
X                staticBuckets: ARRAY [0..SMALL_HASH_TABLE-1] OF HashEntry_star
;
X                numBuckets: int;
X                numEntries: int;
X                rebuildSize: int;
X                downShift: int;
X                mask: int;
X                keyType: int;
X                findProc: PROCEDURE (tablePtr: HashTable_star; 
X                                     key: char_star): HashEntry_star;
X                createProc: PROCEDURE (tablePtr: HashTable_star; 
X                                     key: char_star; 
X                                     newPtr: int_star): HashEntry_star; END;
X
X  HashTable_star = UNTRACED REF HashTable;
X          
X  HashSearch = RECORD
X                 tablePtr: HashTable_star;
X                 nextIndex: int;
X                 nextEntryPtr: HashEntry_star; END;
X
X  HashSearch_star = UNTRACED REF HashSearch;
X
X<*EXTERNAL Tcl_InitHashTable *>
XPROCEDURE InitHashTable (tablePtr: HashTable_star; keyType: int);
X
X<*EXTERNAL Tcl_DeleteHashTable *>
XPROCEDURE DeleteHashTable (tablePtr: HashTable_star);
X
X<*EXTERNAL Tcl_CreateHashEntry *>
XPROCEDURE CreateHashEntry (tablePtr: HashTable_star; 
X                           key: char_star; newPtr: int_star): HashEntry_star;
X
X<*EXTERNAL Tcl_DeleteHashEntry *>
XPROCEDURE DeleteHashEntry (entryPtr: HashEntry_star);
X
X<*EXTERNAL Tcl_FindHashEntry *>
XPROCEDURE FindHashEntry (tablePtr: HashTable_star; 
X                         key: char_star): HashEntry_star;
X
X<*EXTERNAL Tcl_GetHashValue *>
XPROCEDURE GetHashValue (entryPtr: HashEntry_star): ClientData;
X
X<*EXTERNAL Tcl_SetHashValue *>
XPROCEDURE SetHashValue (entryPtr: HashEntry_star; value: ClientData);
X
X<*EXTERNAL Tcl_GetHashKey *>
XPROCEDURE GetHashKey (tablePtr: HashTable_star;
X                      entryPtr: HashEntry_star): char_star;
X
X<*EXTERNAL Tcl_FirstHashEntry *>
XPROCEDURE FirstHashEntry (tablePtr: HashTable_star; 
X                          searchPtr: HashSearch_star): HashEntry_star;
X
X<*EXTERNAL Tcl_NextHashEntry *>
XPROCEDURE NextHashEntry (searchPtr: HashSearch_star): HashEntry_star;
X
X<*EXTERNAL Tcl_HashStats *>
XPROCEDURE HashStats (tablePtr: HashTable_star): char_star;
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_InitHistory *>
XPROCEDURE InitHistory (interp: Interp_star);
X
X<*EXTERNAL Tcl_RecordAndEval *>
XPROCEDURE RecordAndEval (interp: Interp_star; 
X                         cmd: char_star; flags: char): int;
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_SetResult *>
XPROCEDURE SetResult (interp: Interp_star;
X                     string: char_star; freeProc: FreeProc);
X
X<*EXTERNAL Tcl_AppendResult *>
XPROCEDURE AppendResult (interp: Interp_star;
X			s1, s2, s3, s4, s5: char_star := NIL);
X
X<*EXTERNAL Tcl_AppendElement *>
XPROCEDURE AppendElement (interp: Interp_star; string: char_star; noSep: int);
X
X<*EXTERNAL Tcl_ResetResult *>
XPROCEDURE ResetResult (interp: Interp_star);
X
XPROCEDURE FreeResult (interp: Interp_star);
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_SetVar *>
XPROCEDURE SetVar (interp: Interp_star; 
X                  varName, newValue: char_star; flags: int);
X
X<*EXTERNAL Tcl_SetVar2 *>
XPROCEDURE SetVar2 (interp: Interp_star; 
X                   name1, name2, newValue: char_star; flags: int);
X
X<*EXTERNAL Tcl_GetVar *>
XPROCEDURE GetVar (interp: Interp_star; 
X		  varName: char_star; flags: int): char_star;
X
X<*EXTERNAL Tcl_GetVar2 *>
XPROCEDURE GetVar2 (interp: Interp_star; 
X		   name1, name2: char_star; flags: int): char_star;
X
X<*EXTERNAL Tcl_UnsetVar *>
XPROCEDURE UnsetVar (interp: Interp_star; 
X	  	    varName: char_star; flags: int): int;
X 
X<*EXTERNAL Tcl_UnsetVar2 *>
XPROCEDURE UnsetVar2 (interp: Interp_star; 
X	  	     name1, name2: char_star; flags: int): int;
X 
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_SplitList *>
XPROCEDURE SplitList (interp: Interp_star; 
X 		     list: char_star;
X		     argcPtr: int_star;
X		     argvPtr: Argv_star): int;
X
X<*EXTERNAL Tcl_Merge *>
XPROCEDURE Merge (argc: int; argv: Argv): char_star;
X
X<*EXTERNAL Tcl_ScanElement *>
XPROCEDURE ScanElement (src: char_star; flagsPtr: int_star): int;
X
X<*EXTERNAL Tcl_ConvertElement *>
XPROCEDURE ConvertElement (src, dst: char_star; flags: int): int;
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_StringMatch *>
XPROCEDURE StringMatch (string, pattern: char_star): int;
X
X(*---------------------------------------------------------------------------*
)
X
X<*EXTERNAL Tcl_TildeSubst *>
XPROCEDURE TildeSubst (interp: Interp_star; name: char_star): char_star;
X
X(*---------------------------------------------------------------------------*
)
X
XTYPE
X  VarTraceProc = PROCEDURE (clientData: ClientData;
X                            interp: Interp_star;
X			    varName: char_star;
X                            global, flags: int;
X                            oldValue, newValue: char_star): char_star;
X
X<*EXTERNAL Tcl_TraceVar *>
XPROCEDURE TraceVar (interp: Interp_star; 
X		    varName: char_star;
X		    flags: int;
X		    proc: VarTraceProc;
X		    clientData: ClientData): int;
X
X<*EXTERNAL Tcl_TraceVar2 *>
XPROCEDURE TraceVar2 (interp: Interp_star; 
X		     name1, name2: char_star;
X		     flags: int;
X		     proc: VarTraceProc;
X		     clientData: ClientData): int;
X
X<*EXTERNAL Tcl_UnTraceVar *>
XPROCEDURE UnTraceVar (interp: Interp_star;
X                      varName: char_star;
X                      flags: int;
X                      proc: VarTraceProc;
X  		      clientData: ClientData);
X
X<*EXTERNAL Tcl_UnTraceVar2 *>
XPROCEDURE UnTraceVar2 (interp: Interp_star;
X                       name1, name2: char_star;
X                       flags: int;
X                       proc: VarTraceProc;
X  		       clientData: ClientData);
X
X<*EXTERNAL Tcl_VarTraceInfo *>
XPROCEDURE VarTraceInfo (interp: Interp_star; 
X			varName: char_star; 
X			flags: int;
X			proc: VarTraceProc;
X			prevClientData: ClientData): int;
X
X<*EXTERNAL Tcl_VarTraceInfo2 *>
XPROCEDURE VarTraceInfo2 (interp: Interp_star; 
X			 name1, name2: char_star; 
X 			 flags: int;
X			 proc: VarTraceProc;
X			 prevClientData: ClientData): int;
X
X(*---------------------------------------------------------------------------*
)
X
XEND TclC.
SHAR_EOF
$TOUCH -am 0403190992 TclC.i3 &&
chmod 0644 TclC.i3 ||
echo "restore of TclC.i3 failed"
set `wc -c TclC.i3`;Wc_c=$1
if test "$Wc_c" != "13775"; then
	echo original size 13775, current size $Wc_c
fi
# ============= TclC.m3 ==============
echo "x - extracting TclC.m3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > TclC.m3 &&
XUNSAFE MODULE TclC;
X
XIMPORT Cstdlib;
X
XPROCEDURE FreeResult (interp: Interp_star) = 
X  BEGIN
X    IF interp.freeProc # NIL THEN
X      interp.freeProc (interp.result);
X      interp.freeProc := NIL; END;
X  END FreeResult;
X
X
XBEGIN
X  volatile := LOOPHOLE (-1, FreeProc);
X  static := LOOPHOLE (0, FreeProc);
X  dynamic := LOOPHOLE (Cstdlib.free, FreeProc);
XEND TclC.
SHAR_EOF
$TOUCH -am 0403190992 TclC.m3 &&
chmod 0644 TclC.m3 ||
echo "restore of TclC.m3 failed"
set `wc -c TclC.m3`;Wc_c=$1
if test "$Wc_c" != "359"; then
	echo original size 359, current size $Wc_c
fi
# ============= TclCTest.m3 ==============
echo "x - extracting TclCTest.m3 (Text)"
sed 's/^X//' << 'SHAR_EOF' > TclCTest.m3 &&
X(* Copyright (C) 1991, Digital Equipment Corporation           *)
X(* All rights reserved.                                        *)
X(* See the file COPYRIGHT for a full description.              *)
X
X
XUNSAFE MODULE TclCTest EXPORTS Main;
X
XIMPORT TclC;
XIMPORT Rd, Wr, Stdio, Fmt;
XFROM M3toC IMPORT TtoS, CopyTtoS, CopyStoT;
XFROM Ctypes IMPORT int, char_star;
X
X<*FATAL ANY*>
X
XPROCEDURE FactCmd (<*UNUSED*> clientData: TclC.ClientData;
X		   interp: TclC.Interp_star;
X   	 	   argc: int;
X		   argv: TclC.Argv): int =
X  BEGIN
X    IF argc # 2 THEN
X      interp.result := TtoS ("fact has exactly one argument");
X      RETURN TclC.TCL_ERROR; 
X    ELSE
X      VAR i: INTEGER; BEGIN
X        IF TclC.GetInt (interp, argv[1], ADR (i)) = TclC.TCL_ERROR THEN
X          RETURN TclC.TCL_ERROR; END;
X        interp.result := CopyTtoS (Fmt.Int (Fact (i)));
X        RETURN TclC.TCL_OK; END; END;
X  END FactCmd;
X
XPROCEDURE Fact (i: INTEGER): INTEGER =
X  BEGIN
X    IF i = 1 THEN
X      RETURN 1;
X    ELSE 
X      RETURN i * Fact (i - 1); END;
X  END Fact;
X
X
XVAR
X  i: TclC.Interp_star;
X  buf: TclC.CmdBuf;
X  s: char_star;
X  status: int;
X
XBEGIN
X  i := TclC.CreateInterp ();
X  TclC.CreateCommand (i, TtoS ("fact"), FactCmd, 0, NIL);
X  buf := TclC.CreateCmdBuf ();
X
X  TRY
X    LOOP 
X      Wr.PutText (Stdio.stdout, "-> ");
X      Wr.Flush (Stdio.stdout);
X      s := TclC.AssembleCmd (buf, TtoS (Rd.GetLine (Stdio.stdin) & "\n"));
X      IF s # NIL THEN
X        status := TclC.RecordAndEval (i, s, 0);
X        CASE status OF 
X        | TclC.TCL_OK =>
X            Wr.PutText (Stdio.stdout, CopyStoT (i.result) & "\n"); 
X            Wr.Flush (Stdio.stdout);
X        | TclC.TCL_ERROR =>
X            Wr.PutText (Stdio.stderr, "error: " & CopyStoT (i.result) & "\n");
 
X            Wr.Flush (Stdio.stdout);
X        ELSE
X            Wr.PutText (Stdio.stderr, "TclC.Eval returned with code = " 
X					& Fmt.Int (status) & "\n"); 
X            Wr.Flush (Stdio.stdout);
X                                                        END; END; END; 
X  EXCEPT
X  | Rd.EndOfFile => END;
X
X  TclC.DeleteCmdBuf (buf);
X  TclC.DeleteInterp (i);
XEND TclCTest.
SHAR_EOF
$TOUCH -am 0403190992 TclCTest.m3 &&
chmod 0644 TclCTest.m3 ||
echo "restore of TclCTest.m3 failed"
set `wc -c TclCTest.m3`;Wc_c=$1
if test "$Wc_c" != "2167"; then
	echo original size 2167, current size $Wc_c
fi
exit 0


======================================================================= 49 ===
Date:    5 Apr 92 06:49:14 GMT
From:    schwartz@groucho.cs.psu.edu (Scott Schwartz)
Subject: Re: why modula3?


mjordan@src.dec.com (Mick Jordan) writes:
   melling@cs.psu.edu (Michael D Mellinger) writes:
   > chased@rbbb.Eng.Sun.COM (David Chase) writes:
   >    VERBOSE UPPERCASE IDENTIFIERS.
   > Will this be "fixed"?  My fingers bother me enough as it is without
   > having to reach for the shift key all the time.

   I suggest you use the gnuemacs modula-3 mode in which case you will not
   have to type reserved words very often.

I suggest that no one make that argument outside this newsgroup.
Elsewhere, people will recognize that it explicitly admits that there
is a very serious problem with m3, one which requires complex and
expensive tools to work around.  Many of those people will walk away
from m3 forever, never giving it a fair chance, thinking to
themselves, 'Upper case identifiers...  must be a toy language.'

Granted this is what Wirth calls an ephemeral issue, but it is one of
those emotional things that can really hurt an up and coming language.
Keywords are things you type often: as a practical matter ``proc'' is
very much nicer than ``PROCEDURE''.

Fortunately, the DEC M3 compiler comes with sources, so we can all fix
this little problem before it gets carved in stone.

(Sorry to be uptight, but my tendinitis is in upper case today.)


======================================================================= 50 ===
Date:    3 Apr 92 21:32:57 GMT
From:    wkh@duke.austin.ibm.com (Ward K Harold)
Subject: Re: why modula3?

In article <1992Apr2.125203.8319@src.dec.com>, mjordan@src.dec.com (Mick Jordan
) writes:
|> I suggest you use the gnuemacs modula-3 mode in which case you will not
|> have to type reserved words very often.
|> 
|> Mick Jordan

I fear this is a FAQ but just where does the modula-3 mode .el live?  I
looked on archive.cis.ohio-state.edu but it wasn't there.

... WkH

-- 
Ward K Harold				(512) 838-3473 [T/L 678-3473]
IBM Personal Systems Programming	external: wkh@dce.austin.ibm.com
11400 Burnet Rd., Zip 9541		internal: wkh@duke.austin.ibm.com
Austin, TX  78758			vnet: wharrold --ausvmq


======================================================================= 51 ===
Date:    Sun, 5 Apr 92 10:24:01 EDT
From:    wyant@centerline.com
Subject: M3TK for M3 2.05 ?

Is there a new version of M3TK forthcoming ?
I'm trying build the current version under
2.05, but lib/oli gets a significant number
of syntax errors. I thought that before I
delved into this, I'd see if there was a
version that compiled under M3 2.0 coing
out soon.

thanks !

Geoff Wyant
wyant@centerline.com
Centerline Software, Inc.
(Formerly Saber Software, Inc)
10 Fawcett Street
Cambridge, Ma.
01237


======================================================================= 52 ===
Date:    5 Apr 92 21:08:04 GMT
From:    jhummel@broadway.ics.uci.edu (Joseph Edward Hummel)
Subject: real applications where OO did/didn't work well?

Hello all.  Being a student with (as yet :-) little industrial experience,
I'm looking for info on real applications where OOP was used.  I'm
particularly interested in info about how well you feel the OO paradigm
worked in this particular problem -- good or bad.

Please respond by email, and I'll post the results since I think others
will find this interesting (if it hasn't been done already?).

Thanks in advance...

  - joe hummel
    (jhummel@ics.uci.edu)
--
Joe Hummel
ICS Graduate Student, UC Irvine
Internet: jhummel@ics.uci.edu


======================================================================= 53 ===
Date:    6 Apr 92 07:19:12 GMT
From:    qs101@cl.cam.ac.uk (Quentin Stafford-Fraser)
Subject: Gatekeeper


Gatekeeper is now giving me 'User anonymous unknown' messages.
Should I be getting things from somewhere else now?


Quentin

 -----------------------------------
 Quentin Stafford-Fraser            
 Cambridge University Computer Lab  
 qs101@cl.cam.ac.uk
 Tel +44 223 334645
 -----------------------------------


======================================================================= 54 ===
Date:    6 Apr 92 09:19:01 GMT
From:    pfrants@cs.vu.nl (Frants P)
Subject: GATEKEEPER!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Why does gatekeeper.dec.com not recognize "anonymous"?


When will this problem be out of this world???????


======================================================================= 55 ===
Date:    Mon, 6 Apr 92 09:30:21 PDT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: M3TK for M3 2.05 ?

In article <9204051424.AA22562@riposte>, wyant@centerline.com writes:
> Is there a new version of M3TK forthcoming ?
> I'm trying build the current version under
> 2.05, but lib/oli gets a significant number
> of syntax errors. I thought that before I
> delved into this, I'd see if there was a
> version that compiled under M3 2.0 coing
> out soon.
> 

Yes. I am preparing it for release to gatekeeper as I write. Barring some disas
ter
it will be available by the end of the week.

Mick Jordan


======================================================================= 56 ===
Date:    6 Apr 92 14:58:54 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Uppercase reserved words (was: Re: why modula3?)

Re: the post FROM schwartz@groucho.cs.psu.edu (Scott Schwartz), who
RAISES an objection TO upper CASE identifiers.

To SET the RECORD straight, WHILE I have some sympathy FOR his point,
his EXCEPTION TO upper CASE identifiers is a too NARROW, AND NOT a
reason TO go through the CEILING.  (What VALUE a language FOR which
different compilers could OVERRIDE reserved word spelling?  I hope the
chance OF anyone using this LOOPHOLE is NIL.)  I DO NOT think upper
CASE id's have BRANDED Modula-3 a loser. We can DISPOSE OF that
argument.  It is NOT NEW AND there is no need TO REPEAT it.

Let me BEGIN TO ADDRESS this issue: TRUE, I used TO OBJECT TO upper
CASE reserved words when I FIRST saw them because they made my code
look ugly. That was UNTIL I got more experience. At LAST, I like them.
They cut down on on the name space pollution. I like being able TO use
ANY lower CASE identifiers (such AS "from" AND "to") IN my code.  A
close reading OF the book will REVEAL that that Modula-3 has about 100
reserved identifiers (TO use a ROUND NUMBER).  This includes
predefined identifiers WITH keywords. (It is a CARDINAL rule that you
can't use predefined identifiers FOR ANY other purpose IN Modula-3.)
IN the END, I think DEC simply had a BOOLEAN choice TO make, AND
they made it right.

TO avoid an EXTENDED debate AND RETURN TO the REAL issue, let me RAISE
a NEW possibility (OF some VALUE) IN the ARRAY OF solutions FOR GNU emacs
users.  TRY using abbrev mode--it's one OF the better METHODS.  IF you
TYPE your TEXT IN lower CASE, THEN you will get upper CASE reserved
words. I have included the necessary definitions below so you can
IMPORT them into your program.  Warning: Test before using, ELSE the
result may be UNSAFE. I didn't have time FOR a NUMBER OF tests. (Only
one.)

Sam Harbison 
Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA
15213; USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com.

----

PROCEDURE: Change 'global-abbrev-table ' TO 'yourmode-abbrev-table '
IF necessary.  Read IN WITH M-x read-abbrev-file$.

(define-abbrev-table 'global-abbrev-table '(
    ("methods" "METHODS" nil 0)
    ("abs" "ABS" nil 0)
    ("loop" "LOOP" nil 0)
    ("raises" "RAISES" nil 0)
    ("return" "RETURN" nil 0)
    ("bitsize" "BITSIZE" nil 0)
    ("max" "MAX" nil 0)
    ("value" "VALUE" nil 0)
    ("cardinal" "CARDINAL" nil 0)
    ("exports" "EXPORTS" nil 0)
    ("set" "SET" nil 0)
    ("except" "EXCEPT" nil 0)
    ("nil" "NIL" nil 0)
    ("false" "FALSE" nil 0)
    ("or" "OR" nil 0)
    ("if" "IF" nil 0)
    ("eval" "EVAL" nil 0)
    ("min" "MIN" nil 0)
    ("narrow" "NARROW" nil 0)
    ("not" "NOT" nil 0)
    ("try" "TRY" nil 0)
    ("typecode" "TYPECODE" nil 0)
    ("boolean" "BOOLEAN" nil 0)
    ("text" "TEXT" nil 0)
    ("loophole" "LOOPHOLE" nil 0)
    ("unsafe" "UNSAFE" nil 0)
    ("readonly" "READONLY" nil 0)
    ("record" "RECORD" nil 0)
    ("import" "IMPORT" nil 0)
    ("branded" "BRANDED" nil 0)
    ("raise" "RAISE" nil 0)
    ("any" "ANY" nil 0)
    ("array" "ARRAY" nil 0)
    ("extended" "EXTENDED" nil 0)
    ("repeat" "REPEAT" nil 0)
    ("typecase" "TYPECASE" nil 0)
    ("end" "END" nil 0)
    ("of" "OF" nil 0)
    ("bytesize" "BYTESIZE" nil 0)
    ("lonreal" "LONREAL" nil 0)
    ("override" "OVERRIDE" nil 0)
    ("reveal" "REVEAL" nil 0)
    ("subarray" "SUBARRAY" nil 0)
    ("while" "WHILE" nil 0)
    ("ref" "REF" nil 0)
    ("var" "VAR" nil 0)
    ("new" "NEW" nil 0)
    ("const" "CONST" nil 0)
    ("procedure" "PROCEDURE" nil 0)
    ("round" "ROUND" nil 0)
    ("mutex" "MUTEX" nil 0)
    ("to" "TO" nil 0)
    ("ceiling" "CEILING" nil 0)
    ("mod" "MOD" nil 0)
    ("until" "UNTIL" nil 0)
    ("val" "VAL" nil 0)
    ("object" "OBJECT" nil 0)
    ("with" "WITH" nil 0)
    ("module" "MODULE" nil 0)
    ("integer" "INTEGER" nil 0)
    ("refany" "REFANY" nil 0)
    ("bits" "BITS" nil 0)
    ("char" "CHAR" nil 0)
    ("float" "FLOAT" nil 0)
    ("then" "THEN" nil 0)
    ("last" "LAST" nil 0)
    ("trunc" "TRUNC" nil 0)
    ("address" "ADDRESS" nil 0)
    ("dec" "DEC" nil 0)
    ("finally" "FINALLY" nil 0)
    ("null" "NULL" nil 0)
    ("and" "AND" nil 0)
    ("do" "DO" nil 0)
    ("else" "ELSE" nil 0)
    ("istype" "ISTYPE" nil 0)
    ("untraced" "UNTRACED" nil 0)
    ("exception" "EXCEPTION" nil 0)
    ("begin" "BEGIN" nil 0)
    ("dispose" "DISPOSE" nil 0)
    ("floor" "FLOOR" nil 0)
    ("true" "TRUE" nil 0)
    ("lock" "LOCK" nil 0)
    ("by" "BY" nil 0)
    ("exit" "EXIT" nil 0)
    ("adr" "ADR" nil 1)
    ("div" "DIV" nil 0)
    ("real" "REAL" nil 0)
    ("type" "TYPE" nil 0)
    ("elsif" "ELSIF" nil 0)
    ("for" "FOR" nil 0)
    ("number" "NUMBER" nil 0)
    ("from" "FROM" nil 0)
    ("root" "ROOT" nil 0)
    ("interface" "INTERFACE" nil 0)
    ("first" "FIRST" nil 0)
    ("ord" "ORD" nil 0)
    ("case" "CASE" nil 0)
    ("adrsize" "ADRSIZE" nil 0)
    ("as" "AS" nil 0)
    ("in" "IN" nil 0)
    ("inc" "INC" nil 0)
    ))


======================================================================= 57 ===
Date:    6 Apr 92 12:46:07 GMT
From:    weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT])
Subject: Re: GATEKEEPER!!!!!!!!!!!!!!!!!!!!!!!!!!!!

pfrants@cs.vu.nl (Frants P) writes:

>Why does gatekeeper.dec.com not recognize "anonymous"?
>When will this problem be out of this world???????

It's not gatekeeper.dec... they seem to have a problem in one of the 
top-level-nameservers, so that you don't get dec's gatekeeper.
Try the numerical address, that should work.

(Taken from a post to comp.protocols-tcpip.domains)

Regards

Christoph Weber-Fahr

-- 
  Christoph Weber-Fahr                  |  E-Mail:  weber@rhrk.uni-kl.de
  Universitaet Kaiserslautern,  KIT/IVS |  S-Mail:  Postfach 3049
  Tel. 0631/205-3391                    |           D-6750 Kaiserslautern
--------------------------  My personal opinion only    ---------------------


======================================================================= 58 ===
Date:    Mon, 6 Apr 92 16:04:42 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: GATEKEEPER!!!!!!!!!!!!!!!!!!!!!!!!!!!!

In article <1992Apr6.124607.20513@rhrk.uni-kl.de>, weber@rhrk.uni-kl.de (Christ
oph Weber-Fahr [KIT]) writes:

> It's not gatekeeper.dec... they seem to have a problem in one of the 
> top-level-nameservers, so that you don't get dec's gatekeeper.
> Try the numerical address, that should work.

Until the fix propagates from NIC, you can use the numerical address 16.1.0.2.

-- 
Eric.



======================================================================= 59 ===
Date:    Mon, 6 Apr 92 13:25:45 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: archive of comp.lang.modula3 for March 1992

The archive of the messages sent to comp.lang.modula3 in March 1992
is now available in:

	gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3/92-03.Z

Achives for the previous months are available in the same directory.

----
Eric.



======================================================================= 60 ===
Date:    Mon, 6 Apr 1992 13:40:55 PDT
From:    David Goldberg <goldberg@parc.xerox.com>
Subject: trestle and SPARC running OpenWindows 3.0

There is a problem with using trestle on SPARCs if you are running
Openwindows 3.0 (Openwin 2.0 works fine).

The problem is that any trestle application will crash the 3.0 xnews server.
There are two possible workarounds:

1.  Patch xnews.  The Sun bugID for this is 

        1082200 UngrabKey for a particular keycode after GrabKey
                for AnyKey crashes xnews

    Sun has a patch for this.  The one I got from Sun was labeled:

        Patch-ID# 100444-14
        Keywords: X11-NeWS, server, patch, xnews
        Synopsis: Openwindows V3.0 Server Patch 3000-22
        Date:04/01/92

2.  Patch Trestle

    replace

        X.XGrabKey(trsl.dpy, X.AnyKey, X.AnyModifier, ur.w, X.True, 
          X.GrabModeAsync, X.GrabModeAsync);

    with

        VAR min, max: INTEGER;
        BEGIN
          X.XDisplayKeycodes(trsl.dpy, ADR(min), ADR(max));
          FOR i := min TO max DO
            X.XGrabKey(trsl.dpy, i, X.AnyModifier, ur.w, X.True,
                       X.GrabModeAsync, X.GrabModeAsync);
          END;
        END;



  David Goldberg
  goldberg@parc.xerox.com


======================================================================= 61 ===
Date:    Mon, 6 Apr 1992 20:05:15 GMT
From:    twhlai@watdragon.waterloo.edu (Tony Lai)
Subject: Re: why modula3?

In article <=q9H4j2i6@cs.psu.edu> schwartz@groucho.cs.psu.edu (Scott Schwartz) 
writes:
>Elsewhere, people will recognize that it explicitly admits that there
>is a very serious problem with m3, one which requires complex and
>expensive tools to work around.  Many of those people will walk away
>from m3 forever, never giving it a fair chance, thinking to
>themselves, 'Upper case identifiers...  must be a toy language.'
[stuff deleted]

Are uppercase keywords really so bad?  It is simple to write a program
to convert one's favorite lowercase keywords to proper uppercase keywords.


======================================================================= 62 ===
Date:    6 Apr 92 22:55:43 GMT
From:    schwartz@roke.cs.psu.edu (Scott Schwartz)
Subject: Re: why modula3?

twhlai@watdragon.waterloo.edu (Tony Lai) writes:
   Are uppercase keywords really so bad?  It is simple to write a program
   to convert one's favorite lowercase keywords to proper uppercase keywords.

As I said, I was being uptight, but I do think this issue will turn a
lot of people off.  Yes, it is easy to write an encasing
program---maybe pp should be taught to do this as part of its other
functions.  But this admits that the common case is being penalized.
Eiffel, IMHO, does better, with keywords lowercase, and user supplied
classes (conventionally) named in uppercase.


======================================================================= 63 ===
Date:    Tue, 7 Apr 1992 11:19:21 PDT
From:    David Nichols <nichols@parc.xerox.com>
Subject: SunRPC implementation available

[I tried posting this from my news reader, but doesn't seem to have made
it outside of PARC.  My apologies if you see it twice.]

Our Modula-3 implementation of Sun RPC is now available for anonymous
ftp.  It consists of a stub compiler (based on rpcgen) that produces
object-oriented Modula-3 stubs and a runtime that is thread-safe
(although clients have some synchronization responsibilities).  There is
no support for authentication yet.  It has received some testing and use
here, but has not been used extensively.

The code is available on parcftp.xerox.com as "pub/m3/m3rpc.tar.Z".  For
your one-stop shopping convenience, I have also placed in that directory
a copy of the Modula-3 tags package David Goldberg announced recently.

Please send any bugs, comments, etc. to me (nichols@parc.xerox.com).

	David


======================================================================= 64 ===
Date:    7 Apr 92 20:56:53 GMT
From:    salomon@silver.cs.umanitoba.ca (Daniel J. Salomon)
Subject: Re: why modula3?

In article <1992Apr6.200515.22885@watdragon.waterloo.edu> twhlai@watdragon.wate
rloo.edu (Tony Lai) writes:
> Are uppercase keywords really so bad?  It is simple to write a program
> to convert one's favorite lowercase keywords to proper uppercase keywords.

I have written such a program, and included it with this posting.
It was not hard to write, but was rather tedious to type and test.

I wrote the original version because I had a problem with keywords in
Modula-2.  Although I prefer the appearance of uppercase keywords I
hate typing them in uppercase.  My solution was to write a filter that
would convert them to upper case.  I typically use it directly from vi
when editing a program (see below for more details).

Using this filter prevents you from using the reserved words in
lowercase as variables, but I don't think that that is a very safe
practice.   FOR for := from TO to DO do END;


#---- Remove this line and exerything before it. ----
#!/bin/csh
#
#   This shell script will generate the files:
#   m3uc.l, m3uc.flex, makefile.lex, and makefile.flex
#   The files contain both lex and flex source for a filter that
#   will read a Modula-3 source program and output it with all
#   the reserved keywords converted to uppercase.
#   Store this shell script in a file called bundle,
#   then to unbundle the files type:
#               sh bundle
#
#   If you have the scanner generator FLEX on your system, then
#   to compile the filter type the line:
#               make -f makefile.flex
#
#   If you do not have flex on your system, you can compile it using
#   lex by typing:
#               make -f makefile.lex
#
#   The program generated will be called "m3uc".
#   The program reads a Modula-3 program on standard input and
#   outputs it on standard output with all the keyword converted
#   to uppercase.
#   E.g.   m3uc  <mixed_case.m3 >upper_case.m3
#
#   The easiest way to use the filter is from inside vi.
#   To do so, move to the top of the file with the command: 1G
#   then pipe the whole program to the filter by typing: !G m3uc
#
sed -e s/X// <<==== >m3uc.l
X%{
X/*  		                       
X *  m3uc.l
X *  ======
X *  
X *  A lex script for a filter to convert Modula-3 keywords from
X *  mixed-case to uppercase.  Programs are easier to type if the
X *  keywords are entered in lowercase, but easier to read if the
X *  keywords are in uppercase.
X *  This filter gives you the best of both worlds.
X *
X *  The input is read from standard input, and the output generated
X *  on standard output.  Thus m3uc is easily used as a filter during
X *  a vi session.
X */
X
X    int comdep = 0;		/* Current comment nesting depth. */
X
X%}
X
X%Start  CODE COMMENT
X%a 5000
X%e 1500
X%k 1500
X%p 4000
X%o 7000
X
Xletter		[a-zA-Z]
Xdigit		[0-9]
Xa		[aA]
Xb		[bB]
Xc		[cC]
Xd		[dD]
Xe		[eE]
Xf		[fF]
Xg		[gG]
Xh		[hH]
Xi		[iI]
Xj		[jJ]
Xk		[kK]
Xl		[lL]
Xm		[mM]
Xn		[nN]
Xo		[oO]
Xp		[pP]
Xq		[qQ]
Xr		[rR]
Xs		[sS]
Xt		[tT]
Xu		[uU]
Xv		[vV]
Xw		[wW]
Xx		[xX]
Xy		[yY]
Xz		[zZ]
X
X%%
X
X			BEGIN CODE; /* Enter scanner in CODE state. */
X
X<CODE>"(*"		{ ECHO;  BEGIN COMMENT;  comdep++; }
X<COMMENT>"(*"		{ ECHO;  comdep++; }
X<COMMENT>"*)"		{
X			    ECHO;
X			    comdep--;
X			    if (comdep<1) BEGIN CODE;
X			}
X<COMMENT>.		ECHO;
X<COMMENT>\n		ECHO;
X<CODE>"*)"		{
X			    ECHO;
X			    fprintf (stderr,
X				"\n(**** Unopened comment. ****)\n");
X			}
X<CODE>{a}{b}{s}			printf ("ABS");
X<CODE>{a}{d}{d}{r}{e}{s}{s}	printf ("ADDRESS");
X<CODE>{a}{d}{r}			printf ("ADR");
X<CODE>{a}{d}{r}{s}{i}{z}{e}	printf ("ADRSIZE");
X<CODE>{a}{n}{d}			printf ("AND");
X<CODE>{a}{n}{y}			printf ("ANY");
X<CODE>{a}{r}{r}{a}{y}		printf ("ARRAY");
X<CODE>{a}{s}			printf ("AS");
X<CODE>{b}{e}{g}{i}{n}		printf ("BEGIN");
X<CODE>{b}{i}{t}{s}		printf ("BITS");
X<CODE>{b}{i}{t}{s}{i}{z}{e}	printf ("BITSIZE");
X<CODE>{b}{o}{o}{l}{e}{a}{n}	printf ("BOOLEAN");
X<CODE>{b}{r}{a}{n}{d}{e}{d}	printf ("BRANDED");
X<CODE>{b}{y}			printf ("BY");
X<CODE>{b}{y}{t}{e}{s}{i}{z}{e}	printf ("BYTESIZE");
X<CODE>{c}{a}{r}{d}{i}{n}{a}{l}	printf ("CARDINAL");
X<CODE>{c}{a}{s}{e}		printf ("CASE");
X<CODE>{c}{e}{i}{l}{i}{n}{g}	printf ("CEILING");
X<CODE>{c}{h}{a}{r}		printf ("CHAR");
X<CODE>{c}{o}{n}{s}{t}		printf ("CONST");
X<CODE>{d}{e}{c}			printf ("DEC");
X<CODE>{d}{i}{s}{p}{o}{s}{e}	printf ("DISPOSE");
X<CODE>{d}{i}{v}			printf ("DIV");
X<CODE>{d}{o}			printf ("DO");
X<CODE>{e}{l}{s}{e}		printf ("ELSE");
X<CODE>{e}{l}{s}{i}{f}		printf ("ELSIF");
X<CODE>{e}{n}{d}			printf ("END");
X<CODE>{e}{v}{a}{l}		printf ("EVAL");
X<CODE>{e}{x}{c}{e}{p}{t}	printf ("EXCEPT");
X<CODE>{e}{x}{c}{e}{p}{t}{i}{o}{n}	printf ("EXCEPTION");
X<CODE>{e}{x}{i}{t}		printf ("EXIT");
X<CODE>{e}{x}{p}{o}{r}{t}{s}	printf ("EXPORTS");
X<CODE>{e}{x}{t}{e}{n}{d}{e}{d}	printf ("EXTENDED");
X<CODE>{f}{a}{l}{s}{e}		printf ("FALSE");
X<CODE>{f}{i}{n}{a}{l}{l}{y}	printf ("FINALLY");
X<CODE>{f}{i}{r}{s}{t}		printf ("FIRST");
X<CODE>{f}{l}{o}{a}{t}		printf ("FLOAT");
X<CODE>{f}{l}{o}{o}{r}		printf ("FLOOR");
X<CODE>{f}{o}{r}			printf ("FOR");
X<CODE>{f}{r}{o}{m}		printf ("FROM");
X<CODE>{i}{f}			printf ("IF");
X<CODE>{i}{m}{p}{o}{r}{t}	printf ("IMPORT");
X<CODE>{i}{n}			printf ("IN");
X<CODE>{i}{n}{c}			printf ("INC");
X<CODE>{i}{n}{t}{e}{g}{e}{r}	printf ("INTEGER");
X<CODE>{i}{n}{t}{e}{r}{f}{a}{c}{e}	printf ("INTERFACE");
X<CODE>{i}{s}{t}{y}{p}{e}	printf ("ISTYPE");
X<CODE>{l}{a}{s}{t}		printf ("LAST");
X<CODE>{l}{o}{c}{k}		printf ("LOCK");
X<CODE>{l}{o}{n}{g}{r}{e}{a}{l}	printf ("LONGREAL");
X<CODE>{l}{o}{o}{p}		printf ("LOOP");
X<CODE>{l}{o}{o}{p}{h}{o}{l}{e}	printf ("LOOPHOLE");
X<CODE>{m}{a}{x}			printf ("MAX");
X<CODE>{m}{e}{t}{h}{o}{d}{s}	printf ("METHODS");
X<CODE>{m}{i}{n}			printf ("MIN");
X<CODE>{m}{o}{d}			printf ("MOD");
X<CODE>{m}{o}{d}{u}{l}{e}	printf ("MODULE");
X<CODE>{m}{u}{t}{e}{x}		printf ("MUTEX");
X<CODE>{n}{a}{r}{r}{o}{w}	printf ("NARROW");
X<CODE>{n}{e}{w}			printf ("NEW");
X<CODE>{n}{i}{l}			printf ("NIL");
X<CODE>{n}{o}{t}			printf ("NOT");
X<CODE>{n}{u}{l}{l}		printf ("NULL");
X<CODE>{n}{u}{m}{b}{e}{r}	printf ("NUMBER");
X<CODE>{o}{b}{j}{e}{c}{t}	printf ("OBJECT");
X<CODE>{o}{f}			printf ("OF");
X<CODE>{o}{r}			printf ("OR");
X<CODE>{o}{r}{d}			printf ("ORD");
X<CODE>{o}{v}{e}{r}{r}{i}{d}{e}	printf ("OVERRIDE");
X<CODE>{p}{r}{o}{c}{e}{d}{u}{r}{e} printf ("PROCEDURE");
X<CODE>{r}{a}{i}{s}{e}		printf ("RAISE");
X<CODE>{r}{a}{i}{s}{e}{s}	printf ("RAISES");
X<CODE>{r}{e}{a}{d}{o}{n}{l}{y}	printf ("READONLY");
X<CODE>{r}{e}{a}{l}		printf ("REAL");
X<CODE>{r}{e}{c}{o}{r}{d}	printf ("RECORD");
X<CODE>{r}{e}{f}			printf ("REF");
X<CODE>{r}{e}{f}{a}{n}{y}	printf ("REFANY");
X<CODE>{r}{e}{p}{e}{a}{t}	printf ("REPEAT");
X<CODE>{r}{e}{t}{u}{r}{n}	printf ("RETURN");
X<CODE>{r}{e}{v}{e}{a}{l}	printf ("REVEAL");
X<CODE>{r}{o}{o}{t}		printf ("ROOT");
X<CODE>{r}{o}{u}{n}{d}		printf ("ROUND");
X<CODE>{s}{e}{t}			printf ("SET");
X<CODE>{s}{u}{b}{a}{r}{r}{a}{y}	printf ("SUBARRAY");
X<CODE>{t}{e}{x}{t}		printf ("TEXT");
X<CODE>{t}{h}{e}{n}		printf ("THEN");
X<CODE>{t}{o}			printf ("TO");
X<CODE>{t}{r}{u}{e}		printf ("TRUE");
X<CODE>{t}{r}{u}{n}{c}		printf ("TRUNC");
X<CODE>{t}{r}{y}			printf ("TRY");
X<CODE>{t}{y}{p}{e}		printf ("TYPE");
X<CODE>{t}{y}{p}{e}{c}{a}{s}{e}	printf ("TYPECASE");
X<CODE>{t}{y}{p}{e}{c}{o}{d}{e}	printf ("TYPECODE");
X<CODE>{u}{n}{s}{a}{f}{e}	printf ("UNSAFE");
X<CODE>{u}{n}{t}{i}{l}		printf ("UNTIL");
X<CODE>{u}{n}{t}{r}{a}{c}{e}{d}	printf ("UNTRACED");
X<CODE>{v}{a}{l}			printf ("VAL");
X<CODE>{v}{a}{l}{u}{e}		printf ("VALUE");
X<CODE>{v}{a}{r}			printf ("VAR");
X<CODE>{w}{h}{i}{l}{e}		printf ("WHILE");
X<CODE>{w}{i}{t}{h}		printf ("WITH");
X
X<CODE>{letter}({letter}|{digit}|"_")*	ECHO;	/* Identifiers. */
X<CODE>\"([^\"\n])+\"	ECHO;	/* Quote delimited strings. */
X<CODE>\n		ECHO;
X<CODE>.		ECHO;	/* All other characters. */
X%%
====
sed -e s/X// <<==== >m3uc.flex
X%{
X/*  		                       
X *  m3uc.flex
X *  =========
X *  
X *  A flex script for a filter to convert Modula-3 keywords from
X *  mixed-case to uppercase.  This version takes advantage of flex's
X *  special feature for case insensitivity.  Programs are easier to
X *  type if the keywords are entered in lowercase, but easier to
X *  read if the keywords are in uppercase.
X *  This filter gives you the best of both worlds.
X *
X *  The input is read from standard input, and the output generated
X *  on standard output.  Thus m3uc is easily used as a filter during
X *  a vi session.
X */
X
X    int comdep = 0;		/* Current comment nesting depth. */
X
X%}
X
X%Start  CODE COMMENT
X
Xletter		[a-zA-Z]
Xdigit		[0-9]
X
X%%
X
X			BEGIN CODE; /* Enter scanner in CODE state. */
X
X<CODE>"(*"		{ ECHO;  BEGIN COMMENT;  comdep++; }
X<COMMENT>"(*"		{ ECHO;  comdep++; }
X<COMMENT>"*)"		{
X			    ECHO;
X			    comdep--;
X			    if (comdep<1) BEGIN CODE;
X			}
X<COMMENT>.		ECHO;
X<COMMENT>\n		ECHO;
X<CODE>"*)"		{
X			    ECHO;
X			    fprintf (stderr,
X				"\n(**** Unopened comment. ****)\n");
X			}
X<CODE>abs		printf ("ABS");
X<CODE>address		printf ("ADDRESS");
X<CODE>adr		printf ("ADR");
X<CODE>adrsize		printf ("ADRSIZE");
X<CODE>and		printf ("AND");
X<CODE>any		printf ("ANY");
X<CODE>array		printf ("ARRAY");
X<CODE>as		printf ("AS");
X<CODE>begin		printf ("BEGIN");
X<CODE>bits		printf ("BITS");
X<CODE>bitsize		printf ("BITSIZE");
X<CODE>boolean		printf ("BOOLEAN");
X<CODE>branded		printf ("BRANDED");
X<CODE>by		printf ("BY");
X<CODE>bytesize		printf ("BYTESIZE");
X<CODE>cardinal		printf ("CARDINAL");
X<CODE>case		printf ("CASE");
X<CODE>ceiling		printf ("CEILING");
X<CODE>char		printf ("CHAR");
X<CODE>const		printf ("CONST");
X<CODE>dec		printf ("DEC");
X<CODE>dispose		printf ("DISPOSE");
X<CODE>div		printf ("DIV");
X<CODE>do		printf ("DO");
X<CODE>else		printf ("ELSE");
X<CODE>elsif		printf ("ELSIF");
X<CODE>end		printf ("END");
X<CODE>eval		printf ("EVAL");
X<CODE>except		printf ("EXCEPT");
X<CODE>exception		printf ("EXCEPTION");
X<CODE>exit		printf ("EXIT");
X<CODE>exports		printf ("EXPORTS");
X<CODE>extended		printf ("EXTENDED");
X<CODE>false		printf ("FALSE");
X<CODE>finally		printf ("FINALLY");
X<CODE>first		printf ("FIRST");
X<CODE>float		printf ("FLOAT");
X<CODE>floor		printf ("FLOOR");
X<CODE>for		printf ("FOR");
X<CODE>from		printf ("FROM");
X<CODE>if		printf ("IF");
X<CODE>import		printf ("IMPORT");
X<CODE>in		printf ("IN");
X<CODE>inc		printf ("INC");
X<CODE>integer		printf ("INTEGER");
X<CODE>interface		printf ("INTERFACE");
X<CODE>istype		printf ("ISTYPE");
X<CODE>last		printf ("LAST");
X<CODE>lock		printf ("LOCK");
X<CODE>longreal		printf ("LONGREAL");
X<CODE>loop		printf ("LOOP");
X<CODE>loophole		printf ("LOOPHOLE");
X<CODE>max		printf ("MAX");
X<CODE>methods		printf ("METHODS");
X<CODE>min		printf ("MIN");
X<CODE>mod		printf ("MOD");
X<CODE>module		printf ("MODULE");
X<CODE>mutex		printf ("MUTEX");
X<CODE>narrow		printf ("NARROW");
X<CODE>new		printf ("NEW");
X<CODE>nil		printf ("NIL");
X<CODE>not		printf ("NOT");
X<CODE>null		printf ("NULL");
X<CODE>number		printf ("NUMBER");
X<CODE>object		printf ("OBJECT");
X<CODE>of		printf ("OF");
X<CODE>or		printf ("OR");
X<CODE>ord		printf ("ORD");
X<CODE>override		printf ("OVERRIDE");
X<CODE>procedure		printf ("PROCEDURE");
X<CODE>raise		printf ("RAISE");
X<CODE>raises		printf ("RAISES");
X<CODE>readonly		printf ("READONLY");
X<CODE>real		printf ("REAL");
X<CODE>record		printf ("RECORD");
X<CODE>ref		printf ("REF");
X<CODE>refany		printf ("REFANY");
X<CODE>repeat		printf ("REPEAT");
X<CODE>return		printf ("RETURN");
X<CODE>reveal		printf ("REVEAL");
X<CODE>root		printf ("ROOT");
X<CODE>round		printf ("ROUND");
X<CODE>set		printf ("SET");
X<CODE>subarray		printf ("SUBARRAY");
X<CODE>text		printf ("TEXT");
X<CODE>then		printf ("THEN");
X<CODE>to		printf ("TO");
X<CODE>true		printf ("TRUE");
X<CODE>trunc		printf ("TRUNC");
X<CODE>try		printf ("TRY");
X<CODE>type		printf ("TYPE");
X<CODE>typecase		printf ("TYPECASE");
X<CODE>typecode		printf ("TYPECODE");
X<CODE>unsafe		printf ("UNSAFE");
X<CODE>until		printf ("UNTIL");
X<CODE>untraced		printf ("UNTRACED");
X<CODE>val		printf ("VAL");
X<CODE>value		printf ("VALUE");
X<CODE>var		printf ("VAR");
X<CODE>while		printf ("WHILE");
X<CODE>with		printf ("WITH");
X
X<CODE>{letter}({letter}|{digit}|"_")*	ECHO;	/* Identifiers. */
X<CODE>\"([^\"\n])+\"	ECHO;	/* Quote delimited strings. */
X<CODE>\n		ECHO;
X<CODE>.		ECHO;	/* All other characters. */
X%%
====
sed -e s/X// <<==== >makefile.lex
X#  makefile.lex  - LEX version
X#  ============
X#
X#  Generate m3uc using LEX.
X#
X
Xm3uc: m3uc.c
X	cc -O m3uc.c -ll -o m3uc
X
Xm3uc.c: m3uc.l
X	lex m3uc.l
X	mv lex.yy.c m3uc.c
====
sed -e s/X// <<==== >makefile.flex
X#  makefile.flex  - FLEX version
X#  =============
X#
X#  Generate m3uc using FLEX.
X#
X
Xm3uc: m3uc.c
X	cc -O m3uc.c -ll -o m3uc
X
Xm3uc.c: m3uc.flex
X	flex -i m3uc.flex
X	mv lex.yy.c m3uc.c
====


======================================================================= 65 ===
Date:    8 Apr 92 15:18:41 GMT
From:    jjw1@mongoose.gte.com (Jim Walker)
Subject: Modula-3 for a Snake...

--------

Has anyone attempted or started on a port of the latest SRC Modula-3
stuff (2.04) to an HP 700 series machine?  I tried just compiling the
boot stuff for an HP300, but that did not get very far.  So, I was
thinking about making the big leap to do the port.

If anyone has already made a start (Piet?), maybe we should talk...
...Walker

--------
James Walker  <jjw1@gte.com>
GTE Laboratories, Waltham, MA
--
--------
James Walker  <jjw1@gte.com>
GTE Laboratories, Waltham, MA


======================================================================= 66 ===
Date:    Wed, 8 Apr 1992 12:01:33 PDT
From:    David Goldberg <goldberg@parc.xerox.com>
Subject: upper case keywords

Even if you believe that it is poor practice to use the name 'root' as
an identifier for the root of a tree (and not everyone does), you
can't avoid using keywords as identifiers because the interfaces 
supplied with the Modula3 distribution have over 100 instances of such 
use.  (A few examples follow).  Thus tools which always upcase keywords
will not always do the right thing.
 
  VBT.i3:PROCEDURE MiscCodeTypeName(type: MiscCodeType): TEXT;

  VBT.i3:PROCEDURE PutProp(v: T; ref: REFANY); <* LL.sup < v *>

  Unix.i3:<*EXTERNAL*> PROCEDURE rename (from, to: char_star): int; 

  IntTable.i3:PROCEDURE Get (t: T; key: INTEGER; VAR value: REFANY): BOOLEAN;

  RTScheduler.i3:PROCEDURE Pause (until: Time.T; alertable := FALSE)
       RAISES {Thread.Alerted}; 

  Pixmap.i3:PROCEDURE FromBitmap(bits: Raw): T; 
 

David Goldberg
goldberg@parc.xerox.com



======================================================================= 67 ===
Date:    Wed, 8 Apr 1992 11:32:04 PDT
From:    David Nichols <nichols@parc.xerox.com>
Subject: new m3rpc

I've placed a new copy of our RPC code on
parcftp.xerox.com:pub/m3/m3rpc.tar.Z.  This version fixes two problems
in the stub compiler: 1) strdup should no longer appear as an undef, and
2) a situation where a non-compiling stub was generated has been fixed. 
This could only happen if there was no program defined in the .x file.

The new version looks like this:

-rw-r--r--  1 nichols  parc       114065 Apr  8 11:26 m3rpc.tar.Z

Bugs, etc. to me at nichols@parc.xerox.com.

	David


======================================================================= 68 ===
Date:    9 Apr 92 18:17:12 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Errata, Modula-3 (addendum)

Since I posted an errata list for _Modula-3_ on March 24, a number of
other comments turned up. Here is a posting of the revised list. For
those of you who incorporated the older version, the only significant
changes are on pp. 5, 43, 75, and 177.  The complete list of changes
are pages 5, 35, 43, 75, 90, 155, 177, 178, 180, 191, 212, and 311.

	Errata: Modula-3
	(Prentice Hall, 1992)
	Samuel P. Harbison
	April 9, 1992

1.  Errata by Page

Line number "n" is the n'th line from the top of the page; line number 
"-n" is the n'th line from the bottom of the page. An "x" in the column 
labeled "Chg" means that the correction was supplied to the publisher and 
will appear in a future printing; no entry in that column means the problem 
was not considered serious enough to correct.

Page:Line:Chg:Description

1:-4:x:Change "it easy" to "it is easy".

3:-6:x:Change "MODULE Main" to "MODULE Hello1 EXPORTS Main".

3:-1:x:Change "END Main" to "END Hello1".

5:11:x:The sentence should read, "Therefore, the characters MODULEHello1 
	would be considered a single identifier rather than the reserved 
	word MODULE followed by the identifier Hello1." This was correct 
	in the first printing, but "MODULEHello1" may appear as "MODULE 
	Hello1" in the second printing.

5:-5:x:Change "MODULE Main" to "MODULE Hello1 EXPORTS Main".

5:-4:x:Change "END Main" to "END Hello1".

8:7:x:Change "Hello, World!" to "Hello, World!\n"

8::x:Swap positions of Example 1-4 and Figure 1-3.

10:-4:x:Rewrite last paragraph; mention left-associativity.

20:-5:x:Mention that loop variable i is declared in FOR statement.

20::x:Swap positions of Box and Example 2-5.

32:1:x:Add space before "By".

32:6:x:Change "n := n" to "n := BITSIZE(n)"

32:7:x:Add "because the result type of BITSIZE is always CARDINAL."

33:-4:x:Add missing ")" at end of declaration.

33:-5:x:Add missing ")" at end of declaration.

33:8:x:Fix typeface in exercise 4d.

35:1::Change "fifteen" to "eighteen."

38:-17::Change "a,pos" to "a, pos".

43:5:x:The box "Variations on Procedure Calls" makes an inaccurate statement 
	about Modula-2. Modula-2 requires "()" in function calls but not 
	in proper procedure calls.

49:8::"Solution" should be boldface.

50:1::In box, keywords should not be boldface.

57:-9:x:Rephrase as: "Which of the three versions is more readable?"

57:-5:x:Change "page 49" to "page 50".

64:-10:x: -8 MOD 3 is 1, not -1.

64:-5:x:x MOD 2 is 1 if x is odd; it cannot be -1.

67:19::Change "volume : [0..10]" to "volume: [0..10]".

74:-4:x:Add: The type of FIRST and LAST is the base type of T.

74:-4:x:Add: The type of NUMBER is CARDINAL.

74:-3:x:Add: "and has type T" to example of FIRST and LAST.

75:15:3:The solution presented in Example 4-14 doesn't work when VolumeLevel 
	is an enumeration or an integer subrange. The problem is that the 
	value of NewVolume may lie outside the range of VolumeLevel and 
	therefore cause a run-time error. Here is the new example and
	a revised following paragraph

    Example 4-14    

    Rewrite procedure ChangeVolume in Example 4-8 on page 67 assuming
    VolumeLevel is defined as the enumeration type {Off, Soft, Medium,
    Loud, Ear_splitting}.

    SOLUTION  You cannot compute the tentative value of NewVolume as
    VAL(ORD(volume)+n, VolumeLevel) without getting a checked run-time
    error if n is too large or too small. This makes the procedure
    somewhat more cumbersome. Here is one possibility, in which the
    range testing is hidden in the functions MIN and MAX:

	PROCEDURE ChangeVolume(n: INTEGER) =
	  BEGIN
	    WITH 
	      biggest  = ORD(LAST(VolumeLevel)),
	      smallest = ORD(FIRST(VolumeLevel)),
	      proposed = ORD(volume) + n
	    DO
	      volume := VAL(MAX(MIN(biggest,proposed),smallest),VolumeLevel);
	    END;

	  END ChangeVolume;

  Now suppose that v has the subrange type [T.A..T.B]. For the assignment 
  v := e to be legal, the type of e must either be T or else it must be a 
  subrange of T that includes at least one value in T.A..T.B. That is, the 
  types of v and e must share at least one value. Even if the assignment 
  is legal, it is a checked run-time error if the actual value of e is not 
  in T.A..T.B.

90:6:3:Change "Ans" to "answer".

111:6:x:Change "Point, the" to "Point (page 107), the".

111:-6:x:Change "SET OF t" to "SET OF T".

112:-5::Change "CARDINALITY" to "Cardinality".

112:-2::Identifiers in italics should be in the program typeface.

113:3:x:Change ":=" to "=".

129:1:x:Remove "[A]".

129:-3:x:Add "(or LAST(CARDINAL) if the array is empty)" before ":".

129:-10:x:Change "the procedure" to "ForAllElements".

134:-18::Change "out.If" to out. If".

136:1::In the box, the keyword ELSE should not be boldface.

141:18:x:Change "in procedure Forever" to "in the procedure".

141:-14:x:Change "ELSE =>" to "ELSE".

141:-9:x:Change "Chapter 12 (Threads)" to "Chapter 12".

155:-2:x:The last sentence should read: "Ordinary clients will import only 
	Basic, while trusted clients will import both Basic and Friendly 
	(Figure 8-5)."

168:1::In box, keyword "END" should not be boldface.

176:-9::Change "P" to "p" (four times) in Ex. 10-1 and following text.

177:-3:x:Change "beta := beta;" to "beta := alpha;"

178:-1:x:Add NEW to the list of builtin functions for reference types.

180:19::Add a semicolon after "theta := Math.Pi / 2.0".

191:-19::Change "IMPORTS Rational" to "IMPORT Rational".

212:-4::Since TL=TR implies TL<:TR, the first entry in the third row of 
	the table is understood to mean TL<:TR AND TL#TR. The table layout 
	already suggests this interpretation.

214::x:Add "RETURN self" to InitPostion and InitRectangle.

214:-19:x:Editorial changes to paragraph "The Rectangle.init method...".

218::x:Add "RETURN self" to InitPosition and InitRectangle.

219::x:Add "RETURN self" to InitCircle.

219:-8:x:Editorial changes were made to the last paragraph.

226:-7::Change typeface of "Child".

227:8:x:Mention that untraced things are discussed in 13.2 on p. 258.

227:-6:x:Change typeface of "name".

234::x:Change "94681" to "94861" (four times).

296:-7::Change "=QualID" to "= QualID".

299:7:x:The answer to D.1.5(c) is 11, not 3.

300:8:x:Change "a := y" to "b := y".

300:-16:x:Change all "A" and "B" to "a" and "b" in answer to exercise 9.

300:-11:x:Delete procedure heading; the solution is a block statement.

305:::Correct typeface of leading entry in letter groups as necessary.

305:::Add "Alerted (Thread)" to the index (cite p. 250)

311:4::Change "Subtypes (see Types)" to "Subtypes (see Type)".

2.  Errata History

This section lists the errata according to the date they were entered into 
the list.

2.1  March 24, 1992

Pages 1, 3, 5, 8, 10, 20, 32, 33, 56, 57, 64, 74, 111, 113, 129, 141, 214, 
218, 219, 227, 234, 299, 300.

These changes should be reflected in the book beginning with the second 
printing.

2.2  March 31, 1992

Pages 5, 35, 43, 75, 90, 155, 177, 178, 180.

These changes should be reflected in the book beginning with the second 
or third printing.

2.3  April 9, 1992

Pages 191, 212, 311.


======================================================================= 69 ===
Date:    Wed, 8 Apr 1992 12:05:06 GMT
From:    ian@syacus.acus.oz.au (Ian Joyner)
Subject: C++ Critique in comp.lang.c++

I have posted a critique of C++ in comp.lang.c++. This can form a basis of
comparison of Modula-3 and C++.
-- 
Ian Joyner                                     ACSNet: ian@syacus.acus.oz
ACUS (Australian Centre for Unisys Software)   Internet: ian@syacus.acus.oz.au
Tel 61-2-390 1328      Fax 61-2-390 1391       UUCP: ...uunet!munnari!syacus.oz


======================================================================= 70 ===
Date:    10 Apr 92 05:09:02 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Summer Opportunity for Modula-3 Programmer


Hi Folks. I would just like to remind our enthusiastic Modula-3 crowd
that we happen to have a summer position open for a full-time Modula-3
programmer. The position involves building nice front ends for our
Distributed Object Manager prototype using Trestle (most probably
FormsVBT when it comes out :-) and of course Modula-3 (and getting
paid on top it :-).  The full description is available from
misc.jobs.offered.  I will be happy to send you a copy, in case you
don't have access to that newsgroup.

--farshad

P.S., I hope that the USENET thought police doesn't take away my posting
privilages because of this posting. ;-) 


--
Farshad Nayeri                Intelligent Database Systems
fn00@gte.com                  Computer and Intelligent Systems Laboratory
(617)466-2473                 GTE Laboratories, Waltham, MA


======================================================================= 71 ===
Date:    Sat, 11 Apr 92 09:48:00 PDT
From:    msm@src.dec.com (Mark S. Manasse)
Subject: Re: C++ Critique in comp.lang.c++


Ian's article on C++ is quite intersting.  It's a little too pure in its
faith in object-orientation for my tastes, but a lot of its critiques are
sensible.

There are several points of Modula-3 where I suspect that Ian would find 
too much similarity with C++ for his taste, and a few other places he might
be dissatisfied.  Here's my attempt to answer his objections in advance.  
For all those points in Ian's message I don't mention, I think that M3
already solves the problem.


VALUE mode parameters
----- ---- ----------

Both C++ and Modula-3 strive to be good systems programming languages, as
well as good object-oriented programming languages.  Consequently, there
are features exposed by these languages that Ian doesn't like, such as
VALUE parameter mode.  I think that both for compatability with external
libraries and operating systems, and for efficiency, VALUE mode is
essential.  I could believe that a persuasive argument could be made that
READONLY should be the default.


<* HIDES *> considered necessary
----------- ---------- ---------

Ian argues that one shouldn't be able to introduce conflicting names into
the scope of an object.  While this seems sensible, it conflicts badly with
Modula-3's strategy using partially-opaque types for data hiding: I can't
be expected (nor can the compiler check if I succeeded) to avoid
introducing fields and methods whose names conflict with names I can't see.
M3 does avoid one of the most serious pitfalls of C++: the key word
OVERRIDES is used to introduce replacement methods, while METHODS is used
to name a new method.

Two problems remain.  First, a subtype might introduce names into scope
that visibly in that type conflict with supertype names.  Such a conflict
should rarely cause a problem: programs that use the subtype presumably
want to reference the subtype fields when they name something.  However,
the addition of a field or method might inadvertantly change the meaning of
code that used to reference the supertype field; consequently, the compiler
might well issue a warning when it detected name conflicts, unless the pragma
<* HIDES *> preceded the declaration.  The introduction of a HIDES pragma
should be done cautiously, except in very stylized cases, such as init methods.

The final problem is that caused by partial revelation.  The declaration
of a name may appear innocent to the compiler; it may only be later on at a
point where the concrete type and a subtype are both visible that the
conflict is noticed.  A compiler warning would again be appropriate; a
variant of HIDES which specifies the type and name in conflict seems
appropriate.


On ABSTRACT types
-- -------- -----

In M3, because of partial revelation, it is very easy to introduce types
without values for some of the methods.  This error leads to a checked
runtime error at the point of method invocation, but that's a little later
than might be useful.  The compiler could easily provide some help here, with
a small amount of assistance from the interface designer.

In the absence of partial revelations, the compiler would be able to know
which methods were concrete and which abstract, and could warn of any call
to NEW an object with abstract methods, unless the programmer guaranteed
(say by writing <* ABSTRACT init, incr *>) that he was aware that some methods
were abstract.

With partial revelations, life is harder; separate compilation won't allow
the compiler to know whether a method is abstract or not.  If we provide
pragmas ABSTRACT and CONCRETE which apply to types which are partially-
revealed, and which optionally take a list of method names (with any unnamed
methods defaulting the other way), we can check the uses of every type, and
we can have the compiler check that the type meets its abstractness
specification.  It's probably sensible to make CONCRETE the default, since
many introductions of partially-revealed types are just done to hide the
names of the method values.


Default parameters
------- ----------

Ian expressed in no uncertain terms his disdain for default parameters.  I
think that M3's default paramters are somewhat better than C++'s, and that,
in any case, default parameters are too useful in the software engineering
process to toss out.

M3 default parameters are better, because M3 allows parameters to a call to be
named.  Thus, unlike C++, I can make a procedure call where all but the last
parameter is defaulted, by naming that parameter in the call.

This isn't entirely a panacea, but it's as close as we're likely to get.  Ian
argues that we could just give the procedure a different name when some of
the parameters are defaulted, but it's hard enough coming up with one
good name for a procedure, let alone two, or four, or thirty-two.  It's
especially hard to come up with names if you have a procedure that's
already using the best name, but which is missing a parameter.  You wind
up either giving the full procedure some awkward name that reminds you
forever after that someone really botched the interface the first time, or
you have to modify all the clients so that they pass a new parameter that
you could have just as well defaulted, or so that they call the defaulted
version of the procedure.  Blecch.

I further contend that default parameters provide much better documentation
for those defaults than you would get through multiple procedure names.


Objects as monitors
------- -- --------

Ian suggests that objects can be treated as monitors, and that this paradigm
by itself makes objects wonderful for concurrent programming.

I'd like to support this, but it's really only the beginning of what you need
to do.

In Trestle, Greg and I carefully document the locking level of fields and
methods of our objects.  Most of our objects *do* descend from MUTEX, and
that MUTEX frequently does protect the fields and methods of that object.

That in itself, however, is inadequate for concurrent programming.  To avoid
deadlock, it is essential that you have some mechanism for capturing the
ordering on your MUTEXes.  In order to support asynchronous computation,
you must have a mechanism for signalling conditions, so that threads don't
have to busy-wait until there's something for them to do.

Anyhow, I believe that M3 is in much better shape on this point than most
other languages I know.  Greg and I are in the process of working on 
automatic tools to verify that programs that use our locking level pragmas
are race and deadlock free.


capitalizationShouldBeSignificant
---------------------------------

This is basically an unimportant surface feature of a language.  At SRC, we've
found that using capitalization conventions to distinguish types, constants,
and procedures from variables, fields, and methods is helpful.  And it avoids
the awkwardness of having to come up with good names for both a type and a
member of the type.  While you can avoid this by suffix conventions (types
are always plural, say), it's easier to admit that Pie = (Blueberry, Cherry)
is a nice name for the type, and that pie := Pie.Cherry is a sensible way to
name a variable.

But no one will ever be convinced who doesn't already believe.


x.incr()
--------

Ian argues that 0-ary procedures shouldn't need parentheses, just as variables
don't.  Well, maybe, but procedure calls don't have L-values.  That is, it's
an abuse of mathematical thinking to think of variables as 0-ary functions.

Moreover, in the case of a method call, it isn't true that the function is
0-ary; it's 1-ary with an implicit argument of the object itself.

Finally, if naming a procedure or method ought to call it, and special syntax
is required to treat it as a procedure variable, then you're going to need
that special syntax in declaring the values for methods.  Blecch.

I suppose that I could be persuaded that () should be allowed after a variable
or field name to convert it to its value.  That is, if x has a field foo,
x.foo() is a non-designator whose value is that of x.foo.


Procedures versus methods, modules versus objects
---------- ------ -------- ------- ------ -------

Ian complains that in C++, the interface designer must designate which methods
are virtual, and which are not.  M3 doesn't have that problem: all methods
are virtual.

But not all procedures that apply to objects are methods.  Some are 
procedures defined at top-level in an interface.

Greg and I will plead guilty to the charges of having done this extensively
in Trestle.  Our defense is that method syntax is only useful for those things
where you want the programmer to think of the thing as an object, and where
the semantics admit some sensible form of overriding.

Thus, painting into a window in Trestle is a procedure call.  A client
programmer should not think of there being any retained state as a result
of this, except the state on the screen.  And there isn't any utility to
overriding this as a method, except to make it slower.  Because, in fact,
there is state inside a window, and the painting calls are buffered up and
then handed off to a method which gets to deal with them several at a time.

The consequence is that the call requires not just the procedure name, but
the module name as well (adding some of that redundancy that Ian generally
approves of), the system runs faster, and no restrictions have been imposed
on the programmer.

A similar case is that of readers and writers, which are carefully described in
Greg's book on M3.  The outer layer exposes only procedures that perform a lot
of boiler-plate, resolving eventually to method calls on a data structure
tuned for better performance.

Call us troglodytes, call us retrograde, call us insensitive to the higher
truth that everything is a method call.  You would be right.  A programming
language should facilitate the design of well-crafted interfaces; it can not
prohibit the construction of bad ones.  Modules and procedures have proven
their value in the past.  Just because everything I can write with them can
be written in pure object notation doesn't make it a good idea to do so.

Unless you want us to delete all the boolean operators except NAND, all the
arithmetic operators except -, ....


Some final issues
---- ----- ------

Ian may find a few more things about M3 that he'll hate.  I hope not, but
who knows.  Here are a few candidates.

1. Wrong number of friends

In M3, given partial revelations, the notion of friends doesn't make too much
sense.  The information hiding is much better than in C++, because you don't
even get to notice when things you shouldn't use change.  But, if the revelatio
n
is made in an interface, there are no restrictions to prevent programmers
from importing those interfaces.  I think this is good: you never know when
you'll want to write a module for, say, data-structure browsing that will
need to access fields that you had meant to share only with a few of your
closest friends.

In large part, this is mitigated by the ability to have a module export
multiple interfaces, allowing you to reveal things inside an implementation
module, if you really don't want anyone else to know about it.


2. Nested scopes, including nested procedures

Hey, we think they're useful every now and then.  Limited scopes for
variables can be very useful; often you can avoid introducing a
variable until you also know how to initialize it.


3. Objects as references only

This seems to be required by safety, if you have either value mode parameters
or structure copy.  While Oberon seems to get pretty far without this
restriction, I would find it strange to pass an object's data fields in
part; the methods of the object might access fields which didn't exist in
the restricted object.  If you never pass objects by value, and object
copy doesn't copy the methods, you might be OK.  But then you have to deal
with the impact on garbage collection, and that can be a little tricky.

At any rate, there are various techniques one might explore that would
give you the benefits of having objects as records instead of as references
to records.  Garret Swart has posted in the past a few restrictions one
could make that would make stack allocation safe.  On a more interesting note,
Henry Baker's recent SIGPLAN paper (Why CONS shouldn't CONS its arguments)
argues that you can use the stack to hold the most recent generation of
stuff that should be on the heap, copying things off by need.  Clearly, a
compiler could often work out when you're going to wind up needing to do that
copy, and could optimize that case a little for you.


Finally, I would list multiple inheritance, but since Ian never mentioned it,
I'll omit it too.

Mark






======================================================================= 72 ===
Date:    13 Apr 92 14:57:06 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: RPCVBT imports RPC in Trestle?

The interface RPCVBT in Trestle imports RPC in order to have a Trestle
application distributed among many processes. We are directly interested
in such applications and tried without success to find the RPC interface.
Indeed, it probably defines how the processes find themselves and send and
receive messages. Is it there somewhere but not installed in the usual
place or is it missing?
--
---------------------------------------------------------------------

Prof. Michel Dagenais			    dagenais@vlsi.polymtl.ca
Dept of Electrical and Computer Eng.
Ecole Polytechnique de Montreal		    tel: (514) 340-4029

---------------------------------------------------------------------


======================================================================= 73 ===
Date:    Tue, 14 Apr 92 06:32:27 PDT
From:    msm@.dec.com (Mark S. Manasse)
Subject: Re: RPCVBT imports RPC in Trestle?


Regrettably, that interface doesn't currently have a Modula-3 implementation.

In addition to the Modula-3 Trestle, Greg, Steve, and I were maintaining
a Modula-2+ version, where RPC was real.  Even for those parts of the
system that we couldn't (yet) build in M3, we did the design in M3.  RPCVBT
is such a stub.

I don't know whether it would be easy to use PARC's port of Sun RPC to
do this.

Mark


======================================================================= 74 ===
Date:    15 Apr 92 14:00:12 GMT
From:    jjw1@mongoose.gte.com (Jim Walker)
Subject: Porting Modula-3

I have not received any replies to my query regarding porting Modula-3
to an HP Series 700, aka Snake.  (Did that post get out?)  So anyway,
I am going to, as my time permits, attempt to do the port myself.

The most important question that I have (really more of a meta-question)
is whether I should ask my porting questions in this forum, or is there
somebody there at SRC that I should correspond with via e-mail?

That's it for now...
...Walker

--------
James Walker  <jjw1@gte.com>
GTE Laboratories, Waltham, MA


======================================================================= 75 ===
Date:    Wed, 15 Apr 92 10:32:35 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Porting Modula-3

In article <16141@bunny.GTE.COM>, jjw1@mongoose.gte.com (Jim Walker) writes:

> The most important question that I have (really more of a meta-question)
> is whether I should ask my porting questions in this forum, or is there
> somebody there at SRC that I should correspond with via e-mail?

m3-request@src.dec.com is probably the right place to ask that kind of
question.

-- 
Eric.



======================================================================= 76 ===
Date:    Thu, 16 Apr 1992 05:37:50 GMT
From:    ian@syacus.acus.oz.au (Ian Joyner)
Subject: Re: C++ Critique in comp.lang.c++

Mark,

My apologies for taking so long to respond, but I have been inundated with
mails asking for the Postscript, and many being complementary. Let me
answer some of your points.

msm@src.dec.com (Mark S. Manasse) writes:

>Ian's article on C++ is quite intersting.  It's a little too pure in its
>faith in object-orientation for my tastes, but a lot of its critiques are
>sensible.

Let me counter the notion that I am a purist. I am a practitioner, who
happens to see that where things are not implemented cleanly in the
tools we use, that this often makes life difficult. I believe we should
start with a pure base, and evolve from there, adding what is only
necessary.

>There are several points of Modula-3 where I suspect that Ian would find 
>too much similarity with C++ for his taste, and a few other places he might
>be dissatisfied.  Here's my attempt to answer his objections in advance.  
>For all those points in Ian's message I don't mention, I think that M3
>already solves the problem.

You may be jumping the gun a bit. I have not been able to pick up a book
on M3 yet, and have not programmed at all in Modula, but have in Pascal
and Object Pascal (and Simula). Many of the points in the critique are
subtle, and are often fixed in other languages in subtle ways.

>VALUE mode parameters
>----- ---- ----------

>Both C++ and Modula-3 strive to be good systems programming languages, as
>well as good object-oriented programming languages.  Consequently, there
>are features exposed by these languages that Ian doesn't like, such as
>VALUE parameter mode.  I think that both for compatability with external
>libraries and operating systems, and for efficiency, VALUE mode is
>essential.  I could believe that a persuasive argument could be made that
>READONLY should be the default.

I do not believe that systems programming and OOP are at odds.  In fact
I think they are very well suited.  But I do think the way it is done in
C++ is wrong.  Systems level programming does not require that all
structuring and good programming practice needs to be undermined.  If
so, then we should not be developing for that processor, as it must be a
very ill-defined architecture. 

It is also wrong to think that systems programming means a C style
language (or worse assembler).  If Modula-3 is a systems programming
language then it disproves this.  Burroughs has been in the business of
writing systems in higher level languages exclusively since the early
1960s, first with Algol, and then with SDL on the B1000.  This proves
that the concept of minimal extensions to languages can easily support
systems programming.  But that is now the old style way of doing it. 

Now the way that OOP implements systems programming is to embed the
system level stuff in an object of its own, and the program only
accesses the system through this clean interface.  In fact portability
is then guaranteed, as all you need to do is port the system class. 
This is not really so different to the C way of modularisation and
importing interfaces by #include, but it is much cleaner and more
sophisticated. 

I think you may misunderstand my comments on value mode parameters (if
I am not misunderstanding your comments). I am saying that value mode is
the only mode necessary in OOP. Call by reference and by name are
unnecessary, and error-prone, and I like even less the way C simulates
these by passing pointers and function pointers.


><* HIDES *> considered necessary
>----------- ---------- ---------

I can't really comment on this as I don't know about the M3 constructs
you are talking about.  However, OVERRIDES is certainly preferable to
C++'s scheme, so I think M3 is probably way ahead here.  My point though
is that where you have an issue of programmer convenience vs safety,
safety must override convenience.  Since when has programming been
convenient anyway.  I would find it much more convenient, if they just
posted out my pay cheque every week, without me having to come in and
program for it! Programmer convenience in the C sense is often only a
short term consideration.  Nothing is more inconvenient than tracking
down some very subtle errors caused by such convenience. 


>On ABSTRACT types
>-- -------- -----

>In M3, because of partial revelation, it is very easy to introduce types
>without values for some of the methods....

I'm not really sure what you mean by partial revelation in M3. Sounds
rather Biblical though :-)


>Default parameters
>------- ----------

>Ian expressed in no uncertain terms his disdain for default parameters.  I
>think that M3's default paramters are somewhat better than C++'s, and that,
>in any case, default parameters are too useful in the software engineering
>process to toss out.

>M3 default parameters are better, because M3 allows parameters to a call to be
>named.  Thus, unlike C++, I can make a procedure call where all but the last
>parameter is defaulted, by naming that parameter in the call.

Well I did say that there were other ways to provide this other than the
C++ way. Perhaps M3 achieves this. My point is to at least get these
points considered, and not just to accept default parameters as a good
thing. I do agree that the problem without them is increased name
space. But then again, I see this as a matter of programmer convenience
vs safety.


>Objects as monitors
>------- -- --------

>Ian suggests that objects can be treated as monitors, and that this paradigm
>by itself makes objects wonderful for concurrent programming.

>I'd like to support this, but it's really only the beginning of what you need
>to do.

Yes, I agree, but I wasn't going to write a book on this. I think there are
still many problems for the researchers to solve, and that is why we don't
have this with us now. But I think also that what the research is showing
is that the objects must be very clean to achieve this. C++ objects are
not clean enough.


>capitalizationShouldBeSignificant
>---------------------------------

Let me retitle this:

capitalisation_should_not_be_significant

>This is basically an unimportant surface feature of a language.  At SRC, we've
>found that using capitalization conventions to distinguish types, constants,
>and procedures from variables, fields, and methods is helpful.  And it avoids
>the awkwardness of having to come up with good names for both a type and a
>member of the type.  While you can avoid this by suffix conventions (types
>are always plural, say), it's easier to admit that Pie = (Blueberry, Cherry)
>is a nice name for the type, and that pie := Pie.Cherry is a sensible way to
>name a variable.

>But no one will ever be convinced who doesn't already believe.

I agree that this is an unimportant surface feature, but as I showed, it
can lead to really obscure errors.  The thing is the less likely that
something is going to cause an error, the more obscure the error when it
does happen.  Thus, I err again in terms of safety, rather than
programmer convenience, not that this is really at all inconvenient. 

>x.incr()
>--------

>Ian argues that 0-ary procedures shouldn't need parentheses, just as variables
>don't.  Well, maybe, but procedure calls don't have L-values.  That is, it's
>an abuse of mathematical thinking to think of variables as 0-ary functions.

No, I think the abuse to mathematical thinking is the assignment statement.
When you use a variable in an expression, it is equivalent to the notion
of mathematical function. It returns a value of a given type. Thinking of
variables and value returning procedures as both being mathematical
functions is very elegant. Besides in OOP, you should not be assigning to
the a variable entity of an object from outside the class anyway. So to
the interface user of the class, whether the entity is a variable or a
function should be indistinguishable.

>I suppose that I could be persuaded that () should be allowed after a variable
>or field name to convert it to its value.  That is, if x has a field foo,
>x.foo() is a non-designator whose value is that of x.foo.

Well, if you can be persuaded this way, then that proves that the () syntax
is superfluous, and it may as well not be there ;-)

>Call us troglodytes, call us retrograde, call us insensitive to the higher
>truth that everything is a method call. 

OK, you troglodytes, you retrogrades, you insensitive....
Well I didn't really mean that but since you asked for it, only
trying to be obliging :-)

>Some final issues
>---- ----- ------

>Ian may find a few more things about M3 that he'll hate.  I hope not, but
>who knows.  Here are a few candidates.

>1. Wrong number of friends

>In M3, given partial revelations, the notion of friends doesn't make too much
>sense. 

Ah, now I think I see what you mean by partial revelation. I suspect that
this is the very reason, why I said friends were not a very general
mechanism. Partial revelation would be exactly the mechanism I had in
mind as much better and controllable than friend. Is that right?


>2. Nested scopes, including nested procedures

>Hey, we think they're useful every now and then.  Limited scopes for
>variables can be very useful; often you can avoid introducing a
>variable until you also know how to initialize it.

Well I have spent a lot of time writing in languages that provided this,
(ALGOL, Pascal), and thinking how much better off we were than C. But
in the face of OO, and the new style of scoping that brings, I am
not so sure.


>3. Objects as references only

...

>Finally, I would list multiple inheritance, but since Ian never mentioned it,
>I'll omit it too.

No, I have no problems with multiple inheritance. But it must be used
correctly. This would have to be an instance where I would trust
the programmer to play with razor blades, and not ban them, just
because a baby might get hold of them.

Thanks for the comments, I hope that clarified a few things.
-- 
Ian Joyner                                     ACSNet: ian@syacus.acus.oz
ACUS (Australian Centre for Unisys Software)   Internet: ian@syacus.acus.oz.au
115-117 Wicks Rd, North Ryde, N.S.W, Australia 2113.
Tel 61-2-390 1328      Fax 61-2-390 1391       UUCP: ...uunet!munnari!syacus.oz


======================================================================= 77 ===
Date:    Wed, 15 Apr 92 20:37:09 PDT
From:    jdd@src.dec.com (John DeTreville)
Subject: Modula-3 Users Group Meeting...

A few weeks ago here on comp.lang.modula3, Sam Harbison suggested a
Modula-3 get-together at this June's SIGPLAN meeting in San Francisco,
and Michel Dagenais from l'Ecole PolyTechnique de Montreal seconded
the idea of a Modula-3 BOF session.

Here at DEC SRC, we've also been thinking of organizing a Modula-3
Users' Group (MUG?) meeting this summer.  It looks like it might be a
good idea to merge the MUG meeting with the SIGPLAN Modula-3 BOF
session, and this message is to ask people whether they agree.

We were thinking of an all-day meeting, perhaps the Tuesday before
SIGPLAN proper begins.  We can line up a number of speakers from SRC,
and would like to solicit other potential speakers from outside.  We'd
especially like to hear about your experiences using the language and
the SRC system.  In return, we can talk about our own future plans,
and together we can sketch out where Modula-3 is going.

What we need to know is whether people can make it that Tuesday (June
16), and, if not, when might be better.  Our first choice would be to
meet at SRC--there's convenient public transit from San Francisco--but
let us know whether you'd prefer the conference site.  And of course,
a shorter meeting might be easier to schedule.

If you'd like to give a talk, send a title and a very short abstract.
We're also making our own list of people we'd like to hear speak, and
we'll be contacting you if you don't contact us first.

We'd also like to schedule some time for discussions about the
language and system.  If you'd like to place a topic on the agenda,
please mail it in.

And when you send all this in, please send it to me, jdd@src.dec.com.
Sooner is better than later.  I'll post followups to comp.lang.modula3.

Cheers,
John


======================================================================= 78 ===
Date:    16 Apr 92 12:56:44 GMT
From:    thewalt@canuck.ce.berkeley.edu (C. Thewalt)
Subject: Evolution

After reading with great interest the recent discussions about number
crunching in Modula-3, I never saw any answers to some fairly
important questions.  In particular, what is the likelihood that any
of the following features will find their way (formally) into M3?

 1) support for complex types (built-in so that usual operators work)
 2) exponentiation operator
 3) standard math library (trig etc)

It is an elegant language that we'd like to use for large analytical
packages (both teaching and research), but it seems that you have to
do some unnecessarily ugly things to get the three items listed above.

Chris
--
Christopher Robin Thewalt               (thewalt@ce.berkeley.edu)
Dept. of Civil Engineering              These opinions are not necessarily
University of California, Berkeley      shared by my employer...


======================================================================= 79 ===
Date:    Thu, 16 Apr 1992 16:23:57 GMT
From:    mday@jukebox.lcs.mit.edu (Mark Day)
Subject: Re: C++ Critique in comp.lang.c++

   ian@syacus.acus.oz.au (Ian Joyner) writes:

   >msm@src.dec.com (Mark S. Manasse) writes:

   >Ian argues that 0-ary procedures shouldn't need parentheses, just as
   >variables don't.  Well, maybe, but procedure calls don't have
   >L-values.  That is, it's an abuse of mathematical thinking to think of
   >variables as 0-ary functions.

   No, I think the abuse to mathematical thinking is the assignment
   statement.

No, I think the abuse to computational thinking is trying to squeeze
it into a framework of mathematical thinking.

I think you are both making reasonable points about language design
elsewhere in your articles, but I don't think very highly of this
implicit assumption that a programming language is better as it comes
nearer to mathematical thinking.  

--Mark Day

mday@lcs.mit.edu





======================================================================= 80 ===
Date:    16 Apr 92 17:14:19 GMT
From:    ms@cs.brown.edu (Manojit Sarkar)
Subject: C++ vs. M3

A very good thing about M3 is the absence of "include" facility...
In C++, to me includes are sources of confusion - when you
see an "include" statement - you have no idea about what is being
really included - because you include a "file" and you have no
idea about what it contains in terms of your program components
without looking at the file.
Consider IMPORT statements in M3, your imports are real program
components, INTERFACES
there is no additinal level of obscuration through
file names - which has no place in the programming concepts in the
first place. When one is programming, why should one have to worry
about which definition is in which file? You should be able to
refer to the definitions by names instead.

 


======================================================================= 81 ===
Date:    Thu, 16 Apr 1992 05:17:48 GMT
From:    johnh@wheaton.edu (John (Doc) Hayward)
Subject: Possible Modula-3 compiler performace bug?

Is there a problem with v2.0 Modula-3 compiler (or is it a problem
with the MIPS C compiler?  

If a large array is passed by value it takes significantly more time
to compile than if passed by reference.  Below is a script example.

The time seems to be taken up in the c compilation when cc creates a
process called ugen.

We are running version 2.0.

Script started on Wed Apr 15 23:28:14 1992
> csh> cat Main.m3
> MODULE Main;
>     CONST
> 	Size = 10000;
> 
> PROCEDURE Proc(VAR Values:ARRAY [1..Size] OF INTEGER; Lots:INTEGER) : INTEGER
=
>     VAR
> 	I : INTEGER;
> 	Sum : INTEGER := 0;
>     BEGIN
> 	FOR I:= 1 TO Lots DO
> 	    Sum := Sum + Values[I]
> 	END;
> 	RETURN Sum
>     END Proc;
> VAR
>     Values : ARRAY [1..Size] OF INTEGER;
>     I : INTEGER;
>     Sum : INTEGER;
> BEGIN
>     FOR I := 1 TO Size DO Values[I] := I END;
>     Sum := Proc(Values,Size)
> END Main.
> csh> time m3make
> /usr/local/bin/m3 -w2 -make -why -g   -o List Main.m3 
> new source -> compile Main.m3
> "Main.m3", line 7: warning: not used (I)
> "Main.m3", line 17: warning: not used (I)
> 2 warnings encountered
> new objects -> link List
> 3.5u 2.5s 0:12 47% 552+4600k 321+192io 137pf+0w
< ^^^^--- 3.5 user cpu seconds
> csh> ed Main.m3
> 425
> 5
> PROCEDURE Proc(VAR Values:ARRAY [1..Size] OF INTEGER; Lots:INTEGER) : INTEGER
=
> s/VAR //
< ^^^^^^^^ Change from pass by value to pass by reference
> p
> PROCEDURE Proc(Values:ARRAY [1..Size] OF INTEGER; Lots:INTEGER) : INTEGER=
> w
> 421
> q
> csh> !t
> time m3make
> /usr/local/bin/m3 -w2 -make -why -g   -o List Main.m3 
> new source -> compile Main.m3
> "Main.m3", line 7: warning: not used (I)
> "Main.m3", line 17: warning: not used (I)
> 2 warnings encountered
> new objects -> link List
> 121.4u 4.5s 2:20 90% 290+1525k 326+235io 137pf+0w
< ^^^^^^--- 121.4 user cpu seconds
> csh> ^D
> script done on Wed Apr 15 23:34:37 1992
johnh...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=
UUCP: johnh@wheaton.uucp           telephone: (708) 752-5871 (office)
Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187
       Act justly, love mercy and walk humbly with your God. Micah 6:8b


======================================================================= 82 ===
Date:    Fri, 17 Apr 92 14:09:17 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Possible Modula-3 compiler performace bug?

In article <1992Apr16.051748.29331@wheaton.wheaton.edu>, johnh@wheaton.edu (Joh
n (Doc) Hayward) writes:
> Is there a problem with v2.0 Modula-3 compiler (or is it a problem
> with the MIPS C compiler?  

With the C compiler.  ugen is the thing that generate object code from
the intermediate representation used in this compiler (ucode).
I'll try to see what our compiler people have to say.

---
Eric.



======================================================================= 83 ===
Date:    Sat, 18 Apr 1992 09:02:17 GMT
From:    dmb@usl.edu (David M. Brumley)
Subject: Should Params.Get (n), for n >= RTArgs.argc, raise an exception?

I got bitten when I accidentally called Params.Get (n) with  n = argc.
Any sympathy? 

FYI:  m3 ver 2.04, DECstation 5000/200, ULTRIX 4.2


======================================================================= 84 ===
Date:    7 Apr 92 20:19:25 GMT
From:    matthes@dbis1.informatik.uni-hamburg.de (Florian Matthes)
Subject: LONGFLOAT(x:REAL) in 2.05?

A simple, stupid question: Using m3 version 1.6 one could write

	longRealVar:= LONGFLOAT(realVal)

to convert a single precision real value into a double precision real
value. If I try to recompile existing M3 programs with the new 2.05
compiler (SPARC architecture), I get the following error messages:

"...", line nn:  undefined (LONGFLOAT)
"...", line nn:  types are not assignable

Is there a new mechanism to achieve this conversion?

Please reply to matthes@dbis1.informatik.uni-hamburg.de.

Thank you for your help

Florian Matthes


======================================================================= 85 ===
Date:    Mon, 20 Apr 92 12:53:29 EDT
From:    wyant@centerline.com
Subject: M3 and Epoch

Epoch users might want to grab the tek-epoch-stuff package
available via anonymous FTP from a variety of sites
(gatekeeper.dec.com, ftp.uu.net, ...). It provides rendering
of comments in a user-specified font. For M3, I find that it
makes well-documented interfaces quite pleasant to read on
the screen. You need to make one change to modula-3.el to use
it:

old
    (modify-syntax-entry ?\( "()" table)
    (modify-syntax-entry ?\) ")(" table)
new
    (modify-syntax-entry ?\( "()1" table)
    (modify-syntax-entry ?\) ")(4" table)

Otherwise, comment starter and ender characters get dropped.

It shouldn't be to hard to add support for highlighting keywords
as well.


Geoff Wyant
wyant@centerline.com
Centerline Software, Inc.
(Formerly Saber Software, Inc)
10 Fawcett Street
Cambridge, Ma.
01238


======================================================================= 86 ===
Date:    Mon, 20 Apr 92 14:05:10 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: LONGFLOAT(x:REAL) in 2.05?

In article <matthes.702677965@dbis1>, matthes@dbis1.informatik.uni-hamburg.de (
Florian Matthes) writes:
> A simple, stupid question: Using m3 version 1.6 one could write
> 
> 	longRealVar:= LONGFLOAT(realVal)
> 
> to convert a single precision real value into a double precision real
> value. If I try to recompile existing M3 programs with the new 2.05
> compiler (SPARC architecture), I get the following error messages:
> 
> "...", line nn:  undefined (LONGFLOAT)
> "...", line nn:  types are not assignable
> 
> Is there a new mechanism to achieve this conversion?

Yes.  2.x implements the latest version of the language, and there is
now a single operator for conversions to floating-point types:

	FLOAT (x: INTEGER; T: Type := REAL) : T;
 	      (x: Float; T; T: Type := REAL): T;

where Float and T can be any of the floating-point types (REAL,
LONGREAL, EXTENDED).  So you can write:

	longRealVar:= FLOAT (realVal, LONGREAL);

This change was motivated by the introduction of the EXTENDED
floating-point type.  It seemed better to have a single generic
conversion operator than to introduce a new operator to convert to
EXTENDED.

-- 
Eric.



======================================================================= 87 ===
Date:    Wed, 22 Apr 1992 18:28:11 GMT
From:    dmb@usl.edu (David M. Brumley)
Subject: Re: Should Params.Get (n), for n >= RTArgs.argc, raise an exception?

moss@cs.umass.edu (Eliot Moss) writes:

>Well, I can see Params.Get(n) for n >= argc either raising an exception, or
>returning the empty string (or NIL?). AN exception is probably the safeest
>since it will tend to prevent unintended infinite loops .... Eliot
>--

Well, it returns NIL now in SRC Modula-3.  It's simply a matter of
being careful about the value of 'n' and double checking the return
value.  I just thought a range check on the value of 'n' with an
appropriate exception raised on failure would make the interface
foolproof, for fools like me.


======================================================================= 88 ===
Date:    22 Apr 1992 14:27:50 -0500
From:    eckam@cs.utexas.edu (Daniel James Eckam)
Subject: stdout

This may be a stupid question, but I'll ask anyway.  Why is all
interactive output saved until a program finishes execution ?
(m3 version 2.04 on Sun 4)  In other words, what's wrong with this
program:

MODULE test2 EXPORTS Main;

IMPORT Rd, Wr, Stdio, Text;

VAR  c: CHAR;

BEGIN
  c:= ' ';
  WHILE (c # 'y') AND (c # 'n') DO
    Wr.PutText(Stdio.stdout, "Measure time of execution ? (y/n) ");
    c:= Text.GetChar(Rd.GetLine(Stdio.stdin), 0);
  END;
END test2.

When I run this, I don't get any prompts until I have entered a y or n.

----------
Dan Eckam
:w
?
:q
i


======================================================================= 89 ===
Date:    22 Apr 92 16:49:40 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Should Params.Get (n), for n >= RTArgs.argc, raise an exception?

Well, I can see Params.Get(n) for n >= argc either raising an exception, or
returning the empty string (or NIL?). AN exception is probably the safeest
since it will tend to prevent unintended infinite loops .... Eliot
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================= 90 ===
Date:    Thu, 23 Apr 1992 12:11:52 GMT
From:    dmb@usl.edu (David M. Brumley)
Subject: Re: stdout

laverman@cs.rug.nl (Bert Laverman) writes:

>Daniel James Eckam wrote:
>> This may be a stupid question, but I'll ask anyway.  Why is all
>> interactive output saved until a program finishes execution ?
>Never fear; the question isn't stupid. FIrst: output is _buffered_,
>not saved. That makes a small difference.

But should 'Stdio.stdout' be buffered?  According to the interface for
Stdout, "If the output streams are directed to terminals, they should
be unbuffered, so that explicit Wr.Flush calls are unnecessary for
interactive programs."  


======================================================================= 91 ===
Date:    Thu, 23 Apr 1992 07:58:04 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: stdout


Daniel James Eckam wrote:
> This may be a stupid question, but I'll ask anyway.  Why is all
> interactive output saved until a program finishes execution ?
Never fear; the question isn't stupid. FIrst: output is _buffered_,
not saved. That makes a small difference.

> (m3 version 2.04 on Sun 4)  In other words, what's wrong with this
> program:
Ah, that's another questions!

> MODULE test2 EXPORTS Main;
> 
> IMPORT Rd, Wr, Stdio, Text;
> 
> VAR  c: CHAR;
> 
> BEGIN
>   c:= ' ';
>   WHILE (c # 'y') AND (c # 'n') DO
>     Wr.PutText(Stdio.stdout, "Measure time of execution ? (y/n) ");
Insert a "Wr.Flush(Stdio.stdout);" here and all will be well.

>     c:= Text.GetChar(Rd.GetLine(Stdio.stdin), 0);
>   END;
> END test2.
> 
> When I run this, I don't get any prompts until I have entered a y or n.
IO is buffered, and since this is a small program, the flushing of the
output buffers doesn't happen until the program finishes.

> ----------
> Dan Eckam
> :w
> ?
> :q
> i
^X^S^X^C ;-)
-- 
#include <std/disclaimer>

  Bert Laverman,  Dept. of Computing Science, Groningen University
  Friendly mail to: laverman@cs.rug.nl      The rest to: /dev/null


======================================================================= 92 ===
Date:    Thu, 23 Apr 92 11:39:32 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: stdout

In article <dmb.704031112@srl01.cacs.usl.edu>, dmb@usl.edu (David M. Brumley) w
rites:
> laverman@cs.rug.nl (Bert Laverman) writes:
> 
> >Daniel James Eckam wrote:
> >> This may be a stupid question, but I'll ask anyway.  Why is all
> >> interactive output saved until a program finishes execution ?
> >Never fear; the question isn't stupid. FIrst: output is _buffered_,
> >not saved. That makes a small difference.
> 
> But should 'Stdio.stdout' be buffered?  According to the interface for
> Stdout, "If the output streams are directed to terminals, they should
> be unbuffered, so that explicit Wr.Flush calls are unnecessary for
> interactive programs."  

The trouble is that an unbuffered writer has little choice but to
output each character as it is delivered by the class-indenpendent
buffering mechanism.  This means one write(2) call per character and
it seems a bit expensive; when the compiler was invoked under
gnuemacs, the error messages would take a very long time to be
displayed, for example. 

The only way to not have one write(2) call per character is to make
the writer is buffered.  This explains why we changed stdout to be
buffered.

There are two solutions to have the characters appear on the target
before the buffer is full:

- insert some Wr.Flush (wr) in your program,

- build an AutoFlushWr.T on top of your wr.  AutoFlush writers start a
  thread that comes around every now and then to do a Wr.Flush.  I
  believe it is ok to have near the beginning of your program
  something like:

	Stdio.stdout = AutoFlushWr.New (Stdio.stdout);

-- 
Eric.



======================================================================= 93 ===
Date:    Fri, 24 Apr 92 10:27:03 EDT
From:    wyant@centerline.com
Subject: re: AutoFlush stream

Having a thread that flushes the stream periodically seems awkward and non-dete
rministic.
I think most applications want to flush the stream at discrete points, such as 
when a new
line is encountered in the stream. A better interface to an 'AutoFlush' stream 
would be
one that was created with a set of 'break' characters which flushed the stream 
whenever
one was encountered.

Another approach would be to attack the problem from the other side. Normally, 
you
want to flush the output stream when a read is posted to the input stream. How 
'bout
an 'OutputFlushing' reader. This would be created with the writer that was to b
e flushed
on any inout call.

Just some (very) random thoughts...

Geoff Wyant
wyant@centerline.com
Centerline Software, Inc.
(Formerly Saber Software, Inc)
10 Fawcett Street
Cambridge, Ma.
01238


======================================================================= 94 ===
Date:    Fri, 24 Apr 1992 07:46:16 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: stdout


David M. Brumley writes:
> But should 'Stdio.stdout' be buffered?  According to the interface for
> Stdout, "If the output streams are directed to terminals, they should
> be unbuffered, so that explicit Wr.Flush calls are unnecessary for
> interactive programs."  
The problem of whether or not to buffer terminal I/O is debatable. Sometimes
buffered tty I/O is a definite advantage, sometimes it isn't. Most *NIX C
implemenations leave stderr unbuffered, but not stdout. I guess it's a matter
of getting used to it.
  Both the Stdio.i3 and SPwM3 (page 140) say stdout should be unbuffered.
appearently the SRC-m3 implementation doesn't follow suit. However, I don't
mind really, since buffering the terminal I/O can sometimes be advantageous,
especially to reduce the overhead of one system call per character/string.
This sounds silly, but for programs dthat print out a lot of information,
it has a definite effect on the user when he/she is watching.

Flusing stdout is useful habit anyway, since with sockets and pipes it's
not always clear when you're in an interactive environment...

Greetings, Bert
-- 
#include <std/disclaimer>

  Bert Laverman,  Dept. of Computing Science, Groningen University
  Friendly mail to: laverman@cs.rug.nl      The rest to: /dev/null


======================================================================= 95 ===
Date:    Fri, 24 Apr 1992 15:28:14 GMT
From:    treese@crl.dec.com (Win Treese)
Subject: Re: stdout


Since the C stdio library is line-buffered, one has to use an explicit 
flush for prompting without a newline.  It would seem reasonable to
do it for Stdio as well.


Win Treese						Cambridge Research Lab
treese@crl.dec.com					Digital Equipment Corp.

IMPORT Disclaimer;


======================================================================= 96 ===
Date:    Fri, 24 Apr 1992 15:37:27 GMT
From:    barton@chopin.seas.ucla.edu (Bob Barton System Administrator (403)492 
5160)
Subject: Modula 3 on an RS/6000 320

Keywords: 

Has anyone got Modula3 ver 2.04 running on an RS6000?
I am working on an RS6000 320 using AIX 3.1.5.

When trying to do the m3make build_boot I get an error message from awk
indicating syntax errors in source lines 43 and 50 which I think are in the
file /usr/local/lib/m3/mklist.awk. I don't know what this file is meant to do
so I have not tried changing anything in it.

In addition I will soon be moving to AIX 3.2 and wonder if there are any
known problems that appear for Modula 3.

NOTE: (Modula 3 is available by anonymous ftp from gatekeeper.dec.com)
	(for IBM Risc 6000 installations ensure that the BSD install is
	 used not the AIX install) 

Bob Barton (barton@chopin.eche.ualberta.ca)



======================================================================= 97 ===
Date:    Fri, 24 Apr 1992 13:42:31 PDT
From:    David Nichols <nichols@parc.xerox.com>
Subject: Re: stdout

Well, I looked at the code, and WrMove.FastPutString, which is what
PutText and PutString call, now only flushes at the end instead of
calling Wr.PutChar and flushing on each character.  Thus, it would
appear that we could make Stdio.stdout unbuffered without a big
performance hit as long as clients were calling Wr.PutText or
Wr.PutString most of the time.  I wrote a test program and traced it,
and it did indeed make only one write call for an unbuffered Wr.T.

I also tried writing a new writer class that would automatically flush
whenever it saw certain characters (like newlines).  The problem is that
it needs to be unbuffered so it sees everything that's written
immediately, but then it can't tell the wr.flush calls that come from
the normal writing code (e.g. in WrMove.FastPutChar) from the ones the
client makes (from Wr.Flush).  Perhaps the flush method could get an
extra parameter or something.

	David
================
MODULE Main;

IMPORT Wr, UFileWr;

VAR buf, unBuf: Wr.T;

BEGIN
  buf := UFileWr.New(fd := 1, buffered := TRUE);
  unBuf := UFileWr.New(fd := 1, buffered := FALSE);
  Wr.PutText(
    buf, "This is a longish line of buffered output.  Wasn't it fast?\n");
  Wr.Flush(buf);
  Wr.PutText(unBuf, "This is a longish line of unBuffered output."
                      & "  Can you see the chars?\n");
END Main.


======================================================================= 98 ===
Date:    Fri, 24 Apr 1992 19:52:07 GMT
From:    schwartz@roke.cs.psu.edu (Scott Schwartz)
Subject: Re: AutoFlush stream

wyant@centerline.com writes:
| Normally, you want to flush the output stream when a read is posted
| to the input stream. How 'bout an 'OutputFlushing' reader. This
| would be created with the writer that was to be flushed on any inout
| call.

The FIO library in V10 Unix has a ``tie'' function.  You can tie two
descriptors together so that whenever one of them does a read, the
other is flushed.  In this case you would tie stdout to stdin, so that
when the program prompts pending output will be visible.  That seems
like a clever solution to me.


======================================================================= 99 ===
Date:    25 Apr 92 02:50:21 GMT
From:    bbc@cs.rice.edu (Benjamin Chase)
Subject: Re: AutoFlush stream

In article <9204241427.AA24484@riposte> wyant@centerline.com writes:

>Another approach would be to attack the problem from the other side.
>Normally, you want to flush the output stream when a read is posted to
>the input stream. How 'bout an 'OutputFlushing' reader. This would be
>created with the writer that was to be flushed on any inout call.

That was my reaction to the problem, as well.  It should yield an
efficient implementation, yet still do what you want.  Output streams
should also be flushed on (checked) runtime errors.  (You can try to
flush them on the unchecked runtime errors, if you want. :-)

In general, I guess you'd want to be able to indicate that a read on a
specified stream caused a flush on another stream or streams (ie. not
necessarily the stdin/stdout special case), but the stdin/stdout case
is 99% of the problem.
--
	Ben Chase <bbc@rice.edu>


======================================================================= 100 ===
Date:    Fri, 24 Apr 1992 18:30:02 GMT
From:    nr@elan (Norman Ramsey)
Subject: Re: stdout


Many systems handle the problem of unbuffered writes to standard
output by flushing the standard output buffer whenever there is a read
from standard input.  This is done only when the input is
intermittent.  I think it would be worth thinking about how to do this
automatically in Modula-3.


======================================================================= 101 ===
Date:    24 Apr 92 18:53:28
From:    vixie@pa.dec.com (Paul A Vixie)
Subject: Re: AutoFlush stream

I disagree.  Flushing the output "periodically" would let you write large
amounts of data and only pay the system-call overhead of "flush" when the
internal buffer filled up or after you stop writing new data.  This assumes
that the "flush" "timer" will be reset whenever new data is added to the
output buffer.

This combined with a reader that flushed output to its corresponding 
writer, would give you completely smooth output in all but one case, with
a minimum system call overhead in *all* cases.  Seems like a winner.  I
don't like explicit flushes -- it's a detail I don't think an application
ought to have to worry about.  Sort of like error checking vs. exceptions.

C's "line buffering" is a lose, since you still need explicit flushes for
partial-line output, and further, you pay one system call per output line
even if you're writing hundreds (or thousands) of output lines back-to-back.
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Ready, Fire, Aim"
<vixie@pa.dec.com> decwrl!vixie
<paul@vix.com>     vixie!paul          alt.pink.bunny.boom.boom.boom moderator


======================================================================= 102 ===
Date:    Sat, 25 Apr 1992 12:35:16 GMT
From:    dmb@usl.edu (David M. Brumley)
Subject: Re: stdout

laverman@cs.rug.nl (Bert Laverman) writes:

>David M. Brumley writes:
>> But should 'Stdio.stdout' be buffered?  According to the interface for
>> Stdout, "If the output streams are directed to terminals, they should
>> be unbuffered, so that explicit Wr.Flush calls are unnecessary for
>> interactive programs."  
>The problem of whether or not to buffer terminal I/O is debatable. Sometimes
>buffered tty I/O is a definite advantage, sometimes it isn't. Most *NIX C
>implemenations leave stderr unbuffered, but not stdout. I guess it's a matter
>of getting used to it.

I hope it's not a "matter of getting used to it."  I suppose that
depends on whether or not the people at DEC SRC are aware of the
discussions in this group and whether they want to make Modula-3's
standard libraries better than C's. 

>  Both the Stdio.i3 and SPwM3 (page 140) say stdout should be unbuffered.
>appearently the SRC-m3 implementation doesn't follow suit. However, I don't
>mind really, since buffering the terminal I/O can sometimes be advantageous,
>especially to reduce the overhead of one system call per character/string.
>This sounds silly, but for programs dthat print out a lot of information,
>it has a definite effect on the user when he/she is watching.

>Flusing stdout is useful habit anyway, since with sockets and pipes it's
>not always clear when you're in an interactive environment...

I don't think the question is really "To buffer or not to buffer?" but
"When to flush?"  Why not let the programmer decide when the
convenience of automatic flushing becomes too costly?  In the current
implementation, there is no difference between 'stdout' and
'bufferedStdout' since:

  stdout := UFileWr.New (fd := 1, buffered := TRUE);
  bufferedStdout := UFileWr.New (fd := 1, buffered := TRUE);

in spite of the interface description.  Besides, is "unbuffered"
stdout going to be so costly when calls to Wr.PutText() and the rest
end up calling WrMove.FastPutString() thus avoiding excessive write(2)
calls?  What I, and presumably Mr. Eckam, would like is a stdout that
we wouldn't have to explicitly flush.  Others can always decide to use
another interface with more sophisticated buffering and flushing.
Or maybe Stdio could determine whether stdout is a pipe or whatever
and automatically use a more appropriate buffering scheme.



======================================================================= 103 ===
Date:    Sat, 25 Apr 1992 16:00:22 GMT
From:    mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: initializing objects

It seems to me that it is a weakness of Modula 3 that there is no easy
way to ensure that opaque types are properly initialized.  In some
cases, default values for fields works, but only if the default values
are constants.  There are some rather klugey work-arounds, such as
having a field that indicates whether the instance has been
initialized, and then checking that field every time an unknown
instance is encountered.  It would be much nicer to make sure that
instances have been initialized properly to begin with.

It also seems to me that a simple solution is possible.  Introduce a
pragma that indicates that NEW is not allowed for a particular opaque
type.  Then the only way to allocate an object of that opaque type
would be to invoke a module procedure that returns an instance,
already initialized.

-mike



======================================================================= 104 ===
Date:    Fri, 24 Apr 1992 00:42:28 GMT
From:    johnh@wheaton.edu (John (Doc) Hayward)
Subject: Re: stdout (and deadlock problem)

> >Daniel James Eckam wrote:
> >> This may be a stupid question, but I'll ask anyway.  Why is all
> >> interactive output saved until a program finishes execution ?
> >Never fear; the question isn't stupid. FIrst: output is _buffered_,
> >not saved. That makes a small difference.
> 
> But should 'Stdio.stdout' be buffered?  According to the interface for
> Stdout, "If the output streams are directed to terminals, they should
> be unbuffered, so that explicit Wr.Flush calls are unnecessary for
> interactive programs."  

We had the same problem.  Since my students writes interactive programs I
modified Stdio.m3.

>From Stdio.m3 in libm3/rw/src line 25 modified to:

  stdout := UFileWr.New (fd := 1, buffered := FALSE); (* was true now false *)

This seems to work ok for terminals however it should really determine if the
stdout is connected to a terminal before assigning buffered to FALSE.

This may negativly impact performance for redirected stdout programs.

The only other problem which this may have caused is that I get a deadlock when
joining the only thread forked and the main program is waiting to finishing 
output from an unbuffered (autoflush).  The deadlock seems to be related
to the fact that there are no runnable threads at the time it is waiting to 
finish flushing the buffer.  Code looks like:

EVAL Thead.Join(...);
Wr.PutText(Stdio.stdout,"bla bla \n"); (* deadlock occures while waiting for
					  this output to be auto flushed *)

Any hints on this one? (ps. we are running version 2.0)
johnh...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=
UUCP: johnh@wheaton.uucp           telephone: (708) 752-5871 (office)
Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187
       Act justly, love mercy and walk humbly with your God. Micah 6:8b
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=
UUCP: johnh@wheaton.uucp           telephone: (708) 752-5871 (office)
Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187
       Act justly, love mercy and walk humbly with your God. Micah 6:8b


======================================================================= 105 ===
Date:    Sat, 25 Apr 92 18:37:56 -0400
From:    Norman Ramsey <nr@Princeton.EDU>
Subject: Rd.Error is gone

Why has the Error exception been removed from the Rd interface?

Norman


======================================================================= 106 ===
Date:    Fri, 24 Apr 1992 16:10:17 GMT
From:    nr@cs.Princeton.EDU ()
Subject: Questions about installing SRC M3, v 2.0x


I built SRC M3 on a DS3100 making as few changes as possible to the
`model' distributed with that architecture.  I notice that the
default, which I used, compiles the compiler without optimization.
How much of a hit am I taking compiling my own programs if the
compiler isn't optimized?  Can someone tell me how to control
(independently) 
  a) whether the compiler is compiled with optimization
  b) for any library, whether that library is compiled with optimization
I'm perfectly happy to do this by using flags and switches on the
m3make command line if that will do the job.

A separate, unrelated question: I want to build M3 for the SPARC using
the same source directories.  What is the easiest way to do this?
Shall I ftp boot.SPARC*.tar.Z?  Or is there an easy way to
cross-compile?
-- 
Norman Ramsey
nr@princeton.edu


======================================================================= 107 ===
Date:    27 Apr 92 14:04:12 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: AutoFlush stream

>>>>> On 24 Apr 92 23:53:28 GMT, vixie@pa.dec.com (Paul A Vixie) said:

Paul> C's "line buffering" is a lose, since you still need explicit flushes
Paul> for partial-line output, and further, you pay one system call per output
Paul> line even if you're writing hundreds (or thousands) of output lines
Paul> back-to-back.

Umm, wait a minute: one *library* call, e.g., to puts, does NOT equal one
*system* call. The stdio package typically buffers until some considerable
quantity of output is generated, and then does a system call; that is why one
does fflush. Output to terminal devices may be handled differently.

--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================= 108 ===
Date:    Mon, 27 Apr 92 16:00:14 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Questions about installing SRC M3, v 2.0x

In article <1992Apr24.161017.9628@newross.Princeton.EDU>, nr@cs.Princeton.EDU (
) writes:

> Can someone tell me how to control
> (independently) 
>   a) whether the compiler is compiled with optimization

The optimization of the bootstrap compiler and of the bootstrap driver
can be set in the config file (BOOTOPT).  If you want different
options for the compiler and the driver, replaces the instances of
BOOTOPT in one of {compiler,driver}/src/m3makefile.

>   b) for any library, whether that library is compiled with optimization

Add a line like

M3OPT = -O

at the beginning of <library>/src/m3makefile, and cross your fingers so that
your make will take the latter of two definitions of a make symbol. 

> I'm perfectly happy to do this by using flags and switches on the
> m3make command line if that will do the job.

Unfortunately, there is no universal way of passing arguments through
recursive makes, and we would have a hard time without recursive makes.

> A separate, unrelated question: I want to build M3 for the SPARC using
> the same source directories.  What is the easiest way to do this?
> Shall I ftp boot.SPARC*.tar.Z?  Or is there an easy way to
> cross-compile?

The easiest it to get the boot.SPARC* archive and to unpack it in the
same place as your current installation.  All the derived files are
built in directories that are architecture specific.  m3make figures
the architecture for which it should build.

-- 
Eric.



======================================================================= 109 ===
Date:    Mon, 27 Apr 92 15:39:40 PDT
From:    jdd@src.dec.com (John DeTreville)
Subject: Re: Modula-3 Users Group Meeting...

Executive summary: June is approaching, as is the Modula-3 Users'
Group meeting.

Although June 16 doesn't satisfy everyone, nor does holding the
meeting in Palo Alto, these still seem the best choices.  If there's
not a sudden groundswell of complaints, the meeting will be at SRC in
Palo Alto on June 16, the day before SIGPLAN in San Francisco.

If you haven't already, please send us a message if you think you'd
like to attend, so that we can keep a rough head count.  You can now
send your message to mug-meeting@src.dec.com and it will be directed
to the right people.

A couple of people have volunteered talks and we're beating the bushes
to get others to volunteer.  We'd like as many talks from outside SRC
as possible: about Modula-3 itself, about what you've done with it,
whatever.  In addition to full-length talks, we'll have a session for
5-minute talks by anyone with something to say.  If you can't give a
full-length talk, perhaps you'd like to give a 5-minute talk.  Think
about it.

If you think you might like to give a talk, please send a title and
short abstract to mug-meeting@src.dec.com.  If you'd like to propose a
topic for group discussion, send it in too.

I hope to be able to post a initial agenda sometime next week.

Cheers,
John DeTreville
DEC SRC


======================================================================= 110 ===
Date:    Mon, 27 Apr 92 19:44:30 PDT
From:    msm@.dec.com (Mark S. Manasse)
Subject: Re: AutoFlush stream


It shouldn't be very hard to create a new reader class which takes a
reader and writer as input to its init method, and which flushes the
writer whenever a new buffer is needed to satisfy requests to read.

This module could even update stdin in its module initialization section,
so that just by importing LinkedRdWr into your program you could get
the desired behavior.

You could check whether the input reader was intermittent, to decide
whether to just return the reader passed in.  If you suppose that it was,
the methods seek and close need to be overridden so that seek:
1) flushes the linked writer.  2) reads as much as it can from the other
linked reader, and copies it into its own buffer (using CharsReady and
GetSub, for instance, unless it's supposed to block, in which case it
can call GetChar to do the blocking).  A more efficient implementation
could share buff with the underlying reader, just setting the indices
into it differently, if you were sure that no one would access the
underlying reader directly.

Close just needs to flush the writer, and close the linked reader.

Mark


======================================================================= 111 ===
Date:    Mon, 27 Apr 92 17:54:27 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: SRC Modula-3 2.06 available

from gatekeeper.dec.com:pub/DEC/Modula-3/release.

Numerous bug fixes and improvements in the compiler (coverage seems to
be in better shape), the runtime (threads, gc, fingerprint - pickles
seems to be in better shape), the pretty printer, the U* interfaces
in particular for SUN3 and SPARC, showheap, the Modula-3 toolkit. 

New in this release: seekable text writers, Tcl 6.2 binding interface,
modula-3 mode for gnuemacs (both template based and electric), tags
for gnuemacs (really a repackaging of the Xerox PARC stuff). 

-- 
Eric.



======================================================================= 112 ===
Date:    Tue, 28 Apr 92 15:03:39 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Modula-3 AST toolkit 2.06 available

In article <1992Apr28.132911.8977@src.dec.com>, mjordan@src.dec.com (Mick Jorda
n) writes:
> It is built in the same manner as other Modula-3
> distributions, e.g. "m3make build_m3tk install_m3tk"

Make that "m3make -f m3makefile.m3tk all install".

-- 
Eric.



======================================================================= 113 ===
Date:    27 Apr 92 18:35:58 GMT
From:    woolsey@mri.uucp (Jeff Woolsey)
Subject: Re: Modula 3 on an RS/6000 320

In article <1992Apr24.153727.18229@kakwa.ucs.ualberta.ca> barton@chopin.seas.uc
la.edu (Bob Barton System Administrator (403)492 5160) writes:
>Keywords: 
>
>Has anyone got Modula3 ver 2.04 running on an RS6000?
>I am working on an RS6000 320 using AIX 3.1.5.
>
>When trying to do the m3make build_boot I get an error message from awk
>indicating syntax errors in source lines 43 and 50 which I think are in the
>file /usr/local/lib/m3/mklist.awk. I don't know what this file is meant to do
>so I have not tried changing anything in it.
>
>In addition I will soon be moving to AIX 3.2 and wonder if there are any
>known problems that appear for Modula 3.
>
>NOTE: (Modula 3 is available by anonymous ftp from gatekeeper.dec.com)
>	(for IBM Risc 6000 installations ensure that the BSD install is
>	 used not the AIX install) 
>
>Bob Barton (barton@chopin.eche.ualberta.ca)


Thu Apr 16 13:42:09 CDT 1992

Problems installing boot.IBMR2-2.04.tar.Z

1.	This awk, like some others, has different precedence for
	string concatenation and output redirection.  mklist.awk
	requires () around "." name in two places.

1.5	There's an uncommented #----- line in the top-level m3makefile.

2.	I performed the bsdcc installation.

3.	/lib/cpp predefines absolutely no symbols!  it also converts
	tabs to spaces in macro expansions.  Thus, imake needs to
	be built with the kludge.  But I could find no way to convince
	it (after adding || defined(aix) ) that it was actually on
	an aix system other than -Daix in m3make/IBMR2/makefile.

4.	The compiler doesn't like volatile return types from functions.
	I added #define _IMPORT extern just before first offending
	statement in Thread_i.c, Rd_i.c, Wr_i.c, and others.
	Fortunately (?) /lib/cpp doesn't complain about multiple
	#defines.  However, changing the _IMPORT define in all affected
	modules is too tedious [but necessary due to #5 below.  I
	haven't finished doing this yet!].  Changing it more globally
	in a header then means that I need to eliminate _all_ of the
	volatiles, because of type conflicts.  Of course, this means
	that multi-threaded code may exhibit peculiarities, but my
	application is single-threaded, and I'm just benchmarking on a
	borrowed machine anyway.

5.	The resulting compiler looped for an hour trying to build
	the library.  No joy.

6.	m3make scratch_IBMR2 doesn't work, either.
-- 
-- 
Jeff Woolsey			800 950 5554	woolsey@mri.COM
Microtec Research, Inc.	     +1 408 980 1300	woolsey@netcom.COM
Nothing like a three-address mailer....		woolsey@folderol.UUCP


======================================================================= 114 ===
Date:    Tue, 28 Apr 92 13:29:11 PDT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Modula-3 AST toolkit 2.06 available

Version 2 of the Modula-3 AST toolkit, a development of the otherwise defunct
Olivetti Modula-3 implemention, is now available via ftp from
gatekeeper.dec.com.  There are no substantial changes from version 1, other
than the implementation of the "twelve changes" to the language definition.
That is, the toolkit supports the language defined in "Systems Programming with
Modula-3", and is compatible with the conventions of the SRC Modula-3
implementation. The documentation on the toolkit components has been improved,
particularly that for the AST specification.

The system is made available under the same licence terms as the SRC compiler.
In addition the original Olivetti sources are covered by a separate,
non-restrictive, copyright notice.

The toolkit is designed to support the creation of Modula-3 program
development tools and is structured around a compiler front-end 
which uses a public Abstract Syntax Tree (AST) to represent program
source. A description of the (original) system can be found in:

  "An Extensible Programming Environment for Modula-3", Mick Jordan,
  Proceedings of the Fourth ACM SIGSOFT Symposium on Software Development
  Environments, Software Engineering Notes, 15, 6, Dec 1990.

A number of tools are provided with the toolkit, vis:

  * (m3check) A tool that is a step towards an integrated, incremental 
    program development environment for Modula-3. It includes a compiler
    front end, a tool to scan the file system for source file changes
    and recompile changed (and dependent) units, a pre-linker to analyse
    a program for completeness, and a primitive browser. I have reworked
    this tool quite a bit in repsonse to user feedback. On a DECstation 5000,
    if compiled with optimisation, it compiles at about 500 lines a second
    and, since it caches interfaces and is interactive, can provide
    a fast turnround syntax/semantic checker, before invoking "m3make".

  * (m3fe) (Just a) compiler front-end (syntax/semantic analysis), with 
    optional checks for unused variables, uncaught exceptions, etc. The 
    compiler can compile multiple sources in one invocation and compiles each
    interface once only.

  * (m3modgen) A tool to generate skeleton modules from interfaces.

  * (m3seegen) A tool to generate a textual form of a generic 
    instantiation, with optional substitution of the generic formals
    by the actuals.

The toolkit is designed to be extensible, by virtue of the AST
and a collection of reusable compiler components. I expect to add more
tools over time, and hope that others will be motivated to do so. 

** N.B. You must install version 2.06 (or later) of SRC Modula-3 before
** attempting to build the toolkit.

The toolkit is stored in the directory /pub/DEC/Modula-3/release in the
file m3tk-2.06.tar.Z.  It is built in the same manner as other Modula-3
distributions, e.g. "m3make build_m3tk install_m3tk", assuming that you
have already installed SRC Modula-3 (2.06 or later). You will get plenty of 
warning messages, but these are all harmless.

Thanks to Geoff Wyant and David Goldberg for being beta-testers.

Mick Jordan, Apr 24 1992.




======================================================================= 115 ===
Date:    Tue, 28 Apr 92 15:21:42 PDT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: Modula-3 AST toolkit 2.06 available

In article <1992Apr28.150339.11060@src.dec.com>, muller@src.dec.com (Eric Mulle
r) writes:

> Make that "m3make -f m3makefile.m3tk all install".
> 

Right. A big thanks to Eric for doing all the hard work to actually construct t
he 
distribution.

Mick Jordan


======================================================================= 116 ===
Date:    Tue, 28 Apr 92 21:19:37 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: performance

This message reports some experiments I just made, to assess the
performance problems of Modula-3.

In all cases, I am running on a DECstation 5000/200, 64Mb of memory,
Ultrix 4.2, SRC Modula-3 2.06.  The machine was lightly loaded in all
cases. cc is the C compiler what comes with the DECstation, gcc is gcc 2.1.

I concentrated mostly on the size of the programs (but also looked at
the compilation time).  I took two test programs: Hello world (hello),
and the same program with 1000 calls to Wr.PutText instead of one
(hello2).  Times are in seconds, sizes in kilobytes.

I used various combinations of driver/compilers/libm3:

 A bootstrap driver compiled with cc -g
   bootstrap compiler compiled with cc -g
   cc -g
   libm3 compiled with cc -g

 B bootstrap driver compiled with gcc -O2
   bootstrap compiler compiled with gcc -O2
   gcc -g
   libm3 compiled with cc -g
  
 C bootstrap driver compiled with gcc -O2
   bootstrap compiler compiled with gcc -O2
   gcc -g
   libm3 compiled with gcc -O2

 D bootstrap driver compiled with gcc -O2
   bootstrap compiler compiled with gcc -O2
   gcc -O2
   libm3 compiled with gcc -O2

I could not try cc -O2; the m3compiler obtained with cc -O2 does not
run properly.  I am not sure about the problem yet (it's delicate to
debug optimized code).


Here are the quantities I measured:

  a.out data segment ---------------------------------------------------
  a.out text segment ----------------------------------------------    |
  Hello{,2}.mo data segment ------------------------------        |    |
  Hello{,2}.mo text segment -------------------------    |        |    |
  stripped a.out size ----------------------        |    |        |    |
  a.out size --------------------------    |        |    |        |    |
  user time, in seconds  ------       |    |        |    |        |    |
                              |       |    |        |    |        |    |

                 A hello     4.3     853  332       0    0       228  104
                   hello2   11.0     875  352      20    0       250  104
				    
                 B hello     2.8     880  340       0    0       232  108
                   hello2   13.2     920  368      27    0       260  108
      				    
                 C hello     2.9     408  260       0    0       152  108
                   hello2   13.2     448  288      27    0       180  108
				    
                 D hello     2.7     402  260       0    0       152  108
                   hello2  521.8     419  276      16    0       168  108


"a.out text/data segment" are the results of "size" on the executable.

"Hello{,2}.mo text/data segment" are the result of "size" on the
object produced by the compilation of Hello{,2}.m3.

"a.out size" is the size of the executable file; "stripped a.out" is
the size of the executable file after it has been stripped.

"user time" is the user time reported by the csh time on the full
compilation/link of Hello{,2}.m3.  I considered elapsed time too
volatile to be meaningful (I wanted to take only one measurement for
each program).


So let's try to see how we get a 920 k executable (B, hello2).  I got
these number by comparisons of the different cases; these number are
very approximate.

  - 143 of symbol information                   15%  |
  -  18 of debugging information for Hello2      2%  |  60%
  - 391 of debugging information for libm3      42%  |
  -  27 of text for Hello2                       3%
  - 233 of text for libm3                       25%
  - 108 of data for libm3                       12%

Oviously, debugging cost a lot in the a.out size.  The situation could
be better if there was no debugging information for the C variables
that do not correspond to Modula-3 variables (temporaries generated by
the compiler), but I don't know by how much.

The program itself looks reasonnable.

We made no attempts to have a "shrinking" runtime; you get the full
allocator/collector, full thread implementation, full fingerprint
implementation (for pickles), runtime type information, as well as
other pieces, even if your program doesn't need that.  So far, the
programs we have been building here at SRC typically use most of the
runtime, and there was little value in making pieces optional (for
example, replacing the real thread procedures by empty ones if there
is no call to Thread.Fork). Given that, the runtime does not look too
bad.  Of course, if we start to have many programs that don't use the
full runtime, it may be worth investigating that area.

Clearly shared libraries can be a big win.  The text segment and a
good part of the data segment (constant tables for fingerprints) can
be shared.  In earlier experiments with OSF/1 shared libraries, I have
measured the text segment for Hello world going from 295k to 12k and
the data segment going from 100k to 4k.  For solitaire (which uses
trestle), the differences are even more important: 1452k to 128k and
408k to 48k.

On the time side, this is the elapsed time for the various phases of 
C/Hello (these values seem typical):

 seconds  #times  operation
    1.36       2  inhaling library link info
    1.54       1  compiling Modula-3 -> C
    0.11       1  merging new link info
    4.98       2  compiling C -> object
    0.05       1  checking global consistency
    0.11       1  generating _m3main.c
    2.96       1  linking
    0.04       3  removing temporary files
    0.02       1  renaming files
    0.08          other
---------------------------------------------------
   11.26          TOTAL

Shared libraries can be a big win on that front too. In my earlier
experiments, the link time went from 13s to 1s for Hello world, and
from 77s to 7s for solitaire.

I am looking right now into supporting the shared libraries for SunOS.

--
Eric.



======================================================================= 117 ===
Date:    Tue, 28 Apr 92 21:33:43 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: performance

In article <1992Apr28.211937.17186@src.dec.com>, I write:

>                    hello2  521.8     419  276      16    0       168  108

This 521 seconds is not a typo.  I reproduced it a few times.  This
sounds like a bug in gcc, I will investigate.

-- 
Eric.



======================================================================= 118 ===
Date:    28 Apr 92 18:59:58 GMT
From:    mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: Re: initializing objects

In article <1992Apr28.153157.17037@newross.Princeton.EDU> nr@algorithms (Norman
 Ramsey) writes:

> If you declare
>   TYPE T <: REFANY;
> then NEW(T) is illegal...

Yes, but what about objects?  I want to put an object type (perhaps
partially opaque) in an interface and make sure that clients initialize
the object properly.  Is there a way to do this without making
the type completely opaque?

-mike


======================================================================= 119 ===
Date:    Tue, 28 Apr 92 13:29:11 PDT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Modula-3 AST toolkit 2.06 available

Version 2 of the Modula-3 AST toolkit, a development of the otherwise defunct
Olivetti Modula-3 implemention, is now available via ftp from
gatekeeper.dec.com.  There are no substantial changes from version 1, other
than the implementation of the "twelve changes" to the language definition.
That is, the toolkit supports the language defined in "Systems Programming with
Modula-3", and is compatible with the conventions of the SRC Modula-3
implementation. The documentation on the toolkit components has been improved,
particularly that for the AST specification.

The system is made available under the same licence terms as the SRC compiler.
In addition the original Olivetti sources are covered by a separate,
non-restrictive, copyright notice.

The toolkit is designed to support the creation of Modula-3 program
development tools and is structured around a compiler front-end 
which uses a public Abstract Syntax Tree (AST) to represent program
source. A description of the (original) system can be found in:

  "An Extensible Programming Environment for Modula-3", Mick Jordan,
  Proceedings of the Fourth ACM SIGSOFT Symposium on Software Development
  Environments, Software Engineering Notes, 15, 6, Dec 1990.

A number of tools are provided with the toolkit, vis:

  * (m3check) A tool that is a step towards an integrated, incremental 
    program development environment for Modula-3. It includes a compiler
    front end, a tool to scan the file system for source file changes
    and recompile changed (and dependent) units, a pre-linker to analyse
    a program for completeness, and a primitive browser. I have reworked
    this tool quite a bit in repsonse to user feedback. On a DECstation 5000,
    if compiled with optimisation, it compiles at about 500 lines a second
    and, since it caches interfaces and is interactive, can provide
    a fast turnround syntax/semantic checker, before invoking "m3make".

  * (m3fe) (Just a) compiler front-end (syntax/semantic analysis), with 
    optional checks for unused variables, uncaught exceptions, etc. The 
    compiler can compile multiple sources in one invocation and compiles each
    interface once only.

  * (m3modgen) A tool to generate skeleton modules from interfaces.

  * (m3seegen) A tool to generate a textual form of a generic 
    instantiation, with optional substitution of the generic formals
    by the actuals.

The toolkit is designed to be extensible, by virtue of the AST
and a collection of reusable compiler components. I expect to add more
tools over time, and hope that others will be motivated to do so. 

** N.B. You must install version 2.06 (or later) of SRC Modula-3 before
** attempting to build the toolkit.

The toolkit is stored in the directory /pub/DEC/Modula-3/release in the
file m3tk-2.06.tar.Z.  It is built in the same manner as other Modula-3
distributions, e.g. "m3make build_m3tk install_m3tk", assuming that you
have already installed SRC Modula-3 (2.06 or later). You will get plenty of 
warning messages, but these are all harmless.

Thanks to Geoff Wyant and David Goldberg for being beta-testers.

Mick Jordan, Apr 24 1992.




======================================================================= 120 ===
Date:    Tue, 28 Apr 92 21:33:43 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: performance

In article <1992Apr28.211937.17186@src.dec.com>, I write:

>                    hello2  521.8     419  276      16    0       168  108

This 521 seconds is not a typo.  I reproduced it a few times.  This
sounds like a bug in gcc, I will investigate.

-- 
Eric.



======================================================================= 121 ===
Date:    Mon, 27 Apr 92 17:54:27 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: SRC Modula-3 2.06 available

from gatekeeper.dec.com:pub/DEC/Modula-3/release.

Numerous bug fixes and improvements in the compiler (coverage seems to
be in better shape), the runtime (threads, gc, fingerprint - pickles
seems to be in better shape), the pretty printer, the U* interfaces
in particular for SUN3 and SPARC, showheap, the Modula-3 toolkit. 

New in this release: seekable text writers, Tcl 6.2 binding interface,
modula-3 mode for gnuemacs (both template based and electric), tags
for gnuemacs (really a repackaging of the Xerox PARC stuff). 

-- 
Eric.



======================================================================= 122 ===
Date:    27 Apr 92 14:04:12 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: AutoFlush stream

>>>>> On 24 Apr 92 23:53:28 GMT, vixie@pa.dec.com (Paul A Vixie) said:

Paul> C's "line buffering" is a lose, since you still need explicit flushes
Paul> for partial-line output, and further, you pay one system call per output
Paul> line even if you're writing hundreds (or thousands) of output lines
Paul> back-to-back.

Umm, wait a minute: one *library* call, e.g., to puts, does NOT equal one
*system* call. The stdio package typically buffers until some considerable
quantity of output is generated, and then does a system call; that is why one
does fflush. Output to terminal devices may be handled differently.

--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================= 123 ===
Date:    27 Apr 92 18:35:58 GMT
From:    woolsey@mri.uucp (Jeff Woolsey)
Subject: Re: Modula 3 on an RS/6000 320

In article <1992Apr24.153727.18229@kakwa.ucs.ualberta.ca> barton@chopin.seas.uc
la.edu (Bob Barton System Administrator (403)492 5160) writes:
>Keywords: 
>
>Has anyone got Modula3 ver 2.04 running on an RS6000?
>I am working on an RS6000 320 using AIX 3.1.5.
>
>When trying to do the m3make build_boot I get an error message from awk
>indicating syntax errors in source lines 43 and 50 which I think are in the
>file /usr/local/lib/m3/mklist.awk. I don't know what this file is meant to do
>so I have not tried changing anything in it.
>
>In addition I will soon be moving to AIX 3.2 and wonder if there are any
>known problems that appear for Modula 3.
>
>NOTE: (Modula 3 is available by anonymous ftp from gatekeeper.dec.com)
>	(for IBM Risc 6000 installations ensure that the BSD install is
>	 used not the AIX install) 
>
>Bob Barton (barton@chopin.eche.ualberta.ca)


Thu Apr 16 13:42:09 CDT 1992

Problems installing boot.IBMR2-2.04.tar.Z

1.	This awk, like some others, has different precedence for
	string concatenation and output redirection.  mklist.awk
	requires () around "." name in two places.

1.5	There's an uncommented #----- line in the top-level m3makefile.

2.	I performed the bsdcc installation.

3.	/lib/cpp predefines absolutely no symbols!  it also converts
	tabs to spaces in macro expansions.  Thus, imake needs to
	be built with the kludge.  But I could find no way to convince
	it (after adding || defined(aix) ) that it was actually on
	an aix system other than -Daix in m3make/IBMR2/makefile.

4.	The compiler doesn't like volatile return types from functions.
	I added #define _IMPORT extern just before first offending
	statement in Thread_i.c, Rd_i.c, Wr_i.c, and others.
	Fortunately (?) /lib/cpp doesn't complain about multiple
	#defines.  However, changing the _IMPORT define in all affected
	modules is too tedious [but necessary due to #5 below.  I
	haven't finished doing this yet!].  Changing it more globally
	in a header then means that I need to eliminate _all_ of the
	volatiles, because of type conflicts.  Of course, this means
	that multi-threaded code may exhibit peculiarities, but my
	application is single-threaded, and I'm just benchmarking on a
	borrowed machine anyway.

5.	The resulting compiler looped for an hour trying to build
	the library.  No joy.

6.	m3make scratch_IBMR2 doesn't work, either.
-- 
-- 
Jeff Woolsey			800 950 5554	woolsey@mri.COM
Microtec Research, Inc.	     +1 408 980 1300	woolsey@netcom.COM
Nothing like a three-address mailer....		woolsey@folderol.UUCP


======================================================================= 124 ===
Date:    Tue, 28 Apr 92 15:21:42 PDT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: Modula-3 AST toolkit 2.06 available

In article <1992Apr28.150339.11060@src.dec.com>, muller@src.dec.com (Eric Mulle
r) writes:

> Make that "m3make -f m3makefile.m3tk all install".
> 

Right. A big thanks to Eric for doing all the hard work to actually construct t
he 
distribution.

Mick Jordan


======================================================================= 125 ===
Date:    Mon, 27 Apr 92 15:39:40 PDT
From:    jdd@src.dec.com (John DeTreville)
Subject: Re: Modula-3 Users Group Meeting...

Executive summary: June is approaching, as is the Modula-3 Users'
Group meeting.

Although June 16 doesn't satisfy everyone, nor does holding the
meeting in Palo Alto, these still seem the best choices.  If there's
not a sudden groundswell of complaints, the meeting will be at SRC in
Palo Alto on June 16, the day before SIGPLAN in San Francisco.

If you haven't already, please send us a message if you think you'd
like to attend, so that we can keep a rough head count.  You can now
send your message to mug-meeting@src.dec.com and it will be directed
to the right people.

A couple of people have volunteered talks and we're beating the bushes
to get others to volunteer.  We'd like as many talks from outside SRC
as possible: about Modula-3 itself, about what you've done with it,
whatever.  In addition to full-length talks, we'll have a session for
5-minute talks by anyone with something to say.  If you can't give a
full-length talk, perhaps you'd like to give a 5-minute talk.  Think
about it.

If you think you might like to give a talk, please send a title and
short abstract to mug-meeting@src.dec.com.  If you'd like to propose a
topic for group discussion, send it in too.

I hope to be able to post a initial agenda sometime next week.

Cheers,
John DeTreville
DEC SRC


======================================================================= 126 ===
Date:    Mon, 27 Apr 92 16:00:14 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Questions about installing SRC M3, v 2.0x

In article <1992Apr24.161017.9628@newross.Princeton.EDU>, nr@cs.Princeton.EDU (
) writes:

> Can someone tell me how to control
> (independently) 
>   a) whether the compiler is compiled with optimization

The optimization of the bootstrap compiler and of the bootstrap driver
can be set in the config file (BOOTOPT).  If you want different
options for the compiler and the driver, replaces the instances of
BOOTOPT in one of {compiler,driver}/src/m3makefile.

>   b) for any library, whether that library is compiled with optimization

Add a line like

M3OPT = -O

at the beginning of <library>/src/m3makefile, and cross your fingers so that
your make will take the latter of two definitions of a make symbol. 

> I'm perfectly happy to do this by using flags and switches on the
> m3make command line if that will do the job.

Unfortunately, there is no universal way of passing arguments through
recursive makes, and we would have a hard time without recursive makes.

> A separate, unrelated question: I want to build M3 for the SPARC using
> the same source directories.  What is the easiest way to do this?
> Shall I ftp boot.SPARC*.tar.Z?  Or is there an easy way to
> cross-compile?

The easiest it to get the boot.SPARC* archive and to unpack it in the
same place as your current installation.  All the derived files are
built in directories that are architecture specific.  m3make figures
the architecture for which it should build.

-- 
Eric.



======================================================================= 127 ===
Date:    Tue, 28 Apr 92 21:19:37 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: performance

This message reports some experiments I just made, to assess the
performance problems of Modula-3.

In all cases, I am running on a DECstation 5000/200, 64Mb of memory,
Ultrix 4.2, SRC Modula-3 2.06.  The machine was lightly loaded in all
cases. cc is the C compiler what comes with the DECstation, gcc is gcc 2.1.

I concentrated mostly on the size of the programs (but also looked at
the compilation time).  I took two test programs: Hello world (hello),
and the same program with 1000 calls to Wr.PutText instead of one
(hello2).  Times are in seconds, sizes in kilobytes.

I used various combinations of driver/compilers/libm3:

 A bootstrap driver compiled with cc -g
   bootstrap compiler compiled with cc -g
   cc -g
   libm3 compiled with cc -g

 B bootstrap driver compiled with gcc -O2
   bootstrap compiler compiled with gcc -O2
   gcc -g
   libm3 compiled with cc -g
  
 C bootstrap driver compiled with gcc -O2
   bootstrap compiler compiled with gcc -O2
   gcc -g
   libm3 compiled with gcc -O2

 D bootstrap driver compiled with gcc -O2
   bootstrap compiler compiled with gcc -O2
   gcc -O2
   libm3 compiled with gcc -O2

I could not try cc -O2; the m3compiler obtained with cc -O2 does not
run properly.  I am not sure about the problem yet (it's delicate to
debug optimized code).


Here are the quantities I measured:

  a.out data segment ---------------------------------------------------
  a.out text segment ----------------------------------------------    |
  Hello{,2}.mo data segment ------------------------------        |    |
  Hello{,2}.mo text segment -------------------------    |        |    |
  stripped a.out size ----------------------        |    |        |    |
  a.out size --------------------------    |        |    |        |    |
  user time, in seconds  ------       |    |        |    |        |    |
                              |       |    |        |    |        |    |

                 A hello     4.3     853  332       0    0       228  104
                   hello2   11.0     875  352      20    0       250  104
				    
                 B hello     2.8     880  340       0    0       232  108
                   hello2   13.2     920  368      27    0       260  108
      				    
                 C hello     2.9     408  260       0    0       152  108
                   hello2   13.2     448  288      27    0       180  108
				    
                 D hello     2.7     402  260       0    0       152  108
                   hello2  521.8     419  276      16    0       168  108


"a.out text/data segment" are the results of "size" on the executable.

"Hello{,2}.mo text/data segment" are the result of "size" on the
object produced by the compilation of Hello{,2}.m3.

"a.out size" is the size of the executable file; "stripped a.out" is
the size of the executable file after it has been stripped.

"user time" is the user time reported by the csh time on the full
compilation/link of Hello{,2}.m3.  I considered elapsed time too
volatile to be meaningful (I wanted to take only one measurement for
each program).


So let's try to see how we get a 920 k executable (B, hello2).  I got
these number by comparisons of the different cases; these number are
very approximate.

  - 143 of symbol information                   15%  |
  -  18 of debugging information for Hello2      2%  |  60%
  - 391 of debugging information for libm3      42%  |
  -  27 of text for Hello2                       3%
  - 233 of text for libm3                       25%
  - 108 of data for libm3                       12%

Oviously, debugging cost a lot in the a.out size.  The situation could
be better if there was no debugging information for the C variables
that do not correspond to Modula-3 variables (temporaries generated by
the compiler), but I don't know by how much.

The program itself looks reasonnable.

We made no attempts to have a "shrinking" runtime; you get the full
allocator/collector, full thread implementation, full fingerprint
implementation (for pickles), runtime type information, as well as
other pieces, even if your program doesn't need that.  So far, the
programs we have been building here at SRC typically use most of the
runtime, and there was little value in making pieces optional (for
example, replacing the real thread procedures by empty ones if there
is no call to Thread.Fork). Given that, the runtime does not look too
bad.  Of course, if we start to have many programs that don't use the
full runtime, it may be worth investigating that area.

Clearly shared libraries can be a big win.  The text segment and a
good part of the data segment (constant tables for fingerprints) can
be shared.  In earlier experiments with OSF/1 shared libraries, I have
measured the text segment for Hello world going from 295k to 12k and
the data segment going from 100k to 4k.  For solitaire (which uses
trestle), the differences are even more important: 1452k to 128k and
408k to 48k.

On the time side, this is the elapsed time for the various phases of 
C/Hello (these values seem typical):

 seconds  #times  operation
    1.36       2  inhaling library link info
    1.54       1  compiling Modula-3 -> C
    0.11       1  merging new link info
    4.98       2  compiling C -> object
    0.05       1  checking global consistency
    0.11       1  generating _m3main.c
    2.96       1  linking
    0.04       3  removing temporary files
    0.02       1  renaming files
    0.08          other
---------------------------------------------------
   11.26          TOTAL

Shared libraries can be a big win on that front too. In my earlier
experiments, the link time went from 13s to 1s for Hello world, and
from 77s to 7s for solitaire.

I am looking right now into supporting the shared libraries for SunOS.

--
Eric.



======================================================================= 128 ===
Date:    Tue, 28 Apr 92 15:03:39 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Modula-3 AST toolkit 2.06 available

In article <1992Apr28.132911.8977@src.dec.com>, mjordan@src.dec.com (Mick Jorda
n) writes:
> It is built in the same manner as other Modula-3
> distributions, e.g. "m3make build_m3tk install_m3tk"

Make that "m3make -f m3makefile.m3tk all install".

-- 
Eric.



======================================================================= 129 ===
Date:    28 Apr 92 15:31:57 GMT
From:    nr@algorithms (Norman Ramsey)
Subject: Re: initializing objects

In article <MHCOFFIN.92Apr25110022@tolstoy.uwaterloo.ca> mhcoffin@tolstoy.uwate
rloo.ca (Michael Coffin) writes:
>It seems to me that it is a weakness of Modula 3 that there is no easy
>way to ensure that opaque types are properly initialized...

>Introduce a
>pragma that indicates that NEW is not allowed for a particular opaque
>type.  

If you declare
  TYPE T <: REFANY;
then NEW(T) is illegal...


======================================================================= 130 ===
Date:    Mon, 27 Apr 92 19:44:30 PDT
From:    msm@.dec.com (Mark S. Manasse)
Subject: Re: AutoFlush stream


It shouldn't be very hard to create a new reader class which takes a
reader and writer as input to its init method, and which flushes the
writer whenever a new buffer is needed to satisfy requests to read.

This module could even update stdin in its module initialization section,
so that just by importing LinkedRdWr into your program you could get
the desired behavior.

You could check whether the input reader was intermittent, to decide
whether to just return the reader passed in.  If you suppose that it was,
the methods seek and close need to be overridden so that seek:
1) flushes the linked writer.  2) reads as much as it can from the other
linked reader, and copies it into its own buffer (using CharsReady and
GetSub, for instance, unless it's supposed to block, in which case it
can call GetChar to do the blocking).  A more efficient implementation
could share buff with the underlying reader, just setting the indices
into it differently, if you were sure that no one would access the
underlying reader directly.

Close just needs to flush the writer, and close the linked reader.

Mark


======================================================================= 131 ===
Date:    28 Apr 92 15:31:57 GMT
From:    nr@algorithms (Norman Ramsey)
Subject: Re: initializing objects

In article <MHCOFFIN.92Apr25110022@tolstoy.uwaterloo.ca> mhcoffin@tolstoy.uwate
rloo.ca (Michael Coffin) writes:
>It seems to me that it is a weakness of Modula 3 that there is no easy
>way to ensure that opaque types are properly initialized...

>Introduce a
>pragma that indicates that NEW is not allowed for a particular opaque
>type.  

If you declare
  TYPE T <: REFANY;
then NEW(T) is illegal...


======================================================================= 132 ===
Date:    Wed, 29 Apr 92 12:09:43 PDT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: performance

In article <1992Apr28.211937.17186@src.dec.com>, muller@src.dec.com (Eric Mulle
r) writes:

> ...  Of course, if we start to have many programs that don't use the
> full runtime, it may be worth investigating that area.
> 

I am investigating that area as part of the global optimiser, in which unused p
rocedures
and static data are removed. (Before you ask, yes it does handle procedures bou
nd
to methods). Currently I am operating in a source->source mode which causes som
e
problems in handling the guts of the runtime, so right now I cant give measurem
ents
that correspond directly to Eric's for "Hello". However, I can report the size 
of the
resulting source that results from optimising "Hello".  

The "Hello" program simply coalesced into a single module is 1175 lines long an
d
contains 75 procedure bodies.

The "Hello" program with unused procedures removed is 460 lines long and
contains 24 procedure bodies.

I have also applied the optimiser to some Trestle applications, e.g "BadBricks"
,
which is 30,000 lines containing 1268 procedures, and reduces to 22,800 lines
and 848 procedures.

The optimiser is based around the AST toolkit, and I expect to release a
version later this year, once I have implemented a basic inline procedure
expansion capability.

Mick Jordan


 


======================================================================= 133 ===
Date:    Wed, 29 Apr 92 15:20:40 PDT
From:    jdd@src.dec.com (John DeTreville)
Subject: Re: Modula-3 Users Group Meeting...

Well, the mug-meeting@src.dec.com mail alias isn't working at all!
Apologies to everyone who's had their mail bounce.  For right now,
please RSVP to me personally, jdd@src.dec.com.

Also, I forgot to mention that in addition to inviting talks, we
invite any demos you might like to give.  Our meeting room has a
wall-sized video screen, so Trestle-based demos would look especially
stunning.

If you'd like to give a demo, please contact me as soon as possible.
It will probably entail bringing up your system at SRC prior to the
meeting.

Cheers,
John


======================================================================= 134 ===
Date:    Wed, 29 Apr 92 12:09:43 PDT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: performance

In article <1992Apr28.211937.17186@src.dec.com>, muller@src.dec.com (Eric Mulle
r) writes:

> ...  Of course, if we start to have many programs that don't use the
> full runtime, it may be worth investigating that area.
> 

I am investigating that area as part of the global optimiser, in which unused p
rocedures
and static data are removed. (Before you ask, yes it does handle procedures bou
nd
to methods). Currently I am operating in a source->source mode which causes som
e
problems in handling the guts of the runtime, so right now I cant give measurem
ents
that correspond directly to Eric's for "Hello". However, I can report the size 
of the
resulting source that results from optimising "Hello".  

The "Hello" program simply coalesced into a single module is 1175 lines long an
d
contains 75 procedure bodies.

The "Hello" program with unused procedures removed is 460 lines long and
contains 24 procedure bodies.

I have also applied the optimiser to some Trestle applications, e.g "BadBricks"
,
which is 30,000 lines containing 1268 procedures, and reduces to 22,800 lines
and 848 procedures.

The optimiser is based around the AST toolkit, and I expect to release a
version later this year, once I have implemented a basic inline procedure
expansion capability.

Mick Jordan


 


======================================================================= 135 ===
Date:    28 Apr 92 18:59:58 GMT
From:    mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: Re: initializing objects

In article <1992Apr28.153157.17037@newross.Princeton.EDU> nr@algorithms (Norman
 Ramsey) writes:

> If you declare
>   TYPE T <: REFANY;
> then NEW(T) is illegal...

Yes, but what about objects?  I want to put an object type (perhaps
partially opaque) in an interface and make sure that clients initialize
the object properly.  Is there a way to do this without making
the type completely opaque?

-mike


======================================================================= 136 ===
Date:    Thu, 30 Apr 92 01:35:29 GMT
From:    vixie@pa.dec.com (Paul Vixie)
Subject: Re: AutoFlush stream

Paul> C's "line buffering" is a lose, since you still need explicit flushes
Paul> for partial-line output, and further, you pay one system call per output
Paul> line even if you're writing hundreds (or thousands) of output lines
Paul> back-to-back.

[Eliot Moss]
>> Umm, wait a minute: one *library* call, e.g., to puts, does NOT equal one
>> *system* call. The stdio package typically buffers until some considerable
>> quantity of output is generated, and then does a system call; that is why
>> one does fflush. Output to terminal devices may be handled differently.

If you want "line buffering", you get a system call every time there is a
newline in the output stream.  That's what "line buffering" means.  And it
is a compromise design, suitable only for simple languages like C where you
just can't do any better without adding (more and more) warts to the runtime.
-- 
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Ready, Fire, Aim"
<vixie@pa.dec.com> decwrl!vixie
<paul@vix.com>     vixie!paul          alt.pink.bunny.boom.boom.boom moderator


======================================================================= 137 ===
Date:    29 Apr 92 18:23:39
From:    vixie@pa.dec.com (Paul A Vixie)
Subject: Re: AutoFlush stream

Paul> C's "line buffering" is a lose, since you still need explicit flushes
Paul> for partial-line output, and further, you pay one system call per output
Paul> line even if you're writing hundreds (or thousands) of output lines
Paul> back-to-back.

[Eliot Moss]
>> Umm, wait a minute: one *library* call, e.g., to puts, does NOT equal one
>> *system* call. The stdio package typically buffers until some considerable
>> quantity of output is generated, and then does a system call; that is why
>> one does fflush. Output to terminal devices may be handled differently.

If you want "line buffering", you get a system call every time there is a
newline in the output stream.  That's what "line buffering" means.  And it
is a compromise design, suitable only for simple languages like C where you
just can't do any better without adding (more and more) warts to the runtime.
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Ready, Fire, Aim"
<vixie@pa.dec.com> decwrl!vixie
<paul@vix.com>     vixie!paul          alt.pink.bunny.boom.boom.boom moderator


======================================================================= 138 ===
Date:    Thu, 30 Apr 92 01:35:29 GMT
From:    vixie@pa.dec.com (Paul Vixie)
Subject: Re: AutoFlush stream

Paul> C's "line buffering" is a lose, since you still need explicit flushes
Paul> for partial-line output, and further, you pay one system call per output
Paul> line even if you're writing hundreds (or thousands) of output lines
Paul> back-to-back.

[Eliot Moss]
>> Umm, wait a minute: one *library* call, e.g., to puts, does NOT equal one
>> *system* call. The stdio package typically buffers until some considerable
>> quantity of output is generated, and then does a system call; that is why
>> one does fflush. Output to terminal devices may be handled differently.

If you want "line buffering", you get a system call every time there is a
newline in the output stream.  That's what "line buffering" means.  And it
is a compromise design, suitable only for simple languages like C where you
just can't do any better without adding (more and more) warts to the runtime.
-- 
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Ready, Fire, Aim"
<vixie@pa.dec.com> decwrl!vixie
<paul@vix.com>     vixie!paul          alt.pink.bunny.boom.boom.boom moderator


======================================================================= 139 ===
Date:    29 Apr 92 09:35:13 GMT
From:    ljp@sm.luth.se (Johan Persson)
Subject: Embedded formatting in comments

Hi,

Sorry if this is a FAQ; I'm new to M3 and just beginning
my tour through the libraries. I've seen some comment's
which looks like LaTeX. Is there some way to print the
interfaces and use the embedded formatting (some script
or something)?

Thanks,
Johan

----------------------------------------------------------------------
That Is The Question: Co-existence or no existence. Piet Hein
----------------------------------------------------------------------
Johan Persson                  E-mail:               Voice:           
Dept. of Computer Science      ljp@sm.luth.se        +46 (0)920 912 00
University of Lule{\aa}                              Fax:
S-951 87 Lule{\aa},Sweden                            +46 (0)920 988 94
-----------------------------------------------------------------------


======================================================================= 140 ===
Date:    Wed, 29 Apr 92 20:39:06 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Questions about installing SRC M3, v 2.0x

In article <VIXIE.92Apr29162037@cognition.pa.dec.com>, vixie@pa.dec.com (Paul A
 Vixie) writes:

> Has anyone tried M3 with GCC?

Yes, m3 2.06 works with gcc 2.1 -O2 on a DECstation. Sometime the compile
time seems weird (see my message about performance).

-- 
Eric.



======================================================================= 141 ===
Date:    29 Apr 92 16:20:37
From:    vixie@pa.dec.com (Paul A Vixie)
Subject: Re: Questions about installing SRC M3, v 2.0x

When I caused M3 2.04's bootstrap compiler to build the real compiler
with optimization on an Ultrix/RISC 4.2 system, the resulting compiler
failed to work (died with assert errors).  My theory right now is that
the C code generated by M3 is too baroque for the Ultrix/RISC CC in 4.2.

For my next trick, I'm going to try M3 2.06 with GCC 2.1, which has a
slightly more reliable optimizer than the Ultrix/RISC CC -- and GCC lets
you use "-g -O" so you can have optimization and still have debugging
symbols that mostly point to the right places.

Has anyone tried M3 with GCC?
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Ready, Fire, Aim"
<vixie@pa.dec.com> decwrl!vixie
<paul@vix.com>     vixie!paul          alt.pink.bunny.boom.boom.boom moderator


======================================================================= 142 ===
Date:    29 Apr 92 09:35:13 GMT
From:    ljp@sm.luth.se (Johan Persson)
Subject: Embedded formatting in comments

Hi,

Sorry if this is a FAQ; I'm new to M3 and just beginning
my tour through the libraries. I've seen some comment's
which looks like LaTeX. Is there some way to print the
interfaces and use the embedded formatting (some script
or something)?

Thanks,
Johan

----------------------------------------------------------------------
That Is The Question: Co-existence or no existence. Piet Hein
----------------------------------------------------------------------
Johan Persson                  E-mail:               Voice:           
Dept. of Computer Science      ljp@sm.luth.se        +46 (0)920 912 00
University of Lule{\aa}                              Fax:
S-951 87 Lule{\aa},Sweden                            +46 (0)920 988 94
-----------------------------------------------------------------------


======================================================================= 143 ===
Date:    29 Apr 92 16:20:37
From:    vixie@pa.dec.com (Paul A Vixie)
Subject: Re: Questions about installing SRC M3, v 2.0x

When I caused M3 2.04's bootstrap compiler to build the real compiler
with optimization on an Ultrix/RISC 4.2 system, the resulting compiler
failed to work (died with assert errors).  My theory right now is that
the C code generated by M3 is too baroque for the Ultrix/RISC CC in 4.2.

For my next trick, I'm going to try M3 2.06 with GCC 2.1, which has a
slightly more reliable optimizer than the Ultrix/RISC CC -- and GCC lets
you use "-g -O" so you can have optimization and still have debugging
symbols that mostly point to the right places.

Has anyone tried M3 with GCC?
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Ready, Fire, Aim"
<vixie@pa.dec.com> decwrl!vixie
<paul@vix.com>     vixie!paul          alt.pink.bunny.boom.boom.boom moderator


======================================================================= 144 ===
Date:    29 Apr 92 18:23:39
From:    vixie@pa.dec.com (Paul A Vixie)
Subject: Re: AutoFlush stream

Paul> C's "line buffering" is a lose, since you still need explicit flushes
Paul> for partial-line output, and further, you pay one system call per output
Paul> line even if you're writing hundreds (or thousands) of output lines
Paul> back-to-back.

[Eliot Moss]
>> Umm, wait a minute: one *library* call, e.g., to puts, does NOT equal one
>> *system* call. The stdio package typically buffers until some considerable
>> quantity of output is generated, and then does a system call; that is why
>> one does fflush. Output to terminal devices may be handled differently.

If you want "line buffering", you get a system call every time there is a
newline in the output stream.  That's what "line buffering" means.  And it
is a compromise design, suitable only for simple languages like C where you
just can't do any better without adding (more and more) warts to the runtime.
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Ready, Fire, Aim"
<vixie@pa.dec.com> decwrl!vixie
<paul@vix.com>     vixie!paul          alt.pink.bunny.boom.boom.boom moderator


======================================================================= 145 ===
Date:    Wed, 29 Apr 92 20:39:06 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Questions about installing SRC M3, v 2.0x

In article <VIXIE.92Apr29162037@cognition.pa.dec.com>, vixie@pa.dec.com (Paul A
 Vixie) writes:

> Has anyone tried M3 with GCC?

Yes, m3 2.06 works with gcc 2.1 -O2 on a DECstation. Sometime the compile
time seems weird (see my message about performance).

-- 
Eric.



======================================================================= 146 ===
Date:    Wed, 29 Apr 92 15:20:40 PDT
From:    jdd@src.dec.com (John DeTreville)
Subject: Re: Modula-3 Users Group Meeting...

Well, the mug-meeting@src.dec.com mail alias isn't working at all!
Apologies to everyone who's had their mail bounce.  For right now,
please RSVP to me personally, jdd@src.dec.com.

Also, I forgot to mention that in addition to inviting talks, we
invite any demos you might like to give.  Our meeting room has a
wall-sized video screen, so Trestle-based demos would look especially
stunning.

If you'd like to give a demo, please contact me as soon as possible.
It will probably entail bringing up your system at SRC prior to the
meeting.

Cheers,
John


======================================================================= 147 ===
Date:    Thu, 30 Apr 92 10:35:17 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: performance

In article <1992Apr29.120943.2681@src.dec.com>, mjordan@src.dec.com (Mick Jorda
n) writes:
> 
> The "Hello" program simply coalesced into a single module is 1175 lines long 
and
> contains 75 procedure bodies.
> 
> The "Hello" program with unused procedures removed is 460 lines long and
> contains 24 procedure bodies.

This numbers are somewhat misleading.  The resulting Modula-3 code
contains LOCK statements and NEW expressions, which are implemented by
the runtime, but the corresponding procedures do not appear in the
expanded code. 

-- 
Eric.



======================================================================= 148 ===
Date:    30 Apr 92 15:01:40 GMT
From:    ljp@sm.luth.se (Johan Persson)
Subject: A proposal for a new construction

Hi,

I thought I should share some ideas that were floating
around here at the department some years ago and perhaps
get some reactions from experienced M3 programmers on what
an extension to the M3 language, described below, would impose
for problems.

First som background;
Some year ago a group here at the department designed and
implemented an enhanced version of Modula-2 called Modula-2000.
(This project is now abandoned mainly because of time and shortage
of people, although it resulted in some interesting experience.)

Some of the more significant changes was in the type system
which was designed to have a more uniform treatment of
types. Much in the same spirit as M3, for example structural equality.

Some of the restrictions that exists in M2 was removed, for example
the following:

 - the type of the return value of a function procedure must
   be simple

 - an opaque type must be of a fixed size known to the
   compiler

 - constructor expression forms are provided only for simple
   types

 - if the return value of a function is a pointer type,
   an application may not be immediately dereferenced


There was also an extension of the basic types to include
a STRING type.

Furthermore, the module system was enhanced to support
generic modules. There were also some other changes which tried
to clerify the fundamental confusion between object and value in
imperative languages. For example, value parameters are considered
as values and therefore cannot be assigned to. The FOR-statement
was modified to stress the fact that the controlling
"variable" is not a variable but a value which takes on successive
values.

However, the main innovation as compared to M2, as I see it,
was the introduction of the disjoint-union. It was designed
with the possibility of pattern matching, ala ML or HASKELL,
in mind.

It's often the case that one want to define a type whose
element have a number of different forms, In M2 this is expressed
using variant records. Consider an example with arithmetic
expressions.

In M2 you would probably code something like

TYPE
  Operator = (plus,minus,times,div);
  ExprForm = (const,var.opexp);
  Expr = POINTER TO ExprNode;
  ExprNode = RECORD
               CASE form:ExprForm OF
                 const: val:INTEGER
               |   var: id:STRING  
               | opexp: op:Operator;
                        left,right:Expr
               END (* CASE *)
             END (* RECORD *)

The interesting type here is Expr. The form of the actual value
at run time can be determined by looking at the tag field form.
However, access to the correct field is entirely dependent on
the discipline of the programmer and as we all know, if you have
a choice you will probably end up making a mistake.

To remedy this problem the variant record construction was
replaced by the (cleaner) UNION construct. The previous example
would become

TYPE
  Operator = (plus,minus,times,div);
  Expr = UNION
           const : INTEGER
         | var   : STRING
         | opexp : POINTER TO RECORD
                     op: Operator;
                     left,right : Expr
                   END
         END;

An Expr takes one of three possible forms indicated by the tag
const, var or opexp. The tag, however, is not a variable and can
be neither assigned to nor tested. Values of type Expr are built
using the tag as a constructor. The only way to access the contents
of a variable e:Expr is with the use of the VARIANT statement
introduced precisely for this purpose.

Note the POINTER construction, this is necessary as the type
system in M-2000 doesn't allow true recursive types. 

A function to evaluate an expression with respect to an environment
which binds integer values to variable names might look like

PROCEDURE eval(e:Expr; env:Environment.T):INTEGER
  VAR lval,rval:INTEGER;
  BEGIN
    VARIANT e OF
      const(c): RETURN c
    | var(v)  : VARIANT lookup(x,env) OF
                  notfound: error( ... );
                | found(y): RETURN y
		END (* VARIANT *)
    | opexp(f): lval = eval(f^.left,env);
                rval = eval(f^.right,env);
                CASE f^.op OF
                  plus : RETURN lval + rval;
                   (* The rest omitted *)
                END (* CASE *)
    END (* VARIANT *)
  END eval;

The code deserves some explanation. First e is examined and its form
found, (const,var,opexp), then the value is bound to the constructor
variable (c,v,f). Those of you familiar with ML or HASKELL will
recognize this as the imperative version of pattern matching,
admittedly in a very crude form.

It should be noted that the identifier used as argument to the
tags in these variant denotes a value; it is not a variable
and consequently can not be assigned to. This is a consequence
from the fact that 'e' is a value parameter. The assignment of
'e' has the form e:=const(5), for example.
 
The lookup function returns a value of a union type. The
signature could be stated as

PROCEDURE lookup(x:STRING,env:Environment.T): UNION
                                                notfound:
                                              | found:INTEGER
					      END;

The idea in lookup to use unions as range types for partial
functions should ne noted. This is often an elegant method in
such cases partly replacing the use of exceptions. This method
also forces the user to be explicetly aware of the possiblity
of failure, sometimes considered a disadvantage by lazy people
but of course necessary for serious programming.

Now, after this somewhat lengthy introduction, I'll try to
make a point. I was thinking of implementing UNIONS for
M3, but I would like to get a second (and a third) opinion on
what you people experinced with M3 think of this. There might be
some serious pitfalls which I tend to overlook since I haven't
any real experience (yet) with M3.

Thanks in advance,

Johan

----------------------------------------------------------------------
That Is The Question: Co-existence or no existence. Piet Hein
----------------------------------------------------------------------
Johan Persson                  E-mail:               Voice:           
Dept. of Computer Science      ljp@sm.luth.se        +46 (0)920 912 00
University of Lule{\aa}                              Fax:
S-951 87 Lule{\aa},Sweden                            +46 (0)920 988 94
-----------------------------------------------------------------------


======================================================================= 149 ===
Date:    Thu, 30 Apr 92 12:11:05 PDT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: performance

In article <1992Apr30.103517.28231@src.dec.com>, muller@src.dec.com (Eric Mulle
r) writes:
> In article <1992Apr29.120943.2681@src.dec.com>, mjordan@src.dec.com (Mick Jor
dan) writes:
> > 
> > The "Hello" program simply coalesced into a single module is 1175 lines lon
g and
> > contains 75 procedure bodies.
> > 
> > The "Hello" program with unused procedures removed is 460 lines long and
> > contains 24 procedure bodies.
> 
> This numbers are somewhat misleading.  The resulting Modula-3 code
> contains LOCK statements and NEW expressions, which are implemented by
> the runtime, but the corresponding procedures do not appear in the
> expanded code. 
> 

Eric is quite correct. He knows the runtime a lot better than I do! I ran the
wrong version of the optimiser which considers much of the runtime as a hardwir
ed"
black box. So both figures are an underestimate. I redid the analysis, this tim
e
including all the runtime, with the following results.

The "Hello" program simply coalesced into a single module is 9194 lines long an
d
contains 393 procedure bodies.

The "Hello" program with unused procedures removed is 3212 lines long and
contains 126 procedure bodies.

Since I cant currently compile and run these programs I cant be sure that the
optimised version is correct, but it looks ok. 

Mick


======================================================================= 150 ===
Date:    1 May 92 03:10:15 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: A proposal for a new construction

I have two kinds of responses to the proposal for a UNION type:

1) OBJECT types essentially subsume UNIONS with added functionality, though
   they do not have quite as concise a notation, etc. My understanding was
   that UNIONs (or their earlier version, variant records) were not included
   in M3 precisely because of the overlap with OBJECT types.

2) CLU oneof and variant types did all this before. I don't think there's
   necessarily all that much issue about how to do it well. The issue is
   whether, given OBJECT types, it should be done in M3 at all.

Since there are other ways to achieve the functionality, albeit more verbose
ones, I favor considering first extensions that give new functionality. Of
course this tends to run afoul of the original goal of a language that can be
described in 50 pages or less, which I find laudable. Maybe we should agree to
change the limit to 60 or 75 pages :-). There is always a tricky question of
where to stop adding features to a language ....
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================= 151 ===
Date:    Thu, 30 Apr 92 21:27:22 -0400
From:    Norman Ramsey <nr@Princeton.EDU>
Subject: Re: A proposal for a new construction

I believe current wisdom is that the subtyping mechanism should be
used for union types, using TYPECASE for discrimination.  I'm doing
this in my code.  I find it somewhat unsatisfactory since I have to
allocate an object to do it, and since there could always be subtypes
I don't know about, but it works tolerably well.

Norman Ramsey


======================================================================= 152 ===
Date:    Thu, 30 Apr 92 10:35:17 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: performance

In article <1992Apr29.120943.2681@src.dec.com>, mjordan@src.dec.com (Mick Jorda
n) writes:
> 
> The "Hello" program simply coalesced into a single module is 1175 lines long 
and
> contains 75 procedure bodies.
> 
> The "Hello" program with unused procedures removed is 460 lines long and
> contains 24 procedure bodies.

This numbers are somewhat misleading.  The resulting Modula-3 code
contains LOCK statements and NEW expressions, which are implemented by
the runtime, but the corresponding procedures do not appear in the
expanded code. 

-- 
Eric.



======================================================================= 153 ===
Date:    Thu, 30 Apr 92 12:11:05 PDT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: performance

In article <1992Apr30.103517.28231@src.dec.com>, muller@src.dec.com (Eric Mulle
r) writes:
> In article <1992Apr29.120943.2681@src.dec.com>, mjordan@src.dec.com (Mick Jor
dan) writes:
> > 
> > The "Hello" program simply coalesced into a single module is 1175 lines lon
g and
> > contains 75 procedure bodies.
> > 
> > The "Hello" program with unused procedures removed is 460 lines long and
> > contains 24 procedure bodies.
> 
> This numbers are somewhat misleading.  The resulting Modula-3 code
> contains LOCK statements and NEW expressions, which are implemented by
> the runtime, but the corresponding procedures do not appear in the
> expanded code. 
> 

Eric is quite correct. He knows the runtime a lot better than I do! I ran the
wrong version of the optimiser which considers much of the runtime as a hardwir
ed"
black box. So both figures are an underestimate. I redid the analysis, this tim
e
including all the runtime, with the following results.

The "Hello" program simply coalesced into a single module is 9194 lines long an
d
contains 393 procedure bodies.

The "Hello" program with unused procedures removed is 3212 lines long and
contains 126 procedure bodies.

Since I cant currently compile and run these programs I cant be sure that the
optimised version is correct, but it looks ok. 

Mick


======================================================================= 154 ===
Date:    30 Apr 92 15:01:40 GMT
From:    ljp@sm.luth.se (Johan Persson)
Subject: A proposal for a new construction

Hi,

I thought I should share some ideas that were floating
around here at the department some years ago and perhaps
get some reactions from experienced M3 programmers on what
an extension to the M3 language, described below, would impose
for problems.

First som background;
Some year ago a group here at the department designed and
implemented an enhanced version of Modula-2 called Modula-2000.
(This project is now abandoned mainly because of time and shortage
of people, although it resulted in some interesting experience.)

Some of the more significant changes was in the type system
which was designed to have a more uniform treatment of
types. Much in the same spirit as M3, for example structural equality.

Some of the restrictions that exists in M2 was removed, for example
the following:

 - the type of the return value of a function procedure must
   be simple

 - an opaque type must be of a fixed size known to the
   compiler

 - constructor expression forms are provided only for simple
   types

 - if the return value of a function is a pointer type,
   an application may not be immediately dereferenced


There was also an extension of the basic types to include
a STRING type.

Furthermore, the module system was enhanced to support
generic modules. There were also some other changes which tried
to clerify the fundamental confusion between object and value in
imperative languages. For example, value parameters are considered
as values and therefore cannot be assigned to. The FOR-statement
was modified to stress the fact that the controlling
"variable" is not a variable but a value which takes on successive
values.

However, the main innovation as compared to M2, as I see it,
was the introduction of the disjoint-union. It was designed
with the possibility of pattern matching, ala ML or HASKELL,
in mind.

It's often the case that one want to define a type whose
element have a number of different forms, In M2 this is expressed
using variant records. Consider an example with arithmetic
expressions.

In M2 you would probably code something like

TYPE
  Operator = (plus,minus,times,div);
  ExprForm = (const,var.opexp);
  Expr = POINTER TO ExprNode;
  ExprNode = RECORD
               CASE form:ExprForm OF
                 const: val:INTEGER
               |   var: id:STRING  
               | opexp: op:Operator;
                        left,right:Expr
               END (* CASE *)
             END (* RECORD *)

The interesting type here is Expr. The form of the actual value
at run time can be determined by looking at the tag field form.
However, access to the correct field is entirely dependent on
the discipline of the programmer and as we all know, if you have
a choice you will probably end up making a mistake.

To remedy this problem the variant record construction was
replaced by the (cleaner) UNION construct. The previous example
would become

TYPE
  Operator = (plus,minus,times,div);
  Expr = UNION
           const : INTEGER
         | var   : STRING
         | opexp : POINTER TO RECORD
                     op: Operator;
                     left,right : Expr
                   END
         END;

An Expr takes one of three possible forms indicated by the tag
const, var or opexp. The tag, however, is not a variable and can
be neither assigned to nor tested. Values of type Expr are built
using the tag as a constructor. The only way to access the contents
of a variable e:Expr is with the use of the VARIANT statement
introduced precisely for this purpose.

Note the POINTER construction, this is necessary as the type
system in M-2000 doesn't allow true recursive types. 

A function to evaluate an expression with respect to an environment
which binds integer values to variable names might look like

PROCEDURE eval(e:Expr; env:Environment.T):INTEGER
  VAR lval,rval:INTEGER;
  BEGIN
    VARIANT e OF
      const(c): RETURN c
    | var(v)  : VARIANT lookup(x,env) OF
                  notfound: error( ... );
                | found(y): RETURN y
		END (* VARIANT *)
    | opexp(f): lval = eval(f^.left,env);
                rval = eval(f^.right,env);
                CASE f^.op OF
                  plus : RETURN lval + rval;
                   (* The rest omitted *)
                END (* CASE *)
    END (* VARIANT *)
  END eval;

The code deserves some explanation. First e is examined and its form
found, (const,var,opexp), then the value is bound to the constructor
variable (c,v,f). Those of you familiar with ML or HASKELL will
recognize this as the imperative version of pattern matching,
admittedly in a very crude form.

It should be noted that the identifier used as argument to the
tags in these variant denotes a value; it is not a variable
and consequently can not be assigned to. This is a consequence
from the fact that 'e' is a value parameter. The assignment of
'e' has the form e:=const(5), for example.
 
The lookup function returns a value of a union type. The
signature could be stated as

PROCEDURE lookup(x:STRING,env:Environment.T): UNION
                                                notfound:
                                              | found:INTEGER
					      END;

The idea in lookup to use unions as range types for partial
functions should ne noted. This is often an elegant method in
such cases partly replacing the use of exceptions. This method
also forces the user to be explicetly aware of the possiblity
of failure, sometimes considered a disadvantage by lazy people
but of course necessary for serious programming.

Now, after this somewhat lengthy introduction, I'll try to
make a point. I was thinking of implementing UNIONS for
M3, but I would like to get a second (and a third) opinion on
what you people experinced with M3 think of this. There might be
some serious pitfalls which I tend to overlook since I haven't
any real experience (yet) with M3.

Thanks in advance,

Johan

----------------------------------------------------------------------
That Is The Question: Co-existence or no existence. Piet Hein
----------------------------------------------------------------------
Johan Persson                  E-mail:               Voice:           
Dept. of Computer Science      ljp@sm.luth.se        +46 (0)920 912 00
University of Lule{\aa}                              Fax:
S-951 87 Lule{\aa},Sweden                            +46 (0)920 988 94
-----------------------------------------------------------------------


======================================================================= 155 ===
Date:    Thu, 30 Apr 92 21:27:22 -0400
From:    Norman Ramsey <nr@Princeton.EDU>
Subject: Re: A proposal for a new construction

I believe current wisdom is that the subtyping mechanism should be
used for union types, using TYPECASE for discrimination.  I'm doing
this in my code.  I find it somewhat unsatisfactory since I have to
allocate an object to do it, and since there could always be subtypes
I don't know about, but it works tolerably well.

Norman Ramsey


======================================================================= 156 ===
Date:    Fri, 1 May 92 04:11:14 PDT
From:    msm@src.dec.com (Mark S. Manasse)
Subject: Re: Embedded formatting in comments


If you're reading the Trestle interfaces, the answer is a qualified "yes".

The easy way to view the results of typesetting the interfaces is to
get a copy of SRC Research Report #68, the Trestle Reference Manual.  You
can send mail to src-report@src.dec.com to request that a copy be
mailed to you.  Incidentally, the Trestle Tutorial (SRC 69) is on its
way to the printer, so that should be available in a couple of weeks.

If you want to print it yourself, the answer is "not yet".  The programs
we have that build the reference manual from the sources are a bit
fragile at this point.  We hope to improve this soon.  For those of you
interested in the technology, read on.  Every else should probably
stop reading now, before they lose their lunch all over their keyboard.

For the curious, our formatting conventions are pretty simple.  Except for
comments, the program is typeset in a typewriter font, with narrow
margins and no filling or justification.  Most comments are just treated
as Latex text, and can contain arbitrary commands.  Except that double
quotes in a comment are used to surround things that should appear in
the same font as the program, like identifiers.  Now we're almost ready to
typeset.  One exception is that a comment immediately following a procedure
declaration gets typeset indented in a slanted font, sort of like a
theorem in mathematics.  And we toss in automatic index entries for
every declaration in an interface.  And we've always had our pretty-printer
handle comments that have vertical bars in the first column to mean that
the pretty-printer should keep its hands off that line, because it's part
of a table, or a piece of sample code, so we automatically switch to 
typewriter font.  Except sometimes you want to put some text in the
middle of a program example to indicate that some string is a meta-
variable, and not an identifier, so you put those in backquotes, but only
on lines in comments that started with a vertical bar.

Hey, you were warned.

Anyhow, we've found it useful in producing a document that actually
reflected the truth about our interfaces, and we don't find very much
of the typesetting commands too ugly while we're editing.  In particular,
the quoting convention seems quite tolerable.  The main things I don't
like are when we start getting into TeX commands that aren't in the
standard working set of most prgrammers, or aren't obvious.  I consider
something like {\it foo} to be relatively transparent (it means to put "foo"
into italics), and the Latex section header macros aren't too bad.
The ones I don't much like are the ones for typesetting bulleted lists,
mostly because you get a choice of having it look like a bulleted list
in the typeset version or in the typewritten version but not both.  We
still need to invent a couple more conventions, and then we'll be done.

Mark


======================================================================= 157 ===
Date:    1 May 92 03:10:15 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: A proposal for a new construction

I have two kinds of responses to the proposal for a UNION type:

1) OBJECT types essentially subsume UNIONS with added functionality, though
   they do not have quite as concise a notation, etc. My understanding was
   that UNIONs (or their earlier version, variant records) were not included
   in M3 precisely because of the overlap with OBJECT types.

2) CLU oneof and variant types did all this before. I don't think there's
   necessarily all that much issue about how to do it well. The issue is
   whether, given OBJECT types, it should be done in M3 at all.

Since there are other ways to achieve the functionality, albeit more verbose
ones, I favor considering first extensions that give new functionality. Of
course this tends to run afoul of the original goal of a language that can be
described in 50 pages or less, which I find laudable. Maybe we should agree to
change the limit to 60 or 75 pages :-). There is always a tricky question of
where to stop adding features to a language ....
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


