======================================================================== 1 ===
Date:    Wed, 2 Oct 91 14:15:31 PDT
From:    antoy@cs.pdx.edu (Sergio Antoy)
Subject: Modula 3 on the Sequent

Is there an official or unofficial port of Modula 3 on a Sequent?
If yes, is it either for PTX or Dynix?  Thanks.

Sergio Antoy
Portland State University
P.O.Box 751
Portland, OR 97207
voice +1 (503) 725-3009
fax   +1 (503) 725-3221
internet antoy@cs.pdx.edu


======================================================================== 2 ===
Date:    2 Oct 91 21:13:52 GMT
From:    antoy@antares.cs.pdx.edu (Sergio Antoy)
Subject: Modula 3 on the Sequent

Is there an official or unofficial port of Modula 3 on a Sequent?
If yes is either for PTX or Dynix?  Thanks.

Sergio Antoy
Portland State University
P.O.Box 751
Portland, OR 97207
voice +1 (503) 725-3009
fax   +1 (503) 725-3221
internet antoy@cs.pdx.edu


======================================================================== 3 ===
Date:    3 Oct 91 23:06:32 GMT
From:    lins@Apple.COM (Chuck Lins )
Subject: Productivity of Type-Safe Languages

(First some background info)

I recently spent a week in a series of classes on programming for System 7.0
(Apple's fancy new OS for the Mac). You had your choice of programming language
for the various exercises: Pascal or C. There were maybe 12 people in this
class. Two of us used Pascal. Then others used C. In all the exercises, never
once did my programs drop into the debugger. It seemed however that this
happened often with the C programmers. Not real scientific, but perhaps this
is representative of the current state in programming.

(Now for the real part)

At the recent Modula2 conference there was one paper titled something like
"Modula-2 is 3 times better than C". It took a look at the kinds of errors
made by various programmers in each language. The result was that the Modula
compiler found more errors at compile-time than the C compiler. Thus, the C
programmers found their errors at run-time (at least a larger percentage of the
total number of errors). Of course, we all know this.

(Now for the imaginary part)
The members of these newsgroups all know the refrain "type-safe is better". And
I'm certain there are many other advantages to both Modula-3 and Oberon/Oberon-
2.
The problem is how to convinve the rest (or at least a significant number) of
the programming community that this is so AND they are willing to use them 
in everyday work.

The major omission of the aforementioned paper is that it wasn't able to
measure the impact of language on the development cycle and schedule. And it
seems to me that neither Modula-3 nor Oberon-2 will amount to anything more
than a footnote in the pages of programming language history unless there is
some _measureable_ benefit. The marketing "hype" of type-safe is better won't
sell to a programming development manager [maybe to a few, but not many].
What's needed is a good study that says "modula-3 saved us $$$ in the
development of our great product. and it's also why it's so reliable."

Sonething like that will sell these languages in the minds of managers and
programmers (well lots of libraries will keep the latter happy :-)

So here's a plea to the research community to demonstrate to everyone else
that these languages really are better than C (and everyone's favorite C++).
Don't let M3 and O2 go down the dead-end where M2 ended up.

Let me close with:

"Build a better programming language and the world will _not_ beat a path to yo
ur door."

Chuck Lins

-- 
Chuck Lins               | "Shut up! Be happy!" -- Jello Biafra
Apple Computer, Inc.     | Looking for RISC Oberon compiler job.
20525 Mariani Avenue     | Resume available on request. 
Mail Stop 58-C           | Internet: lins@apple.com
Cupertino, CA 95014      |


======================================================================== 4 ===
Date:    Fri, 4 Oct 91 11:35:09 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Modula-3 FAQ

			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.

   There is an overview article "Modula-3", by Sam Harbison, in 
   Byte, Vol. 15, Number 12, October 1990, p 385.


Is Modula-3 a superset of Modula-2 ?

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


Where can I get a definition 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

   Previous definitions were published as SRC Reports # 31 and 52 and
   can be obtained on paper from SRC by sending a message to
   src-report@src.dec.com.  Report # 52 is also available in
   PostScript format via anonymous ftp from gatekeeper.dec.com in
   pub/DEC/Modula-3/report. 


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.  The messages sent to
   comp.lang.modula3 are relayed to a mailing list; send a message to
   m3-request@src.dec.com to be added to it.

   Also, Pine Creek Software publishes a free newsletter and various
   announcements about Modula-3 products and activities.  To be added
   to their mailing list, send email or US mail to:

	Pine Creek Software
	Suite 300
	305 South Craig Street
	Pittsburgh, PA 15213
	Phone & Fax: [1] (412) 681 9811
	Email: modula3@bert.pinecreek.com
   

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/m3-1.6. 

   The current version, 1.6, implements the language defined in the 
   SRC report # 52.  Version 2.0 is in the works and will implement the 
   latest definition.

   Version 1.6 runs on:
	   Acorn R260 running RISC iX 1.21
           Apollo DN4500 running Domain/OS,
           DECstation 3100 and 5000 running Ultrix 4.0 and 4.2
           Encore Multimax running UMAX 4.3 (R4.1.1)
           HP 9000/300 running HP-UX 8.0
           IBM PC running AIX/PS2,
           IBM RT running IBM/4.3, 
           IBM R6000 running AIX 3.1, 
           VAX running Ultrix 3.1
           SPARCstation running SunOS 4.1.x
           SUN3 running SunOS

   SRC Modula-3 includes a user manual, compiler, runtime library,
   core library, pretty-printer, and a few other goodies.  The
   libraries include interfaces for X11R4, I/O streams, string
   functions, access to command line arguments, random numbers, and
   operating system access.

   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 ?

   You can contact Pine Creek Software (see the address above).

----
Eric.




======================================================================== 5 ===
Date:    4 Oct 91 14:47:36 GMT
From:    schoebel@bs5.informatik.uni-stuttgart.de (Thomas Schoebel)
Subject: Re: Productivity of Type-Safe Languages

In article <58163@apple.Apple.COM> lins@Apple.COM (Chuck Lins ) writes:

>   So here's a plea to the research community to demonstrate to everyone else
>   that these languages really are better than C (and everyone's favorite C++)
.
>   Don't let M3 and O2 go down the dead-end where M2 ended up.

Agreeing that some demonstration of the better productivity of MODULA
is necessary to convince more laymen, I don't believe M2 is at a
dead end now. However, there is a risk to be beaten out by the C/C++
promoters.

What to do?

Some ideas:
Compatibility and other demands forces you often to use C. But who says
that you have to code all in C directly? If we had good M2 to C
translators, such could be used as a "preprocessor", using C as
intermediate language, reflecting its usefulness as a portable
assembly language (and usefulness only for that!).

Example: You are asked to do some programming in C. You write it in
M2 (or Oberon, M3) instead, and your "preprocessor" outputs what
your employer wants. While you take advantage from M2, the employer
does not see anything from this (ideally).

Currently, the problem is that no such (portable) preprocessor
is available. For example, the mtc from GMD has some disadvantages:
a) It does no full type checking, the main point of M2
b) Comments are lost
c) translations between different M2 dialects and different C
   dialects (16bit vs. 32bit architectures) are not possible.
d) It is not public domain.

If there were a translator satisfying the above points, there should
be no need to any more use C, as far as a programmer is willing to
learn M2.

Comments on the net ? Is there someone trying to improve mtc?

-- Thomas


======================================================================== 6 ===
Date:    4 Oct 91 15:07:32 GMT
From:    toma@sail.LABS.TEK.COM (Tom Almy)
Subject: Re: Productivity of Type-Safe Languages

In article <58163@apple.Apple.COM> lins@Apple.COM (Chuck Lins ) writes:

>The members of these newsgroups all know the refrain "type-safe is better". An
d
>I'm certain there are many other advantages to both Modula-3 and Oberon/Oberon
-2.
>The problem is how to convinve the rest (or at least a significant number) of
>the programming community that this is so AND they are willing to use them 
>in everyday work.

If I may speak some heresy here (:-) I have been teaching a C class at
a local college for the past year and a half in a class equiped with PCs and
Turbo C (old version). ANSI C allows for a great deal of "type safe"
compilation; in the first class I tell everyone to enable all warning
messages (ok, so in C these are warnings and not *errors*) and make it 
clear that programs that generate any warnings are not acceptable.

With one exception, once the programs compile successfully the students
programs only have logic errors. The one exception is the G*dawful scanf/printf
for which there is no error checking. Of course if the class were C++ we
would be using streams and even this problem would go away.

Anyway, with an ANSI C compiler and *discipline* good results can be achieved.

Don't get me wrong -- I enjoy Modula-2, but the rest of the world, in
particular the "C Majority" isn't standing still -- the old K&R C
High-Level Assembler is becoming a thing of the past.

-- 
Tom Almy
toma@sail.labs.tek.com
Standard Disclaimers Apply


======================================================================== 7 ===
Date:    4 Oct 91 17:19:43 GMT
From:    sdl@mitre.org (Steven D. Litvintchouk)
Subject: Re: Productivity of Type-Safe Languages


In article <58163@apple.Apple.COM> lins@Apple.COM (Chuck Lins ) writes:

> The major omission of the aforementioned paper is that it wasn't able to
> measure the impact of language on the development cycle and schedule. And it
> seems to me that neither Modula-3 nor Oberon-2 will amount to anything more
> than a footnote in the pages of programming language history unless there is
> some _measureable_ benefit. The marketing "hype" of type-safe is better won't
> sell to a programming development manager [maybe to a few, but not many].
> What's needed is a good study that says "modula-3 saved us $$$ in the
> development of our great product. and it's also why it's so reliable."
> 
> Sonething like that will sell these languages in the minds of managers and
> programmers (well lots of libraries will keep the latter happy :-)

I must disagree with this assessment.  Before I got interested in
Modula-3, I used to program in Ada, and saw that the Ada community was
likewise trying (and often failing) to sell type-safety (and other Ada
features) to managers and bean-counters.  My observations:

1.  The programmers who appreciate type-safe languages have a
different style of development, and even a different life-cycle model.
That is, they are used to spending more time on ensuring the
consistency of their design, prior to trying to debug it dynamically.
With a type-safe language, you spend a lot of extra time trying to
push your design through the compiler successfully, and less time
debugging it dynamically.

2.  Prior advances in programming, notably structured programming, did
not become widely used by selling the professional bean-counters on
their "cost-effectiveness."  Rather, they simply became part of the
accepted practices of programmers.  And as those programmers rose up
through the ranks to become project leaders and managers, those
techniques became standardized within the organization.  So what I
often saw in industry, were managers who enforced structured
programming standards and guidelines, despite having no empirical
evidence on their cost-effectiveness.  At the same time, these
managers would oppose Ada and its features such as type-safety, on the
grounds that there was no evidence on their cost-effectiveness!


--
Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730

Fone:  (617)271-7753
ARPA:  sdl@mitre.org
UUCP:  ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl
	"Where does he get those wonderful toys?"


======================================================================== 8 ===
Date:    Fri, 4 Oct 1991 23:13:16 PDT
From:    David Goldberg <goldberg@parc.xerox.com>
Subject: arrays with empty index type

Can arrays have empty index type?  In particular, are the
following valid?

1. the statement:  refArr := NEW(REF ARRAY OF INTEGER, 0)
2. the declaration: arr: ARRAY[1..0] OF INTEGER

what about

3. refArr := NEW(REF ARRAY OF INTEGER, -1)?

The reference manual seems to imply that both 1 and 2 should
be valid, although the 1.6 m3 compiler rejects 2.

     David Goldberg
     goldberg@parc.xerox.com


======================================================================== 9 ===
Date:    Sun, 6 Oct 91 17:51:30 PDT
From:    <gnelson@src.dec.com>
Subject: Re: arrays with empty index type


The expression NEW(REF ARRAY OF INTEGER, 0) and the
declaration VAR arr: ARRAY [1..0] OF INTEGER are both legal,
as the reference manual implies.  The 1.6 compiler should not
be regjecting the declaration.

The expression NEW(REF ARRAY OF INTEGER, -1) is illegal.

Greg


======================================================================== 10 ===
Date:    7 Oct 91 14:38:34 GMT
From:    davis@passy.ilog.fr (Harley Davis)
Subject: Re: Productivity of Type-Safe Languages


In article <58163@apple.Apple.COM> lins@Apple.COM (Chuck Lins ) writes:

   "Modula-2 is 3 times better than C". It took a look at the kinds of
   errors made by various programmers in each language. The result was
   that the Modula compiler found more errors at compile-time than the
   C compiler. Thus, the C programmers found their errors at run-time
   (at least a larger percentage of the total number of errors). Of
   course, we all know this.

   The major omission of the aforementioned paper is that it wasn't
   able to measure the impact of language on the development cycle and
   schedule. And it seems to me that neither Modula-3 nor Oberon-2
   will amount to anything more than a footnote in the pages of
   programming language history unless there is some _measureable_
   benefit. The marketing "hype" of type-safe is better won't sell to
   a programming development manager [maybe to a few, but not many].
   What's needed is a good study that says "modula-3 saved us $$$ in
   the development of our great product. and it's also why it's so
   reliable."

The success or failure of programming languages has absolutely nothing
to do with any inherent value of the language.  It has to do with the
number, value, and openness of the applications written in the
language.  As long as nobody is writing useful programs written in a
language, and distributing the sources, the language will not succeed
on a large scale.

Another potential factor in a language's success is a mandate from
above to use the language.  Ada is an example of such a language.
However, this alone will not guarantee success.  PL/I, for example,
was a flop.

-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis			ILOG S.A.
net: davis@ilog.fr			2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66			94253 Gentilly Cedex, France


======================================================================== 11 ===
Date:    5 Oct 91 20:54:00 GMT
From:    ccoleman@gmuvax2.gmu.edu (Chuck Coleman)
Subject: Oberon-2 ( was Re: Productivity of Type-Safe Languages )

Pardon my ignorance, but when did Oberon-2 come out, and where is it
available?  I haven't even had a chance to play with my MS-DOS Oberon 
compiler!

Chuck Coleman                "Sorry, no concluding witticism"

School:					Work:
Center for Study of Public Choice	NPA Data Services, Inc.
George Mason University			1424 16th St. N.W. Suite 700
4400 University Drive			Washington, DC 20036
Fairfax, VA 22030			(202) 265-7685

BITNET: ccoleman@GMUVAX
Internet: ccoleman@gmuvax2.gmu.edu


======================================================================== 12 ===
Date:    8 Oct 91 23:57:24 GMT
From:    mgallo@zeus.calpoly.edu (M. Gallo)
Subject: Re: Oberon-2

This was originally a letter, but I decided to post due to recurring
inquiries.

>Rumor is there that there is something like Oberon-2.  I know Oberon
>but what is Oberon-2?  Does anybody have some information about it?

It's not just a rumor.  Oberon-2 is an extension of Oberon by
Hans-Peter Mossenbock at ETH, Zuerich.  It is an attempt to enhance
Oberon with new OO and other features while remaining true to the
"spirit" of Oberon.  As far as I know, it has only been implemented
for SPARCstations at this point, but people are writing implementations
for other platforms.  I'm sure that they'll be announced in
comp.lang.modula2 when they're available.  You can find the SPARC
implementation and documentation by ftp at neptune.inf.ethz.ch, among
other places.

Also of interest, perhaps, is Oberon-2's predecessor, Object Oberon. 
Although abandoned in favor of Oberon-2, you can find a description
of it in _Structured Programming_ (1989) v10 n4, pp. 199-207.

I hope this is useful.
-- 
                                                           _   /|
Miguel                                                     \'o.O'
mgallo@ares.calpoly.edu                                    =(___)=
"C is its own virus."                                         U


======================================================================== 13 ===
Date:    10 Oct 91 18:01:56 GMT
From:    jimad@microsoft.UUCP (Jim ADCOCK)
Subject: Re: Productivity of Type-Safe Languages

In article <SCHOEBEL.91Oct4154736@bs5.informatik.uni-stuttgart.de> schoebel@bs5
.informatik.uni-stuttgart.de (Thomas Schoebel) writes:
|I don't believe M2 is at a
|dead end now. However, there is a risk to be beaten out by the C/C++
|promoters.

No risk at all, because Modula-3 [and other OOPS] *have* been
beaten *out* of the market by C/C++.

So, that's not the issue.  Rather, the issue is, what if anything,
can other OOPLs do to beat their way back *into* the market.

Here's some numbers backing up my claims.  From the Computer Select
database:

Number of magazine articles and abstracts referring to a particular
programming language in the last year [out of a total of about 70000
magazine articles and abstracts covering the vast majority of common
computer magazines]

C	3823
C++	 918
Modula-2 104
Modula-3   6

In summary, C and C++ really have taken over the market.  Supporters of
other languages thus need to formulate a strategy for getting their
favorite languages back into the market.  Given that C and C++ really
are quite a kludge, one would have to believe that *some day* *some
language* will come along and knock them out of their present
dominating positions.  But, as of today, its hard to see what and when.
At the very least, a language that would take over from C/C++ better 
address the issue of C/C++ compatibility closely, because all the people
writing tons of software under C/C++ compilers are going to be loath
to throw it all away.  I don't believe its necessary that a language
take the approach of Objective-C or C++ where they try to *be* the
previous language.  Still, you'd better think *seriously* about how
you want to address the back[ass]wardly compatibility issues, if you
want your favorite language to be a success.


======================================================================== 14 ===
Date:    Thu, 10 Oct 1991 21:08:06 PDT
From:    Mark_Weiser.PARC@xerox.com
Subject: Re: Productivity of Type-Safe Languages

Counting magazine articles is hardly a way to measure wins.  For instance, if I
counted the number of articles on cold vs. hot fusion in 1990, I would have
figured cold fusion had won by your measure.

Less facetiously, take OS/2.  Counting OS/2 vs. Windows articles in 1988-1989
would have predicted Windows as dead and OS/2 the winner.  But look what
happened.

And my favorite example: PL/I, the language that was going to take over the
world, the language with all the latest features, etc. etc., just like C++, and
just like C++ a large bag of ugly tricks.  It had its day, and then died as
people got disgusted with its complexity and returned to simpler languages.

-mark


======================================================================== 15 ===
Date:    11 Oct 91 15:06:36 GMT
From:    dduggan@plg.waterloo.edu (Dominic Duggan)
Subject: Experiences etc using Modula-3 for teaching

I'm interested in hearing people's experiences/advice/opinions on using
Modula-3 in a third-year undergrad computer systems course.  The material
for the course is basically IPC and file systems, some intro to distributed
systems.  The text is Silberschatz, Peterson & Galvin, which they will have 
used in the prereq course.  I'd like to use M3 primarily because of its module 
system, possibly doing some Choices stuff later with the object system.
I have some worries, primarily the stability of the compiler (the course will
probably work on Microvax-II's or Sun-3's).  I'm also hoping students can pick
up the basic M3 stuff quickly from previous exposure to Pascal and Ada.  

I'd also be _very_ grateful if someone had an implementation for a stable 
transport layer that could sit atop BSD sockets...

Please reply to me directly, I'll summarize to the net if there's interest.


======================================================================== 16 ===
Date:    Sat, 12 Oct 1991 06:09:56 GMT
From:    schwartz@roke.cs.psu.edu (Scott Schwartz)
Subject: Re: Productivity of Type-Safe Languages


Mark_Weiser.PARC@xerox.com writes:
   And my favorite example: PL/I, the language that was going to take
   over the world, the language with all the latest features, etc.
   etc., just like C++, and just like C++ a large bag of ugly tricks.
   It had its day, and then died as people got disgusted with its
   complexity and returned to simpler languages.

While I agree with this in principle, I wonder if it will work out
that easily in practice.  One thing that did PL/I in was that there
were ``lean and mean'' alternatives, both in terms of simplicity of
conception and of implementation.  (Look at all the miniscule Pascal
compilers in the world!)  Today, while I think there are all sorts of
languages better conceived than C++, I worry about implementation.
How big is the runtime system (or even just ``hello world'') of your
favorite Modula-3 compiler?  Your favorite Scheme compiler?  Or (just
for Mark) your favorite Ceder compiler?  If all the better languages
in the world are percieved as bloated, we may be stuck with C+n for a
long time to come.


======================================================================== 17 ===
Date:    Mon, 14 Oct 91 02:24:00 mdt
From:    Dave Barrett <asgard!barrett@boulder.Colorado.EDU>
Subject: Modula III on HPUX

I am attempting to install modula III version 1.6 onto HP-UX (HP300 config)
The installation package does not work as written because the
link-compiler target in system/complier/Imakefile tries to execute a 
command with too many arguments.  The HP-UX kernal refuses to exec 
command lines more than about 5000 characters.   Is there an easy fix for
this? 

Dave Barrett
barrett@boulder.Colorado.EDU


======================================================================== 18 ===
Date:    13 Oct 91 20:52:25 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: OOPSLA '91 debriefing

I just returned from OOPSLA '91. Here's a quick summary of Modula-3
activities:

Interest: The Modula-3 tutorial had about 35 attendees, which I'm
informed is good for a "specialized" topic.  There was a total
attendance at the conference of about 2,000. About 60 people signed up
for the Modula-3 mailing list at the Pine Creek booth; probably 30
others took literature. I can't estimate the overlap between the booth
visitors and the tutorial attendees, although I think it was low since
the tutorial people already had all the M3 literature I had at the
booth.

Competition: I talked with many C++ programmers; few expressed any
affection for the language. I listened to a long recital about C++
faults (post version 1.2) from the C++ product manager of a major
tools company that was exhibiting at the conference.  The presenter of
a tutorial on C++ class design said that every C++ application he'd
seen had storage problems (leaks or bugs caused by dangling pointers);
he spent about 30 minutes describing all the ways you can get in
trouble.

Conclusions: I had hoped for more Modula-3 interest, but in retrospect
I think the response is OK at this point.  More people are saying that
they have at least heard of Modula-3.  No one said, "I don't like
Modula-3 because <x>" (for any <x>), although some people said they
had to use C++ as a matter of company policy.  The availability of SRC
Modula-3 and the Modula-3 books are important advantages. A PC
compiler is still needed.  In my opinion, the academic community is
ripe for a good teaching language like Modula-3.

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


======================================================================== 19 ===
Date:    10 Oct 91 21:42:39 GMT
From:    sdy@ssc-bee.boeing.com (Ugly Bag of Mostly Water)
Subject: Need Help Installing SRCModula3 (Apollo)

I've been trying to install SRCModula3 on an Apollo (DN4500/DN3000) and have
been having some problems. I have the latest 1.6 distribution direct from the
DECWRL archives and would like to talk to (email) someone who has successfully
installed this on an Apollo (running SR10.3) -- the release notes claim it can
be done but I've encountered the need for  numerous adjustments to the makefile
and have now been totally stalled.

steven yee
sdy@ssc-bee.boeing.com
--
Steven D. Yee                 >>>  my employer does not share my opinions   <<<
sdy@ssc-bee.boeing.com        >>>   that's because I'm always right! ;b     <<<
               You couldn't pay me enough, but go ahead and try.


======================================================================== 20 ===
Date:    14 Oct 91 19:19:58 GMT
From:    raginis@cs.albany.edu (Ragini Shamsunder)
Subject: beginner wanting to know about opaque types


Hi,
	I just started working on Modula3 very recently and am having
trouble figuring out opaque types.  I tried defining a stack in a separate
module without disclosing the data structure.  Here is the INTERFACE:

INTERFACE stks;
TYPE stack <: T;

PROCEDURE push(item : INTEGER; VAR s : stack);
PROCEDURE pop(VAR item : INTEGER; VAR s : stack);
PROCEDURE empty(s : stack) : BOOLEAN;

END stks.

and here is PART of the Module itself:

MODULE stks;

TYPE
	REVEAL stack = T;
	    T = BRANDED  REF RECORD
	        store : ARRAY [1..MYMAX] OF INTEGER;
	        top,  mark : INTEGER;
		END; 

The error given by thecompiler is that T is undefined in the .i3 file.
I am not quite sure how to deal with this problem.  I am trying to avoid
using objects.  
	Could someone provide me with some useful suggestions?  I would
appreciate it and thanks in advance.

Ragini


======================================================================== 21 ===
Date:    Mon, 14 Oct 91 14:42:03 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: beginner wanting to know about opaque types

In article <RAGINIS.91Oct14151958@karp.albany.edu>, raginis@cs.albany.edu (Ragi
ni Shamsunder) writes:

> 	I just started working on Modula3 very recently and am having
> trouble figuring out opaque types.  I tried defining a stack in a separate
> module without disclosing the data structure.  Here is the INTERFACE:
> 
> INTERFACE stks;
> TYPE stack <: T;
> 
> PROCEDURE push(item : INTEGER; VAR s : stack);
> PROCEDURE pop(VAR item : INTEGER; VAR s : stack);
> PROCEDURE empty(s : stack) : BOOLEAN;
> 
> END stks.
> 
> and here is PART of the Module itself:
> 
> MODULE stks;
> 
> TYPE
> 	REVEAL stack = T;
> 	    T = BRANDED  REF RECORD
> 	        store : ARRAY [1..MYMAX] OF INTEGER;
> 	        top,  mark : INTEGER;
> 		END; 
> 
> The error given by thecompiler is that T is undefined in the .i3 file.
> I am not quite sure how to deal with this problem.  I am trying to avoid
> using objects.  
> 	Could someone provide me with some useful suggestions?  I would
> appreciate it and thanks in advance.

Here is a version that should work:

INTERFACE Stks;

TYPE T <: REFANY;

PROCEDURE Push (item: INTEGER; s: T);
...
END Stks.

MODULE Stks;
REVEAL T = BRANDED REF RECORD 
             store: ARRAY [1..MYMAX] OF INTEGER;
             top := 0;
             mark:= 0; END;

...

END Stks.


Note that a client of the stks interface can invoke NEW (Stks.T) (at
least in the latest version of the language).  If you can use the
initializers in the RECORD declaration, that's good enough.  You still
have to be careful to say what should happens in push and the other
procedures when s is NIL:
  - you can say that it is the responsability
    of the caller to ensure that s is non-NIL and not test for that case
    (unchecked runtime error).  
  - you can say that the implementation checks for s to be non-NIL and
    generates a runtime error (by calling RTMisc.FatalError) if it is
    not the case (checked runtime error). 
  - you can check and raise an exception.
  - you can check and allocate the stack (in which case, you need the
    argument to be VAR). 
  - you can provide a "new" procedure in the interface (see below).




Sometime, initialization through the type is not enough, and you need
to execute some code.  In those cases, you can add to the interface:

PROCEDURE New (): T;
  (* allocate a new, empty stack.  You must call this procedure to get
     a valid stks.T *)

and to the implementation:

PROCEDURE New (): T =
  VAR t: T;
  BEGIN
    t := NEW (T);
    (* whatever you need to do *)
    RETURN t;
  END New;

Clients just need to call "Stks.New ()" to get a valid stack.




If you want to use objects, here is a way I do it:

INTERFACE Stks;

TYPE Public = OBJECT METHODS
                new (): T;
                 (* allocate (self = NIL) or initialize (self # NIL) a T.
                    This method must be called before the other methods *)
                push (item: INTEGER);
                ...
              END;

     T <: Public;
...


MODULE Stks;

REVEAL 
   T = Public BRANDED OBJECT
         store : ARRAY [1..MYMAX] OF INTEGER;
	 top,  mark : INTEGER;
       OVERRIDES 
         new := new;
         push := push;
         ...
       END;

PROCEDURE new (self: T): T =
  BEGIN
    IF self = NIL THEN
      self := NEW (T); END;
        
    self.top := ...
    self.mark := ...
  
    RETURN self;
  END new;

Clients of that interface can say:

  t := Stks.T.new (NIL);

to allocate a new stack.  Or a subclass of Stks.T can say:

TYPE Subclass = Stks.T OBJECT ... METHODS ... OVERRIDES new := new; .... END;

PROCEDURE new (self: Subclass): Subclass =
  BEGIN
    IF self = NIL THEN 
      self := NEW (Subclass); END;

    EVAL Stks.T.new (self);

    (* other initialization specific to Subclass *)

    RETURN self;
  END new;

Note that the type Public is there is only to avoid retyping the
public part of the type in the module.  Also, note that I used the SRC
conventions for names (interface, module, procedure and type names
start with an uppercase; method names start with a lower case;
procedures that implement methods start with a lower case -- this last
bit is actually my own convention). 


Finally, the way of doing it with objects depends on the latest
version of the language (where you can call <object type>.<method name>);
this not the language implemented by SRC Modula-3 1.6, but
release 2.0 (to be available soon in a ftp directory near you) will do
that.  In the mean time, the module Stks can export the interface
StksDotT (in addition to Stks), with the procedure new in it:

INTERFACE StksDotT;
FROM Stks IMPORT T;
PROCEDURE new (self: T): T;
END StksDotT.

MODULE Stks EXPORTS Stks, StksDotT;
...
END Stks.

and clients of Stks can import it:

...
IMPORT Stks, StksDotT;
...
t := StksDotT.new ();
...

When 2.0 is available, you just need to change "StksDotT" to "Stks.T"
and to remove the StksDotT interface.


Don't hesitate to post more questions if that is not clear.

-- 
Eric.



======================================================================== 22 ===
Date:    15 Oct 91 06:21:12 GMT
From:    yeung@reed.edu (Woodrow Yeung)
Subject: MPW Modula-3

Has anyone done a port of Modula-3 to generate code for MPW C?  Thanks.

Woodrow Yeung
yeung@reed.edu
--
Woodrow Yeung
tektronix!reed!yeung            or  
tektronix!reed!lclark!yeung     or
tektronix!psu-cs!yeung


======================================================================== 23 ===
Date:    15 Oct 91 06:35:41 GMT
From:    mgallo@zeus.calpoly.edu (M. Gallo)
Subject: Re: OOPSLA '91 debriefing

In article <1991Oct13.205225.18497@bert.pinecreek.com> harbison@bert.pinecreek.
com (Sam Harbison) writes:
>Modula-3 and the Modula-3 books are important advantages. A PC
>compiler is still needed.  In my opinion, the academic community is
>ripe for a good teaching language like Modula-3.

What other implementations for Modula-3 are underway?  A PC version
would be great, but so would native code compilers.
-- 
                                                           _   /|
Miguel                                                     \'o.O'
mgallo@ares.calpoly.edu                                    =(___)=
"C is its own virus."                                         U


======================================================================== 24 ===
Date:    15 Oct 91 12:49:29 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: OOPSLA '91 debriefing

As has been mentioned here a number of times, my research group is developing
GNU Modula-3, which will provide optimized native code with the same
retargetability as the GNU C compiler (since a lot of the code between the two
compilers is shared). When finished, this will be released through the Free
Software Foundation under the usual GNU terms. If you're interested in seeing
it released sooner, get somebody to give us more money :-) ....
--

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


======================================================================== 25 ===
Date:    15 Oct 91 15:12:06 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Other Modula-3 compilers (was Re: OOPSLA '91 debriefing)

I have been in touch with organizations interested in doing Modula-3
compilers for PC's and other non-UNIX systems. Things are moving, but
you should not assume anything is close. Don't be discouraged
from doing a Modula-3 compiler yourself, whether for fun or profit.

There are now several people with Modula-3 compiler expertise.  These
people are willing to help experienced compiler builders deal with the
peculiarities of the Modula-3 language and run-time system, including
garbage collection.  With such help, a Modula-3 compiler and run-time
library should not be difficult to produce.

As is the case for other languages, an outstanding Modula-3 product
will also require good engineering and an effective set of
well-integrated tools. People who have succeeded in producing good
environments for other languages will succeed at Modula-3 also.

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


======================================================================== 26 ===
Date:    15 Oct 91 20:17:20 GMT
From:    tsai@Veritas.COM (Cary Tsai)
Subject: Any unix public domain Modula3 compiler ?

Hi:
I am new in this group. I would like to have a modula3 compiler on my
SYSV machine (i386). Is any public domain modula3 compiler available on
the i386 SYSV system ? DO any manuals or books talk about this language ?


======================================================================== 27 ===
Date:    Tue, 15 Oct 91 14:21:48 PDT
From:    muller@src.dec.com (Eric Muller)
Subject: Re: beginner wanting to know about opaque types

A few more words on the subject:

With a declaration such as:

  TYPE  T <: ROOT; U <: REFANY;

both types T and U are known to be traced references.  T is known to
be an object type, U may be an object type, may be not.  In both
cases, it is legal for a client of an interface that has those
declarations to invoke NEW on theses types.  The function of NEW,
which is to allocate storage in the traced heap, does not really
differ when allocating a REF or an OBJECT (of course, different things
have to be done).


My example used the OVERRIDES keyword in object types.  You may have SRC
Report # 52: "Modula-3 Report (revised)", November 1, 1989.  This is
the language implemented by SRC Modula-3 1.6 (modulo bugs).  In that
language, the syntax does not make the distinction between:

   TYPE foo = bar OBJECT METHODS
                n () := N;
                m    := M; END;

and 

   TYPE foo = bar OBJECT METHODS
                n () := N; 
                m () := M; END;

very apparent.  The first syntax means that the default value for
method 'm' for objects of type foo is M.  The second syntax means that
the type foo introduces a new method, 'm', that takes precedence over
any method 'm' that may have been declared for the type bar.
Pages 13 and 14 of the report describes this difference.

Since that report, 'twelve changes' have been made to the definition
of the language.  One of them is to have a syntax that makes theses
cases more apparent:

   TYPE foo = bar OBJECT METHODS
                n () := N;
              OVERRIDES 
                m := M; END;

and 

   TYPE foo = bar OBJECT METHODS
                n () := N;
                m () := M; END;

The 'twelve changes' have been described in a message sent to
comp.lang.modula3 by Greg Nelson.  They also have been integrated in
the definition of the language, as it appears in:

	Systems Programming with Modula-3
	Greg Nelson, Ed.
	Prentice Hall
	ISBN 0-13-590464-1

We are working on SRC Modula-3 2.0 that will implement this new
definition of the language.



The main mechanism for input/output is implemented by the Rd and Wr
interfaces.  Roughly, a Rd.T is a thing you can get characters from,
and a Wr.T is a thing you can send characters to.  There are various
kinds of readers and writers; some of them are connected to files (see
the Filestream and Stdio interfaces), some are connected to texts (see
the TextRd and TextWr interfaces).  Also, the Fmt and Scan interfaces
are used to transform numbers into texts and back.
            
-- 
Eric.



======================================================================== 28 ===
Date:    Tue, 15 Oct 91 16:02:56 PDT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: beginner wanting to know about opaque types

In article <1991Oct15.142148.15303@src.dec.com>, muller@src.dec.com (Eric Mulle
r) writes:
> A few more words on the subject:
> 
> With a declaration such as:
> 
>   TYPE  T <: ROOT; U <: REFANY;
> 
> both types T and U are known to be traced references.  T is known to
> be an object type, U may be an object type, may be not.  In both
> cases, it is legal for a client of an interface that has those
> declarations to invoke NEW on theses types.  The function of NEW,
> which is to allocate storage in the traced heap, does not really
> differ when allocating a REF or an OBJECT (of course, different things
> have to be done).
> 
> 

This is not quite right. As its says on p53 of Systems Programming in Modula-3,
"If T is declared to an opaque type, NEW(T) is legal only in scopes where T's
concrete type is known completely or is known to be an object type."

So, with the above declarations, a client can NEW(T), but not NEW(U).
I.e. "U <: REFANY" is a pure abstract data type. Only clients that "know"
either the complete revelation (REVEAL U = ...) or a partial revelation
that shows U to be an object type (e.g. REVEAL U <: ROOT) can effect
a NEW(U). 

Mick Jordan




======================================================================== 29 ===
Date:    15 Oct 91 12:46:56 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: beginner wanting to know about opaque types

In article <RAGINIS.91Oct14151958@karp.albany.edu> raginis@cs.albany.edu (Ragin
i Shamsunder) writes:

   Hi,
	   I just started working on Modula3 very recently and am having
   trouble figuring out opaque types.  I tried defining a stack in a separate
   module without disclosing the data structure.  Here is the INTERFACE:

... bunch of code omitted ...

   I am trying to avoid using objects.  

Why avoid using objects? Are you afraid they'll cost too much or something? I
doubt you'll notice any performance difference in a significant program ....
--

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


======================================================================== 30 ===
Date:    Thu, 17 Oct 91 10:39:35 BST
From:    Simon Hood (Maths) <simon@vortex1.exeter.ac.uk>


Am currently running Modula-3 on a Sun SPARC station.  I have successfully 
linked to the C suncore graphics routines, however this does not appear to
contain printer support.

We have Uniras which does, unfortunately its all written in Fortran(?!) and
so to use its printer support routines would mean either linking M3 or C to
Fortran.

Can anyone help with this, or offer any other suggestions?

Simon.


======================================================================== 31 ===
Date:    17 Oct 91 10:46:06 GMT
From:    liam@dcs.qmw.ac.uk (William Roberts)
Subject: Re: Experiences etc using Modula-3 for teaching

In <1991Oct11.150636.17852@watmath.waterloo.edu> dduggan@plg.waterloo.edu 
(Dominic Duggan) writes:

>I'm interested in hearing people's experiences/advice/opinions on using
>Modula-3 in a third-year undergrad computer systems course.

We have just started using Modula-3 (1.6) as a first programming language for 
undergraduate computer science. Actually , we teach two parallel first 
programming courses: "Imperative Programming" which uses Modula-3, and 
"Functional Programming" which uses Miranda. Both of these are being run on 
Mac IIcx workstations running A/UX (I did get M3 more or less working). 

The attraction of Modula-3 is that it will hold up across our entire course: 
it can be used for the Software Engineering course in the second year, and 
students wishing to use it for project work can still get at all of the system 
calls, X libraries etc that they might want.

My main criticism so far is that the m3 compiler does very little to help you 
if you do something wrong which isn't detected within a single compilation 
unit. Worse still, it exposes all its gory implementation innards by letting 
other programs try to report the problem. Here is a recent example:
-----------------
>I seem to be experiencing a problem with the Modula 3 compiler, eg:
>
>> m3 List.i3
>ld: Symbol M3_LINKPROC_IList in
>/import/exampleexec/exec/lib/m3/core/libm3core.a
> is multiply defined. First defined in 00152000_i.o
>ld fatal: Error(s). No output written to a.out
>linking

The Modula3 compiler isn't very clever about a number of things, including
picking up libraries automatically and resolving module name clashes. The
important line in the above message is:

>ld: Symbol M3_LINKPROC_IList in

The "M3_LINKPROC_I" prefix is just part of how M3 gets the normal UNIX linker
to stick all the bits together, and the bit that interests you is the rest of
the symbol, namely List.

You have defined a module called List and imported it, but this in turn
imports various other things which import the M3 system's own implementation
of List. The compiler would have told you earlier and more intelligibly if it
recursively examined all the .i3 files involved, but it doesn't and so things
only go wrong at the linking stage.
-----------------

I might also add that the m2imc tool doesn't notice the PASS3 stuff about nm 
in the config file when you build it, so that doesn't work under A/UX at all.

Reflecting briefly on the use of two different Modula-2 systems in previous 
years, the strengths of those systems relative to the M3 implementation we are 
using are as follows:

1) Ana Systems Modula-2 

This had awful bugs in it and almost no access to C libraries, but it had its 
own linker which collected automatically all the modules implied by the main 
module, scanning a traditional sort of search path to find them and doing the 
validity checks on timestamps embedded in the files. The strength of this was 
that students get sensible messages about the kinds of conflicts illustrated 
above, messages which are meaningful in terms of the Modula-2 language.

2) Cambridge Modula-2

This had much better interfaces to C libraries etc, but generated native 
ns32000 code and nobody here felt like retargeting it to 680x0. The best 
feature of this system was a utility called m2make which generated Makefiles 
for you. I believe it did significant consistency checking as well, but it was 
a few years ago now so I can't remember for certain.


Thinking about m3 1.6, I can't currently see the value of m3ar. It produces 
nice little readable files called libthing.ma, but there is no evidence of 
anything else in the system actually looking at those. The m3 program itself 
certainly doesn't change the list of -l directives at all: it puts in a fixed 
list defined when it was compiled, whether you need them or not.

In summary: m3 1.6 is not expected to be fun to support as a first teaching 
language, because its overall module consistency checking is a side-effect of 
standard linking rather than an explicit part of the system and hence 
generates deeply unhelpful error messages. m3 requires its own checking stage 
at link time (possibly earlier as well), which should also remove the need to 
call every top-level module Main and to specify all of the .io and .mo files 
to be linked. 

--

% William Roberts                 Internet:  liam@dcs.qmw.ac.uk
% Queen Mary & Westfield College  UUCP:      liam@qmw-dcs.UUCP
% Mile End Road                   Telephone: +44 71 975 5234
% LONDON, E1 4NS, UK              Fax:       +44 81-980 6533


======================================================================== 32 ===
Date:    Thu, 17 Oct 91 13:15:56 PDT
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: Experiences etc using Modula-3 for teaching

In article <3883@redstar.dcs.qmw.ac.uk>, liam@dcs.qmw.ac.uk (William Roberts) w
rites:
> In <1991Oct11.150636.17852@watmath.waterloo.edu> dduggan@plg.waterloo.edu 
> (Dominic Duggan) writes:

> My main criticism so far is that the m3 compiler does very little to help you
 
> if you do something wrong which isn't detected within a single compilation 
> unit. Worse still, it exposes all its gory implementation innards by letting 
> other programs try to report the problem. 

Bill or Eric will undoubtedly comment individually on your message, but 
to do what you ask requires a pre-linker, which the 2.0 implementation has.
As an aside, in the now-defunct Olivetti implementation, we had a pre-linker
that used compiler generated ASTs as input. It could and did give very
detailed messages on version mismatches and missing procedures etc.
[In fact for the latter it generated a stub procedure that raised an
exception if called at run-time].


> 2) Cambridge Modula-2
> 
> This had much better interfaces to C libraries etc, but generated native 
> ns32000 code and nobody here felt like retargeting it to 680x0. The best 
> feature of this system was a utility called m2make which generated Makefiles 
> for you. I believe it did significant consistency checking as well, but it wa
s 
> a few years ago now so I can't remember for certain.
> 

The remnants of the Olivetti implementation, which includes the Modula-3 versio
n 
of the "m2make", is available from SRC as part of the Modula-3 toolkit.
Its called "m3tk" and lives on gatekeeper.dec.com in the Modula-3 directory.
It does include checking part of the pre-linker tool but, owing to its memory
needs, probably isnt suitable in a teaching environment.

If you liked the Cambridge Modula-2 libraries, which I wrote a large part of, 
you might like to check out the libraries that come with the toolkit, since the
y 
are based more on the Cambridge model. They essentially evolved out of the
Modula-2 versions. 

Mick Jordan




======================================================================== 33 ===
Date:    21 Oct 91 15:47:34 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Getting Nelson's book

From time to time I get mail from people in the USA and abroad
looking for Nelson's "Systems Programming with Modula-3."  Although
the book should now be available in most US bookstores, a few people
are still having trouble finding it. I have been taking orders, but
selling books is not my line of business, so...

By special arrangement, Total Information, Inc. of Rochester, NY has
agreed to keep Nelson's book in stock and to provide 24-hour
turnaround on book orders. To order, call 1-800-876-4636 or FAX (716)
254-0153. They ship books world-wide and handle a full range of
science and technology books.

I can't yet personally vouch for their service, so I'd appreciate
receiving reports from people who order from them.

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


======================================================================== 34 ===
Date:    23 Oct 91 17:15:10 GMT
From:    kirschne@Informatik.TU-Muenchen.DE (Kirschner)
Subject: Nelson's book's Trestle Window System, where is it ?

Dear Netfellows,

please help me with this problem: 
I lack much experience with Modula-3 programming, but I just managed 
to get a copy of Greg Nelson's "System Programming with Modula-3" 
(Prentice Hall, ISBN 0-13-590464-1). So far, so good.

I have the SRC Modula-3 distribution Version 1.6, which is the latest
available, as far as I know. It installed perfectly on my DEC 5000/200
and all the demos run just fine. I use Ultrix 4.2 with X11R4.

Now I wanted to start programming with M3, and to get catchy results
I chose (X)Windows as an interesting playground. I didn't read through
to whole book yet, but I figured that Nelson covers the subject in his 
Chapter 7 "Trestle Window System Tutorial". On page 171 he says:
"... To use Trestle, you need a copy of SRC Modula-3 and an X server for
your system.[...] They {i.e., the example programs} are in the
trestletutorial directory of the Modula-3 distribution."

Well, I searched through my whole distribution, but I cannot find anything
named Trestle or trestletutorial. All the X11R4-stuff I can see is stored
in dist-1.6/demos/X11R4. But it's all a port of the MIT XConsortium's
demos, done by Chris D. Peterson using the SRC Xt Interface.

The long explained question is: Where can I find this Trestle Window System ?

I think the rest of the Interfaces like Text, Thread, etc. described in
Nelson's book are as provided with my copy of the distribution, but I
haven't checked that yet, either.
( Is there any literature describing the Interfaces to X in this SRC M3
distrib., i.e. Xt, Xaw ? I guess there just a 1:1 port of their equivalences 
in C. )

Can anybody help me ? I'd be very glad, and thank you in advance, too.

Torsten


======================================================================== 35 ===
Date:    Wed, 23 Oct 91 13:23:03 PDT
From:    <gnelson@src.dec.com>
Subject: Re: Nelson's book's Trestle Window System, where is it ?


Torsten Kirschne asks where Trestle is.

You can copy Trestle from

     /archive/pub/DEC/Modula-3/trestle.tar.Z

which is on gatekeeper.  What you find will differ slightly from 
the version in the book (in particular, it is compatible with version 
1.6 of the compiler, while the book version is compatible with version 
2.0 of the compiler).   You can do all the exercises in the book 
except Mouse Hockey.

Greg Nelson





======================================================================== 36 ===
Date:    Thu, 24 Oct 91 09:10:03 PDT
From:    msm@src.dec.com (Mark S. Manasse)
Subject: Re: Nelson's book's Trestle Window System, where is it ?

If you try to experiment much with Trestle beyond what's
in the tutorial in the book, you'll soon discover that 
there are lots of problems; we're working on a new release
that should fix most of them.  In particular, there are 
some quite trivial errors that make fonts and pixmaps hard
to use.

Mark




======================================================================== 37 ===
Date:    25 Oct 91 09:16:54 GMT
From:    collberg@dna.lth.se (Christian S. Collberg)
Subject: Three questions

1) When is the SRC version 2.0 compiler expected to be released?

2) There was talk earlier that the 2.0 release would include a
   pre-linker. Can someone give a brief description of its
   functionality?

3) Why doesn't the Pickle interface include procedures
   "ToBytes" and "FromBytes", i.e. procedures to
   pickle an object into a bytestring and to unpickle
   a bytestring into an object? That would be handy
   when doing remote procedure calls, for example.

Christian



-- 

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


======================================================================== 38 ===
Date:    26 Oct 91 19:16:05 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Why I like Modula3 (C++ libraries)

Well, it came to pass that I was cruising some of the OOP libraries
for C++, looking for some good ideas for Modula-3 libraries.

What I found was that many of these libraries devote a lot of effort
to providing what Modula-3 gives you right out of the box:
bounds-checked arrays, run-time type checking, generics, exceptions,
threads, etc. (Since exceptions and generics aren't yet standard in
C++, the libraries that are out now involved roll-your-own versions.)

These fundamentals turn out to be very complex and underly all the
higher-level libraries, making those yet more obscure.  (For example,
a list package is pretty straightforward--until you see that it's
built on top of the run-time type class and the generic class.)  To
get a productivity improvement, you have to build all your own classes
on top of these underpinnings, too. Thus, not only is the language C++
more complicated than M3, but your own classes get more complicated.

So, after stripping away all the things I don't need in Modula-3, it turns
out there wasn't much else. I guess I'll check back in a year or so...

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


======================================================================== 39 ===
Date:    27 Oct 91 16:22:42 GMT
From:    bytor@ctt.bellcore.com (Ross Huitt)
Subject: Re: Why I like Modula3 (C++ libraries)

In article <1991Oct26.191605.1257@bert.pinecreek.com> harbison@bert.pinecreek.c
om (Sam Harbison) writes:
...
>What I found was that many of these libraries devote a lot of effort
>to providing what Modula-3 gives you right out of the box:
>bounds-checked arrays, run-time type checking, generics, exceptions,
>threads, etc. (Since exceptions and generics aren't yet standard in
>C++, the libraries that are out now involved roll-your-own versions.)

IMNSHO, the biggie is garbage collection. C++ is the only OO language I've
used without GC and it has caused me more heart-aches and more wasted
hours than the lack of generics or exceptions.

>
>These fundamentals turn out to be very complex and underly all the
>higher-level libraries, making those yet more obscure.  (For example,
>a list package is pretty straightforward--until you see that it's
>built on top of the run-time type class and the generic class.)  To
>get a productivity improvement, you have to build all your own classes
>on top of these underpinnings, too. Thus, not only is the language C++
>more complicated than M3, but your own classes get more complicated.

One thing I find myself doing over and over and over again is creating
a slew of infrastructure classes for each implementation class to provide
support for run-time typeinfo, typesafe callbacks, implementation-specification
separation, etc... (Of course I do have some hand-dandy macros to simplify the
process.) If you take the time to read comp.lang.c++ you will constantly
see exchanges like:

Q: How do I implement [some useful mechanism that could easily be accomplished
	in 1 line of Smalltalk]?

A: Well, first you have to create another class....

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


Ross Huitt
bytor@ctt.bellcore.com
(908) 699-2973


======================================================================== 40 ===
Date:    Sun, 27 Oct 1991 15:31:04 GMT
From:    eric@tfs.com (Eric Smith)
Subject: Re: Why I like Modula3 (C++ libraries)

In article <1991Oct26.191605.1257@bert.pinecreek.com> harbison@bert.pinecreek.c
om (Sam Harbison) writes:
>Well, it came to pass that I was cruising some of the OOP libraries
>for C++, looking for some good ideas for Modula-3 libraries.
>
>What I found was that many of these libraries devote a lot of effort
>to providing what Modula-3 gives you right out of the box:
>bounds-checked arrays, run-time type checking, generics, exceptions,
>threads, etc. (Since exceptions and generics aren't yet standard in
>C++, the libraries that are out now involved roll-your-own versions.)
>
>These fundamentals turn out to be very complex and underly all the
>higher-level libraries, making those yet more obscure.  (For example,
>a list package is pretty straightforward--until you see that it's
>built on top of the run-time type class and the generic class.)  To
>get a productivity improvement, you have to build all your own classes
>on top of these underpinnings, too. Thus, not only is the language C++
>more complicated than M3, but your own classes get more complicated.
>
>So, after stripping away all the things I don't need in Modula-3, it turns
>out there wasn't much else. I guess I'll check back in a year or so...
>
>Sam Harbison 
>Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213;
>USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com.


Modula 3 sounds good, but will it work on my computer?  One big
advantage of C++ is that it is ubiquitously available.  With
Zortech C++ Version 3, I can use a cheap but very powerful computer
based on a 486/33.  This computer will accept 64 megabytes of low
cost high speed SIMM memory modules.  The total cost of the whole
system is low enough that most programmers can buy it out of their
salary, and use it at home in their spare time.  That is the kind
of thing that builds grass roots support for a programming language.

Besides, the complexity of the classes is not really a problem.  The
whole purpose of object oriented programming is to make complexity
trivial.  Programmers can ignore the complexities and just access
the public interface of each class they use.

However, if there is some easy way to get Modula 3 to work on this
computer, I am willing to give it a try.  Just like I'm willing to
give Eiffel a try.  I also tried Smalltalk, but I was put off by
the fact that I couldn't use more than 16 megabytes of memory with
the version I tried.  So far, I haven't found anything that beats
C++ in the ways that are important to me.


======================================================================== 41 ===
Date:    Mon, 28 Oct 91 09:06:42 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Nelson's book's Trestle Window System, where is it ?

> You can copy Trestle from
> 
>      /archive/pub/DEC/Modula-3/trestle.tar.Z
> 
> which is on gatekeeper.

That is, you can use anonymous ftp and look in

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

-- 
Eric.


======================================================================== 42 ===
Date:    29 Oct 91 03:25:14 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Modula-3 on PCs (was: Re: Why I like Modula3 (C++ libraries))

In article <1991Oct27.153104.705@tfs.com> eric@tfs.com (Eric Smith) writes:
>
>Modula 3 sounds good, but will it work on my computer?  ...
>...

Indeed, the absence of a good Modula-3 on PC's is a problem. Many of us are
trying hard to correct that problem. SRC Modula-3 2.0 may be more easily
portable to PC's, and there are other Modula-3 implementations under
way and anticipated. Stay tuned...

Sam


======================================================================== 43 ===
Date:    29 Oct 91 22:03:28 GMT
From:    phillip@cs.uow.edu.au (Phillip McKerrow)
Subject: Re: Modula-3 on PCs (was: Re: Why I like Modula3 (C++ libraries))

Is there a Modula 3 available for the Macintosh yet?

Phillip McKerrow
University of Wollongong
Australia


======================================================================== 44 ===
Date:    30 Oct 91 04:49:33 GMT
From:    warwick@cs.uq.oz.au (Warwick Allison)
Subject: Re: Modula-3 on PCs (was: Re: Why I like Modula3 (C++ libraries))

phillip@cs.uow.edu.au (Phillip McKerrow) writes:

>Is there a Modula 3 available for the Macintosh yet?

From what I've seen of the code, it is TRIVIAL to port it - once you can
find the space to build one of the base implementations.

>Phillip McKerrow
>University of Wollongong
>Australia

Cool - my birthplace!

Ciao,
Warwick.
--
  _-_|\       warwick@cs.uq.oz.au
 /     *  <-- Computer Science Department,
 \_.-._/      University of Queensland,
      v       Brisbane, AUSTRALIA.


======================================================================== 45 ===
Date:    28 Oct 91 20:10:00 GMT
From:    matt@emtek.UUCP (Matt Meola)
Subject: Re: Three questions


Is Modula-3 available to the public in source-form?  If so, then how
can one who doesn't have FTP access get it?  I would VERY much like to
investigate modula-3; I currently program in C++, and I love it.  If
Modula-3 looks better, I'll switch!

collberg@dna.lth.se (Christian S. Collberg) writes:
: 1) When is the SRC version 2.0 compiler expected to be released?
: 
: 2) There was talk earlier that the 2.0 release would include a
:    pre-linker. Can someone give a brief description of its
:    functionality?
: 
: 3) Why doesn't the Pickle interface include procedures
:    "ToBytes" and "FromBytes", i.e. procedures to
:    pickle an object into a bytestring and to unpickle
:    a bytestring into an object? That would be handy
:    when doing remote procedure calls, for example.
: 
: Christian
: 
: 
: 
: -- 
: 
: Christian.Collberg@dna.lth.se
: Department of Computer Science, Lund University, 
: BOX 118, S-221 00 LUND, Sweden


------------------------------------------------------------------
Matt Meola                             UUCP: uunet!emtek!matt
Emtek Health Care Systems, Inc.        Phone: (602) 431-9071 x3057
2929 South Fair Lane                   Fax:   (602) 431-9074
Tempe, Arizona 85282


======================================================================== 46 ===
Date:    Wed, 30 Oct 91 08:09:53 PST
From:    <kalsow@src.dec.com>
Subject: Re: Three questions

>  1) When is the SRC version 2.0 compiler expected to be released?

Most of the groups here at SRC have already switched to using 2.0.
We'll make it available for FTP as soon as we can.

>  2) There was talk earlier that the 2.0 release would include a
>     pre-linker. Can someone give a brief description of its
>     functionality?

Yes, 2.0 includes a pre-linker, 1.6 does too.  The 2.0 prelinker
checks inter-module consistency, determines the module initialization
order and allocates some data structure for the runtime type system.
The 1.6 system does all of these things as well, but in a much slower
and more fragile way.

>  3) Why doesn't the Pickle interface include procedures
>     "ToBytes" and "FromBytes", i.e. procedures to
>     pickle an object into a bytestring and to unpickle
>     a bytestring into an object? That would be handy
>     when doing remote procedure calls, for example.

Use the TextWr and TextRd modules to get memory buffered
I/O streams.  Pickle doesn't care what type of stream you
hand it.

  - Bill Kalsow


======================================================================== 47 ===
Date:    30 Oct 91 17:05:50 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Modula-3 source for non-FTP sites (was Re: Three questions)

In article <228@emtek.UUCP> matt@emtek.UUCP (Matt Meola) writes:
>
>Is Modula-3 available to the public in source-form?  If so, then how
>can one who doesn't have FTP access get it?  
> ...

Yes, source is provided in the standard distribution from ftp site
gatekeeper.dec.com in pub/DEC/Modula-3/...

If you have a computer to which Modula-3 has been ported, but not FTP
access, I can provide the SRC distribution on seven 3.25", 1.4meg
PC-compatible floppy disks. The software includes Trestle, m3tk, SRC
Modula-3, and the Modula-3 report. These disks contain the original,
unmodified SRC software distributions. The binary .Z files are split
into pieces (if necessary) and encoded with uuencode. Unpacking
instructions are included.

There is a $50 charge for the disks, plus a shipping and handling fee
($6.00 in the US).

European customers: We expect that this software will be available 
through Real Time Associates in the UK soon. Details will be posted
as soon as they are available.

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


======================================================================== 48 ===
Date:    Wed, 30 Oct 91 15:43:51 PST
From:    harrison@gossamer.pa.dec.com (Stephen Harrison)
Subject: Re: Three questions

In article <9110301610.AA17597@jumbo.pa.dec.com>, kalsow (Bill Kalsow) writes:
>>  3) Why doesn't the Pickle interface include procedures
>>     "ToBytes" and "FromBytes", i.e. procedures to
>>     pickle an object into a bytestring and to unpickle
>>     a bytestring into an object? That would be handy
>>     when doing remote procedure calls, for example.
>
>Use the TextWr and TextRd modules to get memory buffered
>I/O streams.  Pickle doesn't care what type of stream you
>hand it.

Yes it does, unfortunately.  The stream passed to Pkl.Write has to be
seekable.  TextWr's are not.

Cheers,

/Stephen


======================================================================== 49 ===
Date:    30 Oct 91 21:59:23
From:    vixie@decwrl.dec.com (Paul A Vixie)
Subject: SRC M3 GC question

I'm thinking of writing a real-time application in SRC Modula-3 and I'm
concerned about the garbage collection.  What I'm worried about is that
my program will periodically stop collecting/forwarding data while it
runs through the traced heap throwing out the trash.

I know that the SRC M3 GC is based on Joel Bartlett's incremental "mostly
copying" GC, but what I don't know is how often the generated code in 1.6
will call the GC.

I am willing to do a little bit of housekeeping to remove the nastier
trash by hand, but I don't see a RELEASE() anywhere.

I'm also willing to run the GC at times which are convenient for me (that
is, when I expect my data source to be quiescent for a few milliseconds),
but I don't know where the hook is to run the GC and I don't want to go
looking for it lest I end up calling something that disappears in 2.0.

Help?
--
Paul Vixie, DEC Network Systems Lab
Palo Alto, California, USA           "Be neither a conformist or a rebel,
<vixie@decwrl.dec.com> decwrl!vixie   for they are really the same thing.
<paul@vixie.sf.ca.us>  vixie!paul     Find your own path, and stay on it." (me)


======================================================================== 50 ===
Date:    31 Oct 91 07:28:21 GMT
From:    n8243274@henson.cc.wwu.edu (steven l. odegard)
Subject: M3 for 8088

I am investigating the possibility of organizing an enterage to
complete a native-code M3 compiler for the 8088 PC.  I have decided to
write this in Modula-3 (of course) and plan to begin springtime or when
M3 2.0 is publicly available.

I now request opinions for some major design decisions.

The goal will be efficiency of implementation, speed of compilation, and
security of the final product.  Is there on-line documentation available
for writing for the Microsoft Linker, or would I be better off designing
my own linker system?

'Shared' run-time libraries are a must.  It will be intolerable to produce
Megabytes of code to output short messages.  Furthermore, it will be
necessary to support parameter passing to the operating system and routines
written in other PC languages.  Is there on-line documentation of calling
conventions?

I will first be designing my own assembler to 8088 code written as a
Modula-3 library (bottom up), and a Modula-3 parser to an internal structure
(top down).  Would it be an advantage to use one of the RISC architectures
as an internal code representation?  Furthermore, I would like to incorperate
into the design formal verification techniques and an extended pragma set for
rapid evolutionary development, a software development technique and
paradigm I am now formulating.

May I request anyone interested in discussing any of these issues to
email me here at n8243274@henson.cc.wwu.edu.  What I have outlined is
exactly the state of the development now.

					S Lee ODEGARD
					n8243274@henson.cc.wwu.edu


======================================================================== 51 ===
Date:    Thu, 31 Oct 91 09:42:57 PST
From:    <root@src.dec.com>
Subject: Re: SRC M3 GC question

SRC Modula-3 only invokes the garbage collector as a side-effect 
of NEW.  If your real-time critical loops don't do a NEW, they won't 
trigger a collection.  Alternatively you can call RTHeap.DisableCollection
and RTHeap.EnbleCollection to temporarily suspend collections.

You can force a garbage collection by calling RTHeapRep.CollectNow.

The RTHeap and RTHeapRep interfaces are essentially unchanged
between version 1.6 and 2.0.

  - Bill Kalsow


======================================================================== 52 ===
Date:    Thu, 31 Oct 91 15:04:59 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: M3 for 8088

In article <1991Oct31.072821.16552@henson.cc.wwu.edu>, steven l. odegard 
writes:

> May I request anyone interested in discussing any of these issues to
> email me here at n8243274@henson.cc.wwu.edu.  What I have outlined is
> exactly the state of the development now.

Given the interest that has been manifested in the past about PC
implementations of Modula-3, you may want to have the discussion in
comp.lang.modula3.  

eric.



======================================================================== 53 ===
Date:    Thu, 31 Oct 91 21:03:19 -0800
From:    Paul A Vixie <vixie@src.dec.com>
Subject: strange Wr bug (was Re: SRC M3 GC question )

Thanks for your help.  Knowing that RTHeap is not going to change much in 2.0
pretty much tells me what I need to know.  I got several other answers but I
would rather not use DISPOSE() if it means I have to use untraced refs. 

Anyway, I have a new quandry.  I'm co-authoring a Datagram interface to make
UDP sockets available to M3 applications.  I found RTScheduler.IOSelect and
followed the suggestions in its .i3 file; everything seems to work with send()
but when I got around to recv() I was never waking up out of IOSelect().  I
eventually got around to adding a Wr.PutText(Stdio.stdio, mumble) just before
the IOSelect(), but I forgot that stdout is buffered so I got no output before
the program hung in IOSelect() as it had been doing.  So I added a Wr.Flush()
between Wr.PutText and RTScheduler.IOSelect(), and not only did I get my
debugging output, the program stopped hanging and I got my recv() data!  So
I took out the Wr.PutText() and left in the Wr.Flush(Stdio.stdout), and it
still works fine -- even though there is never anything to flush.

Have I tickled a bug, or is there something I should be doing to make IOSelect
work as its .i3 advertises?  I'm willing to call more things, but Wr.Flush()
seems like the wrong way to unwedge my socket select.  Here's the code:

PROCEDURE Receive(self: T; data: REFANY; size: INTEGER): INTEGER =
VAR
	cc: INTEGER;
	fds: CoreOS.FDSet;
BEGIN
	LOCK self DO
	    LOOP
		cc := Usocket.recv(self.socket,
				LOOPHOLE(data, ADDRESS), size, 0);
		IF cc < 0 AND Cerrno.errno # CoreOS.EWOULDBLOCK THEN
			Net.Error();
		ELSIF cc >= 0 THEN
			RETURN cc;
		END;
		fds := CoreOS.FDSet{self.socket};
		(* XXX SHOULD NOT be nec'y but otherwise we block in select *)
		Wr.Flush(Stdio.stdout);
		(* XXX *)
		EVAL RTScheduler.IOSelect(self.socket+1, ADR(fds), NIL, NIL);
	    END;
	END;
END Receive;

I'm using the M3 from /proj/cra.

Thanks,

Paul Vixie
DEC NSL


