======================================================================= 1 ===
Date:    1 Jul 92 14:26:18 GMT
From:    markp@dmsperth.dms.oz (Mark Palmer)
Subject: maspars

We are just about to have shared access to a DECmpp12000, otherwise known as 
a Maspar, and I was wondering if anyone had attempted to use modula 3 on such a
beast. Presumably one would run the 'normal' sequential type code on the front
end DECstation, but possibly link it with parallel code that could execute on
the back end?

D


======================================================================= 2 ===
Date:    Thu, 2 Jul 92 03:50:27 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: Modula-3 FAQ

Archive-name: Modula-3-faq
Last-modified: Jun  6 1992


			MODULA-3 FAQ
			============


What is Modula-3 ?

   The goal of Modula-3 is to be as simple and safe as it can be while
   meeting the needs of modern systems programmers.  Instead of
   exploring new features, we studied the features of the Modula
   family of languages that have proven themselves in practice and
   tried to simplify them into a harmonious language.  We found that
   most of the successful features were aimed at one of two main
   goals: greater robustness, and a simpler, more systematic type
   system.

   Modula-3 descends from Mesa, Modula-2, Cedar, and Modula-2+.  It
   also resembles its cousins Object Pascal, Oberon, and Euclid.

   Modula-3 retains one of Modula-2's most successful features, the
   provision for explicit interfaces between modules.  It adds objects
   and classes, exception handling, garbage collection, lightweight
   processes (or threads), and the isolation of unsafe features.


Is Modula-3 a superset of Modula-2 ?

   No; valid Modula-2 programs are not valid Modula-3 programs.


Where can I get a description of Modula-3 ? 
   
   The definition of Modula-3 is contained in:

	System Programming with Modula-3
	Edited by Greg Nelson
	Prentice Hall Series in Innovative Technology
	ISBN 0-13-590464-1
	L.C. QA76.66.S87 1991

   also known as SPwM3.

   Sam Harbison has written a book about Modula3:

	Modula-3
	Samuel P. Harbison
	Prentice Hall, 1992
	ISBN 0-13-596396-6

   as well as an overview article, "Modula-3", in Byte, Vol. 15,
   Number 12, October 1990, p 385.


Where can I get information on Modula-3 ?

   There is a Usenet newsgroup, comp.lang.modula3.  The archives of
   that group are available via anonymous ftp from gatekeeper.dec.com
   in pub/DEC/Modula-3/comp.lang.modula3.  If you do not have
   access to Usenet, there is a relay mailing list; send a message to
   m3-request@src.dec.com to be added to it.


Where can I get an implementation ?

   There is only one implementation available today.  It has been built
   by SRC and is available via anonymous ftp from gatekeeper.dec.com in
   pub/DEC/Modula-3/release.  Contributed software can be found
   in pub/DEC/Modula-3/contrib.

   The current version, 2.07, implements the language defined in SPwM3.
   There are versions for the following machines:

	AIX386	IBM PC running AIX/PS2,
	AP3000	Apollo DN4500 running Domain/OS
	ARM	Acorn R260 running RISC iX 1.21
	DS3100	DECstation 3100 and 5000 running Ultrix 4.0 and 4.2
	HP300	HP 9000/300 running HP-UX 8.0
 	IBMR2	IBM R6000 running AIX 3.1, 
	IBMRT	IBM RT running IBM/4.3, 
	NEXT    NeXT running ?
	SPARC	SPARCstation running SunOS 4.1.x
	SUN3	SUN3 running SunOS
	UMAX    Encore Multimax running UMAX 4.3 (R4.1.1)
	VAX	VAX running Ultrix 3.1

   SRC Modula-3 includes a user manual, compiler, runtime library,
   some libraries and a few other goodies (see below).

   The compiler generates C as an intermediate language and should be
   fairly easy to port.  Except for the very lowest levels of the
   thread implementation, the entire system is written in Modula-3.


What if I don't have ftp access ?

   Unfortunately, we cannot deliver Modula-3 other than by 
   anonymous ftp.  Your best bet is to post a message to
   comp.lang.modula3, in the hope that somebody with ftp
   access can make a tape or floppy for you.
      

Can I contribute Modula-3 software ?

   Certainly.  Send us what you are willing to share, be it programs,
   libraries or other things.  We'll put them in the distribution. 

-- 
Eric.





-- 
Eric.



======================================================================= 3 ===
Date:    Thu, 2 Jul 92 18:59:21 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: comp.lang.modula-3 archive for june available

The messages sent to comp.lang.modula-3 during the month of June 92 are
available via anonymous ftp from:

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

Previous months are availble in the same directory.

-- 
Eric.



======================================================================= 4 ===
Date:    Thu, 2 Jul 1992 19:53:05 GMT
From:    wewallac@watsol.waterloo.edu (Bill Wallace)
Subject: Generics using generic interfaces

If one has a generic for a list say, and a tree and one wishes to implement
the tree generic in terms of the the list generic, the list generic must
be passed as an argument to the tree generic, and an actual modula/interface
must be created for the list as well as the tree.  It would be nice if
this were not so, if one could say in an interface (even if this is restricted
entirely to generic interfaces)
Generic Interface Tree(Label,List,Elem);
Interface Local=List(Elem); END Local;
...
END Tree.


======================================================================= 5 ===
Date:    3 Jul 92 01:24:47 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Generics using generic interfaces

Well, you don't really want more than instance of the inerface List(T) for a
given T within a program. Hence the need to create such interfaces explicitly,
since structural equivalence is not defined on interfaces, but on types. See
the discussion in the Systems Programming in Modula-3 book ......
--

		J. Eliot B. Moss, Associate 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


======================================================================= 6 ===
Date:    6 Jul 92 14:44:53 GMT
From:    ggf@saifr00.cfsat.honeywell.com (Gary Frederick)
Subject: building a cross compiler

I am interested in building the NeXT version on a Sun.  How do
I set things up such that I can use the Sun compiler to build
new boots for the NeXT?

Please e-mail to ggf@jsoft.com in addition to posting here if
you can.  I may be loosing access to news )-:

Gary


======================================================================= 7 ===
Date:    Sat, 04 Jul 92 22:43:23 GMT
From:    whedon@netcom.com (Bill Whedon)
Subject: Pointer to Professional Programmers Poll

POINTER:  Please see comp.lang.misc article dated Wed 01 Jul 92  04:38:41 GMT
using keywords  language, programming, poll, statistics   for a poll regarding
your use of languages.  Thanks for your patience and for not flaming me for 
not putting your favorite in a box specifically.  There are simply too many
languages, and the poll would have been too big for posting.  Please use the
write-in box as much as you need.  
Thanks in advance for your participation!
Cheers,
bw



-- 

Bill Whedon   whedon@netcom.com (408) 842-9914
"Hey, we're all professionals here, ain't we?"




======================================================================= 8 ===
Date:    Sat, 4 Jul 92 14:51:49 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Modula-3 Users' Group meeting report: part 4

In article 11150@src.dec.com, jdd@src.dec.com (John DeTreville) writes:
> [ ... ]
>                       Proposed Language Changes
>                             Norman Ramsey
> [ ... ]
>Discussion moved from specific topics to the general questions of how
>much change we want and what mechanisms there are for making changes.
>There was broad consensus in favor of keeping the language stable,
>although we didn't explore in detail what ``stability'' meant.  
>Greg Nelson's view was that another ``12 changes'' in the next 18
>months would be too much change, but that there would be changes
>eventually---otherwise the language would be dead.  Sam Harbison
>suggested that we think about making changes approximately every two
>years. 
>
IMHO, the crucial aspect of stability is that a valid M3 program today is
still a valid program tomorrow. Adding new features which simply extend the
capabilities of the language (like VIRTUAL OBJECT) don't affect stability
seriously. Other changes, which might cause that existing programs have to be
adapted, should be included carefully. But why discuss this in terms of
every n months? If there is a consensus that a certain feature is wanted and
needed, why not include it immediately? If someone personally dislikes this,
well - nobody is forced to work with an up-to-date version of the language.
Just stick with your old compiler until you think it's time to install a new
one.

Some good concepts are an important basis for a new language. But if the
language designers can't react (i.e. at least talk about) promptly to new
developments, the language *will* be dead before you know it. This is no
vote for being opportunistic, just for being open to new suggestions.

>Sam Harbison suggested that no changes at all are better than a few
>good changes, and that it is important to be able to point new users
>to a single document that describes the language, not make them apply
>deltas to the existing documents.  Christian Jacobi said that small
>improvements are not worth the disruption.  He also said that there is
>a difficult tightrope walk between promising enough stability and
>getting the necessary changes done.  He thought that the language
>commitee handled the 12 changes quite elegantly in this respect.
>
Hmm, does this mean that language changes should be made in large chunks?!
I don't see any good in this. In fact, I would want changes to come one at
a time, especially if I have to modify my sources.

Of course, there should be an up-to-date language description at any time.
But in what way does this oppose new developments? Just change the language
report accordingly and there we are.

>Dave Detlefs argued the opposite position, that Modula-3 has a small
>user community, so now is a good time to make changes.  Modula-3 might
>need to change to compete with C++ templates.  Eliot Moss pointed out
>that the designers might have an inaccurate picture of the potential
>impact changes, since they and most users are at SRC where the impact
>is high.  Eliot also suggested that compilers with experimental
>features should offer a conforming mode.
>
Very right. Even more important than the small user community seems to be
the fact that there is only one M3 compiler by now. This takes away all the
standarization overhead.

>It was suggested that comp.lang.modula3 could be used as a forum for
>proposing changes, but there seemed to be agreement posting is too
>easy and that the process for proposing changes should be more
>arduous.  Someone asked how well comp.lang.modula3 is working, and
>those present were not too dissatisfied, although there were broad
>complaints that there is too much quantity and the signal-to-noise
>ratio is low.  No-one present volunteered to moderate a Modula-3
>newsgroup.
>
WHAT?! Ever took a look at comp.lang.Ada, ..., not to talk about comp.lang.C++?
The C++ group comes up with 30-60 (!) articles *every day*! If you think
signal-to-noise ratio is low in comp.lang.modula3, just look into a few other
groups. Now there you'll find really idiotic postings. The modula3 group is one
of the most constructive and serious I know of. We surely don't need moderation
.

And talking about quantity: IMHO, there should be much *more* discussion about
conceptual aspects of the language. Most of the time, I have the impression tha
t
not many people are overly interested in improving M3 - either they like it and
use it or they don't (flame on - sometimes this impression extends to the
language designers themselves - flame off).

Anyway: what alternatives have you considered? Discussion about M3 in the
newsgroup is natural - that's what it's good for. So what's the problem? To
take a frequent look into the postings if there might be something valuable
in there? That shouldn't be too hard. Or do you guys think you will have all
good ideas by yourselves (little post-flame here).
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany



======================================================================= 9 ===
Date:    Sat, 4 Jul 92 18:48:30 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Optimization on SPARC Part 2

I've just got into installing M3 2.07 with gcc 2.2.2. In addition to the
optimization error in compiler/src/types/SubrangeType.m3, there seems to
be a new problem in libm3 if compiled with -O. The resulting compiler will
crash with segmentation violation. Also, RGBInt__FromRGB won't run through
the C compiler, because the function returns a RECORD with packed components.

Any help?
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany



======================================================================= 10 ===
Date:    Mon, 6 Jul 1992 07:36:23 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: Optimization on SPARC Part 2


Peter Klein wrote:
> I've just got into installing M3 2.07 with gcc 2.2.2. In addition to the
> optimization error in compiler/src/types/SubrangeType.m3, there seems to
> be a new problem in libm3 if compiled with -O. The resulting compiler will
> crash with segmentation violation. Also, RGBInt__FromRGB won't run through
> the C compiler, because the function returns a RECORD with packed components.
I retrieved 2.07 when it was still in the test-release directory, and it compil
ed
with no problems (boot.SPARC). I use that compiler at the moment without proble
ms.

Earlyer I tried compiling all the 2.06 stuff using the earlyer installed compil
er,
but I never managed to pull it off.

PS I use the standard SUN cc.

PPS Code generation with the current version is MUCH better than previous relea
ses!
    hello worlds is down to 350Kb stripped ;-)

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


======================================================================= 11 ===
Date:    7 Jul 92 01:33:41 GMT
From:    freeman@EuroPARC.Xerox.COM (Steve Freeman)
Subject: m3text in Andrew EZ editor

Does anyone know anything about the m3text mode in the EZ editor in Andrew?
In particular, how to get it to work without core-dumping EZ. I suspect it's
something simple like setting a path but I haven't anyone to hand who would
know.

Incidentally, the reason I'm interested in this is that, much as I like the
language, I find the combination of M3 and emacs (even with the right modes)
pretty bad for the wrists; I think it`s the heavy use of various shift keys.

Steve (really Steve.Freeman@computer-lab.cambridge.ac.uk)


======================================================================= 12 ===
Date:    Tue, 7 Jul 92 06:22:18 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: building a cross compiler

In article <1992Jul6.144453.29189@saifr00.cfsat.honeywell.com>, ggf@saifr00.cfs
at.honeywell.com (Gary Frederick) writes:
> I am interested in building the NeXT version on a Sun.  How do
> I set things up such that I can use the Sun compiler to build
> new boots for the NeXT?

In the toplevel directory:

$ m3make -f m3makefile.compiler cross NEW=NEXT
   to build a cross compiler running on the current machine, compiling
   for NEXT

$ m3make -f m3makefile.compiler bootstrap_both NEW=NEXT
   to cross-compile the driver and the compiler

$ m3make -f m3makefile.compiler pack NEW=NEXT
   to create boot_files/boot.NEXT-2.07.tar.Z, similar to the one we 
   distribute

If your Sun and you NeXT share the file system, you don't need the
last step: go on the NeXT, in the top-level directory and pretend that
you have just unpacked the boot archive.

-- 
Eric.



======================================================================= 13 ===
Date:    7 Jul 92 12:53:22 GMT
From:    ggf@saifr00.cfsat.honeywell.com (Gary Frederick)
Subject: Re: building a cross compiler

Thanks for the info on building the cross.

Gary


======================================================================= 14 ===
Date:    Tue, 7 Jul 92 11:10:26 EDT
From:    wyant@centerline.com
Subject: re: Proposed langauge changes

> [ ... ]
>                       Proposed Language Changes
>                             Norman Ramsey
> [ ... ]
>Discussion moved from specific topics to the general questions of how
>much change we want and what mechanisms there are for making changes.
>There was broad consensus in favor of keeping the language stable,
>although we didn't explore in detail what ``stability'' meant.  
>Greg Nelson's view was that another ``12 changes'' in the next 18
>months would be too much change, but that there would be changes
>eventually---otherwise the language would be dead.  Sam Harbison
>suggested that we think about making changes approximately every two
>years. 
>

The older I get, the more conservative toward language changes I
get. Maybe that's just a consequence of seeing how C++ is evolving.
To many of the proposals are of the form, "Language X has this
nifty feature, can we force it into C++...?"

The principal reasons for suggesting a language change (IMHO) should 
be:

   1) To clarify an ambiguous area of the language definition.
   2) To better support an area where the language 
	a) Discovered to be deficient AND
	b) Discovered to be a widely used area of the language
	   (or was intended to be a widely used area)

I think M3 generics fall under (2) above. I would like to see some
hard thinking done in the area of a cleaner, simpler definition of
generics that preserves abstraction.

--  geoff

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


======================================================================= 15 ===
Date:    7 Jul 1992 22:23:51 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: Proposed langauge changes

In article <9207071510.AA20139@riposte> wyant@centerline.com writes:
>The older I get, the more conservative toward language changes I
>get. Maybe that's just a consequence of seeing how C++ is evolving.
>To many of the proposals are of the form, "Language X has this
>nifty feature, can we force it into C++...?"

I think this is correct -- that is, language change is not necessarily
a bad thing, but it has been a bad thing for C++.  For instance, if
someone could figure out what multiple inheritance was supposed to
mean, and what the useful idioms are, and how to make it interact
cleanly with the rest of the language, then it might be good to add it
to Modula-3.  I hear good things about mix-ins from NeWS and CLOS
programmers.  However, if we don't understand it, or cannot caputer
the useful idioms, or if it as some vile interaction with any existing
good thing, then perhaps we can live without it.

David Chase
Sun


======================================================================= 16 ===
Date:    Tue, 7 Jul 92 23:39:36 GMT
From:    msm@src.dec.com (Mark S. Manasse)
Subject: Re: question on generics


The issue of generics is a bit of a red-herring here; you would have
the same problem if you wanted to put the ListOfBar interface in a
separate interface even if it weren't generic.

The way you get around this is to split up your Foo interface as follows:

INTERFACE Foo;

TYPE 
  Bar <: PublicBar;
  PublicBar = OBJECT ... END;

END Foo.

INTERFACE BarDetails;

IMPORT Foo, ListOfFooDotBar;

REVEAL Foo.Bar = 
  Foo.PublicBar BRANDED OBJECT enumerate(): ListOfFooDotBar.T END;

END BarDetails.


Every Bar will then have an enumerate method, and any clients of BarDetails
will be able to call it.

Alternatively, you could have a Bar interface that reveals only that a
Bar.T is a subtype of ROOT, build ListOfBar, and then have Foo reveal
that a Bar.T had an enumerate procedure, and all the other stuff you
wanted to know about Bars.

Mark


======================================================================= 17 ===
Date:    Tue, 7 Jul 92 17:16:06 EDT
From:    wyant@centerline.com
Subject: question on generics

I may not be thinking about this in the right way...

I have a generic interface, say "List", and
a non-generic interface say "Foo". Foo exports
an object type, say "Bar". Bar has an operation
which wants to return a "List of Bar", using the
generic "List" interface.

Given that I need to have imported an instantiation
of the List interface parameterized by Bar, I don't
see any way to do this with the current generics
definition. I need to have Bar defined in order
to instantiate the "List of Bar" interface, and
I need the "List of Bar" interface defined for the
interface exporting "Bar".

As I said, I may just be thinking of this in the
wrong way.

-geoff


======================================================================= 18 ===
Date:    Tue, 7 Jul 1992 19:58:48 GMT
From:    cope@cbnewsb.cb.att.com (james.o.coplien)
Subject: OOPSLA/92 Development Process Workshop: Call for Papers


		 Preliminary Call for Participation -

			1992 OOPSLA Workshop Proposal

	"Development Processes for Use of the Object Paradigm"
	 ----------------------------------------------------
In conjunction with the OOPSLA '92 conference being held in Vancouver,
British Columbia, Canada, on October 18 - 22 1992, a workshop will
be held on the subject of using OO Methods in the commercial environment. 
I am issuing this preliminary call for papers to allow potential
participants extra time to prepare their position papers.

PURPOSE AND GOALS FOR WORKSHOP
------------------------------

       Most proponents of the object paradigm advocate iterative
       design methods and prototyping, and claim it helps reduce
       long-term software evolution costs.  Many of these claims
       relate to use of	domain analysis	in the front-end process,
       to broaden design scope in a way	that better anticipates, or
       at least	accommodates, long-term	change.	 An iterative
       development process is key to exploring design alternatives
       beyond those considered by more strictly	structured
       techniques.

       These assumptions raise some interesting	questions about	how
       long-term maintenance should be managed.	 Large
       organizations cannot work effectively in	an environment of
       constantly changing interfaces.	How early in the release
       cycle should interfaces be pronounced stable and	put under
       project control?

       Other perspectives on this problem have been suggested:

	  - Totally doing away with organizational ownership of
	    interfaces,	leaving	project	interface management to
	    free, global collaboration;

	  - Doing away with the	concept	of "releases" by defining
	    new	releasable products as the inventory of	services to
	    support them become	stable over time;

	  - Allowing no	deletion of existing code, accommodating
	    evolution only through the addition	of new classes,
	    largely through derivation from existing classes;

	  - Automating generation of product structure or code
	    directly from product specifications, every	time the
	    specification changes;

       This workshop will explore the following	issues,	drawing	on
       the experience of its participants, and on ongoing research
       in this area:

	  - Where objects do and do not	work well to address the
	    problem of changing	interfaces;

	  - What tools,	mechanisms, and	management policies should
	    be used to manage object-oriented interface	evolution
	    (version, interface, and configuration management);

	  - Whether mixed language technologies	(e.g., Smalltalk
	    for	evolution, and C++ for deployment) within a single
	    project help or hurt long-term flexibility and cost.

       In this one day of dialogue, I hope the group can establish
       a framework of development processes based on product
       development interval, project size and maturity,	and such
       other ideas as occur during the day.  Individual	papers will
       be selected for presentation on the workshop agenda, but	all
       are expected to participate in discussion and are encouraged
       to bring	supporting materials.  I would also like to
       entertain proposals for carrying	this dialogue forward in
       one or more forums beyond OOPSLA	'92.

PARTICIPANTS AND OBSERVERS
--------------------------

       Participation is solicited from those actively engaged in
       research on software methodology, architectural evolution,
       or software process, as well as spokespersons for project
       and corporate management strategies for deployment of software
       products.

       Requests to participate as observers will be honored as space
       permits on a first-come, first-served basis.

WORKSHOP FORMAT AND LENGTH
--------------------------

       I hope to keep as much of the agenda as possible free for
       moderated discussion.  Specific papers may be selected for short
       (20 minute) presentations, depending on the response received.
       I am open to suggestions for use of other formats.  The workshop
       will be one day long.

POSITION PAPERS
---------------

       All participants must submit short (1-2 page) position papers to the
       workshop organizer.  The paper should briefly describe your project
       (application, number of people, language used), and address 3-5 issues
       of interest to you.  You may select issues from the list above, 
       or contribute additional issues.  Papers must be submitted by
       August 20, 1992.  Participants will be selected and notified by
       Sept. 15, 1992.  Those who wish to be placed on the waiting list
       for observers should provide us with their name, address, phone
       number, Email address and Fax number.

For more information, please contact me.

	Jim Coplien
	IHC 1G341 AT&T Bell Laboratories
	1000 East Warrenville Road
	Naperville, IL 60566
	Voice: (708) 713-5384   Fax: (708) 713-4982
	Email: cope@research.att.com


======================================================================= 19 ===
Date:    Wed, 8 Jul 1992 04:37:28 GMT
From:    alanf@cs.monash.edu.au (Alan Grant Finlay)
Subject: Re: Changes to Modula-3 <was: UG meeting report part4>

pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) writes:

>IMHO, the crucial aspect of stability is that a valid M3 program today is
>still a valid program tomorrow. Adding new features which simply extend the
>capabilities of the language (like VIRTUAL OBJECT) don't affect stability
>seriously. Other changes, which might cause that existing programs have to be
>adapted, should be included carefully. But why discuss this in terms of
>every n months? If there is a consensus that a certain feature is wanted and
>needed, why not include it immediately? If someone personally dislikes this,
>well - nobody is forced to work with an up-to-date version of the language.
>Just stick with your old compiler until you think it's time to install a new
>one.

One point you seem to have missed is that language users form a community.
If I choose to stick to version X of a language definition and everybody
else moves to X+1 then I can't use or understand some of the code which
is generously donated every now and again.  Changing a language definition
too often => suicide for the language.  As an example, has anybody tried using
Icon?  Versions of Icon are all upwardly compatible and add new features which
only Icon fanatics would bother to learn to use.  The basic core of Icon is
hard enough to learn as it is.

In addition, for users who do not maintain their own computing facilities,
it can be hard to convince an overworked systems manager to reinstall a
little used (in terms of number of users) language compiler every year.


======================================================================= 20 ===
Date:    Wed, 8 Jul 92 17:58:29 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Modula 3 2.07

In article <DAGENAIS.92Jul8095918@pollux.vlsi.polymtl.ca>, dagenais@vlsi.polymt
l.ca (Michel Dagenais) writes:
> Version 2.07 switched from test-release to release without fanfare. Perhaps
> a short announcement on this newsgroup would prevent unnecessary polling of
> gatekeeper.dec.com.

I sent a message on Tue, 30 Jun 92 19:35:34 GMT, Message-ID:
<1992Jun30.193534.20917@src.dec.com>:

SRC Modula-3 2.07 is available in:

        gatekeeper.dec.com:pub/DEC/Modula-3/release

In addition to the usual bug fixes, the main changes are:

  - the libraries color, sx and pinecreek have been merged into libm3

  - three new archives:
        vbtkit, a set of VBTs
        formsvbt, a user-interface editor library
        vbtapps, which include a user-interface editor and demo applications
    I'll let Marc or Jim (the culprits) comment more on that

  - the DECstation OSF/1 version has been reactivated.  I don't know
    if it works.

It seems that the <*OBSOLETE*> mechanism is now reliable.  In the next
release, all the things marked <*OBSOLETE*> in 2.07 will be removed;
you probably want to start cleaning your code when you have a chance.

-- 
Eric.



======================================================================= 21 ===
Date:    Wed, 8 Jul 92 18:03:02 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: short language tutorial?

In article <5960@otc.otca.oz>, johng@otc.otca.oz.au (John Gibbons) writes:
> 
> Is there a short tutorial on modula3 that can be ftped across the net? I woul
d
> like to get a quick idea of the language.

For a very quick idea:

   The goal of Modula-3 is to be as simple and safe as it can be while
   meeting the needs of modern systems programmers.  Instead of
   exploring new features, we studied the features of the Modula
   family of languages that have proven themselves in practice and
   tried to simplify them into a harmonious language.  We found that
   most of the successful features were aimed at one of two main
   goals: greater robustness, and a simpler, more systematic type
   system.

   Modula-3 descends from Mesa, Modula-2, Cedar, and Modula-2+.  It
   also resembles its cousins Object Pascal, Oberon, and Euclid.

   Modula-3 retains one of Modula-2's most successful features, the
   provision for explicit interfaces between modules.  It adds objects
   and classes, exception handling, garbage collection, lightweight
   processes (or threads), and the isolation of unsafe features.

For more details:

   "Modula-3" by Sam Harbison, Byte, Vol. 15, Number 12, October 1990, p 385.


For all the details;
   
   The definition of Modula-3 is contained in:

	System Programming with Modula-3
	Edited by Greg Nelson
	Prentice Hall Series in Innovative Technology
	ISBN 0-13-590464-1
	L.C. QA76.66.S87 1991

   Sam Harbison has written a book about Modula3:

	Modula-3
	Samuel P. Harbison
	Prentice Hall, 1992
	ISBN 0-13-596396-6

There is nothing available on-line.  Of course, if somebody wants to
write or recyle a blurb, we can archive it on gatekeeper.dec.com and/or
mention it in the FAQ.

-- 
Eric.



======================================================================= 22 ===
Date:    Wed, 8 Jul 1992 14:59:18 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Modula 3 2.07

Version 2.07 switched from test-release to release without fanfare. Perhaps
a short announcement on this newsgroup would prevent unnecessary polling of
gatekeeper.dec.com. Moreover, comp.archive would pick up the announcement
and give some further exposure to Modula 3. Besides, there is more in this
new release than the .01 increment suggests (FormsVBT...).

It installed fine on the Sparc here. Does anyone have a packaged "patch" or
shell script that can produce shared libraries. I dont really need sharing
in core (-pic, .so and .sa files...), i just want to reduce the disk 
requirements of executables.
--
---------------------------------------------------------------------

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

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


======================================================================= 23 ===
Date:    8 Jul 92 08:04:28 GMT
From:    johng@otc.otca.oz.au (John Gibbons)
Subject: short language tutorial?


Is there a short tutorial on modula3 that can be ftped across the net? I would
like to get a quick idea of the language.

Thanks in advance


======================================================================= 24 ===
Date:    Wed, 08 Jul 92 17:14:47 -0400
From:    Samuel Harbison <harbison@tartan.com>
Subject: Dr. Dobbs article on Modula-3

The October issue of Dr. Dobbs's journal will contain an 
introductory Modula-3 article, "Safe Programming in Modula-3".

Sam Harbison, Director, Commercial Products Division
Tartan, Inc.; 300 Oxford Drive, Level 4; Monroeville, PA 15146; USA.
Phone: +1 (412) 568-3600; Fax: +1 (412) 568-3636; Email: harbison@tartan.com.


======================================================================= 25 ===
Date:    Wed, 8 Jul 92 03:25:15 PDT
From:    surak!frode (Frode Odegard)
Subject: defaults for VAR parameters

Why can't VAR parameters have defaults ?

			- Frode (frode@odegard.com)



======================================================================= 26 ===
Date:    Wed, 8 Jul 1992 18:22:06 PDT
From:    David Nichols <nichols@parc.xerox.com>
Subject: m3pp with PostScript support

I've made a new version of m3pp with support for PostScript
pretty-printing available for anonymous ftp on parcftp.  This version
uses special fonts for keywords, comments, built-in identifiers, the
procedure name in a procedure declaration, etc.  Unlike similar
programs, this one simultaneously adds fonts and reformats, so it's able
to make line break and column alignment decisions based on the actual
PostScript font widths.

The backend to the formatter package is "generic", so you might be able
to use it to make a pretty-printer for something like ATK (hint, hint).

It's on parcftp.parc.xerox.com (13.1.64.94) in "pub/m3/m3pp.tar.Z".

I'm releasing this myself because the changes to the Formatter package
are larger than normal, and to get it out a little quicker.  Please let
me know how it works for you.  Thanks to Bill Schilit for merging my old
version of this into the current version of m3pp.

	David


======================================================================= 27 ===
Date:    Tue, 7 Jul 1992 13:40:29 GMT
From:    amichail@cayley.waterloo.edu (Amir Michail)
Subject: real-time extensions to high level languages

I am looking for papers/books on adding real-time extensions to high level
languages.  In particular, I am most interested in the extensions required
to handle interrupts.  

I understand that there has been much talk about this, particularly 
in extensions to Ada.  However, I have had a hard time locating papers
on this.

Could someone point me to the definitive sources? 

Amir



======================================================================= 28 ===
Date:    Thu, 9 Jul 92 10:21:57 EDT
From:    wyant@centerline.com
Subject: M3 Keyword and comment highlighting for Epoch

I'd don't know many M3 users use the Epoch version of Emacs,
but this seemed relatively short and useful to post. Its
a modification of Marc Andreesssen's "lightbrite" highlighting
package to support M3. It's pretty much self contained. Before 
loading it, add the following lines to your .emacs file:

(defun make-style-with-font (font)
  "Make a style with font FONT."
  (let ((s (epoch::make-style)))
    (set-style-font s font)
    s))

 (setq red-style (make-style-with-font 
   "*helvetica-medium-r-normal--10*"))
 (setq green-style (make-style-with-font 
   "*courier-bold-r-normal--12*"))
 (setq yellow-style (make-style-with-font 
   "*helvetica-bold-r-normal--10*"))
 (setq magenta-style (make-style-with-font
   "*helvetica-medium-r-normal--10*"))
 (setq comment-style (make-style-with-font
   "*times-medium-i-normal--10*"))
 (setq yellow-underline-style (make-style-with-font
   "*helvetica-medium-o-normal--12*"))
 (setq red-underline-style (make-style-with-font
   "*helvetica-bold-o-normal--12*"))

Below is the "lightbrite" package itself. Let me know what
you think.

--geoff 

------- Cut here -----------

;; File: --- lightbrite.el ---
;;; Author: Marc Andreessen (marca@ncsa.uiuc.edu)
;;; Copyright (C) National Center for Supercomputing Applications, 1992.
;;;
;;; This program is free software; you can redistribute it and/or modify
;;; it under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 1, or (at your option)
;;; any later version.
;;;
;;; This program is distributed in the hope that it will be useful,
;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with your copy of Epoch; if not, write to the Free Software
;;; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
;;;*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;;;* CONTENTS:
;;;*   Lightbrite (formerly marc-hilite) v1.0.
;;;*   Epoch functions for syntax-directed highlighting of assorted
;;;*   types of source, including Lisp, C, LaTeX, plain text, and mail.
;;;* NOTES:
;;;*   Code and ideas stolen from Ken Wood, Heinz W. Schmidt, Paul Nakada,
;;;*   and Dan LaLiberte.
;;;* FUTURE:
;;;*   Dynamic hilighting of regexp's (maybe a bank of
;;;*     available regexp's and associated styles).
;;;* HISTORY:
;;;*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(require 'syntax-decode)

(provide 'lightbrite)

;; TODO:
;; o Should use zones-in-region primitive.
;; o Comment highlighting doesn't work in instant mode.
;; o Move to regexp-based comment highlighting for all modes.
;; o Maybe add a little padding to paragraph/function extents.
;; o Move to list representation of mode/regexp specification.
;; o Save match-data any time we do highlighting.

;;; ---------------------- brite::make-foreground-style ----------------------

(defun brite::make-foreground-style (fgname)
  "Convenience function to make a style with given foreground FGNAME."
  (let ((brite::style (make-style)))
    (set-style-foreground brite::style fgname)
    brite::style))

(defun brite::make-underline-style (fgname)
  "Convenience function to make a style with given underline FGNAME."
  (let ((brite::style (make-style)))
    (set-style-underline brite::style fgname)
    brite::style))

;;; ------------------------- buffer-local variables -------------------------

;; Users can setq the *-default variables before loading this file
;; to affect defaults for buffer-local variables.

;; Define the default values.
(defvar brite::comment-highlight-on-default t)
(defvar brite::touchup-highlight-on-default t)
(defvar brite::touchup-check-string-default t)
(defvar brite::touchup-check-zone-default t)
(defvar brite::highlight-on-write-default nil)

;; Define the buffer-local variables.
(defvar brite::comment-highlight-on nil
  "T if comments should be highlighted in this buffer; NIL otherwise.")
(defvar brite::touchup-highlight-on nil
  "T if syntax-directed touchup should be done in this buffer; NIL otherwise.")
(defvar brite::touchup-check-string nil
  "T if in-string checking should be done in this buffer; NIL otherwise.")
(defvar brite::touchup-check-zone nil
  "T if in-zone checking should be done in this buffer; NIL otherwise.")
(defvar brite::highlight-on-write nil
  "T if this buffer should be re-highlighted on write; NIL otherwise.")

;; Make the buffer-local variables buffer-local.
(make-variable-buffer-local 'brite::comment-highlight-on)
(make-variable-buffer-local 'brite::touchup-highlight-on)
(make-variable-buffer-local 'brite::touchup-check-string)
(make-variable-buffer-local 'brite::touchup-zone-string)
(make-variable-buffer-local 'brite::highlight-on-write)

;; Set the defaults.
(setq-default brite::comment-highlight-on brite::comment-highlight-on-default)
(setq-default brite::touchup-highlight-on brite::touchup-highlight-on-default)
(setq-default brite::touchup-check-string brite::touchup-check-string-default)
(setq-default brite::touchup-check-zone brite::touchup-check-zone-default)
(setq-default brite::highlight-on-write brite::highlight-on-write-default)

;;; --------------------------- control variables ----------------------------

;; Users can setq these before loading this file.

(defvar brite::highlight-on-find t
  "T if we should highlight each new file when it's first loaded.")

;; These should be able to be nil also.
(defvar brite::comment-threshold 100000
  "Integer for maximum size of file for which comments are highlighted.")
(defvar brite::touchup-threshold 30000
  "Integer for maximum size of file for which touchup highlighting is done.")

;; Setting this value small (<5) really makes it look good, but gives
;; quite a performance hit.
(defvar brite::change-interval 6
  "Number of changes between line highlighting, when after-change-function
is activated.")

;; 80 makes sure we see the beginning of normal-length lines.
(defvar brite::area-extent 80 
  "Half of the size of a local area, for instant highlighting purposes.")

;;; --------------------------- colors and styles ----------------------------

;; User can setq either the *-name variables or the *-style variables,
;; at their choice, before loading this file.

;; These colors were chosen for a black background; I don't
;; know how they'd look on a light background.  Suggested foreground
;; colors are wheat, grey80-grey90, #ffa07a, #ffaf7f, #ff7f24,
;; and #efafff.  If you come up with a nice set of fg/bg/highlight
;; colors, send them to me.

(defvar comment-style-color "#7d9ec0")
(defvar red-style-color "red")
(defvar magenta-style-color "magenta")
(defvar green-style-color "green")
(defvar yellow-style-color "yellow")

(defvar comment-style (brite::make-foreground-style comment-style-color)
  "Style used to highlight comments.")
(defvar red-style (brite::make-foreground-style red-style-color)
  "Style used to highlight in red.")
(defvar magenta-style (brite::make-foreground-style magenta-style-color)
  "Style used to highlight in magenta.")
(defvar green-style (brite::make-foreground-style green-style-color)
  "Style used to highlight in green.")
(defvar yellow-style (brite::make-foreground-style yellow-style-color)
  "Style used to highlight in yellow.")

(defvar yellow-underline-style (brite::make-underline-style yellow-style-color)
  "Style used to underline in yellow.")
(defvar red-underline-style (brite::make-underline-style red-style-color)
  "Style used to underline in red.")


;;; --------------------------- internal variables ---------------------------

;; Users shouldn't tamper with these.

(defvar brite::highlight-done nil "Flag for highlighting done once here.")
(make-variable-buffer-local 'brite::highlight-done)
(setq-default brite::highlight-done nil)

(defvar brite::beginning-point 0 "Starting point for regexp searches.")
(defvar brite::ending-point 0 "Ending point for regexp searches.")

(defvar brite::change-counter 0 "Internal counter to track number of changes.")

(defvar brite::instant-highlight-on nil 
  "Flag for instant highlighting.  Call brite::toggle-instant-highlight-on
to turn instant highlighting on and off.")
(make-variable-buffer-local 'brite::instant-highlight-on)
(setq-default brite::instant-highlight-on nil)

(defvar brite::diagnostics-on nil
  "If T, print diagnostics to minibuffer as appropriate.")

;;; ---------------------------- brite::in-zone-p ----------------------------

(defun brite::in-zone-p (point)
  "T if POINT is in a zone, NIL otherwise."
  (if (epoch::zone-at point)
    t
    nil))

;;; ----------------------- brite::in-quoted-string-p ------------------------

(defun brite::in-quoted-string-p (point)
  "Use parse-partial-sexp to check for POINT in quoted string; return
T if so, NIL if not."
  (save-excursion
    (beginning-of-defun)
    (if (null (nth 3 (parse-partial-sexp (point) point)))
      nil
      t)))

;;; ------------------------- brite::regexp-touchup --------------------------

(defun brite::regexp-touchup (regexp sty &optional everytime)
  "Highlight all matches of REGEXP in a given style.  Second arg STY 
is a style.  Optional third arg EVERYTIME indicates that pattern should 
always be highlighted, even when in a zone or string."
  (let (brite::beginning brite::end (case-fold-search nil))
    (save-excursion
      (goto-char brite::beginning-point)
      ;; Loop through all matches in this buffer.
      (while (re-search-forward regexp brite::ending-point t)
        ;; Preserve values of begin/end from search.
        (setq brite::beginning (match-beginning 0))
        (setq brite::end (match-end 0))
        ;; If everytime flag not set, and brite::touchup-check-zone
        ;; not set, check for in-zone-p.
        (if (or everytime (not brite::touchup-check-zone) 
            (not (brite::in-zone-p brite::beginning)))
          ;; Either everytime is set, or we're not checking
          ;; strings, or we're not in a string.
          (if (or everytime
              (not brite::touchup-check-string) 
              (not (brite::in-quoted-string-p brite::beginning)))
            (epoch::add-zone brite::beginning brite::end sty)))))))

;;; --------------------- convenience touchup functions ----------------------

(defun brite::regexp-touchup-red (regexp)
  "Touchup REGEXP in red."
  (brite::regexp-touchup regexp red-style))
(defun brite::regexp-touchup-magenta (regexp)
  "Touchup REGEXP in magenta."
  (brite::regexp-touchup regexp magenta-style))
(defun brite::regexp-touchup-green (regexp)
  "Touchup REGEXP in green."
  (brite::regexp-touchup regexp green-style))
(defun brite::regexp-touchup-yellow (regexp)
  "Touchup REGEXP in yellow."
  (brite::regexp-touchup regexp yellow-style))
(defun brite::regexp-touchup-yellow-always (regexp)
  "Touchup REGEXP in yellow always."
  (brite::regexp-touchup regexp yellow-style t))

(defun brite::regexp-touchup-yellow-underline (regexp)
  "Touchup REGEXP in yellow underline."
  (brite::regexp-touchup regexp yellow-underline-style nil))
(defun brite::regexp-touchup-red-underline (regexp)
  "Touchup REGEXP in red underline."
  (brite::regexp-touchup regexp red-underline-style nil))

;;; ----------------------- brite::highlight-comments ------------------------

;; This function is stolen almost verbatim from Ken Wood's package.
(defun brite::highlight-comments ()
  "Highlight all comments in a buffer if the buffer's size does not
exceed brite::comment-threshold."
  ;; Silently do nothing if there are no regexps to search with
  ;; or if the buffer is too large to highlight.
  (if (and syndecode-comment-start-regexp syndecode-comment-end-regexp
      brite::comment-threshold (< buffer-saved-size brite::comment-threshold))
    (let ((starting-point brite::beginning-point)
        comment-start-begin comment-start-end comment-end-end)
      (save-excursion
        (goto-char brite::beginning-point)
        ;; Algorithm is: search for start of a comment,
        ;; make sure it really is a comment; then highlight
        ;; from there to the end of the comment.
        ;; First, find a comment-start sequence.
        (while (re-search-forward syndecode-comment-start-regexp
            brite::ending-point t)
          (progn
            (setq comment-start-begin (match-beginning 0))
            (setq comment-start-end (match-end 0))
            ;; Check that the comment start sequence really does
            ;; indicate the start of a comment, and that it's not
            ;; inside a string etc.
            (if (nth 4 (parse-partial-sexp starting-point comment-start-end))
              ;; Yes, this is really the start of a comment
              (progn
                (goto-char comment-start-end)
                ;; Find the end of the comment by searching
                ;; for a comment terminating sequence.
                ;; Second arg was changed to brite::ending-point
                ;; to keep emacs from complaining during per-line
                ;; highlighting.
                (re-search-forward syndecode-comment-end-regexp
                  brite::ending-point t)
                (setq comment-end-end (point))
                ;; Highlight the comment
                (epoch::add-zone comment-start-begin comment-end-end
                  comment-style)
                ;; Start the next syntax parse at the end of the
                ;; comment just processed.
                (setq starting-point comment-end-end)))))))))

;;; ------------------------- brite::true-mode-name --------------------------

;; Author: Lynn Slater (lrs@indetech.com).
(defun brite::true-mode-name ()
  "Returns the name of the mode in such a form that the mode may be
  re-established by calling the function named by appending '-name' to
  this string.  This differs from the variable called mode-name in that
  this is guaranteed to work while the values held by the variable may
  have embedded spaces or other junk."
  (let ((major-mode-name (symbol-name major-mode)))
    (substring major-mode-name 0
      (or (string-match "-mode" major-mode-name)
        (length major-mode-name)))))

;;; ------------------------ brite::do-buffer-touchup ------------------------

;; Datatype must be preceded by whitespace, open paren, or open brace.
(setq brite::c-datatype-prefix "[ \n\t({]")
;; Datatype must be followed by whitespace, close paren, or *.
(setq brite::c-datatype-suffix "[ \n\t)*]")

;; Keyword must be preceded by whitespace or open brace.
(setq brite::c-keyword-prefix "[ \n\t{]")
;; Keyword must be followed by whitespace, semicolon, or open paren.
(setq brite::c-keyword-suffix "[ \n\t;(]")
(setq brite::c-directives
  "\\(#endif\\|#else\\|#ifdef\\|#ifndef\\|#if\\)")
(setq brite::c-defines
  "\\(#include\\|#define\\|#undef\\|typedef\\|enum\\)")
(setq brite::c-datatypes
  (concat brite::c-datatype-prefix
    "\\(int\\|float\\|Float\\|char\\|double\\|short\\|long\\|void\\|struct\\|un
ion\\)"
    brite::c-datatype-suffix))
(setq brite::c-data-attributes
  "\\(unsigned\\|extern\\|static\\|public\\|private\\)")
(setq brite::c-flagged-keywords
  (concat brite::c-keyword-prefix  "\\(return\\|exit\\|assert\\|goto\\)"
    brite::c-keyword-suffix))
;
; Modula-3 variables
;
(setq brite::m3-flagged-keywords
      "\\(PROCEDURE\\|TYPE\\|VAR\\|MODULE\\|INTERFACE\\|IMPORT\\|RETURN\\|RAISE
\\|FROM\\|RAISES\\)"
      )
(setq brite::m3-datatypes
      "\\(INTEGER\\|REAL\\|BOOLEAN\\|CARDINAL\\|CHAR\\|TEXT\\)"
      )
(setq brite::m3-flagged-block-keywords
      "\\(BEGIN\\|CASE\\|OF\\|FINALLY\\|TYPECASE\\|END\\|IF\\|THEN\\|ELSE\\|ELS
IF\\|WHILE\\|TRY\\|EXCEPT\\|LOOP\\)"
      )

;; In the future this will be in table format and facilities
;; will be provided for extending both the modes supported and
;; the regexp's used.
(defun brite::do-buffer-touchup ()
  "Based on current mode, do series of calls to brite::regexp-touchup routines
to highlight certain regex patterns certain colors, if the buffer's size
is less than brite::touchup-threshold."
  ;; Allow touchup-threshold to be nil also.
  (if (or (null brite::touchup-threshold)
      (< buffer-saved-size brite::touchup-threshold))
    (cond
      ;;-------------------------------------------------------------------
      ((equal mode-name "Text")
        ;; String between sets of three dashes is a section header.
        ;; Three equal-signs marks a subsection.
        ;; '-->' and 'o' are 'item' indicators.
        ;; String 'Justification:' is always red;
        ;; at the moment we flag comments (in shell scripts,
        ;; etc) in red also.
        ;; UNRESOLVED/FUTURE/CORRECTION/TODO should be flagged.
        (brite::regexp-touchup-magenta "\\( ===\\|=== \\)")
        (brite::regexp-touchup-green "\\(-?-->\\|[ \n\t]o[ \t]\\|^o[ \n\t]\\)")
        (brite::regexp-touchup-red "\\(Justification: \\|#.*\\)")
        (brite::regexp-touchup-yellow 
          "\\(UNRESOLVED\\|FUTURE\\|CORRECTION\\|T[Oo][ ]?D[Oo]\\|--- .* ---\\)
"))
      ;;-------------------------------------------------------------------
      ((equal mode-name "RMAIL")
        ;; These don't have beginning-of-line rules ("^From" etc) because
        ;; I like them highlighted in messages included in other messages.
        (brite::regexp-touchup-yellow "From:.*")
        (brite::regexp-touchup-magenta "Date:.*")
        (brite::regexp-touchup-green "Subject:.*"))
      ;;-------------------------------------------------------------------
      ((equal (brite::true-mode-name) "rmail-summary")
        ;; If this is a message we've sent, highlight the receiver.
        (brite::regexp-touchup-magenta " to: [^ ]*")
        ;; Highlight the date column.
        (brite::regexp-touchup-green " [ 0-9][0-9]-[A-Za-z][A-Za-z][A-Za-z] "))
      ;;-------------------------------------------------------------------
      ((equal mode-name "Mail")
        (brite::regexp-touchup-red "--text follows this line--")
        (brite::regexp-touchup-green "Subject:.*")
        (brite::regexp-touchup-magenta "\\(^To:.*\\|^CC:.*\\)"))
      ;;-------------------------------------------------------------------
      ((equal mode-name "Texinfo")
        ;; Code fragments and keystrokes in green.
        (brite::regexp-touchup-red-underline "\\(@menu\\|@item\\)")
        (brite::regexp-touchup-yellow-underline "\\(^@chapter.*\\|^@section.*\\
|^@subs.*\\|^@unnumbered\\|^@appendix\\)")
        (brite::regexp-touchup-green "\\(@code{[^}]*}\\|\@kbd{[^}]*}\\|@file{[^
}]*}\\)")
        ;; Menu entries and xrefs in magenta.
        (brite::regexp-touchup-magenta "\\(\*.*::\\|@xref{[^}]*}\\)")
        (brite::regexp-touchup-yellow "^@node[^,]*")
        ;; (brite::regexp-touchup-yellow "\\(^@chapter.*\\|^@section.*\\|^@unnu
mbered.*\\)")
        (brite::regexp-touchup-red "\\(@dfn{[^}]*}\\|^@[a-z]index.*\\)")
      )
      ;;-------------------------------------------------------------------
      ((or (equal mode-name "AUC-LaTeX") (equal mode-name "LaTeX"))
        (brite::regexp-touchup-yellow 
          "\\([\\]document.*[}]\\|[\\]input.*[}]\\|[\\]include.*[}]\\|includeon
ly.*[}]\\)")
        (brite::regexp-touchup-magenta "\\([\\]begin.*[}]\\|[\\]end.*[}]\\)")
        ;; String between sets of three dashes is in a comment banner.
        (brite::regexp-touchup-yellow-always "--- .* ---")
        ;; For font changes, pick up:
        ;;   o Opening brace, backslash, and keyword.
        ;;   o Any number of characters, except }.
        ;;   o Closing brace.
        ;; How to pick up entire \verb<char><string><char>?
        ;; How to handle multiline footnote?
        (brite::regexp-touchup-red 
          "\\([\\]item\\|[{][\\]it[^}]*[}]\\|[{][\\]sc[^}]*[}]\\|[{][\\]em[^}]*
[}]\\|[\\]verb\\|[\\]footnote\\|[\\]label.*[}]\\|[\\]ref.*[}]\\)")
        ;; Assume citation is one long word; always on one line.
        ;; Also get three dashes in normal text.
        (brite::regexp-touchup-green 
          "\\([\\]cite[^}]*[}]\\|[ \n]---[ \n]\\|[\\]chapter\\|[\\]section\\|[\
\]subsection\\|[\\]subsubsection\\|[\\]appendix\\|[\\]tableofcontents\\|[\\]new
page\\)"))
      ;;-------------------------------------------------------------------
      ((or (equal mode-name "C") (equal mode-name "C++"))
	(brite::regexp-touchup-red-underline "^[_a-zA-Z][^=\n]*(\\(.*;\\|[^{]*\
\)") ;; fn decls
        (brite::regexp-touchup-red brite::c-directives)
        (brite::regexp-touchup-red "NULL")
        ;; These are removed for performance reasons.
        (brite::regexp-touchup-magenta brite::c-datatypes)
        (brite::regexp-touchup-magenta "\\([ \t]switch[ (]\\|[ \t]break;\\)")
        (brite::regexp-touchup-green brite::c-data-attributes)
        (brite::regexp-touchup-green "[ \t]case.*:")
        (brite::regexp-touchup-yellow brite::c-defines)
        (brite::regexp-touchup-yellow brite::c-flagged-keywords)
        (brite::regexp-touchup-yellow-always "--- .* ---"))
      ;;-------------------------------------------------------------------
      ((or (equal mode-name "Modula 3"))
	(brite::regexp-touchup-yellow brite::m3-flagged-keywords)
	(brite::regexp-touchup-red brite::m3-flagged-block-keywords)
	(brite::regexp-touchup-magenta brite::m3-datatypes)
       	(brite::regexp-touchup-yellow-always "--- .* ---"))
      ;;-------------------------------------------------------------------
      ((or (equal mode-name "Emacs-Lisp") (equal mode-name "Lisp"))
        (brite::regexp-touchup-magenta "(interactive[^)\n]*)")
        (brite::regexp-touchup-green "\\(setq\\|defvar\\|let[ \*]\\|global-set-
key\\|define-key\\)")
        (brite::regexp-touchup-red "\\(nil\\|epoch::[^ \t\n)]*\\)")
        ;; This gets strings, unless they contain quotes, which
        ;; throws it out of whack.
        ;; (brite::regexp-touchup-red "\"[^\"]*\"")
        (brite::regexp-touchup-yellow 
          "\\(return\\|(require[^)]*)\\|(load[^)]*)\\)")
        ;; Sadly, this hits (end-of-_defun_) also.
        (brite::regexp-touchup-red-underline "defun")
        ;; This doesn't, but it doesn't look real good.
        ;; (brite::regexp-touchup-yellow-underline "defun [a-zA-Z\-\*:]+")
        (brite::regexp-touchup-yellow-always "--- .* ---"))
)))

;;; ------------------------ brite::highlight-buffer -------------------------

(defun brite::highlight-buffer ()
  "Highlight current buffer as appropriate."
  (if brite::comment-highlight-on (brite::highlight-comments))
  (if brite::touchup-highlight-on (brite::do-buffer-touchup)))

;;; --------------------- brite::set-search-whole-buffer ---------------------

(defun brite::set-search-whole-buffer ()
  "Tell the highlighting code to search the entire buffer."
  (setq brite::beginning-point (point-min))
  (setq brite::ending-point (point-max)))

;;; ---------------------- brite::set-search-this-defun ----------------------

(defun brite::set-search-this-function ()
  "Tell the highlighting code to only search this function."
  (save-excursion
    (beginning-of-defun)
    (setq brite::beginning-point (point))
    (end-of-defun)
    (setq brite::ending-point (point))))

;;; -------------------- brite::set-search-this-paragraph --------------------

(defun brite::set-search-this-paragraph ()
  "Tell the highlighting code to only search this paragraph."
  (save-excursion
    (backward-paragraph)
    (setq brite::beginning-point (point))
    (forward-paragraph)
    (setq brite::ending-point (point))))

;;; ---------------------- brite::set-search-this-line -----------------------

(defun brite::set-search-this-line ()
  "Tell the highlighting code to only search this line."
  (save-excursion
    (beginning-of-line)
    (setq brite::beginning-point (point))
    (end-of-line)
    (setq brite::ending-point (point))))

(defun brite::set-search-this-area ()
  "Tell the highlighting code to only search the immediate area."
  ;; We assume the re-search routines will do range-checking
  ;; (definitely checking on bound is done).
  (setq brite::beginning-point (- (point) brite::area-extent))
  (setq brite::ending-point (+ (point) brite::area-extent)))

;;; ---------------------- brite::do-highlight-on-find -----------------------

(defun brite::do-highlight-on-find ()
  "Called by find-file-hooks; does highlighting as appropriate."
  ;; Extract comment details from the current syntax table.
  (if brite::highlight-on-find
    (progn
      (message "Highlighting...")
      (decode-syntax-table)
      (brite::set-search-whole-buffer)
      (brite::highlight-buffer)
      (message "Highlighting... done.")
      (if brite::diagnostics-on
        (message "Made %d zones." (length (epoch::zone-list))))
      (setq brite::highlight-done t))))

;;; ---------------------- brite::do-highlight-on-write ----------------------

(defun brite::do-highlight-on-write ()
  "Called by write-file-hooks; does highlighting as appropriate."
  ;; Check to see if we highlight this buffer on write.
  (if brite::highlight-on-write
    (progn
      (message "Highlighting...")
      ;; Check to see if there is any highlighting currently in effect.
      (if brite::highlight-done
        ;; If so, remove & redo highlighting.
        (progn
          (epoch::clear-zones)
          (brite::set-search-whole-buffer)
          (brite::highlight-buffer))
        ;; Else, do highlighting for the first time.
        (progn
          (decode-syntax-table)
          (brite::set-search-whole-buffer)
          (brite::highlight-buffer)
          (setq brite::highlight-done t)))
      (message "Highlighting... done.")))
  ;; Have to return nil or write-file-hooks will get stuffed up.
  nil)

;;; ---------------------- brite::do-highlight-explicit ----------------------

(defun brite::do-highlight-explicit ()
  "Called interactively; does highlighting as appropriate."
  (interactive)
  ;; Check to see if there is any highlighting currently in effect.
  (if brite::highlight-done
    ;; If so, remove & redo highlighting.
    (progn
      (epoch::clear-zones)
      (brite::set-search-whole-buffer)
      (brite::highlight-buffer))
    ;; Else, do highlighting for the first time.
    (progn
      (decode-syntax-table)
      (brite::set-search-whole-buffer)
      (brite::highlight-buffer)
      (setq brite::highlight-done t))))

;;; ----------------------- brite::rmail-show-message ------------------------

(defun brite::rmail-show-message ()
  "Called from rmail-show-message hook, and ensures that rmail buffers
will always be highlighted."
  ;; Save current value of touchup max size and temporarily balloon
  ;; it to nil.  This is safe since RMAIL only
  ;; sets the buffer extents to that part of the file that holds the current
  ;; message, so (point-min) is not necessarily 0 and (point-max) is
  ;; not necessarily buffer-saved-size; thus, we can highlight the
  ;; whole buffer for each message without incurring huge performance
  ;; penalties.
  (let ((brite::touchup-threshold-temp brite::touchup-threshold))
    (setq brite::touchup-threshold nil)
    (brite::do-highlight-explicit)
    (setq brite::touchup-threshold brite::touchup-threshold-temp)))

;;; ---------------------- brite::clear-zones-in-region ----------------------

(defun brite::clear-zones-in-region (start end)
  "Prune zones lying in region defined by START and END from list
of zones in buffer."
  (catch 'brite::done-clearing-zones
    (dolist (foo (epoch::zone-list))
      (let ((foo-start (epoch::zone-start foo)))
        ;; We remove zones that start inside this region.
        (if (and (>= foo-start start) (<= foo-start end))
          (epoch::delete-zone foo))
        ;; If the zone starts after the end of this region,
        ;; we're done.
        (if (> foo-start end)
          (throw 'brite::done-clearing-zones t))))))

;;; ---------------------- brite::do-highlight-question ----------------------

(defun brite::do-highlight-function ()
  "Called interactively; highlights current defun only."
  (interactive)
  (message "Highlighting function.")
  ;; Check to see if there is any highlighting currently in effect.
  (if brite::highlight-done
    ;; If so, remove & redo highlighting.
    (progn
      ;; We have brite::set-search-this-function to set function
      ;; extents in globals, then clear that region.
      (brite::set-search-this-function)
      (brite::clear-zones-in-region brite::beginning-point brite::ending-point)
      (brite::highlight-buffer))
    ;; Else, do highlighting for the first time.
    (progn
      (decode-syntax-table)
      (brite::set-search-this-function)
      (brite::highlight-buffer)
      (setq brite::highlight-done t))))

;;; --------------------- brite::do-highlight-paragraph ----------------------

(defun brite::do-highlight-paragraph ()
  "Called interactively; highlights current paragraph only."
  (interactive)
  (message "Highlighting paragraph.")
  ;; Check to see if there is any highlighting currently in effect.
  (if brite::highlight-done
    ;; If so, remove & redo highlighting.
    (progn
      ;; We have brite::set-search-this-paragraph to set paragraph
      ;; extents in globals, then clear that region.
      (brite::set-search-this-paragraph)
      (brite::clear-zones-in-region brite::beginning-point brite::ending-point)
      (brite::highlight-buffer))
    ;; Else, do highlighting for the first time.
    (progn
      (decode-syntax-table)
      (brite::set-search-this-paragraph)
      (brite::highlight-buffer)
      (setq brite::highlight-done t))))

;;; ----------------------- brite::highlight-on-change -----------------------

(defun brite::highlight-on-change (pos inspos dellen)
  "Highlights current line only.  Accepts arguments as per 
after-change-function.  Don't do anything if DELLEN nonzero.
Assume highlighting has already been done here to speed things
up.  Only do this every brite::change-interval changes."
  ;; First make sure this isn't a deletion.
  (if (= dellen 0)
    (progn
      ;; Increment the change counter.
      (setq brite::change-counter (+ brite::change-counter 1))
      ;; Do line highlight if this is a good time.
      (if (>= brite::change-counter brite::change-interval)
        ;; Protect everything to keep this from messing up replaces.
        (save-excursion
          (let ((data (match-data)))
            (unwind-protect
              (progn
                (setq brite::change-counter 0)
                ;; To search on the current line, use this.
                ;; (brite::set-search-this-line)
                ;; To search in the immediate area, do this.
                (brite::set-search-this-area)
                (brite::clear-zones-in-region brite::beginning-point 
                  brite::ending-point)
                (if brite::comment-highlight-on (brite::highlight-comments))
                (if brite::touchup-highlight-on (brite::do-buffer-touchup)))
              (store-match-data data))))))))
 
;;; ------------------- INTERACTIVE STATUS CHANGE ROUTINES -------------------

(defun brite::toggle-comment-highlight-on ()
  "Toggle buffer-local comment highlighting."
  (interactive)
  (setq brite::comment-highlight-on (not brite::comment-highlight-on))
  (message "Setting comment highlighting to %s." brite::comment-highlight-on)
  (brite::do-highlight-explicit))

(defun brite::toggle-touchup-highlight-on ()
  "Toggle buffer-local touchup highlighting."
  (interactive)
  (setq brite::touchup-highlight-on (not brite::touchup-highlight-on))
  (message "Setting touchup highlighting to %s." brite::touchup-highlight-on)
  (brite::do-highlight-explicit)
  (if brite::diagnostics-on
    (message "With touchup, %d zones in buffer." (length (epoch::zone-list)))))

(defun brite::toggle-touchup-check-string ()
  "Toggle buffer-local in-quoted-string checking."
  (interactive)
  (setq brite::touchup-check-string (not brite::touchup-check-string))
  (message "Setting touchup string-checking to %s."
    brite::touchup-check-string)
  (brite::do-highlight-explicit))

(defun brite::toggle-touchup-check-zone ()
  "Toggle buffer-local in-zone checking."
  (interactive)
  (setq brite::touchup-check-zone (not brite::touchup-check-zone))
  (message "Setting touchup zone-checking to %s."
    brite::touchup-check-zone)
  (brite::do-highlight-explicit))

(defun brite::toggle-highlight-on-write ()
  "Toggle buffer-local highlighting on write."
  (interactive)
  (setq brite::highlight-on-write (not brite::highlight-on-write))
  (message "Setting highlight on write to %s." brite::highlight-on-write))

(defun brite::balloon-comment-threshold ()
  "Balloon the maximum file size for comment highlighting."
  (interactive)
  (setq brite::comment-threshold (+ (buffer-size) 1000))
  (message "Ballooning comment highlighting max size to %d."
    brite::comment-threshold)
  (brite::do-highlight-explicit))

(defun brite::balloon-touchup-threshold ()
  "Balloon the maximum file size for touchup highlighting."
  (interactive)
  (setq brite::touchup-threshold (+ (buffer-size) 1000))
  (message "Ballooning touchup highlighting max size to %d."
    brite::touchup-threshold)
  (brite::do-highlight-explicit)
  (if brite::diagnostics-on
    (message "%d zones in buffer." (length (epoch::zone-list)))))

(defun brite::toggle-instant-highlight-on ()
  "Toggle value of brite::instant-highlight-on."
  (interactive)
  (if (boundp 'after-change-function)
    (progn
      (setq brite::instant-highlight-on (not brite::instant-highlight-on))
      (if brite::instant-highlight-on
        (progn
          (make-variable-buffer-local 'after-change-function)
          (setq after-change-function 'brite::highlight-on-change)
          (message "Instant highlighting is active."))
        (progn
          (setq after-change-function nil)
          (message "Instant highlighting in inactive."))))))

;;; --------------------------------------------------------------------------
;;; ----------------------------- HOOKS AND KEYS -----------------------------
;;; --------------------------------------------------------------------------

;; Author: Daniel LaLiberte (liberte@cs.uiuc.edu).
(defun brite::postpend-unique-hook (hook-var hook-function)
  "Postpend HOOK-VAR with HOOK-FUNCTION, if it is not already an element.
hook-var's value may be a single function or a list of functions."
  (if (boundp hook-var)
      (let ((value (symbol-value hook-var)))
	(if (and (listp value) (not (eq (car value) 'lambda)))
	    (and (not (memq hook-function value))
		 (set hook-var
		      (append value (list hook-function ))))
	  (and (not (eq hook-function value))
	       (set hook-var
		    (append value (list hook-function))))))
    (set hook-var (list hook-function))))

;; Do the hooks.
(brite::postpend-unique-hook 'find-file-hooks 'brite::do-highlight-on-find)
(brite::postpend-unique-hook 'write-file-hooks 'brite::do-highlight-on-write)
(brite::postpend-unique-hook 'rmail-show-message-hook 
  'brite::rmail-show-message)
(brite::postpend-unique-hook 'mail-setup-hook 'brite::do-highlight-explicit)

;; C-z SPC does whole-buffer highlighting.
(global-set-key "\C-z " 'brite::do-highlight-explicit)

;; C-c f (C-z f is taken) highlights the current function.
;; C-c p (C-z p is taken) highlights the current paragraph.
(global-set-key "\C-cf" 'brite::do-highlight-function)
(global-set-key "\C-cp" 'brite::do-highlight-paragraph)

;; C-z c and C-z t toggle comment/touchup highlighting
;; for this buffer.
(global-set-key "\C-zc" 'brite::toggle-comment-highlight-on)
(global-set-key "\C-zt" 'brite::toggle-touchup-highlight-on)

;; C-z C and C-z T balloon the comment/touchup threshold for
;; all buffers.
(global-set-key "\C-zC" 'brite::balloon-comment-threshold)
(global-set-key "\C-zT" 'brite::balloon-touchup-threshold)

;; C-z q/z/w toggle misc parameters.
(global-set-key "\C-zq" 'brite::toggle-touchup-check-string)
(global-set-key "\C-zz" 'brite::toggle-touchup-check-zone)
(global-set-key "\C-zw" 'brite::toggle-highlight-on-write)

;; C-z a toggles instant highlighting.
(global-set-key "\C-za" 'brite::toggle-instant-highlight-on)


======================================================================= 29 ===
Date:    9 Jul 92 10:10:17
From:    thewalt@canuck.ce.berkeley.edu (C. Thewalt)
Subject: Re: Proposed langauge changes

While I understand the reserve expressed in making dramatic changes, I
don't understand why the same reserve is applied to relatively trivial
extensions like complex number support and an exponentiation operator.
The latter may require considerable discussion to nail down the
semantics, but in terms of language extension both of these seem pretty
minor.

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...


======================================================================= 30 ===
Date:    9 Jul 92 12:56:24 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: defaults for VAR parameters


      Why can't VAR parameters have defaults ?

I think the primary answer is: because it would not be very useful, and might
be dangerous. A default for a VAR would have to be a *variable* (lvalue to
those familiar with C terminology), since it must be assignable. One cannot
simply pass the address of a constant, but would have to do something like
have the caller's code sequence allocate an additional anonymous variable and
pass its address. I suppose one could give a value in a default clause, which
would be the initial value of such a variable. That's how such a thing might
be postulated to work.

Now I cannot come up with any specific quantitative evidence, but I don't
believe I would use this feature very often. More importantly, VAR parameters
are there so that a procedure can have an effect on them, and defaults for
them may remove all or most of a procedure's effect, so why call it under such
circumstances? This is why I think it is probably not widely useful, and also
potentially dangerous in the sense that it may lead to user surprise or
unintended behavior (or lack of behavior).

WHile I cannot speak for the language designers, I suspect the bottom line was
that the utility did not outweigh the costs of defining and implementing such
a feature. Of course, it could be that it never occurred to them (it would not
have occurred to me).

Regards ---							Eliot
--

		J. Eliot B. Moss, Associate 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


======================================================================= 31 ===
Date:    Thu, 9 Jul 92 14:31:06 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: question on generics

In article AA20531@riposte, wyant@centerline.com () writes:
>I may not be thinking about this in the right way...
>
>I have a generic interface, say "List", and
>a non-generic interface say "Foo". Foo exports
>an object type, say "Bar". Bar has an operation
>which wants to return a "List of Bar", using the
>generic "List" interface.
> [ ... ]
>As I said, I may just be thinking of this in the
>wrong way.

IMHO, you are. What you are trying to design here is what we call an
entry-collection-subsystem: your objects represent some form of entry,
whereas the list is a collection of these entries. I've been taught
that the only right way to implement this is to make an abstract data
type for the object and another abstract data/object type for the list.
The main reason for designing this way is that the implementation of the
entry type and the implementation of the collection type should be
hidden from each other. This does not only conform to the basic rule that
different implementation decisions should be encapsulated in different
modules, but it also improves reusability: the entry type can be reused
without changes in another collection and vice versa.

I admit that my argumentation here is somewhat weakened by the fact that
your collection type is generic. But nevertheless I consider it a very
important rule not to mix operations on the entry type and on the
collection type in the same interface.
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany



======================================================================= 32 ===
Date:    Thu, 9 Jul 92 15:47:16 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Proposed langauge changes

In article l5k6bnINN1ge@exodus.Eng.Sun.COM, chased@rbbb.Eng.Sun.COM (David Chas
e) writes:
>In article <9207071510.AA20139@riposte> wyant@centerline.com writes:
>>The older I get, the more conservative toward language changes I
>>get. Maybe that's just a consequence of seeing how C++ is evolving.
>>To many of the proposals are of the form, "Language X has this
>>nifty feature, can we force it into C++...?"
>
>I think this is correct -- that is, language change is not necessarily
>a bad thing, but it has been a bad thing for C++.  For instance, if
>someone could figure out what multiple inheritance was supposed to
>mean, and what the useful idioms are, and how to make it interact
>cleanly with the rest of the language, then it might be good to add it
>to Modula-3.  I hear good things about mix-ins from NeWS and CLOS
>programmers.  However, if we don't understand it, or cannot caputer
>the useful idioms, or if it as some vile interaction with any existing
>good thing, then perhaps we can live without it.
>
>David Chase
>Sun


I don't know if you've read my earlier posting on the language changes
discussion, but somehow you are going about exactly the direction at
which I flamed a bit. I agree with both of you up to the point that the
C++ way of handling changes is just as bad as the rest of the language.
Of course, every development step has to be considered carefully. Especially
in a language which claims to be ``compact'', interactions between new ideas
and existing features should be investigated thoroughly.

Now, learning from the C++ mess should not result in taking the opposite
direction. My impression of the M3 developers (this includes everyone who
feels pointed at, not just the guys at SRC) is, that this thorough
investigation just isn't happening. Everyone is just saying something like
"Hey, what's the problem? We've got a nice little language here, which
could be better, but we don't know in what way, so ..."

Since you mentioned the MI thing again: I still don't see any problem with
it. If you remember my first article, I didn't say: "Gee, MI is such a
fantastic thing, we simply *must* have it", I just wanted to encourage
a discussion about the pros and cons of it. But, if anything, the
discussion almost convinced me that it actually *is* useful. The pro side
provided some IMHO good examples, where MI is a natural way of solving
a problem. The con side came up only with "MI is hard to understand" (I
still don't believe that, examples?) and "We have MI in C++, but we don't
use it" (this also prooves nothing). Even more, if I haven't missed
anything in John DeTreville's Users Group Meeting Report, some Users
found MI worth discussing, but nothing came from it. Now this isn't
exactly what I would call ``thorough investigation''.

My personal conclusion from this is that there should be *more* discussion
about proposed new language features than in C++. At the moment, it is
far less. Don't forget that some people consider some things essential
which you might think of as unnecessary or even bad. If you don't give
these people at least some reasons *why* it's not in M3, they'll never
use it.
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany



======================================================================= 33 ===
Date:    Thu, 9 Jul 1992 12:19:31 PDT
From:    jacobi.PARC@xerox.com
Subject: Re: defaults for VAR parameters

I agree with Eliot that I consider defaults for VAR parameters would not fit
into Modula 3; I do not propose to introduce it.
However, in languages where such functionality is available I use it a lot and
I don't see why it has to be dangerous.
    In Mesa, VAR parameters are approximated with taking the adresses
    and passing it to a pointer parameter; I very frequently use a
    default of NIL for such pointer parameters.
    In Modula 3, the EVAL statement implements approximately the concept
    in question, only slightly less general.

Christian


======================================================================= 34 ===
Date:    Thu, 9 Jul 92 20:56:33 PDT
From:    surak!frode (Frode Odegard)
Subject: Re: defaults for VAR parameters

I was writing a procedure that would mostly store its result in 'x' but
sometimes in a different variable.  After getting tired of writing P(x)
most of the time I thought that being able to say PROCEDURE P (VAR w: INTEGER :
= x)
would be "nice".

Obviously 'x' would have to be visible in the scope where P is declared.
Obviously 'x' would have to be a variable, or rather, an lvalue.

Correct me if I'm wrong, but there is nothing inherently dangerous in evaluatin
g
the lvalue 'x', it should be no more dangerous than evaluating some another
lvalue explictly passed to P.

As for the argument that a default may lead to surprises, well, that can be
said for value parameter defaults, too..  Defaults should be used with care,
that's for sure.

But I agree with Eliot and Christian that this is not a MUST-HAVE feature, it's
just something that struck me.

The obvious solution is to write an <*inline*> procedure Pdefault that calls P(
x)
and let the compiler (or Mick :->) take care of it.  It was just a thought,
really. :-}

			- Frode <*reply-to: frode@odegard.com *>



======================================================================= 35 ===
Date:    10 Jul 92 00:25:59 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: defaults for VAR parameters

>>>>> On 9 Jul 92 19:19:31 GMT, jacobi.PARC@xerox.com said:

jacobi.PARC>     In Mesa, VAR parameters are approximated with taking the
jacobi.PARC> adresses and passing it to a pointer parameter; I very frequently
jacobi.PARC> use a default of NIL for such pointer parameters.  In Modula 3,
jacobi.PARC> the EVAL statement implements approximately the concept in
jacobi.PARC> question, only slightly less general.

With VAR paramters there is no equivalent passing NIL and no way to test for
it either. I think this makes the approaches substantially different. In
Modula-3, one would have to pass the address of *something* .....   Eliot
--

		J. Eliot B. Moss, Associate 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


======================================================================= 36 ===
Date:    Fri, 10 Jul 1992 03:33:13 GMT
From:    alanf@cs.monash.edu.au (Alan Grant Finlay)
Subject: documentation of libraries

I have some tutorials for the standard libraries and trestle but many
additional libraries have no documentation.  I can look in the include
directory but there are hundreds of interfaces, listed in alphabetical
order.  If these interfaces are the documentation then I need at least a
list of which interfaces belong to which library and preferably a dependancy
tree.

I could write a program to read the include directory and contruct a forest
of dependencies, has anybody else done this.  Am I missing something?

	Alan


======================================================================= 37 ===
Date:    Fri, 10 Jul 1992 00:33:36 GMT
From:    Ari.Huttunen@hut.fi (Ari Juhani Huttunen)
Subject: Re: Proposed language changes

In article <1992Jul9.154716.7869@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.inf
ormatik.rwth-aachen.de (Peter Klein) writes:

! a problem. The con side came up only with "MI is hard to understand" (I
! still don't believe that, examples?) 

It doesn't have to be. I find the Sather way of doing MI very easy to 
understand. Quoting the Sather report:

	"A class 'A' inherits the features of another class 'B' when the
	 name 'B' appears in A's feature list. We say that B is a parent class
	 and that A is a child. The semantics is exactly as if the features
	 of B were textually copied into A at the point the name appears.
	 Any references that appear in the inherited feature definitions will
	 be resolved in the new namespace. Later features in a class with
	 the same name as earlier ones override the earlier definitions. This
	 means that the order in which classes are inherited can have an
	 effect on the meaning. A class may inherit from many other classes.
	 This is called MULTIPLE INHERITANCE."

Depending on the language, it can be made to look more difficult. But
the concept is on that paragraph.
--
...............................................................................
Ari Huttunen                               They say the sky high above
90-7285944                                   is Caribbean blue...  (Enya)


======================================================================= 38 ===
Date:    Fri, 10 Jul 92 15:48:42 EDT
From:    wyant@centerline.com
Subject: RE: Proposed language changes

I don't want to debate the question of whether
MI is good or bad. The more pertinent question
to my mind is: can multiple inheritance be added
cleanly and simply to a type system that was designed
for single inheritance ? The evidence suggests not:
MI was added to SmallTalk in the mid-80's. It never
really caught on because it didn't fit naturally
into the SmallTalk model. It was added to C++ about
5 years after the C++ type system was initially
designed; again I believe this proved to warp the
language considerably. 

In general, I have doubts about adding significant
new features to a language after its initial design.
It can be done, but it needs to be done with the same
care as the original definition process. Most useful and
long-lived languages go 5-10 years between
major language changes; witness Fortran, ADA, and C.
C was in use for a good ten years before the first ANSI
standardization efforts, and the changes made by ANSI
were relatively straightforward. It has changed very little
since the standardization. The C++ language on the other hand 
is changed in major ways every 2 years.

My other sense is that the innovation should not come in the
language, but in the accompanying libraries and tools. I would 
like to see people expending their energies on well-designed
and innovative libraries; such things as an interesting data
model and database integrated into the M3 environment, libraries
for constraint-based programming, rule based systems, computational
geometry, algorithm visualization, transaction based systems, ...

Well, I've said more than enough, so I'll shut up now.

--geoff


======================================================================= 39 ===
Date:    Fri, 10 Jul 92 19:02:35 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: documentation of libraries

In article <alanf.710739193@bruce.cs.monash.edu.au>, alanf@cs.monash.edu.au (Al
an Grant Finlay) writes:
|> I have some tutorials for the standard libraries and trestle but many
|> additional libraries have no documentation.  I can look in the include
|> directory but there are hundreds of interfaces, listed in alphabetical
|> order.  If these interfaces are the documentation then I need at least a
|> list of which interfaces belong to which library and preferably a dependancy
|> tree.
|> 
|> I could write a program to read the include directory and contruct a forest
|> of dependencies, has anybody else done this.  Am I missing something?


It is true that today you have no way of finding which libraries you
need to link with.  We have some prototype programs to do that, I guess
we should push forward to make them available (they work by looking at
the .ix, .mx and .ax files).

It is also true that there is no coherent documentation of the
interfaces that are available.  We realize that this a real problem,
but we haven't found any good solution yet.  The most promising
solutions rely on stylized comments at the beginning of each
interface, for example:

(* Keywords: foo, bar, foobar;
   Classification:  user interfaces, text widgets;

   This is a one line description.

   This is more complete description
   of what this interface is about. *)

The Keywords field would be used to build an index.  The
Classification field would be used to include the description at a
right place in a document of all the interfaces.  The one-line would
help for quick selection.

But then, we don't really know which tools to use to manipulate that
information.  We probably need more than on tool: one to get an
overview of what is available, one to find which interface to use for
a particular job.

Producing a formatted output (say using TeX) is almost guaranteed to
be obsolete as soon as it is ready, and it is difficult to use
on-line.  Also, not everybody has TeX.

I am tempted to try to use info under gnuemacs.  The nice thing is
that I could easily get the documentation while I am working on a
program.  Note that we already have a tags mechanism for Modula-3.  

Of course, it may be that this kind of problem has already been
solved, and that we could reuse the solution.  If you know of one,
please let us know.  

Also, if you have a working documentation system, we are ready to
modify the interfaces so that they include the needed information in
the right format.

-- 
Eric.



======================================================================= 40 ===
Date:    11 Jul 92 15:04:51 GMT
From:    ark@alice.att.com (Andrew Koenig)
Subject: Re: Proposed language changes

In article <9207101948.AA26823@riposte> wyant@centerline.com writes:

> It [multiple inheritance] was added to C++ about
> 5 years after the C++ type system was initially
> designed; again I believe this proved to warp the
> language considerably. 

Oh?  Can you give us some concrete examples of that warpage?

For instance, can you show a case where the existence of
multiple inheritance in C++ inconveniences programmers that
don't use it?
-- 
				--Andrew Koenig
				  ark@europa.att.com


======================================================================= 41 ===
Date:    Sat, 11 Jul 92 19:50:10 -0400
From:    Norman Ramsey <nr@Princeton.EDU>
Subject: installing src m3

Installing m3 is getting to be a big chore, because there are so many
packages.  I'm delighted to have access to so much interesting
software, but there has to be a better way to build it.  Here are some
suggestions.

  - put the boot files and the rest of the stuff in separate directores,
    so that I can use ftp to
	mget *.tar.Z
    without getting boot files that I don't need.

    also place in a separate directory compiler, driver, doc, and the
    other packages that are included in the boot files

    So I am proposing three subdirectories of release:

	boot:	holds boot files for the various architectures
	basics:	holds only those packages include in boot 
	others: holds libm3 and all the other packages

    now when I want a new compiler, I can get one file from
    the boot directory, everything from the others directory,
    and I don't have any duplicates.

    I assume there is a scenario where it's advantageous to get
    compiler, driver, etc. from the others directory, instead of using
    the boot files, but I don't understand what that scenario might
    be.
    
  - Once I have ftp'ed a collection of stuff, I want to be able
    to build it all with a single command.  The problem is, I
    have to build things in a certain order (e.g. X11R4 before
    trestle).  So could SRC provide some sort of makefile
    or shell script to use to build whatever's present, in an
    order that works?  Given the dependencies between packages,
    it is easy to generate a script like this one:

        build boot
        build libm3
        if [ -r m3makefile.X11R4 ]; then build X11R4; fi
        if [ -r m3makefile.X11R4 -a -r m3makefile.trestle ]; then 
          build trestle
        fi
        ...

    where `build x' == m3make -f m3makefile.x all install


Norman Ramsey
 


======================================================================= 42 ===
Date:    Sun, 12 Jul 92 00:07:51 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: installing src m3

In article <9207112350.AA21799@cs.Princeton.EDU>, Norman Ramsey <nr@Princeton.E
DU> writes:
|> Installing m3 is getting to be a big chore, because there are so many
|> packages.  I'm delighted to have access to so much interesting
|> software, but there has to be a better way to build it.  Here are some
|> suggestions.
[...]
|> 
|>     So I am proposing three subdirectories of release:
|> 
|> 	boot:	holds boot files for the various architectures
|> 	basics:	holds only those packages include in boot 
|> 	others: holds libm3 and all the other packages

Sounds fine with me.  If there are no objections, we'll do that for
the next release. 

|>   - Once I have ftp'ed a collection of stuff, I want to be able
|>     to build it all with a single command.  

I'll put a script that does that in the next release.

-- 
Eric.



======================================================================= 43 ===
Date:    Sat, 11 Jul 92 17:54:20 -0400
From:    Norman Ramsey <nr@Princeton.EDU>

From: nr@cs.Princeton.EDU (Norman Ramsey)
Newsgroups: comp.lang.modula3
Subject: elapsed time spent in threads
Summary: 
Followup-To: 
Distribution: world
Organization: Princeton University, Dept. of Computer Science
Keywords: 


I want to learn how much elapsed time is spent in a particular thread,
in the style of ETimer.T.  Is there some way for the scheduler and
ETimer to get in cahoots, or is there some other good way to find out
how much elapsed time is spent in a thread?


======================================================================= 44 ===
Date:    12 Jul 92 20:13:32 GMT
From:    mbk@lyapunov.ucsd.edu (Matt Kennel)
Subject: Re: Proposed language changes

ark@alice.att.com (Andrew Koenig) writes:
: In article <9207101948.AA26823@riposte> wyant@centerline.com writes:
: 
: > It [multiple inheritance] was added to C++ about
: > 5 years after the C++ type system was initially
: > designed; again I believe this proved to warp the
: > language considerably. 
: 
: Oh?  Can you give us some concrete examples of that warpage?
: 
: For instance, can you show a case where the existence of
: multiple inheritance in C++ inconveniences programmers that
: don't use it?

I don't think that's exactly the problem.  It's that those people who
*want* to use multiple inheritance have to deal with its problems and
evolutionary vestiges.

A difficult-to-use-MI also affects the way that libraries are designed
and implemented, and a programmer not directly using MI often uses
libraries.  Unfortunately despite OOP becoming so popular, there's still
an emphasis on the language rather than really good libraries.

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

Personally, I don't like C++ at all--I think it's much too complicated
and difficult for what it does.  The syntax is too hard for humans to
parse.

One of the languages I like best is Sather.  It was amazing
to nearly completely understand it in 45 minutes.  It's very simple.
Perhaps a bit too spare, but otherwise I like it alot.

It has multiple inheritance and parameterized types and for the first
time I really understood what these did.  It seems thought that classes
can only take types as arguments, and not values.  I.e. with a generic
list class you can make a list of foobars class, but not a list of
foobars of size 11.

One nice thing is that it generates code made *specific* for the
paramterized class, and not only the general case with tons of indirect
function calls.

I might actually start using it for my work were it not for the
fact that there isn't even a "do loop" construct, i.e. only a general
loop and you have to 'manually' increment a counter.  It's simply a
minor syntactical convenience, but such a common case (especially
in numerical programming).  (Of course, I'd really like index notation
for arrays, but that's another long story...)

: -- 
: 				--Andrew Koenig
: 				  ark@europa.att.com

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego


======================================================================= 45 ===
Date:    Sun, 12 Jul 1992 23:47:16 GMT
From:    dmb@srl02.cacs.usl.edu (David M. Brumley)
Subject: Does NEW() accept positional bindings for OBJECTS?

Page 46 of _SPwM3_ shows a generic stack module:

GENERIC MODULE Stack (Elem);
  REVEAL
    T = BRANDED OBJECT n: INTEGER; a: REF ARRAY OF Elem.T END;

  PROCEDURE Create(): T = BEGIN RETURN NEW(T, 0, NIL) END Create;
  ...


Can a new T be initialized this way?  


======================================================================= 46 ===
Date:    Mon, 13 Jul 1992 09:01:45 GMT
From:    harald@cs.ruu.nl (Harald Vogt)
Subject: Thread Aqcuire and Release problem

Hello,

we installed the newest m3 from gatekeeper on our HP900/400
machines and have problems with the Thread module, 
especially with the implementation of the binary semaphore 
(Mutex, NewMutex, Acquire, Release). 
It used to run on an earlier version of m3. We would like to use 
m3 for a course on Parallel Programming. Below follows a test
program which demonstrates our problems in detail. 

Is there anoybody out there with an m3 implementation on which
the program below runs? If yes, which version of m3 and which
C-compiler do you use? Or, is my test program not OK?

Any help is appreciated,

--
     Harald* Vogt, Department of Computer Science, Utrecht University,
     Padualaan 14, P.O. Box 80.089,  3508 TB Utrecht, The Netherlands.     
     E-mail: harald@cs.ruu.nl, Phone:+31-30-532249, Fax:+31-30-513791

MODULE Main;

(* This little program demonstrates that the Acquire and Release 
   calls do not function properly. Two processes are started:
   a producer and consumer. The consumer waits on the producer.
   Output when run: CONSUMER
		    Quit (core dumped).

   However, the processes do run concurrently when no Release and 
   Acquire is used.

   HARDWARE-CONFIG: HP9000/425 HP-UX 8.0 SYSV M68000 
   SOFTW-CONFIG: Newest m3 version 2.07 from gatekeeper and gcc is used

   Harald Vogt  *)

IMPORT Wr, TextWr, Word;
FROM Stdio IMPORT stdout;
FROM Thread IMPORT IncDefaultStackSize,Fork, T, Join, Closure, Mutex, NewMutex,
Acquire, Release;
 
TYPE Procobj   = Closure BRANDED "p007 T" OBJECT
                  local : PROCEDURE();
                 END;
 
VAR p1, p2 : T;
    sp, sc : Mutex;

PROCEDURE work (self: Procobj): REFANY RAISES {}=
BEGIN self.local(); RETURN NIL;
END work;

PROCEDURE StartProcess (proc: PROCEDURE()): T=
VAR process : Procobj;
    handle  : T;
BEGIN
  process := NEW( Procobj, local := proc, apply := work );
  handle := Fork( process );
  RETURN handle;
END StartProcess;
 
PROCEDURE WaitFor (VAR handle: T)=
BEGIN EVAL Join(handle);
END WaitFor;

PROCEDURE PRODUCER()=
BEGIN
FOR i := 1 TO 10 DO
  Acquire(sc);
  Wr.PutText(stdout, "PRODUCER\n");
  Release(sp);
END
END PRODUCER;

PROCEDURE CONSUMER()=
BEGIN
FOR i := 1 TO 10 DO
  Acquire(sp); 
  Wr.PutText(stdout, "CONSUMER\n");
  Release(sc);
END
END CONSUMER;

BEGIN
  IncDefaultStackSize(10000); (* To be sure *)
  sp := NewMutex();
  Acquire(sp);
  sc := NewMutex();
  p1 := StartProcess (PRODUCER);
  p2 := StartProcess (CONSUMER);
  WaitFor( p1 );
  WaitFor( p2 );
END Main.
-- 
     Harald* Vogt, Department of Computer Science, Utrecht University,
     Padualaan 14, P.O. Box 80.089,  3508 TB Utrecht, The Netherlands.     
     E-mail: harald@cs.ruu.nl, Phone:+31-30-532249, Fax:+31-30-513791



======================================================================= 47 ===
Date:    13 Jul 92 06:12:05 GMT
From:    johng@otc.otca.oz.au (John Gibbons)
Subject: how do I get the modula3 revised report?

Is the modula-3 revised report available over the net?



======================================================================= 48 ===
Date:    13 Jul 92 16:22:51 GMT
From:    os102@cl.cam.ac.uk (Oliver Stephens)
Subject: Re: installing src m3


In article <9207112350.AA21799@cs.Princeton.EDU>, Norman Ramsey writes:
|> 
|>     I assume there is a scenario where it's advantageous to get
|>     compiler, driver, etc. from the others directory, instead of using
|>     the boot files, but I don't understand what that scenario might
|>     be.
|>     

I have a scenario where these are useful (although it does not strictly fit
this category as the bootstrapped version was also required).

After building the bootstrapped compiler for SPARC, I built libm3 then made
a shared library version of it.  I then rebuilt the compiler and driver from
the M3 source to produce versions which used the shared library.

Resulting saving in space is :

  m3         - from 2.8 to 0.5 Mbytes
  m3compiler - from 5.3 to 3.1 Mbytes

-------------------------------------------------------------------------
Olly Stephens                                oliver.stephens@cl.cam.ac.uk
Computer Laboratory
University of Cambridge    Loved you there and then, and now like a sheep
United Kingdom                                             - Van Morrison


======================================================================= 49 ===
Date:    13 Jul 92 10:17:39
From:    thewalt@canuck.ce.berkeley.edu (C. Thewalt)
Subject: Re: Proposed langauge changes

Regarding my request for complex number support and an exponentiation
operator.

In article <1992Jul13.150924.1971@exu.ericsson.se> exuhag@exu.ericsson.se (Jame
s Hague) writes:

   Big, bloated languages are made up of lots of little things...

What bloat does complex number support cost when you already have all
the operators you need for integer and floating point support?  While
I might back off the exponentiation operator request, since you can
get by without it with minor pain (although I think it is silly not to
include it), the cost of supporting complex numbers on the user code
side is way too great considering the minor impact it would have on
langauge syntax.

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...


======================================================================= 50 ===
Date:    Mon, 13 Jul 92 11:09:38 EDT
From:    wyant@centerline.com
Subject: re: question on generics

About a week ago, I posted 

>I may not be thinking about this in the right way...
>
>I have a generic interface, say "List", and
>a non-generic interface say "Foo". Foo exports
>an object type, say "Bar". Bar has an operation
>which wants to return a "List of Bar", using the
>generic "List" interface.
> [ ... ]
>As I said, I may just be thinking of this in the
>wrong way.


Well, I was thinking about it in the wrong way.
I was revealing too much information in the interface;
namely that a "Bar" contains a "List of Bar". By making
Bar opaque and requiring clients to call an iterator, I
broke the apparent circularity.  Clients only ever deal
with the opaque type 'Bar.T" while the implementation is
revealed to have a "List of Bar.T" which is trivial to
instantiate from the generic "List" interface at this 
point.

Thanks to all those that help break my mental "circularity".

--geoff


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


======================================================================= 51 ===
Date:    Mon, 13 Jul 92 16:32:50 +0200
From:    a.vermeulen@ECN.NL (Vermeulen A.T.)
Subject: Manuals on vbtkit, formsvbt and miniformsedit etc...

The new release (2.07) of SRC Modula-3 seems to deliver a really workable syste
m to the
users. I was impressed by the demos (fisheye, cube , calculator) which show how
 good
libraries and good (language) design can alleviate the life of application prog
rammers.
Documentation is still a weak point however and commenting in the sources and i
nterface
units is very sparse until now. 
This surely does stimulate experimenting but it would be nice if the labour cou
ld be
directed towards further enhancement and just using the libraries instead of tr
ying to
figure out how this and that works.
Are there any plans to bring out some documentation on vbtkit and vbtforms?  Th
e
IMHO very useful interface contruction kit miniformsedit should get the attenti
on of all
M3-programmers!

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


======================================================================= 52 ===
Date:    13 Jul 92 15:09:24 GMT
From:    exuhag@exu.ericsson.se (James Hague)
Subject: Re: Proposed langauge changes

C. Thewalt writes:
>
>While I understand the reserve expressed in making dramatic changes, I
>don't understand why the same reserve is applied to relatively trivial
>extensions like complex number support and an exponentiation operator.
>The latter may require considerable discussion to nail down the
>semantics, but in terms of language extension both of these seem pretty
>minor.

Big, bloated languages are made up of lots of little things...
--
James Hague   
exuhag@exu.ericsson.se


======================================================================= 53 ===
Date:    13 Jul 92 14:50:50 GMT
From:    andy@brian.informatik.rwth-aachen.de (Andreas Schuerr)
Subject: Re: Proposed language changes


Well, I agree with you that a language with a large
number of STANDARD libraries is a better development
tool than a programming language without libraries
or a language the compilers of which each have a
different set of libraries (as e.g. in Modula-2).

But you will have difficulties to find language
users or library developers for a brand-new
language which doesn't contain at least all
really important concepts of its direct competitors
Eiffel, C++, etc.

For instance, our group is busy with the development
of integrated software development environments,
and we have implemented many (generic) tools using
the language Modula-2 (producing some hundred 
thousands lines of code). There is e.g. a graph-oriented
nonstandard DBMS which is currently extended by a
front-end for a data modelling and database programming
language.

This DBPL offers the concept of MI and we are 
continously using MI on the conceptual level as
well as on the implementation level. Up to now
we have to implement inheritance and dynamic
binding in Modula-2 using many tricks (type-casts,
procedure arrays, ...).

You may guess from the above written lines that we
are looking for another implementation language 

* which has a Modula-2-like "look&feel"

* which doesn't permit a C-like style of programming

* and which supports MI.
  
Therefore, we would like to use Modula-3, but we will
never use a language forcing us to simulate MI further-
on.

To summarize: its true that nobody will try to use a
new language without usefull standard libraries, but
it's also true that nobody will spend many efforts to
supply libraries for a new language which has up-to-now
neither a large user community nor contains new important
concepts like MI.

Dr. Andy Schuerr,
Lehrstuhl fuer Informatik III
RWTH Aachen
D-5100 Aachen (Germany)


======================================================================= 54 ===
Date:    13 Jul 92 18:22:05 GMT
From:    schilit@Xerox.com (Bill Schilit)
Subject: BUG in PQueueADT.ig

Problem: building a program with PQueueADT.ig causes:

    ***
    *** runtime error:
    ***    Segmentation violation - possible attempt to dereference NIL
    ***    pc = 0xf7ffeee8
    ***

Cure: In PQueueADT.ig change:

  T = OBJECT METHODS
        new (): T;
          (* create (self = NIL) or initialize (self # NIL) a PQueue.T *)
	
To:

  T = OBJECT METHODS
        new (): T := new;
          (* create (self = NIL) or initialize (self # NIL) a PQueue.T *)
	
	

- Bill


======================================================================= 55 ===
Date:    Mon, 13 Jul 92 12:00:31 -0700
From:    <mhb@src.dec.com>
Subject: Re: Manuals on vbtkit, formsvbt and miniformsedit etc...


Manuals for VBTkit and FormsVBT are being polished as I typed. (Well, 
acutally they are in other windows on my screen and on Jim Meehan's 
screen....) 

The code for VBTkit and FormsVBT was put on the "test" distribution 
a few weeks ago for a couple of alpha testers who really needed the 
functionality. It was moved to the "release" distribution unintentionally, 
since the documentation wasn't there yet. 

The VBTkit reference manual will be like Chapters 4, 5 and 6 of the 
Trestle reference manual: TeXified .i3 files with some additional 
prose giving the ``big picture''. The FormsVBT Reference Manual is 
intended for less sophisticated clients, so it will be less terse. 

Stay tuned.


======================================================================= 56 ===
Date:    13 Jul 1992 21:54:06 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: Proposed langauge changes / MI

In article <1992Jul9.154716.7869@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.inf
ormatik.rwth-aachen.de writes:
>Since you mentioned the MI thing again: I still don't see any problem with
>it.

There's a couple of problems -- sorry if I didn't go into details.

(1) Define the semantics of TYPECASE (which case is chosen?)

(2) Can we add MI without slowing down SI?  (This is a trick
    question, because you need to worry about both current
    (sleazy compilers) and future (good compilers) performance.)

(3) MI has some weird interactions with opaque supertypes.
    Suppose you get something like (pardon my mangling of the
    syntax):

    TYPE X <: OBJECT;
    TYPE Y <: OBJECT;

    A = X OBJECT METHODS ... END;
    B = Y OBJECT METHODS ... END;

    C = A,B OBJECT METHODS ... END;

    Now, what if it turns out that X and Y actually share
    a common ancestor?  Are the data fields and methods shared, or no?
    (sharing is not consistent with encapsulation -- my conclusion is
    that sharing should not occur in this case.  However, for mix-ins
    it appears that sharing is what you want.  One resolution is to
    only allow sharing to occur when it is not hidden.  However, I
    don't know if this can be done in a consistent and reliable
    fashion; what happens if there are multiple views of the objects
    involved?)

(4) How does narrow work in the presence of repeated inheritance?
    (a) what is the right answer?
    (b) can we implement this efficiently?

    That is, suppose you have:

    TYPE X <: OBJECT;

    A = X OBJECT METHODS ... END;
    B = A,X OBJECT METHODS ... END;

    C = A,B OBJECT METHODS ... END;

    Suppose I narrow an "X" to an "A", given that what I've really got
    is a C.  Which one?  How efficient is "NARROW" now?

(5) Discover and document any remaining semantic/implementation
    gotchas.

My concern about efficiency may seem misplaced, but if what you're
after is flexibility with no major concern for performance, you can
get that already from CLOS.  (And yes, I am *very* interested in
Dylan, which I am told is something like Scheme+CLOS.)

Comparisons with bullet-items on the C++ Real-Soon-Now list are also
unfair.  It could be that they are unimplementable, or come with
horrible interactions, or maybe there is more sizzle than steak (e.g.,
maybe the feature is "provided" but in a useless fashion).

David Chase
Sun


======================================================================= 57 ===
Date:    Tue, 14 Jul 92 02:59:53 GMT
From:    news@massey.ac.nz (USENET News System)
Subject: Re: Proposed langauge changes

In article <1992Jul13.150924.1971@exu.ericsson.se>, exuhag@exu.ericsson.se (Jam
es Hague) writes:
> 
> C. Thewalt writes:
> >
> >While I understand the reserve expressed in making dramatic changes, I
> >don't understand why the same reserve is applied to relatively trivial
> >extensions like complex number support and an exponentiation operator.
> >The latter may require considerable discussion to nail down the
> >semantics, but in terms of language extension both of these seem pretty
> >minor.
> 
> Big, bloated languages are made up of lots of little things...
> --

I agree. We should get rid of a few more inessential little things.

Let's see... If we eliminated the division and subtraction operators,
ah, what about multiplication?

I'm getting quite enthusiastic about this, perhaps we only need the Boolean
data type and a couple of logical operations. We can implement everything
else in terms of these. It may be a bit of trouble, but, after all, as it's 
in the interest of a  more parsimonious language, I'm sure to get a lot of
support.


======================================================================= 58 ===
Date:    Tue, 14 Jul 92 11:20:20 GMT
From:    mw@frodo.ki.fht-mannheim.de (Marc Wachowitz)
Subject: Re: Sather (was: Re: Proposed language changes

mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
: Despite what all the proponents of OOP say, either explicitly or by
: their textbook examples, I do *not* think that a class structure is the
: best solution for this problem (i.e. matrix and vector and tensor classes
: and overload the + and the - and the blah blah blah).  There's another soluti
on
: that's cleaner and more general, at least in the (important!) domain of
: array operations.
IMO the problem isn't that classes are wrong (though I prefer CLOS-like
decoupling of classes and generic functions, with the ability to specialize
on the types of all arguments), but the lack support for building new control
structure abstractions, like macros is Lisp.
Probably it wouldn't be particularly difficult to write a macro that does what
you want - and you could specify whatever special-case optimizations you knew
of (which "level" of programmer does that is another question, but IMO it shoul
d
be available at every level).


-------------------------------------------------------------------------------
Marc Wachowitz, mw@gandalf.ki.fht-mannheim.de, 75742@novell1.rz.fht-mannheim.de
  *  wonder everyday    *    nothing in particular    *    all is special  *


======================================================================= 59 ===
Date:    14 Jul 92 00:48:18 GMT
From:    Ari.Huttunen@hut.fi (Ari Juhani Huttunen)
Subject: Sather (was: Re: Proposed language changes

In article <13q3pdINNk5u@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) 
writes:

! One of the languages I like best is Sather.  It was amazing
! to nearly completely understand it in 45 minutes.  It's very simple.
! Perhaps a bit too spare, but otherwise I like it alot.

! I might actually start using it for my work were it not for the
! fact that there isn't even a "do loop" construct, i.e. only a general
! loop and you have to 'manually' increment a counter.  It's simply a
! minor syntactical convenience, but such a common case (especially
! in numerical programming).  (Of course, I'd really like index notation
! for arrays, but that's another long story...)

Take a look at lib/base/do.sa. It implements some loop constructs. You
are able to say things like:
	c: DO := DO::times(100); until c.is_done loop ..foobar.. end;

No, I haven't tried to use it.

(What do you mean by index notation?)
--
...............................................................................
Ari Huttunen                               They say the sky high above
90-7285944                                   is Caribbean blue...  (Enya)


======================================================================= 60 ===
Date:    14 Jul 1992 07:42:31 GMT
From:    mbk@lyapunov.ucsd.edu (Matt Kennel)
Subject: Re: Sather (was: Re: Proposed language changes

Ari.Huttunen@hut.fi (Ari Juhani Huttunen) writes:
: In article <13q3pdINNk5u@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel
) writes:
: 
: ! One of the languages I like best is Sather.  It was amazing
: ! to nearly completely understand it in 45 minutes.  It's very simple.
: ! Perhaps a bit too spare, but otherwise I like it alot.

I should remind people that I'm not a computer scientist, but a 
(probably future unemployed) physicist.

: ! I might actually start using it for my work were it not for the
: ! fact that there isn't even a "do loop" construct, i.e. only a general
: ! loop and you have to 'manually' increment a counter.  It's simply a
: ! minor syntactical convenience, but such a common case (especially
: ! in numerical programming).  (Of course, I'd really like index notation
: ! for arrays, but that's another long story...)
: 
: Take a look at lib/base/do.sa. It implements some loop constructs. You
: are able to say things like:
: 	c: DO := DO::times(100); until c.is_done loop ..foobar.. end;

I did.  It still seems unnatural.  Seems, hell.  It is.  Take a look at
it, and be honest.  I think "do loops" were deleted from Modula-2 in
going to Oberon (an intentionally small language, like Sather), and
reinstated after practical experience in Oberon-2.  A simple, very common
concept deserves a simple, idiomatic statement.

: No, I haven't tried to use it.
: 
: (What do you mean by index notation?)

Implied iteration and summation over repeated indices.  (a.k.a. Einstein
summation convention).  It's a common notation in math and science--computer
or no.

E.g.  Vector A = Matrix B times vector C:
	A(i) = B(i,j)*C(j)
or more explicitly

	"for all i" A(i) = "sum over j" B(i,j)*C(j).

This concept subsumes nearly all of Fortran 90's matrix & vector operations.
Explicitly parallel too.  In comp.lang.misc there was a long debate
on this a couple of months ago.  Jim Giles also had the same position, and
in fact I think his operation even designed specific extensions to Fortran
to express this concept.  (In fact if I were to design an optimizer for
an F90 compiler, I might want to internally represent array
operations in this generalized form so I could write only 1 code generator).

Despite what all the proponents of OOP say, either explicitly or by
their textbook examples, I do *not* think that a class structure is the
best solution for this problem (i.e. matrix and vector and tensor classes
and overload the + and the - and the blah blah blah).  There's another solution
that's cleaner and more general, at least in the (important!) domain of
array operations.

In case you're wondering:  Yes, I do think that iteration and arithmetic 
on arrays deserves special case attention in the language.  I think possible
solutions can be elegant, clean, with a strong non-computer precedents, and
not at all interfere with other aspects of the language.  Nobody's done it
really 'right' yet.   (Sather with index operations might be very attractive
though.  It would have that 'killer' feature that nobody else has, and do
all the normal stuff easier.  With a good enough library and optimization
it would be at least technically, a formidable competitor to Fortran.).

: --
: .............................................................................
..
: Ari Huttunen                               They say the sky high above
: 90-7285944                                   is Caribbean blue...  (Enya)

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego


======================================================================= 61 ===
Date:    Tue, 14 Jul 92 18:09:54 GMT
From:    detlefs@src.dec.com (Dave Detlefs)
Subject: Re: Proposed language changes

In his article of July 9, 1992, David Chase does an admirable thing:
he lays some concrete objections to multiple inheritance, rather than
heaping non-specific scorn on the concept.  While not completely
convinced that MI in M3 is a good idea, I tend to lean that way, and
will attempt to play the devil's advocate and respond to his points.

> (1) Define the semantics of TYPECASE (which case is chosen?)

This seems pretty easy; the current rule says that the first case arm
whose type is a supertype of the case expression is chosen, which
seems to work just as well in the MI case.

> (2) Can we add MI without slowing down SI?  (This is a trick
>     question, because you need to worry about both current
>     (sleazy compilers) and future (good compilers) performance.)

The C++ experience seems to answer yes to this question, though, as
you implicitly point out below, this experience may not carry over to
Modula-3.

> (3) MI has some weird interactions with opaque supertypes.
>     Suppose you get something like (pardon my mangling of the
>     syntax):
>
>     TYPE X <: OBJECT;
>     TYPE Y <: OBJECT;
>
>     A = X OBJECT METHODS ... END;
>     B = Y OBJECT METHODS ... END;
> 
>     C = A,B OBJECT METHODS ... END;
> 
>     Now, what if it turns out that X and Y actually share
>     a common ancestor?  Are the data fields and methods shared, or no?
>     (sharing is not consistent with encapsulation -- my conclusion is
>     that sharing should not occur in this case.  However, for mix-ins
>     it appears that sharing is what you want.  One resolution is to
>     only allow sharing to occur when it is not hidden.  However, I
>     don't know if this can be done in a consistent and reliable
>     fashion; what happens if there are multiple views of the objects
>     involved?)

Again, I'll argue from the viewpoint that C++ faces many of the same
problems and gives a solution that at least addresses all the
problems.  As you point out, there are times when sharing is
appropriate, and times when it is not.  (I tend to think that sharing
is almost always the right choice, but let's push that discussion.)
C++ lets you specify both: a supertype may be virtual or not; all
virtual instances of a type in a MI subtype lattice are collapsed into
a single node.  Another principle guiding the design of MI in C++ is
that any ambiguity must be explicitly resolved by the programmer; in
the example above, if A and B had defined fields with the same name,
then a C method would have to narrow 'self' to an A or a B before
selecting that field.

So, one answer to the question is that we add some syntax allowing us
to specify whether a supertype is the-M3-equivalent-of-virtual.  Then,
in the example you've given, in any scope in which it is revealed that
X and Y are both subtypes of Z, those revelations will say whether Z
is a virtual supertype or not.  Let's say that Z has a field a.  If
Z is a virtual supertype in both cases, then there is only one copy of
a Z in a C, and it is clear what c.a means if c is a C.  If Z is not
virtual in both cases, then c.a is ambiguous; to eliminate the
ambiguity, the programmer would have to write NARROW(c, A).a or
NARROW(c, Y).a.   If there is a scope in which it is revealed that
X is a subtype of Z, then there is still no problem, since c.a is
unambiguous in all the cases: if Z is not a supertype of Y, then there
is no conflict, if Z a virtual supertype of both X and Y, then there
is no ambiguity, since c.a refers to the same field; if Z is a
non-virtual supertype of both X and Y, in this scope c.a must refer
NARROW(c, X).a, since we don't know of anything about Y and Z in this
scope.

> (4) How does narrow work in the presence of repeated inheritance?
>     (a) what is the right answer?
>     (b) can we implement this efficiently?
> 
>     That is, suppose you have:
> 
>     TYPE X <: OBJECT;
> 
>     A = X OBJECT METHODS ... END;
>     B = A,X OBJECT METHODS ... END;
> 
>     C = A,B OBJECT METHODS ... END;
> 
>     Suppose I narrow an "X" to an "A", given that what I've really got
>     is a C.  Which one?  How efficient is "NARROW" now?


Again, the C++ answer is: if A and X are virtual supertypes in all cases,
the right answer is clear, since there is just one subobject of each
type in a C.  If A and X are not virtual supertypes, and x is a
variable whose static type is X containing a value whose allocation
type is C, then we have the following type graph:

              X  (1)
              |
              |
  (2)  X      A
       |      |
       |      |
       A      B
        \    /
         \  /
           C

How did we get a variable with static type X and allocation type C?
We originally allocated a C and assigned to a variable of some
supertype.  If we assigned it to a B variable there is no ambiguity;
we could then assign that result to an X variable and end up at (1).
If we assigned the C value directly to an A variable or an X variable,
however, there would be ambiguity, so the compiler would have to
complain.  So, the C++ answer says that there is no way to get from a
C value to the X subobject labelled (2).  (This ambiguity is one of
the reasons I recommend the ubiquitous use of virtual base classes
whenever I'm asked.)

Given that we're at the X labelled (1), then NARROW's of the value to
any of an A, B, or C is well-defined.

Perhaps a the confusing example you want to bring out is if X is a
virtual supertype, but A is not.  This this case you get

          X
         / \ 
        /   \    
       +      A
       |      |
       |      |
       A      B
        \    /
         \  /
           C

Now we can assign a C value directly to an X variable, but what if we
NARROW it back to an A?  How about: that's ambiguous, and therefore
illegal.

As an overall comment, note that there is a certain consistency in the
C++ approach to MI: if we it isn't completely obvious what the
compiler should do, the compiler rejects the program, and requires you
to be a little more explicit.  This tends to prevent at least some
potential misuses of MI.

So, this little missive makes a small start at addressing what MI
would mean if we added it; it does nothing to argue that it would be a
good thing if we did.  I happen to believe that it would; but I'll
leave that argument for another time.  I look forward to further
debate.

Dave









======================================================================= 62 ===
Date:    14 Jul 92 15:09:29 GMT
From:    tlai@cs.toronto.edu (Tony Wen Hsun Lai)
Subject: Re: Proposed langauge changes

In article <1992Jul14.025953.24560@massey.ac.nz> news@massey.ac.nz (USENET News
 System) writes:
>In article <1992Jul13.150924.1971@exu.ericsson.se>, exuhag@exu.ericsson.se (Ja
mes Hague) writes:
>> C. Thewalt writes:
>> >While I understand the reserve expressed in making dramatic changes, I
>> >don't understand why the same reserve is applied to relatively trivial
>> >extensions like complex number support and an exponentiation operator.
[stuff deleted]
>> 
>> Big, bloated languages are made up of lots of little things...
>
>I agree. We should get rid of a few more inessential little things.
>
>Let's see... If we eliminated the division and subtraction operators,
>ah, what about multiplication?
>
>I'm getting quite enthusiastic about this, perhaps we only need the Boolean
>data type and a couple of logical operations. We can implement everything
>else in terms of these. It may be a bit of trouble, but, after all, as it's 
>in the interest of a  more parsimonious language, I'm sure to get a lot of
>support.

Theoretically, you need only two counters, increment, decrement, and
compare with zero.  Writing efficient programs is a bit harder though.  :)

Seriously, to quote from Systems_Programming_with_Modula-3, "C.A.R. Hoare
has suggested that as a rule of thumb a language is too complicated if it
can't be described precisely and readably in fifty pages.  The Modula-3
committee elevated this to a design principle....  There are so many good
ideas in programming language design that some kind of arbitrary budget
seems necessary to keep a language from getting too complicated."

Tony Lai
--
Usenet.  The triumph of noise over signal.


======================================================================= 63 ===
Date:    14 Jul 1992 17:47:04 GMT
From:    ceeunex@garnet.berkeley.edu (UC Extension Engineering)
Subject: Short course announcement

University Extension, University of California, Berkeley
presents...a course on Object-Oriented Programming in C++ in two
locations:

	August 31-September 3, 1992/UC Berkeley
	September 14-17, 1992/New Orleans, Louisiana

Course introduces object-oriented methodology in C++, and presents
specific techniques using C++ that illustrate essential concepts
in object-oriented programming.  It highlights key points of
working code to demonstrate C++ capabilities.  Participants are
expected to know the basics of C++ programming; this is not a
hands-on course.

For a detailed course brochure, send request to:  

Carol Abrahamson, Continuing Education in Engineering, 
UC Berkeley Extension
e-mail:     ceeunex@garnet.berkeley.edu
fax:        (510) 643-8683 
phone:      (510) 642-4151


======================================================================= 64 ===
Date:    13 Jul 92 14:23:43 GMT
From:    sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Proposed language changes

In article <9207101948.AA26823@riposte> wyant@centerline.com writes:
>I don't want to debate the question of whether
>MI is good or bad. The more pertinent question
> ...

>My other sense is that the innovation should not come in the
>language, but in the accompanying libraries and tools. I would 
>like to see people expending their energies on well-designed
>and innovative libraries; such things as an interesting data
>model and database integrated into the M3 environment, libraries
>for constraint-based programming, rule based systems, computational
>geometry, algorithm visualization, transaction based systems, ...
> ...

However, the existence of good (class) libraries for specialised purposes
tends to increase the demand for MI, since in many cases one has to inherit
some class from each library in order to exploit its facilities.
(This has at least been the experience of many people who have used
some generally available C++ class libraries.)

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------


======================================================================= 65 ===
Date:    13 Jul 92 14:18:34 GMT
From:    sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Proposed language changes

In article <ARI.HUTTUNEN.92Jul10023336@wonderwoman.hut.fi> Ari.Huttunen@hut.fi 
(Ari Juhani Huttunen) writes:
>In article <1992Jul9.154716.7869@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.in
formatik.rwth-aachen.de (Peter Klein) writes:
>
>! a problem. The con side came up only with "MI is hard to understand" (I
>! still don't believe that, examples?) 
>
>It doesn't have to be. I find the Sather way of doing MI very easy to 
>understand. Quoting the Sather report:
>
>	"A class 'A' inherits the features of another class 'B' when the
>	 name 'B' appears in A's feature list. We say that B is a parent class
>	 and that A is a child. The semantics is exactly as if the features
>	 of B were textually copied into A at the point the name appears.
>	 Any references that appear in the inherited feature definitions will
>	 be resolved in the new namespace. Later features in a class with
>	 the same name as earlier ones override the earlier definitions. This
>	 means that the order in which classes are inherited can have an
>	 effect on the meaning. A class may inherit from many other classes.
>	 This is called MULTIPLE INHERITANCE."
>
>Depending on the language, it can be made to look more difficult. But
>the concept is on that paragraph.

Independently of the language, it _is_ more difficult if it is to remain
sensible even in complicated situations.  According to the quote,
it would seem that parallel superclasses can interfere surprisingly
with each other in Sather.

However, I am more optimistic than e.g. Alan Snyder (if the quote,
"multiple inheritance is a good thing, but nobody knows how to do it right",
is correctly accredited to him).  I think that MI can even be done right,
but have not studied whether and how it could be retrofitted to Modula-3.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------


======================================================================= 66 ===
Date:    13 Jul 92 14:39:34 GMT
From:    sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Proposed language changes

In article <23145@alice.att.com> ark@alice.UUCP () writes:
>In article <9207101948.AA26823@riposte> wyant@centerline.com writes:
>
>> It [multiple inheritance] was added to C++ about
>> 5 years after the C++ type system was initially
>> designed; again I believe this proved to warp the
>> language considerably. 
>
>Oh?  Can you give us some concrete examples of that warpage?
>
>For instance, can you show a case where the existence of
>multiple inheritance in C++ inconveniences programmers that
>don't use it?

Well, if any class B inherits some other class A as _public_ (or protected),
and the designer of B has even the least doubt that somebody might later
use B in a "fork-join" (*) situation, it would be very sensible to declare
the inheritance as "virtual" (meaning a sharable superclass part).
However, besides the performance penalty, this causes two drawbacks:

1. If non-default initialisation for A is needed, every constructor
   of every subclass (direct or indirect) of B must explicitly restate
   that initialisation.

2. "Downcasting" a pointer of type A* to a pointer of type B* becomes
   absolutely impossible (of course this is a very dangerous operation
   even in the allowed situations).

(*) This means that there is some other direct subclass of A, say C,
such that neither B nor C is a subclass of the other,
and some further class inherits both B and C (directly or indirectly).

Shameless plug:  see my paper, "A critique of the inheritance principles
of C++" (Computing Systems, Winter 1992), for eshasutinxhaustin.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------


======================================================================= 67 ===
Date:    Wed, 15 Jul 1992 08:02:49 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: installing src m3


Oliver Stephens writes:
> After building the bootstrapped compiler for SPARC, I built libm3 then made
> a shared library version of it.  I then rebuilt the compiler and driver from
> the M3 source to produce versions which used the shared library.
Whoa! Having just built the stuff and installed it, and not having found any
remarks about this in the README, I didn't even try.

Can you give me a 'ten easy steps to shared-lib happyness'?

> Resulting saving in space is :
> 
>   m3         - from 2.8 to 0.5 Mbytes
>   m3compiler - from 5.3 to 3.1 Mbytes
  Boy, our system maintainer will be tickled pink when he hears that. We get
alarmed shouts about lack of disk space allmost at a weekly basis.

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


======================================================================= 68 ===
Date:    Tue, 14 Jul 92 23:57:45 -0700
From:    nolan@pavone.enet.dec.com (Chris @ VAR - DTN: 787-8460 15-Jul-1992 085
5)
Subject: PLEASE REMOVE ME FROM THE MODULA-3 INTEREST LIST



  Fort the second time of asking I wish to be removed from the M3 interest
  and distribution lists. I am getting FAR too much mail and I wish it to
  STOP.

thanks,
chris.


======================================================================= 69 ===
Date:    15 Jul 1992 22:23:14 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: Proposed language changes

>In article <9207101948.AA26823@riposte> wyant@centerline.com writes:
>> It [multiple inheritance] was added to C++ about
>> 5 years after the C++ type system was initially
>> designed; again I believe this proved to warp the
>> language considerably. 

In article <23145@alice.att.com> ark@alice.UUCP () writes:
>Oh?  Can you give us some concrete examples of that warpage?

>For instance, can you show a case where the existence of
>multiple inheritance in C++ inconveniences programmers that
>don't use it?

Okey-dokey, I'll bite.  (Cut to the end to skip the long-winded stuff).

Right now, C++ (2.1, 3.0) requires that I read about virtual and
non-virtual base classes.  Without MI, these wouldn't be there.

Right now, C++ (2.0, 2.1, 3.0) lacks the ability to cast from a base
type to a derived type in certain situations.  It is, in fact, an
intellectual burden to discover and remember those situations.  I
believe that this is a consequence of multiple inheritance, since
single inheritance does not require any offsets of the "this" pointer.

Right now, C++ (2.0, 2.1, 3.0) pretty much requires (but does not
enforce) virtual destructors in certain single-inheritance
situations.  As you can see already, I don't recall quite when that
is, and this is a bug.  I believe this weird requirement is a
consequence of multiple inheritance (same as above -- an offset "this"
pointer).

Right now, C++ (same versions) lacks run-time type checking.  I don't
know why it doesn't have it, but I do know that it is more difficult
to define, implement, and explain this in the presence of multiple
inheritance.  Having implemented this in the past for a language with
single inheritance, I know that it is not terribly hard in that case.
This is an example of where the addition of one feature may have
prevented/delayed the addition of another feature.

In the future, C++ may have some form of run-time type-checking.  In a
language with single inheritance (like Modula-3) this can be
implemented in a way that it requires a constant amount of time to
perform any type check, and log(#cases) time to execute a typecase
statement (with arbitrary depth in the cases and the type tree).  Will
C++'s versions of these statements have similar efficiency, assuming
that I don't use multiple inheritance?  (I've been trying to figure
out how one might search the DAG quickly, but haven't had the time to
really make much progress.)  This is an example of where the addition
of one feature may have prevented the best presentation or
implementation of another feature.

In the future, it might be nice to add garbage collection to C++.  I
know it is easy to do a good garbage collection in a SI system, but
I'm not sure of what the MI interactions are.  It does not simplify
the garbage collector or make it faster (the offset pointers are the
basic pain here.  References cause similar problems.)

I'm a little curious where all this goes with (say) persistent data,
or pickled data, or dynamically loaded libraries.  I've done the
homework (other people have helped) to convince myself that I
implement a single-inheritance type system that would provide
efficient NARROW and concurrent introduction of new types (no locking,
assumes certain consistency properties of the underlying memory
system).  TYPECASE is a little harder, but I think about it from time
to time.  I wouldn't be surprised if MI had bad interactions with
these features.

Note that these are features that I have used in the past (in the
Olivetti M-3 system) and wished that I had access to now in C++.  I
have not experienced such a burning need for MI.  This doesn't mean
that MI is never useful, but if most of the cases where it is useful
sound something like "A friend of a grandmother of an old boss of mine
was working on this window system..." then I remain skeptical. (This
is an exaggeration.  Several people have told me good stories about
mix-ins.  However, the C++ MI system is considerably larger than
mix-ins, and it might be possible to add mix-ins w/o all the other
restrictions.)

So in summary:

1. MI makes the language bigger, even if I confine myself to a SI
   subset.  (virtual base classes)

2. MI adds more rules that a SI user must follow.
   (restrictions on down-casting; virtual destructors)

3. MI may have delayed other useful features.
   (run-time types)

4. MI may prevent other useful features from being implemented in
   their most useful fashion.  Speaking for myself, I've used and
   liked those features (run-time types, garbage collection,
   pickled data), but MI has never done much for me.

David Chase
Sun


======================================================================= 70 ===
Date:    Thu, 16 Jul 92 09:52:51 +0200
From:    a.vermeulen@ECN.NL (Vermeulen A.T.)
Subject: Redundant files in trestle-archive

In the archive trestle-2.07.tar.Z on gatekeeper a redundant compiled executable
has not been deleted (it's not a SPARC executable). It's called BadBricks. Also
the .mx and the .mo file are redundant. Removing them from the archive could
reduce the amount of data transported over the net considerably.

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


======================================================================= 71 ===
Date:    15 Jul 92 23:07:43 GMT
From:    Ari.Huttunen@hut.fi (Ari Juhani Huttunen)
Subject: Re: Sather (was: Re: Proposed language changes

In article <13u0h7INN43r@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) 
writes:

! I should remind people that I'm not a computer scientist, but a 
! (probably future unemployed) physicist.

Warning! This text was written by a computer science student.  ;-)

! : Take a look at lib/base/do.sa. It implements some loop constructs. You
! : are able to say things like:
! : 	c: DO := DO::times(100); until c.is_done loop ..foobar.. end;

! I did.  It still seems unnatural.  Seems, hell.  It is.  Take a look at
! it, and be honest.  I think "do loops" were deleted from Modula-2 in
! going to Oberon (an intentionally small language, like Sather), and
! reinstated after practical experience in Oberon-2.  A simple, very common
! concept deserves a simple, idiomatic statement.

It's very easy for me to be honest: that DO-loop looks awful. But I don't
think adding the DO-loop to Sather would solve more problems than it creates.
Should there also be for-, while-do-, do-while- and do-until-loops? A single
loop construct makes more easily readable code.

Also, in Sather a very common thing is a 'cursor' that goes through the
elements of a container class (like a list) in some order. The until-loop-end
style loop is very good for this. UNTIL we_have_gone_through_all_the_elements_
_in_this_container LOOP use_the_element_in_the_container END;

! Implied iteration and summation over repeated indices.  (a.k.a. Einstein
! summation convention).  It's a common notation in math and science--computer
! or no.

! E.g.  Vector A = Matrix B times vector C:
! 	A(i) = B(i,j)*C(j)
! or more explicitly

! 	"for all i" A(i) = "sum over j" B(i,j)*C(j).

! This concept subsumes nearly all of Fortran 90's matrix & vector operations.
! Explicitly parallel too.  In comp.lang.misc there was a long debate
! on this a couple of months ago.  Jim Giles also had the same position, and
! in fact I think his operation even designed specific extensions to Fortran
! to express this concept.  (In fact if I were to design an optimizer for
! an F90 compiler, I might want to internally represent array
! operations in this generalized form so I could write only 1 code generator).

! Despite what all the proponents of OOP say, either explicitly or by
! their textbook examples, I do *not* think that a class structure is the
! best solution for this problem (i.e. matrix and vector and tensor classes
! and overload the + and the - and the blah blah blah).  There's another soluti
on
! that's cleaner and more general, at least in the (important!) domain of
! array operations.

The array operations are important to you. To others they might not be 
so important. Furthermore, adding such constructs would change the language
radically. That seems a little too high price for not having to use objects
and redifine their methods/member functions/features.

No-one forces you to use an object-oriented language against your will.
--
...............................................................................
Ari Huttunen                               They say the sky high above
90-7285944                                   is Caribbean blue...  (Enya)


======================================================================= 72 ===
Date:    16 Jul 92 12:25:20 GMT
From:    ark@alice.att.com (Andrew Koenig)
Subject: Re: Proposed language changes

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

> Right now, C++ (2.1, 3.0) requires that I read about virtual and
> non-virtual base classes.  Without MI, these wouldn't be there.

Virtual base classes are part of MI.  A program that doesn't use MI
won't use virtual base classes either.

> Right now, C++ (2.0, 2.1, 3.0) lacks the ability to cast from a base
> type to a derived type in certain situations.

Those situations all involve virtual base classes.

> Right now, C++ (2.0, 2.1, 3.0) pretty much requires (but does not
> enforce) virtual destructors in certain single-inheritance
> situations.

This has nothing to do with MI.  You need a virtual destructor if
you use a base class pointer to delete a derived class object.
In this respect, operator delete is much like any other member function.

> Right now, C++ (same versions) lacks run-time type checking.

No fair complaining about parts of C++ that don't exist!  :-)
Seriously, I don't see why MI should make this any harder:
it is already necessary to figure out which virtual functions
to call and any run-time type information can use the same
mechanism as virtual functions.

> In the future, it might be nice to add garbage collection to C++.  I
> know it is easy to do a good garbage collection in a SI system, but
> I'm not sure of what the MI interactions are.  It does not simplify
> the garbage collector or make it faster (the offset pointers are the
> basic pain here.  References cause similar problems.)

I don't think it makes an awful lot of difference.  Again, it doesn't
seem to be any more difficult than getting the right information into
virtual function tables.

> I'm a little curious where all this goes with (say) persistent data,
> or pickled data, or dynamically loaded libraries.

This is getting a little off the point.  The original claim was that
`MI warps the language' and I asked for examples.  All of the above
examples are either integral parts of MI, which therefore cannot be
said to be effects on the rest of the language, or speculations about
things that do not currently exist.

> 1. MI makes the language bigger, even if I confine myself to a SI
>    subset.  (virtual base classes)

Virtual base classes are part of MI.

> 2. MI adds more rules that a SI user must follow.
>    (restrictions on down-casting; virtual destructors)

The first restriction applies only to programs using virtual base classes,
which art part of MI; the second is unrelated to MI.

> 3. MI may have delayed other useful features.
>    (run-time types)

Every feature delays other useful features.

> 4. MI may prevent other useful features from being implemented in
>    their most useful fashion.

I haven't seen any real evidence for this.
-- 
				--Andrew Koenig
				  ark@europa.att.com


======================================================================= 73 ===
Date:    Thu, 16 Jul 92 14:36:47 BST
From:    Grant "M." Friel <grant@cs.keele.ac.uk>
Subject: Problem compiling demos archive

I've just been trying to compile the demo programs for modula3-2.07.  columns
and tetris appear to be ok, but quite a few errors were reported when trying
to make solitaire.  It is reporting "missing file" and "number of actuals 
doesn't match number of generic formals" in most of the solitaire source files.
Am I doing something wrong?  (The trestle and bicycle libraries appear to
have been generated and installed ok)


I also got the following during the make process for both tetris and columns,
but both programs worked.   Is this safe to ignore or what ? 

ld: Undefined symbol
   _get_wmShellWidgetClass
   _get_applicationShellWidgetClass

Thanks in advance for any help.


Grant
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Email : (JANET)  grant@uk.ac.keele.cs
	      (BITNET) grant%cs.kl.ac.uk@ukacrl
	      (UUCP)   ...!uknet!kl-cs!grant
	      (other)  grant@cs.keele.ac.uk
+---------------------------------------------------------------------------+
 "We shall not cease from exploration, And the end of all our exploring will 
  be to arrive where we started and know the place for the first time."
                                        T.S. Elliot  (deep huh!)
+---------------------------------------------------------------------------+



======================================================================= 74 ===
Date:    16 Jul 92 10:54:51 GMT
From:    os102@cl.cam.ac.uk (Oliver Stephens)
Subject: Re: installing src m3

OK, shared libraries under SunOS.

The trick is to compile all the C files with -PIC (Position Independent Code),
then link to produce shared library object (linked with -assert pure-text to
make sure it is possible).

Below are two scripts which create shared library versions of libm3 and
libm3ui (trestle).  I am a third of the way through incoporating more general
code into m3make to do this stuff automatically on request: will post the
results.

As far as disc space goes, there is a minus in that you still need the
ordinary libraries present.  This is not as bad as it sounds because the shared
library is much smaller than the ordinary :

5416 -rw-rw-r--  1 os102     5531122 Jul 12 19:17 libm3.a
 456 -rw-rw-r--  1 os102      458016 Jul 12 19:16 libm3.ax
1512 -rwxrwxr-x  1 os102     1540096 Jul 12 20:34 libm3.so.1.1*

3024 -rw-rw-r--  1 os102     3085202 Jul 12 18:30 libm3ui.a
 272 -rw-rw-r--  1 os102      269321 Jul 12 18:28 libm3ui.ax
 832 -rwxrwxr-x  1 os102      843776 Jul 12 18:48 libm3ui.so.1.1*

And the advantages are great :

       m3            from 2809856 to  524288 bytes
       m3compiler    from 5332992 to 3072000 bytes
       replayheap    from 3899392 to  245760 bytes
       showthread    from 3940352 to  237568 bytes
       m3pp          from 1228800 to  180224 bytes
       miniformsedit from 1245184 to  245760 bytes (this uses shared library
                                                    versions of vbtkit and
                                                    miniformsvbt as well)

---+---+---+---+--- mklibm3-so.sh ---+---+---+---+---

#! /bin/csh -f

#
# Makes SunOS shared library version of libm3
# 
#   First make libm3.a, but with the -k flag, so that you can
#   keep the generated _m3lib.c.  You also need to do a preliminary make
#   to get the .PGM_SOURCES file.
#
#   set PREFIX variable in this script with the location of your
#   installed binaries (PREFIX in the config file), run this script in
#   libm3/SPARC, then install the resulting libm.so.1.1 in
#   PREFIX/lib/m3
#

set PREFIX=/usr

set m3src=`cat .PGM_SOURCES`

if (! -e .m3path) then
  cat > .m3path <<sdfsdf
-D../C/src/generic
-D../runtime/src/generic
-D../C/src/SPARC
-D../runtime/src/generic
-D../word/src
-D../runtime/src/generic
-D../thread/src/generic
-D../unix/src/ultrix-3-1.SPARC
-D../unix/src/ultrix-3-1.generic
-D../time/src
-D../runtime/src/generic
-D../rw/src
-D../thread/src/generic
-D../float/src/SPARC
-D../thread/src/generic
-D../random/src/generic
-D../float/src/generic
-D../float/src/SPARC
-D../float/src/generic
-D../float/src/SPARC
-D../float/src/generic
-D../float/src/SPARC
-D../C/src/SPARC
-D../runtime/src/SPARC
-D../thread/src/SPARC
-D../unix/src/ultrix-3-1.generic
-D../unix/src/ultrix-3-1.SPARC
-D../float/src/SPARC
-D../convert/src
-D../fingerprint/src
-D../text/src
-D../fmt/src
-D../inttable/src
-D../list/src
-D../main/src
-D../rw/src
-D../scan/src
-D../smallio/src
-D../smallos/src
-D../text/src
-D../time/src
-D../stable/src
-D../types/src
-D../reftable/src
-D../arith/src
-D../geometry/src
-D../statistics/src
-D../formatter/src
-D../parseparams/src
-D../uid/src
-D../property/src
-D../table/src
-D../pkl/src
-D../filename/src
-D../word/src
-D../perftool/src
-D../etimer/src
sdfsdf
endif

# Generate .c files:

m3 -make -why -commands -nostd -C -F.m3path -F.PGM_SOURCES

# Now compile to position indep code (so that we get sharable text at RT)

echo M3Runtime.c
rm -f x.c
ln -s ../Csupport/src/generic/M3Runtime.c x.c
cc -I$PREFIX/lib/m3 -O -c -PIC x.c
mv x.o M3Runtime.o

echo M3_BUILTIN.ic
rm -f x.c
ln -s ../Csupport/src/generic/M3_BUILTIN.ic x.c
cc -I$PREFIX/lib/m3 -O -c -PIC x.c
mv x.o M3_BUILTIN.io

echo dtoa.c
rm -f x.c
ln -s ../Csupport/src/SPARC/dtoa.c x.c
cc -I$PREFIX/lib/m3 -I../Csupport/src/generic \
	-I../Csupport/src/SPARC -O -c -PIC x.c
mv x.o dtoa.o

# should use m3src
foreach  i (*.mc)
	echo $i
	rm -f x.c
	ln -s $i x.c ; cc -I$PREFIX/lib/m3 -O -c -PIC x.c
	mv x.o `basename $i mc`mo
end

foreach  i (*.ic)
	echo $i
	rm -f x.c
	ln -s $i x.c ; cc -I$PREFIX/lib/m3 -O -c -PIC x.c
	mv x.o `basename $i ic`io
end

cc -I$PREFIX/lib/m3 -O -c -PIC _m3lib.c

ld -o libm3.so.1.1  -assert pure-text *.?o *.o

---+---+---+---+--- mktrestle-so.sh ---+---+---+---+---

#! /bin/csh -f

# From David Goldberg (goldberg@parc.xerox.com)
# Hacked about by Dave Evers (dme@cl.cam.ac.uk) 25/5/92.
# Makes SunOS shared library version of trestle
# 
#   First make libmui3.a, but with the -k flag, so that you can
#   keep the generated _m3lib.c.  You also need to do a preliminary make
#   to get the .PGM_SOURCES file.
#
#   set PREFIX variable in this script with the location of your
#   installed binaries (PREFIX in the config file), run this script in
#   trestle/SPARC, then install the resulting libm3ui.so.1.1 in
#   PREFIX/lib/m3

set PREFIX=/usr

set m3src=`cat .PGM_SOURCES`

if (! -e .m3path) then
  cat > .m3path <<sdfsdf
-D$PREFIX/include/m3
-D.
-D../src/splitm3
-D../src/vbtm3
-D../src/trestlem3
-D../src/xvbtm3
sdfsdf
endif

m3 -make -why -commands -C -F.m3path -F.PGM_SOURCES -lm3X11R4

# should use m3src

foreach  i (*.mc)
	echo $i
	rm -f x.c
	ln -s $i x.c ; cc -I$PREFIX/lib/m3 -O -c -PIC x.c
	mv x.o `basename $i mc`mo
end

foreach  i (*.ic)
	echo $i
	rm -f x.c
	ln -s $i x.c ; cc -I$PREFIX/lib/m3 -O -c -PIC x.c
	mv x.o `basename $i ic`io
end

cc -I$PREFIX/lib/m3 -O -c -PIC _m3lib.c

ld -o libm3ui.so.1.1  -assert pure-text *.?o _m3lib.o

-------------------------------------------------------------------------
Olly Stephens                                oliver.stephens@cl.cam.ac.uk
Computer Laboratory
University of Cambridge    Loved you there and then, and now like a sheep
United Kingdom                                             - Van Morrison


======================================================================= 75 ===
Date:    16 Jul 92 21:08:06 GMT
From:    olender@vivaldi.cs.colostate.edu (Kurt Olender)
Subject: Academic use of Modula-3?


We have been thinking about alternatives to Pascal for the primary teaching
language in our coursework at Colorado State.  Modula-3 is one option.

1. Are there any other academic institutions using Modula-3?
2. Are there any PC or Macintosh based implementations planned
   that anyone knows about?
3. Are there any textbooks for introductory level courses (CS-1, Data
   structures, etc) existing or planned that use Modula-3?

Thanks for whatever information you can provide.


======================================================================= 76 ===
Date:    17 Jul 92 16:36:57 GMT
From:    bs@alice.att.com (Bjarne Stroustrup)
Subject: Re: Proposed language changes



chased@rbbb.Eng.Sun.COM (David Chase @ Sun Microsystems, Mt. View, Ca.)

 > Right now, C++ (2.0, 2.1, 3.0) pretty much requires (but does not
 > enforce) virtual destructors in certain single-inheritance
 > situations.  As you can see already, I don't recall quite when that
 > is, and this is a bug.  I believe this weird requirement is a
 > consequence of multiple inheritance (same as above -- an offset "this"
 > pointer).

Since you don't quite recall what the problem is I can't quite be specific,
but I see no such problem.

 > Right now, C++ (same versions) lacks run-time type checking.  I don't
 > know why it doesn't have it, but I do know that it is more difficult
 > to define, implement, and explain this in the presence of multiple
 > inheritance.  Having implemented this in the past for a language with
 > single inheritance, I know that it is not terribly hard in that case.
 > This is an example of where the addition of one feature may have
 > prevented/delayed the addition of another feature.

That is pure conjecture, and wrong. C++ was designed without run-time
type information mechanisms because I disliked the effect of their use
in Simula programs. When I was convinced that having such mechanisms
was less trouble than not having them I implemented it in two morning's
of real time, about 4 hours of solid work. The amount of code needed
(combined compiler and run-time support code is less than 150 lines
of C++).

 > In the future, C++ may have some form of run-time type-checking.  In a
 > language with single inheritance (like Modula-3) this can be
 > implemented in a way that it requires a constant amount of time to
 > perform any type check, and log(#cases) time to execute a typecase
 > statement (with arbitrary depth in the cases and the type tree).  Will
 > C++'s versions of these statements have similar efficiency, assuming
 > that I don't use multiple inheritance?  (I've been trying to figure
 > out how one might search the DAG quickly, but haven't had the time to
 > really make much progress.)  This is an example of where the addition
 > of one feature may have prevented the best presentation or
 > implementation of another feature.

Maybe, but that again is conjecture. The dumb and easy implementation of
a downcast involves n-1 calls of a trivial recursive function where n is
the distance betwwen the static type of the object and the desired static
type.



======================================================================= 77 ===
Date:    Fri, 17 Jul 92 21:08:37 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Proposed langauge changes / MI

In article l63uruINNl6m@exodus.Eng.Sun.COM, chased@rbbb.Eng.Sun.COM (David Chas
e) writes:
>In article <1992Jul9.154716.7869@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.in
formatik.rwth-aachen.de writes:
>>Since you mentioned the MI thing again: I still don't see any problem with
>>it.
>
>There's a couple of problems -- sorry if I didn't go into details.
>
I think that we should discuss exactly those details (instead of personal
opinions about "good" or "bad" language features).

So, before I deal with your points, let me point out what kind of MI I would
support.

- A may inherit from B and C only if B and C themselves are subtypes of D. This
  does not only solve some of your problems, it also forces the designer to
  think about common properties of B and C. This improves reusability, data
  abstraction etc. If this restriction forces you to include a class which
  seems "artificial", you are probably composing two classes which should not
  be composed (just because they have nothing in common).

- A should have only one copy of D's data fields. I can't think of any problem
  where you would like to have two copies (one from B, one from C). This is
  likely a case where an OBJECT b:B; c:C; END; should be used.

- If there are name clashes between data fields in B and C, these should be
  resolved internally. Everything else will interfere with data abstraction.

- Methods from D, which are redefined differently in B and C, have to be redefi
ned
  in A. This can be checked statically.

>(1) Define the semantics of TYPECASE (which case is chosen?)
>
I agree, this is a problem. One simple solution comes into my mind: For A, B, a
nd
C, TYPECASE would only select D. This is not very satisfying, although it does
fit into the existing language. TYPECASE in general is a statement only useful 
in
SI systems. But this is not a fault of MI. If you would include a feature into
some language which would not allow, let's say, pointers, does this imply that
pointers are not useful?
To me, TYPECASE is a construct for easy handling of objects with a "variant REC
ORD"
semantics (correct me if I'm wrong). Such objects are SI by nature. My proposal
 for
a modified TYPECASE still allows such usage.

>(2) Can we add MI without slowing down SI?  (This is a trick
>    question, because you need to worry about both current
>    (sleazy compilers) and future (good compilers) performance.)
>
Who knows? I'd like to take a chance. Many features, which are common today, we
re
regarded as "unimplementable" some years ago (and some still are, look at
the discussion about garbage collection in comp.lang.object). Most other OO
languages have it, so it shouldn't be that bad.

>(3) MI has some weird interactions with opaque supertypes.
>    Suppose you get something like (pardon my mangling of the
>    syntax):
>
>    TYPE X <: OBJECT;
>    TYPE Y <: OBJECT;
>
>    A = X OBJECT METHODS ... END;
>    B = Y OBJECT METHODS ... END;
>
>    C = A,B OBJECT METHODS ... END;
>
>    Now, what if it turns out that X and Y actually share
>    a common ancestor?  Are the data fields and methods shared, or no?
>    (sharing is not consistent with encapsulation -- my conclusion is
>    that sharing should not occur in this case.  However, for mix-ins
>    it appears that sharing is what you want.  One resolution is to
>    only allow sharing to occur when it is not hidden.  However, I
>    don't know if this can be done in a consistent and reliable
>    fashion; what happens if there are multiple views of the objects
>    involved?)
>
Well, I've answered this already. I think they should be shared. Why does this
interfere with data abstraction? B and C (in my example) may act upon D's data
only through D's methods. This should assert the integrity of D's data. B and C
offer methods to change their own data, as well as modified or complex combinat
ions
of D's methods. So data hiding is supported (am I missing a point?).
The only problem I do see here is that A has to know that B and C both inherit
from D. But then: according to my proposal, if A may inherit from B and C, it
already knows that there *has* to be some common ancestor of B and C. A should 
be
aware of this, because it makes A itself a subclass of D. But this is not so
very different from SI: If A is a subclass of B and B of C, then A also knows
that it's a subclass of C. Otherwise, it can't use C's methods and the inherita
nce
is useless.

>(4) How does narrow work in the presence of repeated inheritance?
>    (a) what is the right answer?
>    (b) can we implement this efficiently?
>
>    That is, suppose you have:
>
>    TYPE X <: OBJECT;
>
>    A = X OBJECT METHODS ... END;
>    B = A,X OBJECT METHODS ... END;
>
>    C = A,B OBJECT METHODS ... END;
>
>    Suppose I narrow an "X" to an "A", given that what I've really got
>    is a C.  Which one?  How efficient is "NARROW" now?
>
This is not allowed in my proposal, because there is no common superclass for
A and X. Besides, I can't see any sense in this class hierarchy.

>(5) Discover and document any remaining semantic/implementation
>    gotchas.
>
Yes.

>My concern about efficiency may seem misplaced, but if what you're
>after is flexibility with no major concern for performance, you can
>get that already from CLOS.  (And yes, I am *very* interested in
>Dylan, which I am told is something like Scheme+CLOS.)
>
I don't see any efficiency drawbacks from MI. Of course, there is more work
to do for the compiler. But how does it affect execution speed?

>Comparisons with bullet-items on the C++ Real-Soon-Now list are also
>unfair.  It could be that they are unimplementable, or come with
>horrible interactions, or maybe there is more sizzle than steak (e.g.,
>maybe the feature is "provided" but in a useless fashion).
>
You're right. But nevertheless, M3 has to compete with C++ and others. And, as 
I
stated in some earlier posting, if you want people to use M3 instead of C++ (or
Sather, Eiffel, ..., all of which *have* MI), you have to give them some *real*
good reasons why M3 hasn't MI. I'm not convinced yet. But any suggestions are
welcome.

---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany



======================================================================= 78 ===
Date:    17 Jul 1992 23:04:58 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: Proposed language changes / comparisons

>In article <l699aiINNc43@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Ch
ase) writes:
>>

In article <23185@alice.att.com> ark@alice.UUCP () writes:
>
>No fair complaining about parts of C++ that don't exist!  :-)

No, exactly fair.  Time spent designing and implementing multiple
inheritance is time not spent doing other things.  This may not be
what you thought "warping the language" means, but it is good enough
for me.

>> [run-time type-checking]

>Seriously, I don't see why MI should make this any harder:
>it is already necessary to figure out which virtual functions
>to call and any run-time type information can use the same
>mechanism as virtual functions.

I think you are being a bit glib here.  For a single-inheritance type
system, the virtual function tables contain a constant amount of
additional information describing the position of a type in a type
tree (the technique described in a letter in TOPLAS recently is
inferior).  To determine if type A is an ancestor of type B, it
suffices to know that lr_pre_number(A) <= lr_pre_number(B) and that
lr_post_number(A) >= lr_post_number(B).  See Paul Dietz, "Maintaining
Order in a Linked List", STOC 1982.  For single inheritance, we're
talking about one word per VFT to a type descriptor, and each type
descriptor can contain as little as two words encoding pre- and
post-order numbers.  I'm pretty sure it is not this simple for
multiple inheritance.

On the other hand, the TOPLAS technique seems like it could be hacked
to work for MI.  The space cost goes up (O(max inheritance depth) per
VFT, I think), but the time cost stays low (assuming that the hack
works, of course).  I'm not sure what happens if a new type is loaded
into a running system, since it could increase the inheritance depth,
and thus require changing the sizes of the VFTs.

The problem gets worse if you consider TYPECASE (if you choose to
implement it).  Using techniques described in the Dietz paper, you can
implement typecase for single inheritance to run in O(log # cases)
time, with O(#cases) space cost.  For multiple inheritance?  (Again,
I'd love to be enlightened.)

>> 4. MI may prevent other useful features from being implemented in
>>    their most useful fashion.

>I haven't seen any real evidence for this.

It's difficult to prove this, but I'll try a comparison with Modula-3.

The Olivetti M-3 implementation required < 10 people-years to obtain
roughly cfront functionality, PLUS garbage collection, PLUS automatic
makefile generators and dependency checkers, PLUS (an instance of) an
interpreter, PLUS automatic generation of marshalling code, PLUS a
compiler-server (cached interface files, a big win), PLUS run-time
types, PLUS a skeleton AST system used to build pretty printers and
implementation stub generators, PLUS a threads library (briefly ported
to multi-threaded Mach on a '386 before Olivetti shut the lab down --
presumably, we were insufficiently productive :-).  Like C++, we
churned through a couple of versions of the language in the process.
Like C++, we targeted multiple archictectures.

(Note that there are several interesting language tools in the list,
as opposed to "language features".)

Now, compare this with what has appeared for C++, a language of much
greater commercial significance.  Either the crew at Olivetti (some
working part-time, some also writing papers, some working on another
continent) was phenomenally good, or else we were working on a much
easier problem.  I'd like to think that we were good, but we weren't
that good.  It's been two years since I last worked on Modula-3,
and presumably more than 10 people-years have been spent since then
(at various software houses) improving C++ and building tools, and
that's on top of whatever was already available in 1990.  Where's the
goodies?  *Something* has prevented those other features from
appearing.  (To be fair, I'm certain that backward semi-compatibility
with C is the biggest obstacle.)

David Chase
Sun


======================================================================= 79 ===
Date:    17 Jul 1992 23:31:16 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: Proposed language changes

In article <23207@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>chased@rbbb.Eng.Sun.COM (David Chase @ Sun Microsystems, Mt. View, Ca.)
> > In the future, C++ may have some form of run-time type-checking.  In a
> > language with single inheritance [this is cheap]. ... Will
> > C++'s versions of these statements have similar efficiency, assuming
> > that I don't use multiple inheritance?  
> >This is an example of where the addition
> > of one feature may have prevented the best presentation or
> > implementation of another feature.

>Maybe, but that again is conjecture. The dumb and easy implementation of
>a downcast involves n-1 calls of a trivial recursive function where n is
>the distance betwwen the static type of the object and the desired static
>type.

"Trivial" is not necessarily cheap, depending upon the shape of the
type DAG and the dynamic frequency of type checks (*).  It is also a
bit worrying (as a potential future user of RTTI in C++) that the best
refutation available to my inefficiency fears is "that again is
conjecture".  This implies that a feature is being added to the
language without a clear handle on the costs of its use (because if
you had a cost estimate, if it was any good, you could remove my fears
and make me look like an ignoramus by revealing the efficient
algorithm, instead of by saying "conjecture".  Therefore I must
conclude that no good time bound is known).

Is this good language design?  (Unfair question -- given that MI has
already been added, it is almost impossible to remove.  Since RTTI is
necessary, it must also be added, and let the costs fall where they
will.  However, this supports the assertion "MI has warped the
language", if one believes that RTTI is more important than MI, or if
one believes that the wrong kind of MI was chosen w/o taking the needs
of an important feature like RTTI into account.)

(*) I believe Mick Jordan has reported substantial speedups in his AST
system by making all the types visible and "flattening" the TYPECASE
statements into ordinary switch statements.  The last time I was near
M-3, TYPECASE and NARROW were implemented using the algorithm
Stroustrup describes, since (as noted in Stroustrup's post) that is
the easy way to do it.  This is evidence that trivial is not
necessarily cheap.

David Chase
Sun


======================================================================= 80 ===
Date:    Fri, 17 Jul 92 21:24:32 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Proposed langauge changes / MI

>One simple solution comes into my mind: For A, B, and
>C, TYPECASE would only select D.

Sorry, this is nonsense. I meant: D should only select A. If both B and C are
given, but not A, the ELSE-case is chosen.
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany



======================================================================= 81 ===
Date:    18 Jul 92 01:03:48 GMT
From:    mbk@lyapunov.ucsd.edu (Matt Kennel)
Subject: Sather's Multiple Inheritance

The more I read about it, the more I like way Sather does inheritance:
simply and easily.  ("Omit needless brain" :-) )

I'll quote from it's manual:
============
3.2 Inheritance

A class "A" inherits the features of another class "B", when the name
"B" appear's in A's feature list.  We say that B is a parent class and
that A is a child.   The semantics is exactly as if the features of
B were textually copied into A at the point the name appears.  Any
references that appear in the inherited feature definitions will be
resolved in the new namespace.  Later features in a class with
the same name as earlier ones override the earlier definitions.
This means that the order in which classes are inherited can have
an effect on the meaning.  A class may inherit from many other classes.
{And then,  "you can't have cycles in the inheritance graph"---my
paraphrase}
===============

That's it!  (well almost...see below)


I.e. you do:

class CHILD is

	PARENT_CLASS_ONE;	--- That inherits one class
	PARENT_CLASS_TWO;	--- That inherits another

	new_variable : INT;	--- A new feature of this class

	new_method is
		---  a new method for this class
	end;
end;


Now what if both PARENT_CLASS_ONE and PARENT_CLASS_TWO
have two features, say integer variables "count":

Then you can use "alias new_name old_name":
===========
class CHILD is

	PARENT_CLASS_ONE;	--- That inherits it
	alias count_one count;	--- rename "count" from P_C_O
	PARENT_CLASS_TWO;	--- That inherits another
	alias count_two count;	--- Rename that one as well

	count : INT;		--- A third "count" different from the
				--- other two.

	new_variable : INT;	--- A new feature of this class

	new_method is
		---  a new method for this class
	end;
end;
============


I don't know if this solution is perfect for all circumstances, but it
appears to a layman to cover a whole lot, and it's very easy to understand.

Does OOP help real productivity if you have to spend a tremendous amount of
brainpower on figuring out the rules of the language?  I don't think so---
only the real geniuses with a mind for pedantic detail can be more
productive, but they were the most productive to begin with anyway.

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego


======================================================================= 82 ===
Date:    18 Jul 92 15:54:25 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Proposed langauge changes / MI

Peter suggests that if D inherits from B and C, then B and C must share a
common ancestor A. This condition is trivially satisfied - ROOT is the
anscestor of all OBJECT types. Peter, I think perhaps you have a different and
stronger condition in mind. Could you try to articulate it? I don't think
requiring B and C to have the same immediate ancestor is general enough, and I
think saying they have to have a common ancestor other than ROOT requires more
defense -- MI ought to allow one to combine completely orthogonal types if
that's useful, shouldn't it? Why is it wrong to do so? You seem to have a
style or idiom in mind that I have not been able to derive from what you've
said so far ....
--

		J. Eliot B. Moss, Associate 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


======================================================================= 83 ===
Date:    18 Jul 92 16:36:30 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Sather's Multiple Inheritance

Matt describes Sather's MI aproach from the Sather manual. From that
description, it sounds as if Sather does not support encapsulation (or, at
least, opaque supertypes) to hide stuff from most subtypes. Once you have
opaque supertypes, you have a worse problem with name clashes -- you can't
know what's going to clash! (Because you can;t know what's in a supertype.)
Sounds to me as if Sather flattens the types out completely, which will
interfere with building large system, by undermining encapsulation.
--

		J. Eliot B. Moss, Associate 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


======================================================================= 84 ===
Date:    Sat, 18 Jul 1992 18:32:28 GMT
From:    mday@jukebox.lcs.mit.edu (Mark Day)
Subject: Re: Proposed langauge changes / MI

   pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) writes:

   You're right. But nevertheless, M3 has to compete with C++ and others.
   And, as I stated in some earlier posting, if you want people to use M3
   instead of C++ (or Sather, Eiffel, ..., all of which *have* MI), you
   have to give them some *real* good reasons why M3 hasn't MI. I'm not
   convinced yet. But any suggestions are welcome.

Some people have been so burned by MI in C++ that they consider it a
good thing to leave out of a language.  So it's not obvious to me that
you have to have MI to "compete" with C++ and company.

--Mark Day

mday@lcs.mit.edu



======================================================================= 85 ===
Date:    18 Jul 92 16:30:17 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Speed of TYPECASE (was Re: Proposed Language Changes)

The SRC compiler uses the following technique (I may be paraphrasing a bit,
but I think it captures the essence):

	Take the tree of types and walk it in a depth first manner. Using a
	global counter, drop numbers off at the nodes, as follows. For an
	internal node, drop one number off before visiting the children and
	another afterwards; for leaves, simply drop off one number. The type
	code of a type is simply the first number dropped at the trees node in
	the tree.

TYPECASE consists of taking the typecode of the item being cased and seeing,
for each arm in sequence, if the typecode falls within the range allowed for
the arm. If the arm is a leaf type, then there is only one possible value; if
the arm is an internal node, then there is an upper and lower bound.

A simple implementation would consist of a series of IF tests, each testing
either equality or two bounds.

Almost any implementation must special case NIL since it is generally not
represented as a pointer to a thing that can supply a type code. I will assume
that that is done first, before any IFs or CASEs.

In SI at least, the order of the cases can be removed by getting rid of later
cases that are covered by earlier ones (which I think is an error anyway
(don't have my M3 book here)). So we can break it all down into ranges of
typecodes and case arms that go with them; a given arm may have several
ranges, since earlier arms may handle subtypes. Anyway, given this viewpoint,
it is easy to see that an O(arms) linear search can be turned into an
O(log(arms)) binary search or, by listing each individual type code in the
range of interest, into an O(1) indexed branch.

Now Mick can correct me, but I recall discussing this with him a bit at the
time of the MUG, so even some details are a little off, I think I can clarify
the general point: if you know all the types involved, you can build the type
tree and know the type codes at compile time, and turn the sequential-IF
implementation of TYPECASE into a CASE statement, which could result in a
switch statement in the code output by the SRC compiler (though I am not sure
that it actually *does* result in a switch in C; the SRC compiler may insist
on deciding how to carry out the CASE that Mick builds).

This is an interesting argument in favor of the type numbering, etc., used by
the SRC system, which is different from what we've design for the GNU system.
I believe that we test TYPECASE arms sequentially, using a different narrowing
test. We consider the depth of the two types in the tree. Let's call the
(allocated, not static) type of the object the *source* type, and the type we
are trying to narrow to the *destination* type. The destination type's depth
(distance from the root) in the type tree must be <= the source type's depth,
and the source type's supertype at the depth of the destination type must be
exactly the destination type. So we have a <= test of a variable against a
compile-time known constant, and an equality test of a variable against a
constant (we store the vector of supertypes somewhere easily accessible from
the type). The advantage of our system is that types can be added without
affecting the actual tests in any way. We think this may be important for
persistent systems, where new subtypes may be added (and code for them loaded
dynamically from the store) after a program is compiled. Hence, the type tree
of the SRC approach is not static, and their approach breaks down. We can
probably still come up with an O(log(arms)) implementation of our scheme; it
is just hard to do it O(1) in the face of a type tree growing dynamically.

All of this breaks down in the MI setting. I can't think of an O(1) narrow
test, much less an O(log(n)) TYPECASE test, that is at all space efficient and
that works in the face of dynamically growing type DAGs. Some of the folks
with the logic language project at MCC (I think Hassan Ait-Kaci was one) did
some work on making DAG narrow tests efficient, but I believe they assumed a
static DAG so you could do a bunch of precomputation.

It may turn out that the way to do it is to use a potentially expensive
algorithm to check subtypes, and to do one or more kinds of caching to save
the results. For example, each TYPECASE statement could have a fixed size
cache (organized as a hash table, of course) to say which arm to use for some
recently presented types. This may well turn out to be expected O(1) for most
programs. If the cache size is 1, this is similar to the inline method cache
idea -- if the type is the one we know about, go to the location recorded,
otherwise do the more painful technique and update the cache. (If you go
implement this and got the idea from me, don't forget to give me credit :-).
--

		J. Eliot B. Moss, Associate 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


======================================================================= 86 ===
Date:    Sat, 18 Jul 92 20:14:36 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: how do I get the modula3 revised report?

In article <6004@otc.otca.oz>, johng@otc.otca.oz.au (John Gibbons) writes:
|> Is the modula-3 revised report available over the net?

No, you have to get:

	System Programming with Modula-3
	Edited by Greg Nelson
	Prentice Hall Series in Innovative Technology
	ISBN 0-13-590464-1
	L.C. QA76.66.S87 1991

also known as SPwM3.

-- 
Eric.


======================================================================= 87 ===
Date:    18 Jul 92 20:39:36 GMT
From:    ark@alice.att.com (Andrew Koenig)
Subject: Re: Proposed langauge changes / MI

In article <MDAY.92Jul18133228@jukebox.lcs.mit.edu> mday@jukebox.lcs.mit.edu (M
ark Day) writes:

> Some people have been so burned by MI in C++ that they consider it a
> good thing to leave out of a language.  So it's not obvious to me that
> you have to have MI to "compete" with C++ and company.

Whom are you thinking of, aside from Tom Cargill?

Note that at various times, Tom has also called for removing
constructors and overloaded operators from C++.  Moreover, I don't
think he's actually been burned from it; he just doesn't think
it is useful.
-- 
				--Andrew Koenig
				  ark@europa.att.com


======================================================================= 88 ===
Date:    Sat, 18 Jul 92 20:25:02 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Thread Aqcuire and Release problem

In article <1992Jul13.090145.1005@cs.ruu.nl>, Harald Vogt asks about threads.

Your program is illegal.  SPwM3, p70, describes Thread.Release:

	PROCEDURE Release (m: Mutex);
	  The calling thread must have m locked.  Unlocks m.

The precondition is not respected by your program.  We have introduced
an explicit check of the precondition (to help find bugs in the
implementation), which explains the difference of behaviour with the
previous releases.  You should normally get some message from the
runtime; I don't know why you did not get one.

-- 
Eric.



======================================================================= 89 ===
Date:    Sun, 19 Jul 1992 01:27:25 GMT
From:    rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Subject: Re: Sather's Multiple Inheritance

Eliot Moss:
   Matt describes Sather's MI aproach from the Sather manual. From
   that description, it sounds as if Sather does not support
   encapsulation (or, at least, opaque supertypes) to hide stuff from
   most subtypes. Once you have opaque supertypes, you have a worse
   problem with name clashes -- you can't know what's going to clash!
   (Because you can;t know what's in a supertype.)  Sounds to me as if
   Sather flattens the types out completely, which will interfere with
   building large system, by undermining encapsulation.

>From what I read, you can get opacity by the simple expedient of
masking the detail you want hidden with a later namespace conflict.
You can see the names, but the original definitions are shadowed from
the point where you see those names.

Similarly, it doesn't seem matter if you don't know the details of a
superclass.  As long as they're visible from the points that need to
know about them, things are ok.

The question I'd have, about Sather, is how simple is it to express
dynamically structured data?  If it's difficult to express such data,
you'll have to resort to fancy footwork to express otherwise simple
concepts.  [This naming stuff is, obviously, not dynamic.]

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
The U.S. government went another thousand million dollars into debt today.


======================================================================= 90 ===
Date:    19 Jul 1992 19:20:59 GMT
From:    mbk@lyapunov.ucsd.edu (Matt Kennel)
Subject: Re: Sather's Multiple Inheritance

rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
: Eliot Moss:
:    Matt describes Sather's MI aproach from the Sather manual. From
:    that description, it sounds as if Sather does not support
:    encapsulation (or, at least, opaque supertypes) to hide stuff from
:    most subtypes. Once you have opaque supertypes, you have a worse
:    problem with name clashes -- you can't know what's going to clash!
:    (Because you can;t know what's in a supertype.)  Sounds to me as if
:    Sather flattens the types out completely, which will interfere with
:    building large system, by undermining encapsulation.
: 
: From what I read, you can get opacity by the simple expedient of
: masking the detail you want hidden with a later namespace conflict.
: You can see the names, but the original definitions are shadowed from
: the point where you see those names.

I don't know what quite you mean, but there's the "private" attribute:

"Any feature definition may be preceded with the keyword "private".
 Only routines defined within the class itself may access such features.
 Private features will also be private in any classes which inherit them.
 ...A common exasmple is to define an attribute as private and to provide
 a routine which returns its value.  This keeps other classes from changing
 the value while still allowing them to read it."


: Similarly, it doesn't seem matter if you don't know the details of a
: superclass.  As long as they're visible from the points that need to
: know about them, things are ok.

I don't think I quite know the whole story here, but my opinion is that
if you're inheriting a class, then you're on the "implementation" side
of things and so it's OK to know the details.

If you want to be on the "user" side of things, then just include an object
of the pseudo-parent class as a feature of your new class and you can use it
like any other object.

I guess I don't quite understand the point of having a type that you
can inherit from 

: 
: The question I'd have, about Sather, is how simple is it to express
: dynamically structured data?  If it's difficult to express such data,
: you'll have to resort to fancy footwork to express otherwise simple
: concepts.  [This naming stuff is, obviously, not dynamic.]

What exactly do you mean here?  Do you mean say a routine that could
take an object of that could be any one of a few different types?

I think in that case you'd have to define a "superclass" from which
any of the possible subclasses are derived and then declare the routine
to take an argument of type 'superclass', but operates with dynamic runtime
dispatching.

This is dogma in most object-oriented languages, right?  

Though actually
in Sather you can manually find out the "type" of any random object:
( I guess the only allowed operations are equality and inequality on this. )
===============
5.5  The type attribute.

All classes have a predefined constant attribute named "type".  Its
value belongs to CLASS_TYPE, a descendent of INT, and equals the tag
on objects used to identify the class.  It is useful in constructs such
as "if a.type = FOO::type then ..."
===============

Class relationships are trees, whether for better or worse. (Why not
general "bags"?)

: -- 
: Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
: The U.S. government went another thousand million dollars into debt today.

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego


======================================================================= 91 ===
Date:    Sun, 19 Jul 92 21:45:52 -0700
From:    <gnelson@src.dec.com>
Subject: Re: Does NEW() accept positional bindings for OBJECTS?


David Brumley asks:

Page 46 of _SPwM3_ shows a generic stack module:

GENERIC MODULE Stack (Elem);
  REVEAL
    T = BRANDED OBJECT n: INTEGER; a: REF ARRAY OF Elem.T END;

  PROCEDURE Create(): T = BEGIN RETURN NEW(T, 0, NIL) END Create;
  ...

Can a new T be initialized this way?  

The answer is no; the book is in error. The NEW 
expression should be

    NEW(T, n := 0, a := NIL).

The error was corrected in the second printing.

Greg


======================================================================= 92 ===
Date:    Mon, 20 Jul 1992 03:06:31 GMT
From:    maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Sather's Multiple Inheritance

>
>Class relationships are trees, whether for better or worse. (Why not
>general "bags"?)
>
	no, in C++ they're DAGS. Completely new opportunities
arise with MI.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------


======================================================================= 93 ===
Date:    Mon, 20 Jul 92 02:06:32 PDT
From:    surak!frode (Frode Odegard)
Subject: inheritance

mbk@inls1.ucsd.edu <Matt Kennel> writes:

> [..]
> I don't think I quite know the whole story here, but my opinion is that
> if you're inheriting a class, then you're on the "implementation" side
> of things and so it's OK to know the details.
> [..]

When you design a class you should take care in defining both the interface to
clients, i.e. users of the class as well as to subclassees.  Ideally you should
be able to change the internals of a class and make few, if any, changes to you
r
subclasses.  Interfaces and partial revelations help - see the stream classes i
n
libm3.

(Under NeWS I didn't like to directly modify instance variables declared in
superclasses.)

				- Frode <* reply-to: frode@odegard.com *>

--------------------------------------------------------------------
Odegard Labs, Inc., 100 Bush St., Suite 625, San Francisco,
CA 94104-3909, USA; +1-415-434-4242, +1-415-434-4243(fax),
frode@odegard.com(internet)




======================================================================= 94 ===
Date:    19 Jul 1992 18:54:40 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: Sather's Multiple Inheritance

In article <MOSS.92Jul18123630@ibis.cs.umass.edu> moss@cs.umass.edu writes:
>Matt describes Sather's MI aproach from the Sather manual. From that
>description, it sounds as if Sather does not support encapsulation (or, at
>least, opaque supertypes) to hide stuff from most subtypes. Once you have
>opaque supertypes, you have a worse problem with name clashes -- you can't
>know what's going to clash! (Because you can;t know what's in a supertype.)

My reading may be wrong, but I didn't read it quite that way.  I read
that a redeclaration of a name merely hides the former declaration of
the name.  The clause about "as if substituted in place" also makes
this work, because it means that hidden sharing is not possible.  That
is, given (opaque or not) (pardon the mutilated syntax):

  A = OBJECT ...0 END;
  B = A OBJECT ...1 END;
  C = A OBJECT ...2 END;
  D = A,B,C OBJECT ...3 END;

what you've really got is:

  D = OBJECT ...0 END (* A *)
      OBJECT ...0 END OBJECT ...1 END (* B *)
      OBJECT ...0 END OBJECT ...2 END (* C *)
      OBJECT ...3 END;

The scoping rules mean that the repeated declarations of A are
harmless (though in this case, the leading declaration of "A" is
somewhat useless), and the "as if substituted" rules mean that B and C
do not share the data or methods of their common ancestor "A".  This
means that the ancestor can be hidden w/o ill effect.

There is one problem with this, which is that (as I understand it)
there are idioms of MI that profit very much from shared methods and
data.  However, these idioms apparently require that the sharing be
visible for it to be useful, so maybe it is possible to cut this both
ways (sharing and opaque supertypes interact in some sane way that
allows encapsulation and the useful idioms).

However, we're still stuck with broken typecase, at least until
someone figures out how to make it go fast again.

One thought problem: if MI is used, is TYPECASE quite so necessary?

David Chase
Sun


======================================================================= 95 ===
Date:    Mon, 20 Jul 1992 09:25:48 GMT
From:    Ari.Huttunen@hut.fi (Ari Juhani Huttunen)
Subject: Re: Sather's Multiple Inheritance

In article <147qlkINNft3@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) 
writes:

! Now what if both PARENT_CLASS_ONE and PARENT_CLASS_TWO
! have two features, say integer variables "count":

! Then you can use "alias new_name old_name":
! ===========
! class CHILD is

! 	PARENT_CLASS_ONE;	--- That inherits it
! 	alias count_one count;	--- rename "count" from P_C_O
! 	PARENT_CLASS_TWO;	--- That inherits another
! 	alias count_two count;	--- Rename that one as well

! 	count : INT;		--- A third "count" different from the
! 				--- other two.

! end;
! ============

! I don't know if this solution is perfect for all circumstances, but it
! appears to a layman to cover a whole lot, and it's very easy to understand.

You still have the problem that CHILD, PARENT_CLASS_ONE and PARENT_CLASS_TWO
refer to the same 'count' each, unless you re-rewrite the functions in
the parent classes. (In some cases this would be desirable, in others it
would not.)

The problem would be solved, if this were possible: 'rename count_two count'.
--
...............................................................................
Ari Huttunen                               They say the sky high above
90-7285944                                   is Caribbean blue...  (Enya)


======================================================================= 96 ===
Date:    20 Jul 92 09:04:02 GMT
From:    Ari.Huttunen@hut.fi (Ari Juhani Huttunen)
Subject: Re: Sather's Multiple Inheritance

>Eliot Moss:
>   Sounds to me as if
>   Sather flattens the types out completely, which will interfere with
>   building large system, by undermining encapsulation.

Well said. That is my understanding also. But the front page of Sather
manual says that large systems are not intended to be built with Sather.
(No, I don't think it is a good policy either.)

"Abstract. This report describes the object-oriented programming lan-
guage Sather. Sather is a simplified, optimized variant of Eiffel (Sather 
tower is a landmark in Berkeley). It is meant to be a working language, 
focussed on the practical needs of writing efficient, reusable code. It is 
designed for individual researchers or small groups and eliminates fea-
tures which are pedantic, of purely theoretical interest, or necessary 
only for large or naive programming teams. Sather has clean and sim-
ple syntax, parameterized classes, object-oriented dispatch, multiple in-
heritance, strong typing, and garbage collection. It generates efficient C 
code which is easily integrated with existing code. "

Rockwell:
>From what I read, you can get opacity by the simple expedient of
>masking the detail you want hidden with a later namespace conflict.
>You can see the names, but the original definitions are shadowed from
>the point where you see those names.

Kennel:
>I don't know what quite you mean, but there's the "private" attribute:

Let's consider a simple example:

class FATHER is

	private xyz:INT;

	foobar is
		xyz := 123;
	end; -- foobar

end; -- FATHER

class CHILD is

	FATHER;
	alias father_xyz xyz; 

	xyz:DOUBLE is 
		res := 1.0;
	end; -- xyz

end; -- CHILD

When the 'foobar'-procedure is used on an object of type FATHER, it works
correctly and assigns 123 to an integer 'xyz'. But when the foobar is
used on an object of type CHILD, well, the compiler catches the error...
(You cannot assign to a procedure.)

The 'private' does not prevent redefinition of 'xyz' in CHILD. Also, the
'foobar' still uses the old name 'xyz' in CHILD, because the 'alias' 
does not change it. (But you can refer to the integer in CHILD by calling
it 'father_xyz'.)

(I ran the code through a Sather compiler.)

>Though actually
>in Sather you can manually find out the "type" of any random object:
>( I guess the only allowed operations are equality and inequality on this. )

With the help of library classes you can test if one type is a subtype
of another.
--
...............................................................................
Ari Huttunen                               They say the sky high above
90-7285944                                   is Caribbean blue...  (Enya)


======================================================================= 97 ===
Date:    21 Jul 92 15:10:44 GMT
From:    os102@cl.cam.ac.uk (Oliver Stephens)
Subject: Shared Libraries under SunOS

More stuff on shared libraries under SunOS :

  1. You don't need the contents of lib<name>.a if you have lib<name>.so.*
     as programs are never linked with -Bstatic (at least I cannot think of
     any reason why they should).  You do, however, need a file of that name
     for the driver to work correctly, so you can replace it with a zero-length
     file to save more disc space

  2. Below are some m3make templates for creating shared libraries
     automatically.  They give you two new directives :

       sharedLibrary(name)  - equivalent of library(name)
       SharedLibrary(name)  - equivalent of Library(name)

     There are three (at least) minor gotchas :

       A. If you have a lib<name>.a but no lib<name>.so.* then the driver
          won't bother to rebuild : solution - remove lib<name>.a

       B. If the link fails (usually because some of the source files have
          not been compiled with a shared library target in mind) then the
          driver ignores it - this is because I replace the archive pass of
          the driver with a link pass, but the driver ignores the exit status
          of this pass : solution - remove all object files [m3make clean]
          before starting a shared library build

       C. If an installed lib<name>.a already exists (from a previous ordinary
          library build) then it will not change to zero-length when you
          install the shared library - this is because I use 'touch' to create
          the file : solution - change it to a zero-length file by hand or
          delete it first (if you want the extra disk space)

---+--- The following should go in your $(LIB_USE)/toplevel.tmpl file ---+---

#ifdef TARGET_SPARC

#define sharedLibrary(name)                                            @@\
all:: lib##name.a                                                      @@\
clean:: ; rm -f lib##name.a lib##name.ax lib##name.so.1.1              @@\
lib##name.a: FRC; $(DO_M3) -X1@-PIC@ -Y3@$(LIB_USE)/ld-so@ -Y4@touch@  \
-a lib##name.a $(PGM_SOURCES) $(IMPORT_LIBS)

#define SharedLibrary(name)                                            @@\
install::                                                              @@\
        INSTALL (lib##name.so.1.1, $(LIB_INSTALL), 755)                @@\
        INSTALL (lib##name.ax, $(LIB_INSTALL), 644)                    @@\
        touch $(LIB_INSTALL)/lib##name.a                               @@\
sharedLibrary(name)

#else

#define sharedLibrary(name)  library(name)
#define SharedLibrary(name)  Library(name)

#endif

---+--- And the following shell script should go in $(LIB_USE)/ld-so ---+---

#!/bin/csh -f
#
# ld-so : shared library linker for m3
#
# (just a simple shell around /bin/ld which changes the arguments
#  so that shared libraries can be created - needed because I don't
#  have enough control over the commands the m3 driver issues)
#
# Olly Stephens (os102@cl.cam.ac.uk) - 20/7/92
#

set argv[1]=-o                   # change 'cru' to '-o'
set argv[2]=$2:r.so.1.1          # change <lib>.a to <lib>.so.1.1

/bin/ld -assert pure-text $*

---+---

-------------------------------------------------------------------------
Olly Stephens                                oliver.stephens@cl.cam.ac.uk
Computer Laboratory
University of Cambridge    Loved you there and then, and now like a sheep
United Kingdom                                             - Van Morrison


======================================================================= 98 ===
Date:    21 Jul 1992 20:04:41 GMT
From:    mbk@lyapunov.ucsd.edu (Matt Kennel)
Subject: Re: Sather's Multiple Inheritance

Ari.Huttunen@hut.fi (Ari Juhani Huttunen) writes:
: In article <147qlkINNft3@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel
) writes:
: 
: ! Now what if both PARENT_CLASS_ONE and PARENT_CLASS_TWO
: ! have two features, say integer variables "count":
: 
: ! Then you can use "alias new_name old_name":
: ! ===========
: ! class CHILD is
: 
: ! 	PARENT_CLASS_ONE;	--- That inherits it
: ! 	alias count_one count;	--- rename "count" from P_C_O
: ! 	PARENT_CLASS_TWO;	--- That inherits another
: ! 	alias count_two count;	--- Rename that one as well
: 
: ! 	count : INT;		--- A third "count" different from the
: ! 				--- other two.
: 
: ! end;
: ! ============
: 
: ! I don't know if this solution is perfect for all circumstances, but it
: ! appears to a layman to cover a whole lot, and it's very easy to understand.
: 
: You still have the problem that CHILD, PARENT_CLASS_ONE and PARENT_CLASS_TWO
: refer to the same 'count' each, unless you re-rewrite the functions in
: the parent classes. (In some cases this would be desirable, in others it
: would not.)
: 
: The problem would be solved, if this were possible: 'rename count_two count'.

I think there's a bug in the compiler, actually.  As you were, I wasn't able
to override an integer feature (storage) with a procedure, but I was
able to override that same integer feature with a feature of different type.
============================
class FATHER is

	private xyz:INT;

        foobar is
                xyz := 123;
        end; -- foobar

end; -- FATHER

class CHILDBAD is

        FATHER;
        alias father_xyz xyz;

        xyz:DOUBLE is
                res := 1.0;
        end; -- xyz

end; -- CHILDBAD

class CHILDGOOD is

        FATHER;
        alias father_xyz xyz;

        xyz:DOUBLE;

end; -- CHILDGOOD


class TEST is
	main is
		a:FATHER;
		a.foobar;

		b:CHILDGOOD;
		b.foobar;

--		c:CHILDBAD;
--		c.foobar;
--  Compiler gives an error if you uncomment these lines! ???
--
	end;

end;

===================================

: --
: .............................................................................
..
: Ari Huttunen                               They say the sky high above
: 90-7285944                                   is Caribbean blue...  (Enya)

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego


======================================================================= 99 ===
Date:    23 Jul 92 12:23:24 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Proposed langauge changes / MI

In article 92Jul18115425@ibis.cs.umass.edu, moss@cs.umass.edu (Eliot Moss) writ
es:
>Peter suggests that if D inherits from B and C, then B and C must share a
>common ancestor A. This condition is trivially satisfied - ROOT is the
>anscestor of all OBJECT types. Peter, I think perhaps you have a different and
>stronger condition in mind. Could you try to articulate it? I don't think
>requiring B and C to have the same immediate ancestor is general enough, and I
>think saying they have to have a common ancestor other than ROOT requires more
>defense -- MI ought to allow one to combine completely orthogonal types if
>that's useful, shouldn't it? Why is it wrong to do so? You seem to have a
>style or idiom in mind that I have not been able to derive from what you've
>said so far ....
>--
>
>		J. Eliot B. Moss, Associate 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

Excuse me for being unclear. (I obviously haven't had my best day when I wrote
that article anyway :).

Well, although you're questions seem to be a little bit rhetorical: yes, I
actually meant *direct* subclasses. To put it in other words: I would agree
to MI if it is restricted to very simple fork/join situations. Furthermore,
I think that all data from the common superclass should be shared.

If you want to combine orthogonal classes, you actually build the cartesian
product of these classes. If I'm not completely wrong, this is exactly what
RECORDs are good for. So, if B and C are independent, I would combine these
using A = OBJECT b: B; c: C; END.

I'm totally aware of the fact that this is a little bit awkward for the people
used to MI from other languages, because you have to copy and merge B and C's
interfaces to get an interface for A. But it *can* be done. On the other hand,
if you have a (virtual in the C++ sense) superclass D and subclasses B and C
from D, there is no way to simulate A = B, C OBJECT END with SI without loosing
data hiding.

So, my proposal is sort of a compromise. It prevents MI from getting too
complicated - for the user as well as for the compiler/run time system. But I
don't think it prohibits the essential point about MI.
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany


======================================================================= 100 ===
Date:    Mon, 27 Jul 92 14:39:59 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: M3 and Solaris

Well, the subject line almost says it: Will the current Sparc4 version of SRC M
3
run under Solaris? If not, will there be a Solaris port?

---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany



======================================================================= 101 ===
Date:    Mon, 27 Jul 92 23:04:37 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: M3 2.03 - does not install -> help me, please

In article <1992Jul27.210919.18395@Informatik.TU-Muenchen.DE>, kirschnt@Informa
tik.TU-Muenchen.DE (Torsten R. Kirschner) writes:

|> I had ftp'ed M3 2.03 when it was out and wanted to install it today, but
|> I ran into this problem:
[...]
|> After decompressing and untar'ing all the files 

One possible explanation is that you did not grab
boot.DS3100-2.03.tar.Z, or that its unpacking did not go well.  (This
is assuming that 2.03 was organized similarly to 2.07 - I can't
remember if that is the case)

In any case, you probably want to use 2.07 which is now available.

-- 
Eric.



======================================================================= 102 ===
Date:    Mon, 27 Jul 1992 21:09:19 GMT
From:    kirschnt@Informatik.TU-Muenchen.DE (Torsten R. Kirschner)
Subject: M3 2.03 - does not install -> help me, please

Dear Netfellows,

I had ftp'ed M3 2.03 when it was out and wanted to install it today, but
I ran into this problem:
After decompressing and untar'ing all the files and setting them up
under /usr/local/src/m3 I created the correct m3make/config/config file
and ran (cd m3make ; make all install ).
But when I want to run m3make build_boot, I get the following error:
> /usr/local/src/m3 508 # m3make build_boot
> cd driver/boot-DS3100; m3make -DBOOT
> sh: driver/boot-DS3100: bad directory
> *** Error code 1
> 
> Stop.
And he's right there. There simply is no directory driver/boot-DS3100,
only an empty driver/DS3100. Do I need additional files or did I miss
a point to install M3?

I would be very happy if someone working with M3 could give me a hint
on how to get M3 installed. Thanks in advance.
Torsten
--
Torsten R. Kirschner            DOMAIN: torki@mpipf-muenchen.mpg.dbp.de
Christoph-Probst-Str. 8/818        FAX: +49 89 342473
8000 Muenchen 40                  HOME: +49 89 3234102
Deutschland   X.400: /C=de/ADMD=dbp/PRMD=mpg/O=mpipf-muenchen/s="torki"


======================================================================= 103 ===
Date:    Tue, 28 Jul 1992 05:13:47 +0200
From:    "Torsten R. Kirschner" <kirschnt@informatik.tu-muenchen.de>
Subject: Re: M3 2.03 - does not install -> help me, please

In article <1992Jul27.230437.23288@src.dec.com> you write:
>In article <1992Jul27.210919.18395@Informatik.TU-Muenchen.DE>, kirschnt@Inform
atik.TU-Muenchen.DE (Torsten R. Kirschner) writes:
>
>|> I had ftp'ed M3 2.03 when it was out and wanted to install it today, but
>|> I ran into this problem:
>[...]
>|> After decompressing and untar'ing all the files 
>
>One possible explanation is that you did not grab
>boot.DS3100-2.03.tar.Z, or that its unpacking did not go well.  (This
>is assuming that 2.03 was organized similarly to 2.07 - I can't
>remember if that is the case)
>
>In any case, you probably want to use 2.07 which is now available.
>
>-- 
>Eric.


Dear Eric,

thank You for Your information. As I currently lack FTP access (my
institution goes for the OSI stack) it could take me some time to
get it, but I'll have to do it anyway, I guess.

Yours thankfully
Torsten


-- 
Torsten R. Kirschner            DOMAIN: torki@mpipf-muenchen.mpg.dbp.de
Christoph-Probst-Str. 8/818        FAX: +49 89 342473
8000 Muenchen 40                  HOME: +49 89 3234102
Deutschland   X.400: /C=de/ADMD=dbp/PRMD=mpg/O=mpipf-muenchen/s="torki"


======================================================================= 104 ===
Date:    28 Jul 92 14:53:04 GMT
From:    Steve.Freeman@cl.cam.ac.uk (Steve Freeman on ely.cl.cam.ac.uk)
Subject: SIGPIPE raised during file IO

I've found that, running under SunOS, if a connection such as a pipe
or socket is broken a SIGPIPE is raised at the next write and the whole
process dies. Shouldn't this be managed by the UFileRdWr library, 
perhaps a SIG_IGN set?

Steve
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Steve Freeman, Computer Lab, University of Cambridge, UK
Steve.Freeman@computer-lab.cambridge.ac.uk


======================================================================= 105 ===
Date:    27 Jul 92 09:09:55 GMT
From:    olm@daimi.aau.dk (Ole Lehrmann Madsen)
Subject: ECOOP'92 proceedings

I have been asked about how to get the  proceedings of ECOOP'92.
Here is the reference:

	O. Lehrmann Madsen (Ed.)
	ECOOP'92, European Conference on Object-Oriented Programming
	Utrecht, The Netherlands, June/July 1992, Proceedings 
	Lecture Notes in Computer Science 615
	ISBN 3-540-55668-0 Springer Verlag Berlin Heidelberg New York
	ISBN 0-387-55668-0 Springer Verlag New York Berlin Heidelberg
	

---olm


======================================================================= 106 ===
Date:    Wed, 29 Jul 1992 20:56:35 GMT
From:    dave@kanga.lcs.mit.edu (David Sternlicht)
Subject: trestle

-- 
Has anybody built trestle with X11R5?
			
				dave sternlicht
				mit X consortium
				dave@expo.lcs.mit.edu


======================================================================= 107 ===
Date:    Thu, 30 Jul 92 08:41:01 +0200
From:    a.vermeulen@ECN.NL (Vermeulen A.T.)
Subject: Re: trestle

> Has anybody built trestle with X11R5?

Yes, I did, no problems at all. I use the X11R5-library on a Sun IPX under
SunOS 4.1.1. running OpenWindows 2.0.

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



======================================================================= 108 ===
Date:    Thu, 30 Jul 1992 01:12:06 GMT
From:    dave@kanga.lcs.mit.edu (David Sternlicht)
Subject: trestle...

------------------------------------------------------------
Hello again modula-3 people!

I pulled the m3 X11R4 package off gatekeeper and incanted:

m3make -f m3makefile.X11R4 all install

on it (even though I have r5 installed...)
This allowed me to sucessfully do:

m3make -f m3makefile.trestle all install

Great!  Now I go to trestle/apps and say:

m3make Hello

and I get the following...

/usr/local/bin/m3 -w1 -make -why -g -D../src/xvbtm3:../src/vbtm3:../src/splitm3
:../src/trestlem3  -commands -o Hello Hello.m3   ../mips/libm3ui.a -lm3X11R4 -l
X11 
inhale ../mips/libm3ui.a
inhale /usr/local/lib/m3/libm3X11R4.a
inhale -lX11
inhale /usr/local/lib/m3/libm3.a
inhale -lm

program missing -> link Hello
missing interface "Trestle" imported by:
   Hello.m3  
missing interface "TextVBT" imported by:
   Hello.m3  

Fatal Error: incomplete program

Fatal Error: incomplete program
*** Error code 255
make: Fatal error: Command failed for target `Hello'

could some kind person tell me what I did wrong?
I found latex documentation but so far, no man pages 
for the compiler...
------------------------------------------------------------
			
				dave sternlicht
				mit X consortium
				dave@expo.lcs.mit.edu


======================================================================= 109 ===
Date:    Thu, 30 Jul 92 03:01:16 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: trestle...

Unfortunately, the m3makefile in trestle/apps is not portable.  You
need to edit it and replace "mips" by the name of your architecture
(DS3100, SPARC, whatever).  I'll try to make things better for the
next release.  Sorry for the trouble.

Also, X11R5 should be fine; isn't it compatible with X11R4 clients ?

-- 
Eric.



======================================================================= 110 ===
Date:    Thu, 30 Jul 1992 10:10:50 GMT
From:    ddean@sapphire.risc.uni-linz.ac.at (Drew Dean)
Subject: Building SRC M3-2.07 on a NeXT

I'm having trouble building 2.07 on a NeXT running NeXT's 2.2 OS.  The  
compiler built fine, but I can't build libm3.  First problem was that  
dirname is missing, but I wrote it in C (:-() after consulting an Ultrix  
system.  Now, however, I get the following in response to a m3make -f  
m3makefile.libm3:
Make:  Don't know how to make /M3Config.m3.  Stop.

Ok, so something somewhere is inserting a space where there shouldn't be  
one...But if I hand tweak the .makefile to get around this, the compiler  
then dies (sorry, I don't remember the exact error, but it's a seg fault  
or something similar).

I'm interested in Modula-3, but I can't really good a grip on the language  
until the compiler works... :-)

Thanks,
Drew Dean
ddean@risc.uni-linz.ac.at
My opinions, not RISC's.


======================================================================= 111 ===
Date:    Thu, 30 Jul 1992 13:07:50 GMT
From:    dave@kanga.lcs.mit.edu (David Sternlicht)
Subject: trestle

Thankyou for all the help I recieved in getting my trestle apps to work.
My primary interest at this point is in multithreading a c++ toolkit for
adoption as an X Consortium standard.  Evidently the modula-3/trestle community
is a little further ahead in mt user interface toolkits than I am so I wish
to learn...  Being a newcommer to this list I would be interested in who is
doing industrial or academic code development work with trestle and maby
a little about there applications.  This news group is sure alot easier to foll
ow
than comp.lang.c++ :-)
-- 
			
				dave sternlicht
				mit X consortium
				dave@expo.lcs.mit.edu


======================================================================= 112 ===
Date:    Tue, 28 Jul 1992 11:46:12 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: The HP 'snake'


Er,
  I know I posted about this before, but some folks here are starting
to press me about it. How's the status on the HP9000/720 port
of SRC-m3? I remember we had to wait on a major overhaul of the
Thread implementation, but wasn't that done in 2.07? So how about it?
Need any help on it?

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


======================================================================= 113 ===
Date:    Thu, 30 Jul 92 19:18:55 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: M3 2.07 Compiler/Trestle/HP 9000s300 problem

In article <DG.92Jul30171808@dgupta.hpl.hp.com>, dg@dgupta.hpl.hp.com (Dipankar
 Gupta) writes:

|> I have a problem with compiling trestle from the 2.07 distribution on
|> an HP 9k/3xx running HPUX 8.0. The compiler barfs:

The lines in question look simple to me, so it is probably something
more complex than just big expressions.  You should get in touch with
HP people to find out if their C compiler has been fixed.

|> Could it be due to my having compiled
|> the driver with -O (full optimisation) on the HP C compiler?

It is the C compiler that is complaining.  Optimization of the driver or
the Modula-3 compiler does not change the C produced, hence should
have no effect.

-- 
Eric.



======================================================================= 114 ===
Date:    Thu, 30 Jul 92 18:49:07 GMT
From:    muller@src.dec.com (Eric Muller)
Subject: help with Umman.i3

I wrote the interface Umman, which is supposed to capture the
/usr/include/sys/mman.h header file.  I have a version for DECstation
and VAX runing Ultrix, and a version for DEC OSF/1 (see below). 

If somebody could send me the versions for the other platforms, it would
be great.

Thanks for your help,
Eric.


(* Copyright (C) 1992, Digital Equipment Corporation                         *)
(* All rights reserved.                                                      *)
(* See the file COPYRIGHT for a full description.                            *)
(*                                                                           *)
(* Last modified on Thu Jul 30 11:49:02 PDT 1992 by muller                   *)

INTERFACE Umman;  (* DS3100, VAX *)

FROM Ctypes IMPORT int;
FROM Utypes IMPORT caddr_t, size_t, off_t;

(*** sys/mman.h ***)

CONST
  PROT_READ  = 16_1;
  PROT_WRITE = 16_2;
  PROT_EXEC  = 16_4;

  MAP_SHARED  = 1;
  MAP_PRIVATE = 2;

  MAP_FIXED   = 16_100;

  MADV_NORMAL     = 0;
  MADV_RANDOM     = 1;
  MADV_SEQUENTIAL = 2;
  MADV_WILLNEED   = 3;
  MADV_DONTNEED   = 4;

<*EXTERNAL*>
PROCEDURE mmap (addr: caddr_t; len: size_t; prot,flags,fd: int; 
                off: off_t): caddr_t;

<*EXTERNAL*>
PROCEDURE munmap (addr: caddr_t; len: size_t): caddr_t;

<*EXTERNAL*>
PROCEDURE mprotect (addr: caddr_t; len, prot: int): int;

END Umman.



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

INTERFACE Umman;  (* DEC OSF/1 *)

FROM Ctypes IMPORT int;
FROM Utypes IMPORT caddr_t, size_t, off_t;

(*** sys/mman.h ***)

CONST
  PROT_NONE  = 0;
  PROT_READ  = 16_1;
  PROT_WRITE = 16_2;
  PROT_EXEC  = 16_4;

  MAP_SHARED  = 1;
  MAP_PRIVATE = 2;

  MAP_FILE    = 16_00;
  MAP_ANONYMOUS = 16_10;
  MAP_ANON      = 16_10;
  MAP_TYPE      = 16_F0;

  MAP_FIXED   = 16_100;
  MAP_VARIABLE = 16_00

  MAP_HASSEMAPHORE = 16_0200;
  MAP_INHERIT      = 16_0400;
  MAP_UNALIGNED    = 16_0800;

  MADV_NORMAL     = 0;
  MADV_RANDOM     = 1;
  MADV_SEQUENTIAL = 2;
  MADV_WILLNEED   = 3;
  MADV_DONTNEED   = 4;
  MADV_SPACEAVAIL = 5;

TYPE
  msemaphore = RECORD
    msem_state: int;
    msem_wanted: int; END;
  msemaphore_star = UNTRACED REF msemaphore;

CONST
  MSEM_UNLOCKED =   0;
  MSEM_LOCKED = 1;
  MSEM_IF_NOWAIT = 2;
  MSEM_IF_WAITERS = 3;

  MS_ASYNC = 1;
  MS_SYNC = 3;
  MS_INVALIDATE = 4;


<*EXTERNAL*>
PROCEDURE madvise (addr: caddr_t; len: size_t; behav: int): int;

<*EXTERNAL*>
PROCEDURE mmap (addr: caddr_t; len: size_t; prot,flags,fd: int; off: off_t)
  : caddr_t;

<*EXTERNAL*>
PROCEDURE msync (addr: caddr_t; len: size_t; flags: int): int;

<*EXTERNAL*>
PROCEDURE munmap (addr: caddr_t; len: size_t): int;

<*EXTERNAL*>
PROCEDURE mprotect (addr: caddr_t; len: size_t; prot: int): int;

<*EXTERNAL*>
PROCEDURE mvalid (addr: caddr_t; len: size_t; prot: int): int;

<*EXTERNAL*>
PROCEDURE msem_init (sem: msemaphore_star; initial_value: int);

<*EXTERNAL*>
PROCEDURE msem_lock (sem: msemaphore_star; condition: int): int;

<*EXTERNAL*>
PROCEDURE msem_remove (sem: msemaphore_star): int;

<*EXTERNAL*>
PROCEDURE msem_unlock (sem: msemapore_star; condition: int): int;

(* shm_open and shm_unlink have no man pages *)

END Umman.



-- 
Eric.



======================================================================= 115 ===
Date:    30 Jul 92 16:18:08 GMT
From:    dg@dgupta.hpl.hp.com (Dipankar Gupta)
Subject: M3 2.07 Compiler/Trestle/HP 9000s300 problem


I have a problem with compiling trestle from the 2.07 distribution on
an HP 9k/3xx running HPUX 8.0. The compiler barfs:

dgupta.hpl.1675> m3make -f m3makefile.trestle
        cd trestle; /users/dg/bin/m3make all
============================= Building in HP300
        /users/dg/bin/m3 -w1 -make -why -O   -a libm3ui.a -F.PGM_SOURCES -lm3X1
1R4
new source -> compile ../src/splitm3/TranslateVBT.m3
"TranslateVBT.m3", line 47: compiler error: register allocation error
new source -> compile ../src/splitm3/RigidVBT.m3
"RigidVBT.m3", line 28: compiler error: register allocation error
new source -> compile ../src/xvbtm3/XClient.m3
"XClient.m3"verflow, line 755: compiler error: register allocation error
compilation failed => not building library "libm3ui.a"

Anyone else have this problem? Could it be due to my having compiled
the driver with -O (full optimisation) on the HP C compiler?

Thanks muchly,
Dipankar Gupta
HPLabs Bristol UK
dg@hplb.hpl.hp.com
--
--


======================================================================= 116 ===
Date:    Fri, 31 Jul 92 06:34:08 PDT
From:    bates@salm04.boeing.com
Subject: Language definition ambiguity

I am reading the latest M3 language definition in the August SIGPLAN.
Section 3.2 says:

"For a VAR parameter, the actual must be a writable designator 
 whose type is the same as that of the formal, or, in case of
 a VAR array parameter, assignable to that of the formal."

I first parsed this to mean:

"in case of a VAR array parameter, the actual's type must be
 assignable to the type of the formal."

Looking at the definitions of assignability of types to types,
of subtypes, and specializing to arrays, this would allow an
open array actual to be passed to a fixed array formal without
a shape check, which isn't safe.  So, a reread gave me this 
alternate interpretation:

"in case of a VAR array parameter, the actual must be
 assignable to the type of the formal."

This invokes assignability of an expression to a type, which 
includes the shape check.  I presume this is the right
interpretation.  

I think the English is ambiguous, or possibly even misleading,
since we don't know if the implied parallel text before 
"assignable" is "a writable designator whose type is" or 
"a writable designator .. (which) is"

Rodney M. Bates
Boeing
P.O. Box 7730, MS K80-13
Wichita, KS 67277-7730
316-523-2015
bates@awsil4.boeing.com



======================================================================= 117 ===
Date:    Fri, 31 Jul 1992 21:53:53 GMT
From:    andru@meson.lcs.mit.edu (Andrew Myers)
Subject: m3process - new version available

This is essentially the same program previously advertised, but with
many minor tweaks and improvements. It converts "M3SU", which is
"Modula-3 without Semicolons and required Uppercase keywords", into
Modula-3. It does syntax-checking on M3SU, so you receive rapid feedback
on syntactic errors.  m3make support is included.

Send me mail if you want a copy.

Andrew


